libsodium mess

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> Yo Eric!
> 
> On Thu, 19 Jan 2017 14:30:35 -0500
> "Eric S. Raymond" <esr at thyrsus.com> wrote:
> 
> > Gary E. Miller <gem at rellim.com>:
> > > > - to fuzz the low-order bits of the clock.  
> > > 
> > > Hmm, can you expand on this a bit?  Which clock?  How much fuzz?
> > > Does this degrade anything?  
> > 
> > Whenever ntpd polls the system clock, it fuzzes the lowest-order
> > digits of the result. The amount of fuzz to apply is bounded by half
> > the measured interval between system clock ticks.
> 
> Hmm, and how much would that typically be?

I...don't actually know.  Probably less than a microsecond.  It should be
available as the value of the system variable "fuzz" (internally sys_fuzz)
but I see

ntpq> rv 0 fuzz
fuzz=0.001

which makes me suspect a units problem somewhere.

The way it's measured is by doing two unfuzzed calls to get time
immediately adjacent to each other: see measure_tick_fuzz() in
ntp_proto.c.

I haven't looked at that code closely.  It could be buggy.

> > That shouldn't degrade anything. I presume it's a measure to foil
> > timing attacks of some sort.  Daniel might be able to say more.
> 
> At first glance this seems reasonable, but my experience with the
> GR-601W suggests otherwise.  My experience with the GR-601W shows that
> ntpd can find a timing edge and hold onto it very well.
> 
> Whe ends up is there will be an offset of up to 1/1024 sec from the
> correct time, but the jitter is much less.
> 
> Can you point me to this code?  I want to rip it out and do a test.

libntp/systime.c

Have fun.  You'll probably do a better job of ayditing that code than I would.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170119/32d50ff0/attachment.bin>