[ntp:questions] Re: using ntpd to feed the system's random device

Ulrich Windl Ulrich.Windl at RZ.Uni-Regensburg.DE
Tue Oct 4 14:42:16 UTC 2005


"David L. Mills" <mills at udel.edu> writes:

> Brian,
> 
> In NTPv4 the precision measured by ntpd reveals how many bits of the timestamp
> fraction are significant. Following good security practice, the
> non-significant low order bits are filled with an unbiased random fuzz
> generated by the Unix random() routine.
> 
> Dave
> 
> Brian Utterback wrote:
> 
> > Adrian von Bidder wrote:
> >
> >>> On some systems, there's a kernel random-device. That device collects
> >>> entropy from numerous devices (like interrupts from disk i/o, keyboard
> >>> clicks intervals, etc.). Now as it seems that the drift and the
> >>> offsets can be pretty much random I was wondering it ntpd could be
> >>> enhanced so that it sends this data to the kernel random-device? It
> >>> can be helpfull for systems that, for example, hardly have any
> >>> disk-i/o and such.

I think Dave made a joke: The lower-than-precision bits in the system time are
_implicitely_ filled (=considered) random. Right?

> >>
> >>
> >>
> >> Should work - network delays are very random, so using the lower few
> >> bits of the unprocessed offsets (raw, each time ntpd receives a packet)
> >> would probably give you some random input.
> >>
> >> Problems:
> >>  - ntp is very low traffic, so you'd not get much random data
> >>  - kernel/userspace interface - so far, afaik, most random sources for
> >> kernel random device is kernel-internal.
> >>  - ntp is time-critical code, you'd have to take care not to make the
> >> timekeeping worse by this processing.
> >>
> >> So I guess, primarily because of the first item, that it's not worh it
> >> if you're not extremely starved of random data.
> > Another problem of a more serious nature is the issue of resolution. The
> > last few bits may not change at all! How will you decide which bits to
> > use in the middle?
> >




More information about the questions mailing list