David Schwartz wrote:
> > > Predicting the clock's offset from reality and the two way path to
> > > the server of choice is impossible, plus if people enable authentication
> > > later on the packets will be choke full of high-quality entropy.
> > Please quantify 'impossible'.
> Impossible as in cannot be done. The offset between, for example, the
> processor clock and the NIC clock is unpredictable.
The EXACT offset is unpredictable. Unfortunately that's not
what matters because an attacker can still guess.
What does matter is the set of likely/possible offsets. That
set may be small or may be large or may be biased. Can you
tell me how large it *typically* is on your computer?
My clock usually is within a few seconds from my NTP server.
I guess -assuming microsecond resolution- that allows for a
couple of million possibilities but no more. I can definately
extract one or two bits of entropy from this, but can I do
ten, twenty or even 30? 
Can you generate a 1024-bit RSA key after processing 10 NTP
packets? I don't think so. How many *do* you need?
You need to quantify all this to make a good entropy estimate.
Just implementing this functionality because 'predicting the
clock's offset [...] is impossible' is pretty pointless.
 And then, what's the effect of an attacker sniffing your
LAN? What information would he have to make his guess more
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_ \_| \ _|/' \/
(_)>(_) (_) (_) (_) (_)' _\o_
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message