RE: Counter Mode Security: Analysis and Recommendations

["The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>]

The basic question is whether or not a cipher that is susceptible to
an attack requiring 2^88 bytes of storage is acceptable for an IPsec
standard.  Were this a voting organization, I'd vote no.

The implication of this, should others agree, would be that something
would have to change in the proposed counter mode.  All parties appear
to agree that a longer key for the cipher is a solution.  Thus, I'd
expect everyone to agree that the draft should say that AES with
192-bit or 256-bit keys is a MUST for counter mode.  If there's no
agreement on such an obvious point, then call the whole thing off.

Why, though, would one (even Rivest) be more willing to accept a
slower cipher than to generate more keying material at the start?

I've got a few nits about the draft.  The phrase "As such," is always
useless and should be excised.  There's a phrase "need not be full 128
bits" that needs fixing.  It is redundant to specify the number of AES
rounds for use with each key size, because it leads to the thought
that the AES standard leaves the choice open to the user.  The section
on the counter block is a little confusing because it looks like the
counter block is on the wire.  Terminology that leads to a phrase "AES
counter block cipher block" is saddening.

Hilarie