[Cryptography] Question re: Initialization Vector for AES Counter Mode…

[Jerry Leichter]

> Mmmm.  It is my opinion that counter mode is (and stream ciphers in
> general are) a mistake.  We've discussed the limitations of stream
> ciphers and counter modes before on this list. It allows opponents who
> know what is stored at a given location to alter it by bitflipping, in
> such a way that the decrypted message will be their chosen text rather
> than the text that was originally written there....
On the other hand, it's widely understood today that encryption without authentication is hazardous *anyway*, no matter how you do it.  Once you assume you have to use authentication, XOR attacks become uninteresting.

The unavoidable hazard with stream ciphers is that if you repeat a key, you immediately leak information about the XOR of the two messages.

I find the general comments here about counter mode an interesting change in attitude.  In the past (a couple of years back), I had several participants on this list who I respect strongly *favor* counter mode as very simple, having very simple proof of security, easy to implement, etc., etc.  At one point, I suggested using a stronger combiner than XOR in order to protect against XOR attacks.  The general response was as I responded above:  It's pointless, you have to authenticate anyway.

What I think has changed over the years is a greater appreciation of the need for mechanisms that are secure against the inevitable operational and implementation errors. That's the main concern with stream ciphers; they do have the advantage of very simple implementations, which are easy to get right.  Of course, once you add authentication, you lose some of that.

There are some interesting other advantages to counter mode.  Suppose you don't entirely trust your (hardware) AES implementation - you think it might leak information about the plaintext being encrypted.  In counter mode, that's harmless - what's being encrypted is known to the opponent anyway.  Looking at this a bit more broadly, the "red" data never has to go near the AES implementation.  (Of course, the key does, so this reasoning only goes so far.  But you can make things much harder on the attacker by generating key streams all the time, and picking later which to use for what.  So the attacker may get a key, but can't tell what it applies to.)

I also wonder if the terms "stream" and "block" encryption are too limiting.  If you define a stream mode to encrypt bits to bits independently of each other, then the only possible combiner is XOR (or XOR with complement, which changes nothing).  We then jump from individual bits to (currently) 128-bit blocks mapped to 128-bit blocks, again independently of each other.  We then invent modes to get around the data leaked by ECB for block mode - but I'm not aware of much work to define modes that do something similar for stream encryption.  Naturally, you'd have to first lose the "bit independence" - but block modes lose the block independence anyway.

For example, you can map pairs of key and plaintext bits to pairs of ciphertext bits.  You now have a couple of choices of invertible mappings - I'm too lazy to enumerate them - and you can avoid the XOR attack.  Of course, there are other two-bit transformations that produce predictable outputs, so this doesn't gain much.  You need to go to more bits - and have the map depend on the key.  The result might or might not be secure - careful analysis needed - but it doesn't fit into either the stream or the block characterization.
                                                        -- Jerry