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

[Alex Alten <Alten@attbi.com>]

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

- Alex



--

Alex Alten
Alten@ATTBI.com