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

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



On Tuesday 30 July 2002 04:00, Alex Alten wrote:
> Hello Uri,

 Hi there!

> >> 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? 

>From /dev/random on Unix. 
Let Windows people figure out for themselves. (:-)

> This requires much
> more frequent reseeding than keys themselves need rekeying. 

Huh? I don't get it. A PRNG once primed, can run for a long time,
perhaps even until  the next reboot. And in any case, /dev/random
is there to provide when n eeded.

> A PRNG
> cannot produce more entropy than the original seed bits.

PRNG isn't supposed to produce more entropy - just practically
uncorrelated (with the actual entropy strength of uncorrelation)
stream of bits.  So what's new here and why is it an issue?   

You seem to be mixing the ultimate strength of the algorithm
(which is not greater than the actual entropy of the key) with
the practical correlation of the output bits.

Example: PRNG is Rijndael in OFB mode. Key size is 256 bits. The actual 
entropy of that key is 102 bits. Used to produce 2MB of PR bits to
encrypt 2MB of data. And 2MB more of PR bits to key another 
cipher suite. In this scenario what's the problem you were talking 
about?

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

Depends on the PRNG of course - but shouldn't be any more likely to 
repeat than the output stream itself.

BTW, who speaks of encrypted IV?


> >> 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? 

If it has hardware like that mentioned in RFC 1750 and software that
follows that RFC - it's good enough for me. If it doesn't - I don't 
know.

> What quality of random
> source can be expected on this low-end device?

See above. 

Plus, IV doesn't REALLY have to be random. It's something people are 
talking about now because of the threat brought up by S. Fluhrer when
more than one user sits on one SA. Such a low-end device isn't very 
likely to run multiuser...

As for the _really_ small devices (such as cell phones) - I'm 
investigating it now.


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

Good question - I don't know (and let somebody else worry about it, so 
feel free to offer suggestions :-).
-- 
Regards,
Uri-David
-=-=-<>-=-=-
<Disclaimer>