> In message <[EMAIL PROTECTED]>, Alexander Langer writ
> es:
> >Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
> >
> >> I have thought about adding a entropy server to my array of weird
> >> servers in my lab.  Something like a Geiger counter and a smokedetector
> >> could do wonders.
> >
> >HA! Cool!
> >
> >Do that please!
> >
> >I mean, seriously.
> >And an option to sysinstall, where you can enable this as you can with
> >ntpdate :)
> DuH!
> NTP is the perfect way to gather entropy at bootup!
> 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.
> We need an enterprising soul to add an option (default on) to
> ntpdate to write the received packets in toto to /dev/random
> if it exists.
> If somebody does this, I will spear-head the effort of getting it
> into the ntpv4 sources (Hmm, don't  I have a commit bit there
> already ?  Can't remember...)

Actually, you could really use this in ntpd(8), rather than just ntpdate.
You could crank in the offset and delay samples for each packet
received from an NTP peer; this will have the effect of adding into
the entropy pool the "noise" in the latency of the path between you
and each of your NTP peers.  This varies over time with each sample,
and in fact, NTP goes to considerable effort in it's sample filtering
to exclude the noisy samples.  We need to get that date before it's
discarded and contribute it to the entropy cause.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to