[87956] in cryptography@c2.net mail archive
Re: More info in my AES128-CBC question
daemon@ATHENA.MIT.EDU (Steven M. Bellovin)
Wed May 9 18:46:13 2007
Date: Wed, 9 May 2007 17:02:44 -0400
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: tls@rek.tjls.com
Cc: cryptography@metzdowd.com
In-Reply-To: <20070509193544.GA15594@panix.com>
On Wed, 9 May 2007 15:35:44 -0400
Thor Lancelot Simon <tls@rek.tjls.com> wrote:
> On Wed, May 09, 2007 at 01:13:36AM -0500, Travis H. wrote:
> > On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote:
> > > Frankly, for SSH this isn't a very plausible attack, since it's
> > > not clear how you could force chosen plaintext into an SSH
> > > session between messages. A later paper suggested that SSL is
> > > more vulnerable: A browser plugin can insert data into an SSL
> > > protected session, so might be able to cause information to leak.
> >
> > Hmm, what about IPSec? Aren't most of the cipher suites used there
> > CBC mode?
>
> ESP does not chain blocks across packets. One could produce an ESP
> implementation that did so, but there is really no good reason for
> that, and as has been widely discussed, an implementation SHOULD use
> a PRNG to generate the IV for each packet.
Mostly right. RFC 2405 stated:
Implementation note:
Common practice is to use random data for the first IV and the
last 8 octets of encrypted data from an encryption process as the
IV for the next encryption process; this logically extends the CBC
across the packets.
not as a requirement but as a hint. On the other hand, RFC 3602 says
The IV MUST be chosen at random, and MUST be
unpredictable.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
