[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



At 07:58 AM 8/5/2002 -0700, David A. Mcgrew wrote:
> > First, I propose the following additional paragraph in the Security
> > Considerations section:
> >
> >     There are fairly generic precomputation attacks against all block
> >     cipher modes that allow a meet-in-the-middle attack against the key.
> >     These attacks require the creation and searching of huge tables of
> >     ciphertext associated with known plaintext and known keys.  Assuming
> >     that the memory and processor resources are available for a
> >     precomputation attack, then the theoretical strength of AES-CTR (and
> >     any other block cipher mode) is limited to 2^(n/2) bits, where n is
> >     the number of bits in the key.  The use of long keys is the best
> >     countermeasure to precomputation attacks.  Therefore, implementations
> >     that employ 128-bit AES keys should take precautions to make the
> >     precomputation attacks more difficult.  The concatenation of the
> >     Flags, Truncated SPI, and IV fields within the counter block can be
> >     thought of as a per-packet nonce.  Repeated use of the same nonce
> >     value (even with different keys) ought to be avoided.  One approach
> >     is to randomly assign SPI values; however, since the only 24 bits of
> >     the SPI are included in the nonce, a random SPI value provides
> >     limited additional security.
>
>Actually, the 24-bit truncated SPI values need not be random in order to
>protect against a precomputation attack.  It is sufficient for those values
>to be used uniformly.  An implementation which generates SPI values
>sequentially would reap the same benefit, if it generated all possible
>values (and didn't favor the initial portion of the sequence).
>But we can't rely on a SPI selection strategy for security anyway, since
>RFC2401 allows any SPI selection method, so it doesn't make much difference.

Good point.  I reworded it to:

    There are fairly generic precomputation attacks against all block
    cipher modes that allow a meet-in-the-middle attack against the key.
    These attacks require the creation and searching of huge tables of
    ciphertext associated with known plaintext and known keys.  Assuming
    that the memory and processor resources are available for a
    precomputation attack, then the theoretical strength of AES-CTR (and
    any other block cipher mode) is limited to 2^(n/2) bits, where n is
    the number of bits in the key.  The use of long keys is the best
    countermeasure to precomputation attacks.  Therefore, implementations
    that employ 128-bit AES keys should take precautions to make the
    precomputation attacks more difficult.  The concatenation of the
    Flags, Truncated SPI, and IV fields within the counter block can be
    thought of as a per-packet nonce.  Repeated use of the same nonce
    value (even with different keys) ought to be avoided.  One approach
    is to consecutively assign SPI values; however, since the only 24
    bits of the SPI are included in the nonce, a SPI value provides
    limited additional security.

Russ