[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt
Paul:
> >>>>> "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.
Are you happy with the following replacement paragraph?
Additionally, since AES has a 128-bit block size, regardless of the
mode employed, the ciphertext generated by AES encryption becomes
distinguishable from random values after 2^64 blocks are encrypted
with a single key. Since ESP with Enhanced Sequence Numbers allows
for up to 2^64 packets in a single security association (SA), there
is real potential for more than 2^64 blocks to be encrypted with one
key. Therefore, implementations SHOULD generate a fresh key before
2^64 blocks are encrypted with the same key. Note that ESP with
32-bit Sequence Numbers will not exceed 2^64 blocks even if all of
the packets are maximum-length Jumbograms.
Russ