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

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



Hello Uri,

At 08:07 PM 7/29/2002 -0400, Uri Blumenthal wrote:
>On Monday 29 July 2002 18:56, Alex Alten wrote:
>> Thanks David,
>>
>> My misunderstanding of the IV generation details.  I just read your
>> other explanation of the secret starting offset for the IV sequence.
>> In your/Fluher's design, is this offset generated separately from
>> the key bits?
>
>Depending on how the key bits are generated, it may not matter.
>For example, if the key bits are produced by a crypto-strong PRNG,
>then the offset can be taken from that stream. [I admit that I 
>personally would prefer a different source, possibly with a different 
>keying of that same PRNG.]    Otherwise, there can be a big problem.
>
>> What if the key is used repeatedly, or in the worst case shared
>> among many hosts? 
>
>Shouldn't matter - because anyway the key is used for more than one 
>packet. What does matter is that the combination of Key+IV never 
>repeats.  Good random seeding should take care of it, I think.
>

Yes, but how do you get good random seeding?  This requires much 
more frequent reseeding than keys themselves need rekeying.  A PRNG
cannot produce more entropy than the original seed bits. This means
that for a given key a significant fraction of the encrypted IV+cntr
blocks from session to session will be likely to repeat.

>> What happens if a host reboots?  Does the secret
>> offset start at the same initial value?  If not, how do you
>> guarentee this?
>
>Good questions.   
>
>I'd say - seeding the generating PRNG with /dev/random output 
>after host reboot should give a reasonably good assurance.
>
>> BTW, I'm not completely clear on this aspect.  Does the sender
>> completely control the IV sequence generation? 
>
>He better!

OK.  What if he's a $300 IPsec box?  What guarentee do you have
that the IV sequence generation is done well?  What quality of random
source can be expected on this low-end device?

>
>> Can the receiver process incoming packets out-of-order or handle 
>> dropped packets?
>
>Again, he better. 

What about fragmented packets?

Regards,

- Alex

>-- 
>Regards,
>Uri-David
>-=-=-<>-=-=-
><Disclaimer>
>
--

Alex Alten
Alten@ATTBI.com