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

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

Alex,

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten
> Sent: Monday, July 29, 2002 11:42 AM
> To: Housley, Russ; David A. Mcgrew
> Cc: ipsec@lists.tislabs.com
> Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt
>
>
> At 09:59 AM 7/29/2002 -0400, Housley, Russ wrote:
> >[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.  If one is concerned about this type of dictionary
> attack, the
> >use of a longer AES key provides more protection without imposing
> >additional requirements on key management.
> >
> >Russ
> >
>
> I believe someone already has stated the problem will be to prevent the
> counter
> from repeating (or being predictable) with the same key. It's entropy in
> practice
> may be fairly low.  Also, there may be the fairly likely danger
> of shared keys
> across multiple hosts which is deadly if any IV values commonly repeat on
> different hosts (this helped to kill WEP).  I think this is the
> crux of the
> matter,
> and I don't think this can be solved with a software PRNG
> algorithm.  What I'd
> recommend is to try to pull it from hardware, like the Intel P4 supporting
> chipset.
> If this is not possible maybe a large random seed can be placed on each
> host, and
> the PRNG is then used to pseudo-randomly mix/fold the seed bits. One can
> get quite
> a few "unpredictable" random IV values that way. There will be an
> exponential
> decay in unpredictableness, but hopefull you can start high enough up on
> the curve
> for it to useful.  Eventually the seed would need to be refreshed, but if
> it is
> infrequent enough it could be done by hand.  The large seed should remain
> secret
> during its lifetime otherwise it will be subject to an inverse matrix
> precomputation
> attack.  It would be ideal if the PRNG had a large set of random small
> seeds available
> to it as well, so that the start of it's cycle per new session would be
> unpredictable
> (it too needs to be refreshed periodically).

I think that the discussion is somewhat hard to follow, my apologies for the
terseness of the mail that started this thread.

Russ' draft requires distinct IV values, which implies that a deterministic
mechanism must be used to produce them.  The use of a true random number
generator, as you'd suggest, would generate repeat values after 2^32
packets, with a high probability.  Given the fact that using the same IV
value twice in counter mode gives away the exor of the plaintexts, this is
something that we want to avoid.

Russ and I are in agreement that counter mode should be implemented using
IVs generated by a deterministic algorithm.  What I was proposing is that
additional security against attacks which use precomputation (e.g.
key-collision and time-memory tradeoff attacks) by making part of the
counter secret, so that the adversary does not know all of the inputs to the
AES cipher that are used to generate a particular range of keystream.

David