More info in my AES128-CBC question

[Leichter, Jerry]

| > | > > 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.
| > I hope it's a cryptographically secure PRNG.  The attack doesn't
| > require any particular IV, just one known to an attacker ahead of
| > time.
| > 
| > However, cryptographically secure RNG's are typically just as
| > expensive as doing a block encryption.  So why not just encrypt the
| > IV once with the session key before using it?  (This is the
| > equivalent of pre-pending a block of all 0's to each packet.)
| 
| But if the key doesn't change between messages then this makes the IV
| of the second block constant and if any plaintext repeats in the first
| block of plaintext then you have a problem.
I guess my proposal was ambiguous.  You don't use the encryption of
the *initial* IV for each packet; you use the encryption of what you
would otherwise have used as the IV, i.e., the last ciphertext block
of the previous packet.  The IV of the packet after that is just as
variable as it ever was.  (If it were not, then CBC would be just
about useless:  The CBC encryption of, say, the second block of two
all 0 blocks would always be the same!)
							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com