Re: Counter Mode Security: Analysis and Recommendations

[Stephen Kent <kent@bbn.com>]

At 8:34 PM -0500 11/21/02, Paul Koning wrote:
>  >>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:
>
>  Stephen> Ted, I concur with your analysis re the storage requirements
>  Stephen> for this attack, and how daunting they seem. This strikes me
>  Stephen> as the sort of attack that I would protect against if it
>  Stephen> cost almost nothing, but as we see, it does have a cost,
>  Stephen> e.g., in terms of extra storage for additional per-SA state
>  Stephen> for the added bits, or in terms of using bigger AES keys,
>  Stephen> with attendant increases in the number of rounds and the key
>  Stephen> state size. Also there are costs to vendors in supporting
>  Stephen> the additional key sizes and numbers of rounds.
>
>Agreed on increasing key sizes.  But I don't agree for the case where
>128-bit keys and a 64-bit random number are used.  Yes, that increases
>the per-SA state by 8 bytes.  And yes, that cost is "almost nothing".
>
>     paul

The persistent, per-SA data that is crypto security related for 
AES-128-CTR is 16 bytes of key. Depending on the way that the sender 
generates the per-packet IV, another 8 bytes might also be retained 
per outbound SA.  The packet sequence counters (transmit or receive) 
and receive window bit map are outside the crypto boundary and thus 
may have less stringent storage requirements, so I don't count them 
here. Adding 8 bytes for a salt to the 24 byte total noted above is a 
33% increase of this type of data.

This cost is almost nothing for software implementations, but in 
hardware it might be significant.

Steve