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

David L. Mills mills at udel.edu
Wed Oct 5 01:58:36 UTC 2005


Ulrich,

Thanks for the plain ASCII, which is much easier for me to read than 
curlicue Times Roman.

I wasn't making a joke; the unused bits truly are filled with a random 
bitstring. This is to further frustrate tempoterrorists trying to guess 
the next originate timestamp. This is most important for those machines 
that do not have means to interpolate between tick interrupts.

Dave

Ulrich Windl wrote:

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