EricBall's Tech Projects

Drat. I just figured out that Cipher Feedback mode (aka CFB) fails horribly if the plaintext of the first block is known.

 

CFB mode works by encrypting an Initialization Vector, then XORing it with the plaintext block to produce the ciphertext block. The resulting ciphertext block is then encrypted and XOR'd with the next plaintext block to produce the second ciphertext block. And so on. The big advantage is decryption re-uses the encryption routine.

 

But say you have a case where the first plaintext block and the ciphertext block are both known. (Not unrealistic as the first block is often a well defined header.) Then it's possible to determine the encrypted IV and use that to create the first ciphertext block for an arbitrary plaintext. So there's a slight possibility an attacker could create an arbitrary first block which would contain enough code to beep out the encryption key.

 

Cipher Block Chaining mode (aka CBC) should defeat this because the plaintext of the first block is "behind" the encryption. So even if you have a known plaintext all you can do is generate the same ciphertext. The disadvantage is CBC mode requires the decryption routine.

Using the GEAR emulator I've confirmed the Key Expansion routine generates the correct output (and takes 4K+ cycles). Found two bugs and one optimization. Next I get to start tracing through the cipher routine. Thank gods for the NIST example data which shows the data at each step.

 

One more bug and SubBytes + ShiftRows done. MixColumns + AddRoundKey is next. I just ran it and it fails. Sigh...

 

It's working. Two more bugs squashed. Now I need to work out the Inverse Cipher routine. (Similar, but different and slightly more complicated, and may not optimize as nicely.)

 

Each of the bugs has been fairly simple:

1. SHR instead of SHL to multiply by 2

2. AND #4 instead of AND #3 for MOD 4

3. ADD #3 instead of ADD #5 when I wanted to add 4 then add 1.

4. MOVD instead of MOVS (update destination rather than source)

5. ROL instead of ROR

 

So, not logic problems per-se. More like typos. Do what I mean, not what I say.

To be sure, using CFB means that someone can create an image with any desired first block. So what? Design the boot loader so that the first block won't be stored anyplace and then the first block could be filled with 128 bits of random garbage.

In actual fact, the first 16 bytes of the Propeller binary image don't appear to contain any code. However, I'd rather avoid any chance that someone could figure out a way to embed code in those 16 bytes.

 

I'm just surprised that the literature I've read doesn't indicate this weakness. For Output FeedBack (OFB) mode where only the encrypted IV is used as the input to the next Cipher function, the lit indicates if the plaintext for any block is known then the ciphertext for any arbitrary plaintext can be generated for that block. Generating new IVs for each message is supposed to address this issue, but for my environment the IV is either static (stored onchip) or stored with the code (and therefore subject to duplication/reuse). CBC mode does away with the known plaintext risks by putting the plaintext behind the Cipher function.