J-Crypt is an easy-to-use, secret-key encryption program.

To use, simply "drag and drop" a file onto J_Crypt.exe. This will cause JCrypt to launch. The choices are to encrypt, unencrypt, or calculate hash for the file. The ‘dropped’ file will not be modified. Encrypted files carry the JKC extension. When encrypting, if the file "root.jkc" already exists, it will be overwritten with the newly encrypted data. When unencrypting, the file will not be written if the file cannot be authenticated. The decrypted file will have the original filename, unless a file with the original filename already exists in the target directory, in which case the unencrypted file will be named: originalfilename_unencrypted.

Overview of encryption scheme:

1. hash password
2. hash file
3. combine 1 & 2
4. use 3 to seed the PRNG. PRNG consists of a "rule30 cellular automata". Size of automata is 65536 bits by default, but is adjustable.
5. initialize the PRNG. Initialization vector is set to AUTO by default...notes the time, then steps the system forward until the number of cycles = the system bit-width. Next, the time is checked, and the system continues updating until 0.5 secs has passed, or, if it already took more than 0.5 secs, then it continues updating for an additional 0.1 seconds. If Initialization is not AUTO, then the automata is simply stepped forward according to the Init Vector.
6. PRNG output is a subset of the automata...every 1 out of every x bits is returned. x = 8 by default, but is adjustable.
7. file is encrypted by XORing with the PRNG output.
8. hash the encrypted file
9. combine 1 & 8 and use as in step 4 to seed a new PRNG
10. initialize this new PRNG using the total number of steps used in 5 as the initialization vector
11. encrypt 8 and the original filename with the output of the new PRNG
12. write encrypted file consisting of header parameters (offset to encrypted file, system bit size, ‘x’ (see 6 above), initialization vector), encrypted header(filename, hash of original file), encrypted file(the original file)

The point of this rigmarole is to 1) prevent an attacker, who has both plaintext and cyphertext copies of a given document, from gaining insight about the contents of other files encrypted using the same password 2) allows the file to be authenticated 3) makes a dictionary attack costly, as it will take a minimum of 0.5 seconds to try each password (assuming the attacker’s computer is of comparable speed to that used to encrypt).

The generator is a "Rule30" cellular automata where each cell is updated in parallel according to it’s neighborhood. "Rule30" is simply:

(00011110 = 30, thus the name. There are 256 possible nearest neighbor rules...for 1d binary cellular automata.)

The default generator is a 65536 bit system with wrapping boundary conditions. The system is held in an array. If you consider the array as column of 32-bit words, and you represent each word in it’s binary form, then starting at the top of the column, the automata consists of the first bit of each word, followed by the second bit of each word, followed by the third bit of each word, etc. A consequence of this is that adjacent bits in the array are 2048 bits (default values) apart in the automata. This setup is used for efficiency of implementation, rather than for obfuscation.

The generator returns a subset of the automata as it’s output. The output is columns of the automata, skipping every other bit in each column, with adjacent columns spaced and out of phase with each other. To visualize this, imagine the bits of the automata laid out in a row, and the space between columns is 4. Starting with the first bit, mark every 8th bit for output, then update the system to create a new row. On this row, starting on the 4^th bit, mark every eighth bit for PRNG output then update the system. On this third row, you again start at the first bit and mark every eighth bit for PRNG use. The spacing between adjacent bits is user adjustable, with a default value of 16.

It is difficult to gain much insight regarding the contents of the hidden cells based on the content of cells revealed in this manner. This coupled with the fact that the "Rule30" system is inherently chaotic and lossy (1-way) from one row to the next provide for the strength of this system as a random number generator.

It is difficult to measure the cycle length of such a system containing n-bits that is larger than about n = 60 bits wide. For the smaller sizes (n = 8, 16, and 32) the cycle length varies considerably depending on the initial condition. Most initial conditions lead to cycle lengths on the order of 2^(0.75n), but some short-cycle initial conditions exist that produce repeat cycles on the order of 2^(0.25n). For the small systems, the short-cycles appear for about 5% of the initial conditions. If the short-cycle trend persists for the larger systems, then we might expect a short cycle of 2^16384. Since the system returns 512 bytes per iteration, we might expect, the system to repeat after outputting about 10^4900 GB of data. If the system is not "short-cycle seeded", we might expect the system to produce 10^14500 GB of data before repeating. However, testing the accuracy of these numbers is non-feasible.

In analyzing the output stream from this system using the "Diehard2" (analyzes 300MB of data), I have found that systems need to be sized around 12,000 in order to show no bias in all the tests. I use the larger size of 65536 (an array of 2048, 32-bit words) simply because modern computers can handle this size data array easily and efficiently, and using a larger size offers a slight speed increase, since the calls to update the system don’t have to be made so often.

Please do not use this software for any illegal purposes.

J_Crypt is available at:

Joe Campbell

jkc8289 at bellsouth dot net

J_Crypt assumes that the native word size is 32-bits. The program was written and tested on a little-endian machine, but I have attempted to make it endian neutral. However, as I do not have access to a big-endian machine, its big-endian behavior is untested. I would appreciate feedback about this.

I’d like to acknowledge the efforts of Stephen Wolfram (author of A New Kind of Science) for his work with 1d cellular automata.

V01.0.1.0 12-01-03

speed increase, Interface adjustment, changed timers display

V01.0.0.9 11-26-03

Made changes to slicerclass. Compatible with earlier versions, but inlined a function, increased safety, and decreased size.

V01.0.0.5-V01.0.0.8 11-11-02

Speed tweaks & cleaned up code

V01.0.0.4 11-05-2003

Minor interface adjustments

V01.0.0.3 11-04-2003

Made header more standard

V01.0.0.2 10-28-2003

Changed header-file usage

V01.0.0.1 10-23-2003

Fixed bug with "toggler" implementation.

V01.0.0.0 10-21-2003

First C++ release of J-Crypt with header-file reader.

April-May 2003

Early versions in QB4.5