[ntp:questions] Re: ntpd transmit timestamp precision
GDowd at symmetricom.com
Thu Feb 16 21:08:23 UTC 2006
It's always a good idea to randomize unused bits to increase entropy in
the packet. And it seems like I remember one of your papers
specifically relating the randomization to the security aspect.
gdowd at symmetricom dot com (antispam format)
Technologist, TT&M Div.
"The current implementation is non-obvious and may need to be improved."
Date: Thu, 16 Feb 2006 12:34:07 +0000
From: "David L. Mills" <mills at udel.edu>
Subject: [ntp:questions] Re: ntpd transmit timestamp precision
To: questions at lists.ntp.isc.org
Message-ID: <dt1rgb$8co$1 at dewey.udel.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
The ONLY function of the random fuzz is to fill the timestamp bits below
the microsecond, and this ONLY with the kernel syscall that returns time
in microseconds. Do NOT interpret the agenda in any other way. There is
no benefit whatsoever to fuzz the bits below the nanosecond.
Damion de Soto wrote:
> Hi Brian, Danny, David.
> So, currently the low-order bits are only randomised if the system
> doesn't have HAVE_CLOCK_GETTIME || HAVE_GETCLOCK.
> They should always be randomised to the calculated precision of the
> (incidently, in the two libraries i've just looked in - glibc & uClibc
> - the clock_gettime() function just calls gettimeofday() anyway - so
> they definately shouldn't be treated differently)
> I tried to work out an easy way to always add random fuzz to our
> current degree of system precision, but then i ran into the second
> the system clock precision is calculated in default_get_precision() in
> ntp_proto.c - this function uses consecutive calls to get_systime()
> to calculate the minimum tick difference. Won't this be always wrong
> if the random fuzz code in get_systime() is used, and give a much
> higher precision than is really available?
More information about the questions