Re: Core draft last call update.

[daw%mozart.cs.berkeley.edu@localhost (David Wagner)]

Bill Sommerfeld  wrote:
> - Wei Dai: plaintext-guess-verification attack possible against CBC
>based symmetric encryption modes.
>
>Proposed resolution: WG does not see this as a serious issue but will pursue
>other encryption modes; no document change necessary at this stage.

Hmm.  I'm a little concerned about this.  Here's my reaction.

I looked at the packet format and it looks like there may be the
opportunity to exploit this against sessions that contain at least
2^16 packets and that multiplex data from multiple sources (surprisingly
common).  That's not a devastating attack, but it's probably not
such a good property, either.

3DES, AES, and Blowfish are supposed to be very conservative ciphers.
The above flaw partially undermines this strength.  If there were some
attack on our block cipher requiring only 2^16 known or chosen plaintexts,
we'd run screaming; are there reasons to hold our modes of operation
to a lower standard?

For comparison, attacks of comparable impact have led to changes in the
IPSec packet format (Bellovin's cut-and-paste attacks) and might lead
to changes to TLS (heavy discussions ongoing in TLS WG right now).

I don't see it as an urgent "fix this today!" bug, but standards move
slowly and it may make sense to get started on fixing the specification.
(It's not going to get any easier with time.)

Looking at this from a design perspective, the fix seems to be
straightforward.  AES-CTR would do fine.  AES-CBC with unpredictable
IV's would also be ok, so long as all implementations enforce the
constraint that they won't start emitting ciphertext until they've
consumed all the plaintext for this message, but I bet many implementations
do not enforce this condition -- for this reason, I suggest AES-CTR.

How much work would it take to fix this weakness?