In message <[EMAIL PROTECTED]>, "Jeroen C. van Gelderen" writes:
>> People have tried for 30+ years to predict what a quartz xtal
>> will do next. Nobody expects any chance of success. Add to this
>> the need to predict the difference between one or more NTP servers
>> and your local qartz xtal and I think we can safely say "impossible".
>
>See my reply to David Schwartz. What kind of numbers are we
>talking about?
With microsecond timestamps, 64second ntp poll period we are talking
about approx 10 bits of randomness in the received packet and about
3 bits of randomness in the clock difference.
FreeBSD uses nanosecond timestamping (Actually could do nanoseconds
with 32 bitfractions), but that only adds about 4 bits to the clock
difference due to the clock frequency end interrupt hardware.
>> >I think we first need to figure out the security implications.
>>
>> I think the security implications of having no entropy are much
>> worse than having entropy which a truly superhuman *maybe* could
>> guess *some* of the bits in, are far worse.
>
>I agree, but to paraphrase: that's policy decision.
>Just quantify it so that people can be their own judge.
No, it is not policy to try to get as many random bits as we can
by default. It would be policy to *not* do so for some obscure
principle of scientific purity.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
