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

[Scott Fluhrer <sfluhrer@cisco.com>]

At 11:21 AM 7/29/2002, David A. Mcgrew wrote:
>Russ,
>
>thank you for your comments, more inline:
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:rhousley@rsasecurity.com]
> > Sent: Monday, July 29, 2002 7:00 AM
> > To: David A. Mcgrew
> > Cc: ipsec@lists.tislabs.com
> > Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt
> >
> >
> > [Klaus]
> > > > yes, I agree with you, I can not see any reason to use an
> > external IV for
> > > > AES CTR if algorithms easy can be defined for internal
> > building of IV's
> > > with
> > > > ESP sequence number and SPI. The only cryptographic
> > requirement for the
> > > > sequence of IV's is, that all the counter values, derived
> > from all the IV's
> > > > over all the ESP packets, transformed by AES, are different
> > as long as one
> > > > fixed key is used.
> >
> > [David]
> > >that's right.  Additionally, some additional strength against
> > attacks which
> > >rely on precomputation of a database to use during the attack
> > stage can be
> > >gained by having the part of the counter be secret.
> >
> > We have discussed the inclusion of a secret component in the counter.  It
> > complicates the key management by requiring an additional secret value to
> > be managed.
>
>I disagree with the supposition that including a secret component in the
>counter complicates key management.  I'll explain what I'm thinking; please
>let me know if or where your assumptions are different.
>
>One simple way in which counter mode can include a secret component is to
>define that value to be part of the key.  This method allows counter mode to
>use a secret component in the counter, while hiding that fact from a key
>management protocol.
>
>For example, define the format of the counter key to look like:
>
>    +---------------+------------+
>    |    AES Key    |   Offset   |
>    +---------------+------------+
>
>where "Offset" is the secret counter component.  The AES Key field would
>have a fixed length (as the draft has a distinct IANA transform number for
>each AES key length).  The Offset could be fixed length (which is certainly
>simpler), or could have a variable length if that proves desirable.  In any
>case, a variable-length Offset field would not introduce any ambiguity.
>
>The counter mode ESP transform gets to define what its key looks like; the
>above definition is perfectly valid.  IKE is quite capable of dealing with
>the format above, since it can work with any key length cipher in ESP.  I
>defer to Scott Fluhrer for more details, as he's implemented what I've
>described here (which he and I worked out in the summer of y2k, to give
>credit where it is due).

Yes, it is as Dave described it.  A concrete example would be: the above 
mode with 128 bit AES keys and 64 bit secret counter offset would ask IKE 
for 192 bits of keying material, and interpret the first 128 bits as the 
AES key, and the last 64 bits as the offset.  We would note that this uses 
192 bits of keying material and delivers (at best) only 128 bits of 
strength -- I do not believe that is a serious (or even minor) problem.


>I certainly agree that it would be overly complicated to expect a key
>management system to manage the 'secret counter component' as a distinct
>data type.  But there's no reason to do that, since the simple key format
>described above works just as well.  I fear that perhaps this point has been
>a source of miscommunication between us in the past.
>
> > If one is concerned about this type of dictionary
> > attack, the
> > use of a longer AES key provides more protection
>
>Yes, this is completely true.  Using a bigger AES key also provides
>protection against precomputation attacks.  However, this approach has some
>disadvantages.  The computational cost of AES is greater for the 192-bit key
>and 256-bit key versions, by 20% and 40% respectively, making this approach
>less efficient than that of using a random offset.  Also, a number of
>current AES implementations do not include the larger key sizes, and thus
>could not use this approach.
>
>In summary, my reasons for preferring the inclusion of a 'secret counter
>component' are that 1) it adds a significant amount of security against
>precomputation attacks, 2) it adds little or no computational cost, and 3)
>it fits easily into the current architecture.
>
>David