RRCE encrypts 1 byte at a time by xor with a 1 byte key segment from key file.
The key segment pointer is determined from nonce/iv, input data, and key file data.
The randomized order of key segments is determined by nonce/iv, key file data, and input data.
Any change in input data, byte number, or iv will result in a different key value used.
This encryption algorithm aims for greater speed and simplicity than RRCEV1.
RRCEV2 is an 8-bit algorithm, so key can range from 16 to 256 bytes (128 to 2048 bits).
The key file should be filled with high-quality random
data, like recorded radio static or something far more sophisticated.
rrce.zip is the source code version 200711061630. rrce.exe.zip is the Windows (XP 32-bit) exe version 200711061630.
Encrypted 3-Byte File Byte/Algorithm Example
output[0] = nonce / initialization vector iv (previousEncryptedByte = 0)
The output filesize = inputfilesize+1. So this 3-byte
file would be 4 bytes. The keys can be 256 bytes, but it revolves
for smaller key files. The code can use the %(modulus operator) to compute the remainder, which is slow and currently commented out, but it works for any key size up to 256 bytes. The faster code uses bitwise operations to calculate the remainder and the key must be a power of 2 bytes.
This makes it very difficult to determine key size.
The entire key is also not guaranteed to be used on any one file
because the key segments are chosen by combining key data and
ciphertext data, which should be very random in nature.
For this simple driver program, the nonceiv is just the LSB of the current time. The first byte is xored with key[key[nonceiv+0]] and key[0], which should insure that nothing about the key or the input file can be determined from the nonceiv. In the case that the first byte of the input file is guessed, xoring the 1 byte known plaintext with 1 byte ciphertext will yield 1 byte of the key xored with 1 byte of the key, but that is not very useful.
Known Plaintext Attack
A known plaintext attack already constitutes a security breach, but it
may reduce the number of test keys over a brute force attack. The known
plaintext corresponds to some known ciphertext.
In the case of a known plaintext attack, segments (bytes) of the key
cannot be easily determined by xoring the
ciphertext and known plaintext. This is one of the major differences from RRCEV1.
Unknowns
There may very well be a shortcut method to breaking this encryption,
but I have not found it yet. It is quite possible that some math savant
or someone with a different perspective will end up finding a hole in
this, so rigorous research and testing are needed.
Related Algorithms
I discovered some interesting information after writing the initial
versions of RRCE and this web page. Apparently the algorithm I came up
with is a type of stream cipher (or 8-bit block cipher depending on your perspective). It uses some techniques similar to other stream cipher algorithms like RC4,
which is used in SSL, WEP, and WPA. The similarities lie in the use of
input data and key data to mangle the key during use. This attempts to
approximate the behavior of one-time pad encryption schemes and maximize resistance to stream cipher attacks.
RC4 uses input and key data in an 8-bit lookup table, which is very
fast, but not random enough for many applications. RRCE computes key
order using key data and encrypted
input data. RRCEV2 achieves about 87.5MB/s on a 3.0GHz Xeon.
RRCE should be more random than RC4, but an in-depth analysis by experts is necessary. RRCE's nonceiv is
analogous to the initialization vector (IV) on Wikipedia's Comparison
of Stream Ciphers table, but unlike RC4's IV, the use of input data and
key data to determine key offsets after the first encrypted byte should
thwart the key reuse attack that crippled WEP because key byte order is randomized.
