Gregory Hildstrom Projects Publications Resume Contact About Youtube Donate

Randomized Random-Cipher Encryption Version 2

Overview

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

  1. output[0] = nonce / initialization vector iv (previousEncryptedByte = 0)
  2. output[1] = input[0] ^ key[key[nonceiv+0]] ^ key[previousEncryptedByte]
  3. output[2] = input[1] ^ key[key[nonceiv+1]] ^ key[previousEncryptedByte]
  4. output[3] = input[2] ^ key[key[nonceiv+2]] ^ key[previousEncryptedByte]

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.