eRedHerring Block Cipher
Abstract
The new idea is for this symmetric key encryption to produce cipher text plus a second key. This second key can be applied to decrypt the cipher text to produce a second plain text that is plausible and harmless.
Details
The eRedHerring Algorithm takes three inputs and outputs two blocks. The inputs are the key, the secret plaintext, and the Red Herring Decoy Plaintext. The outputs are the cipher text and a second key that is matched with the Red Herring Decoy Plaintext. Therefore, the user can store the ciphertext with the second key and when decryption uses the second key, the plaintext is the decoy plaintext instead of the secret plaintext. It is expected that this functionality can be provided for AES and many other well defined algorithms because the key is known and all plaintexts are known. Imagine if one month from now, software is for sale that wraps up around an AES product to implement this functionality. Then Off The Shelf AES software can be bundled with eRedHerring software to output the second key for AES. Then people could have more privacy!
Here is how it is done. Use an initialization vector along with a second key to xor to provide the decoy.
Step 1: Encrypt the secret message using AES-ECB with an initialization vector of zero and the first key.
Step 2: Select a second key at random.
Step 3: Decrypt the cipher text from step 1 using second key.
Step 4: Calculate IV from xoring the decrypted string and the decoy string
Step 5: Store IV and second key with ciphertext for future decryption choices
Step 6: Choose to decrypt with first key or second key and xor with IV to see decoy
------------------------------------------------------------------
For a single block the algorithm is easy, but it is harder for multiple blocks. The IV initialization vector can be used to carry the red herring information to be xored with the block that is decrypted with the second key. The goals for this work are capable of becoming a white elephant unless I spell out more limitations. For example, if the block size is 64 bits and the key is limited to at least 256 bits, then it becomes easier to find a second key for a secondary decrypted block.
The goal for the eRedHerring work is to design a new cryptographic algorithm that calculates alternative keys more easily than for strong ciphers. This will be a weaker cryptographic algorithm than is normally proposed, due to the albatross around the neck of the eRedHerring. The invention of the Albatross Logic Mirror is planned to provide the alternative key in sub-blocks that are computationally costly, but which are affordable. Insights into the "excess avalanche" which was blindly provided in all 15 AES candidates in 1999 will help to balance the need for second key generation versus avalanche. In other words, the new cipher will have a slower rate of avalanche than other candidate algorithms while it records states from rounds concerning sets of compatible keys.
Excess Avalanche Paper
http://csrc.nist.gov/archive/aes/round1/conf2/Folmsbee.pdf
The calculation of 1/(2**(n*m)) likelyhood of using more blocks is valid. Future research into the Actor Sequencer is planned to provide any arbitrary mask sequence seeded with one block. The lengthy pre-computation of the Actor Sequencer performance simulation is expected to suppliment the use of linear algebra to predict success. My advantage will be from providing weak crypto that conforms to second key generation goals. That weakness level will be adjusted to be good enough for rock and roll.
-----------------------------------------------
The OTP is what inspired me to emulate that capability to decrypt to
any plain text. That capability is not offered in other brands, so an
apparatus can be contrived to offer this decryption function for a
block cipher. It is not easy but complicated logic flows can perform
wonders. This will not allow as much randomness as other ciphers. It
will have linear predictability concerning related keys so the second
key can be produced. A 256 bit key for a 64 bit block provides for
duplicate keys to be plentiful. Then at each round, related key states
will be recorded. It is hoped that a few megabytes of Related Key
State information will be enough to produce a family of compatible
keys for a given decoy text.
The decoy text will usually have many blocks of data in it. This is a problem.
This work is abandoned for the red herring.
