Version 4.0 stator structure is modular compared with versions 1 to 3. More details to follow.
Theory of operation for the
Chaotic Random Core Version 4.0
The Chaotic Random Core is best viewed as a motor with
one stator and two rotors.
The Chaotic Random Core
The CRC is a modular pseudo random number generator. It's internal state starts at 128 bits and has no theoreical
upper limit. The only requirement is that the stages must be added in 128 bit increments.
The Eristic Cryptographic Toolkit uses a CRC with eight security levels which repersent 512 to 4096
bits, in 512 bit increments.
The CRC has no limits on key length. It can be keyed manually from the console keyboard, or it can be keyed with a 2 gigabyte file.
The CRC outputs a single eight bit byte at a time. All variables in the CRC are 8 bit bytes, so the CRC is endian neutral.
Version 2 of the CRC has been sucessfully run on an Arduino 'Micro' embedded controller.
Some definitions and an overview of how the individual parts function.
- Element: Eight 8-bit elements make up the core of a segment. Elements are indexed with the k variable.
- Segment: Each is made up of eight elements. Each individual segment is indexed with the j variable.
Individual segments must be paired together in an odd/even arraingement, meaning that when j is even, the segment is considered even.
- xor_sum: This value is generated by exclusive-or-ing all eight elements in a segment together. The old value
of the xor_sum from the previous cycle is disgarded. Each segment is represented in the 'C' language as a structure
which contains one xor_sum and an array with eight bytes in it.
- Segment Group: The Eristic Cryptographic Toolkit groups eight segments together as a segment group. Each segment group
holds 512 bits of state and is equal to one security level. A security level of 2 would have 16 segments in total (1024 bits
of state). Segment groups are indexed with the i variable.
- Rotors: The CRC uses two rotors for most of it's functions with the exception of Harmonia (key exchange usage).
Both rotors have 256 entries consisting of the numbers 0 to 255 shuffeled in a random mannor. Both rotors are indexed with
an eight bit index variable that is allowed to "roll over" ie. when 3 is added to a rotor index that equals 254, the resultant
rotor index would be 1. The 'C' unsigned character data type works well for this. The program Hera is used to generate
a unique standard set of rotors for each program in the toolkit.
- inner_rotor[ inner_rotor_index ]
- outer_rotor[ outer_rotor_index ]
- Input Bytes: An array with up to eight bytes in it is passed to the CRC each time the CRC is called. When the CRC is being keyed
or it is hashing a file, data from the key or file stream is is loaded into the input byte array. In the case of the Eristic
Cryptographic Toolkit, if a security level of 3 is being used, input_bytes will have the first three bytes used.
Once keyed, input_bytes is zeroed out and the CRC "free runs" generating random numbers.
- Mask Bytes: The mask is what controls the "direction" of the XOR operation of the segment element to either inner rotor or
outer rotor. In each case, the result is stored in the segment element. The following procedure is used to initalize the mask:
The mask bytes can then used to control the stator XOR operation as follows:
- For each itreation of i, select the proper input_byte[i].
- For each bit set in input_byte[i], set all of the bits in the corrisponding mask[i].
- If the bit in input_byte[i] is clear, zero all bits in mask[i]
- XOR mask[x] with the xor_sum from the segment in the segment group that is 180 degrees opposite position wise, and
that has an even/odd relationship that is opposite to the segment referenced by x. ( if x=0, the xor_sum from segment 5 would be
used ). ( if x=6, the xor_sum from segment 3 would be used).
In both cases, the result is stored in the segment element. This process is key to keeping the CRC, which is basicaly an iterated
function system from heading to or "gravitating" towards an attractor. Version 3 of Discordia would display a chi-squared distribution
of around 170 in it's output stream when it was keyed with files that were large (20 megabytes or so) due to the CRC heading for an attractor. The
lag in development from version 1 (2008) to version 2 (2012) was primarially due to trying to find a way to control the XOR direction
that would not destroy the chi-squared distribution of the random output stream.
- If bit x in mask[j] is set, element[x] in segment[j] is XOR-ed to the inner rotor.
- if bit x in mask[j] is clear, element[x] in segment[j] is XOR-ed with the outre rotor
- Even Segment Inner Rotor Index: When an even segment is being XOR-ed to an inner_rotor, because the inner rotor index is
"stale", meaning, it was not modified by the preceding segment (which was odd), the segment group index number has 1 added to it
and then it is multiplied by 8 and the product is added to the "stale" inner rotor index to produce the base starting point for
processing the elemenmts in the current segment. Note that the inner_rotor_index is not modified by this operation.
- Odd Segment Outer Rotor Index: Same as Even segment except that ( ( i + 1 ) * 8 ) is used as a modifier to the
outer_rotor_index for the same reasons.
The basic sequence of operations of the CRC can be broken down as follows:
- Initialization: Set all of the bits in all of the elements in all of the stators as well as the rotor indexes.
- Keying: Feed bytes into the CRC via the input_bytes array to put it into an initial and repeatable state. When data
is fed in to the CRC a security level must be specified with the toolkit reference source code.
- Generation: Free run the CRC with the input_bytes array zeroed and a security level set. Every cycle the CRC
generates a single random 8-bit byte.
Detailed descriptions of the CRC components follow:
- The CRC function is called with input_bytes and security_level as parameters.
- security_level index outer loop is set up using i as a variable.
- mask is generated for the segment_group indexed with i.
- Segment index variable j is set up to loop through the 8 segments indexed with i (segment group).
- One even and odd segment pair are processed with each iteration of j.
- Stator element index variable k is set up to loop through the elements in the stator indexed with j.
- Segment elements are XORed with the proper rotor as indicated with the mask[j].
- The xor_sum for the segment indexed with j is calculated.
- The proper rotor index variable is XORed with the xor_sum of the current segment. Even segments to inner_rotor_index,
odd segments to outer_rotor_index.
- 8 segments in the group are processed.
- Loop back to process the next segment group.
- The CRC returns a random byte generated by XORing the inner_rotor_index with the outer_rotor_index.
The design philsosophy of the Eristic Cryptographic Toolkit since the origonal version of Eris, has been to build a secure
pseudo random number generator first, and then adapt it to real works cryptography uses. By focusing on generating good random
numbers, a measurable metric can be established. The CRC has been, and will allways by 8 bit in nature. Being able to run
in a limited environment (CPU and memory) was a design objective from the start of this project. Keeping the design simple
enough to easily visualize helps with both development and analysis.
The CRC has evolved over time from it's neural network roots in version 1.0 of Eris.
Version 4's modular system incorporates all of the reasearch and lessons
learned in previous versions while staying true to the origional design objectives.
The NIST SHA-3 contest
was my "official" start as a crypto geek. Eris 1.0 was never submitted for consideration as SHA-3 due to my paying job
at the time having a deadline that was within two weeks of the SHA-3 submission deadline. Eris 1.0 would have been torn to shreads
anyway, primiarially due to my inexperience and unfamiliarity with the subtletys of the subject of cryptography at the time.
Over the next few years I tore Eris 1.0 to shreads on my own and finaly version 2.0 was produced.
When the Eristic Cryptographic Toolkit is built from source, Hera is compiled first. Once built, Hera is then
invoked with the 'g' command line option which causes Hera to generate the 'C' header files which define the rotors
for the rest of the binarys in the toolkit.
When not used in the build process, Hera serves as a general purpose random number generator.
Eris is a hash function which can generate a variable length hash of a file. Valid hash lengths range from 1 to 512
bytes, depending on security level. If a security level of 1 is chosen, the max hash length is 64 bytes, if a security
level of 8 is chosen, up to 512 bytes of hash can be generated.
Discordia is a stream cipher. It uses the CRC to generate a stream of random numbers that Discordia then XOR's against
the plain text input.
Athena uses the CRC to "shuffle" the input file like a deck of cards. As long as the file lengths are different,
an attacker attempting to XOR two files together encrypted using Discordia, with the same key, will be unable to extract
any meaningfull information.
This link shows a graphic example of the problem that
Athena attempts to solve.
The sequence of operations to shuffle a file will go something like this:
To un-shuffle, generate a pad file with the CRC keyed with the decrypt key and the file length. Index from the
last byte of the file in reverse order as the shuffle procedure.
- Encrypt plaintext with Discordia or some other algorithm.
- Key Athena with the same key used in the encryption algorithm.
- Key Athena with the file length.
- Shuffle the file like a deck of cards as follows:
- Index through the file a byte at a time, from the beginning of the file, swaping the indexed byte with a byte
indexed by the CRC.
Harmonia is a key exchange protocall. During early development (pre. 1.0) of the single rotor version of Eris,
the single rotor would "stall" from time to time. Harmonia takes advantage of this phenomenon using a single rotor CRC
at each end of a insecure connunication channel to generate identical keys.
Aphrodite will be an authentication protocall.
Chaos Check is a tool I'm hacking together to test the chi-squared distribution of the output of the CRC. As with
the rest of the software on the site, it is a work in progress. In my experience, the chi-squared test seems to be the
best indication of the CRC's performance.
Return to main page.