[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