[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IV sizes for AES candidates
Theodore Y. Ts'o <tytso@mit.edu> wrote:
> When we talked how IV's for CBC mode, we were told that using a counter
> for the IV was a bad idea, because if the first eight bytes were known
> and fixed (as they commonly were), you could end up with known
> plaintext/ciphertext pairs that were a low hamming distance apart, and
> this could be used as a wedge to attack a cipher.
IMHO, the similarity of the inputs to the cipher shouldn't be more
than a minor consideration. If your cipher can't resist differential
cryptanalysis, you might as well throw it away and replace it with a
modern one that can. :-)
A bigger worry -- for CBC mode -- with using a counter for your IV is
that it can leak information about the plaintext. This vulnerability is
specific to CBC mode, and does not occur with OFB mode or counter mode.
Technical details may be found below.
So, I wouldn't be worried about using a counter for OFB or counter mode.
Here are the technical details. To quote from Phil Rogaway's comments
to the IPSEC working group back in 1996,
``As an example, it is not true that CBC encryption
can use an arbitrary nonce initialization vector: it is essential
that the IV be unpredictable by the adversary. (To see this, suppose
the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryp-
tion of 0x0000000000000000 followed by an encryption of
0x0000000000000001 is recognizably distinct from a (first) encryption
of 0x0000000000000000 followed by an encryption of
0x0000000000000000. Clearly this violates violates the notion of a
secure encryption sketched in Section 2.''
http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt
This illustrates why the problem with using a counter for your IV is
specific to CBC mode, and is not problematic for OFB or counter mode.
References: