[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IV sizes for AES candidates

Ted:

Maybe I'm just slow, but I don't follow your point about the known
plaintext. Bellare, Killian, and Rogaway's proof of the security of counter
and CBC modes starts with the assumption that ALL the encrypted data is
chosen plaintext, not just known plaintext. It seems to me their theorem
says if you don't trust your block cipher and key in counter mode, you
shouldn't trust them to any greater extent in CBC mode, and you have
plausible grounds to trust them even less. What am I missing? You seem to be
implying there is a proof of some other theorem saying CBC mode is at least
as secure as counter mode when the plaintext is only known and not chosen,
or when used with "real" instead of ideal block ciphers, or ...?

My belief is that Steve's reservations about counter mode are the sorts of
concerns that a counter mode proposal has to address. I don't understand the
problem you raise.

-- Jesse

-----Original Message-----
From: Theodore Y. Ts'o [mailto:tytso@MIT.EDU]
Sent: Thursday, August 10, 2000 9:41 PM
To: Steven M. Bellovin
Cc: Walker, Jesse; ipsec@lists.tislabs.com
Subject: Re: IV sizes for AES candidates


   From: "Steven M. Bellovin" <smb@research.att.com>
   Date: Thu, 10 Aug 2000 14:29:13 -0400

   In message
<392A357CE6FFD111AC3E00A0C99848B002FE990F@hdsmsx31.hd.intel.com>, "W
   alker, Jesse" writes:
   >I share Helger's desire to at least consider counter mode for AES.
Counter
   >mode is an opportunity to gain better data privacy than CBC mode offers
and
   >perhaps better performance as well. The WG can fall back to CBC mode if
   >scrutiny reveals counter mode is somehow inapplicable within ESP.

   Counter mode appears to be one instance of a "seekable stream cipher", 
   per draft-mcgrew-ipsec-scesp-00.txt.  As was discussed in Pittsburgh, 
   there are a number of limitations, including the very strong 
   requirement for authentication and the need for a flat-out ban on using 
   it with manual keying -- if you don't use IKE, there's just too much 
   risk of seeing two streams encrypted with the same key and counter.

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.

If you use counter mode, doesn't this guarantee that in the face of
known plaintext, you'll have a *lot* of known plaintext/cipgertext that
have a low haming distance, and so would be subject to the same attacks
as mentioned in the previous paragraph, right?

So wouldn't the argument that says that we shouldn't use a counter to
generate IV's also mean that using counter mode would also be a bad
idea?  (This is in addition to all of the issues of an absolute
requirement for using a MAC if you care about message integrity at
all, and the dangers of resusing a keystream if you're not careful.)

							- Ted