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

Re: Counter Mode Security: Analysis and Recommendations



Hi David,

	Barbara and I held off issuing a last call on
draft-ietf-ipsec-ciph-aes-ctr-01 on Friday because Barbara indicated
to me that she had talked to you, and she had told you that you were
about to publish a five-page writeup documenting a security
shortcoming in the current I-D that was about to be published.  I assume
that this writeup is the one that you were referring to:

> http://www.mindspring.com/~dmcgrew/ctr-security.pdf

Having read your writeup, I'm confused how this applies to
draft-ietf-ipsec-ciph-aes-ctr-01.  The basic summary of your writeup
seems to be (1) the IV needs to be 64 bit, (2) it needs to be
unpredictable, and a good way to do this is to generate the IV using a
counter starting at an unpredictable random value. 

The current ID specifies the use of a 64-bit explicit IV, which can be
set by the sender in any fashion which is convenient for the sender,
as long as the requirement that an IV is never reused for a particular
key.  There is even text in the security requirements section which
covers the topic of precomputation attacks.

Perhaps it could be made more explicit in the light of your comments
by adding a recommendation that if the sender is using an incrementing
counter or an LFSR to generate the IV, an unpredictable starting value
for the counter or LFSR would be a good idea.  Not starting the IV at
zero would seem to me to be self-evident, but sometimes stating such
things explicitly for the benefit of the college intern implementing
from the RFC is a good thing.

Did I miss anything from your counter-mode security writeup?   

							- Ted