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

["David A. Mcgrew" <mcgrew@cisco.com>]

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).

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