Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Housley," == Housley, Russ <rhousley@rsasecurity.com> writes:

 >> First, a correction to the Security Section.  In the last
 >> paragraph of Section 6, the draft is right to state that no more
 >> than 2^64 blocks should be encrypted with any fixed key.  But the
 >> draft implies that this limitation can be avoided if
 >> implementations "make use of the longer AES key sizes."  This is
 >> not right, the 2^64 limit applies to all key sizes.  It does not
 >> apply to larger block sizes; however, the AES spec doesn't include
 >> the larger RIJDNAEL block sizes.  In the same vein, the sentence
 >> "Additionally, AES with a 128-bit key is vulnerable to the
 >> birthday attack after 2^64 blocks" should read "Additionally, AES
 >> is vulnerable...".

 Housley,> You are correct.  I propose the following replacement
 Housley,> paragraph:

 Housley,> Additionally, since AES has a 128-bit block size,
 Housley,> regardless of the mode employed, AES is vulnerable to a
 Housley,> birthday attack after 2^64 blocks are encrypted with a
 Housley,> single key. ...

Is that actually correct for counter mode?  The counter is not a
random function, so the birthday paradox doesn't apply to the
keystream. 

If I remember the discussion with David correctly, what IS true is
that at around 2^64 blocks, counter mode (as well as the other modes)
becomes "distinguishable" from a random string.  And that's an
interesting property from the point of view of security proofs, but I
didn't think that it leads directly to an attack in the case of
counter mode.

So the recommendation is ok, but I think the reasoning might be
restated.

	paul