[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Counter Mode Security: Analysis and Recommendations
David:
Thanks for documenting this issue so clearly. The material presented here
might be new for many participants on this list, but it was discussed at
length by the design team.
During the design team, I posted the following reply when you raised this
issue. At that time, you were calling the additional random value a
salt. This paper does not seem to use the same name.
> > I have spoken to Ron Rivest about salt, and he is strongly opposed to
> > it. His reasons are pretty straightforward. First, if the salt is needed
> > to defeat a precomputation attack, then the key is too short. A better
> > countermeasure is a longer key. With AES, longer keys are readily
> > available.
While I have not spoken to Ron Rivest about this topic since the design
team, Ron was quite emphatic that the appropriate countermeasure to
precomputation attacks is longer keys. This is the reason that the counter
mode draft includes support for all three AES key sizes.
The use of the additional secret value that you propose leads to the
generation of additional keying material. If these attacks are an issue,
then I propose that it is better to use it to make a longer AES key.
There is already a discussion of precomputation attacks in the Security
Considerations section of the current draft. It says:
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.
In my view, this document is ready for working group last call.
Russ