Anybody taking care of refclock_trimble?

[Hal Murray]

> I'm unsure if that ever went into NTPd proper, but the BSD folks started to
> add random bits to the lower end of the timestamp sent over the net so they
> would know when someone was replaying packets.  The attack surface is low for
> this kind of stuff (you'll never know what someone else can come up with
> however) but in principle these bits should be crypto secure so that nobody
> can infer internal state. 

There is a draft data-minimization in progress.  The idea is to set almost 
everything in the request packet to a constant so bad guys can't use NTP 
requests to help track you.

The transmit time slot is set to a random number while the actual transmit 
time is saved.  That's the whole time slot, not just the lower bits.  When the 
reply comes back, the slot in the packet with the "transmit time" is checked.  
If it matches the random value that was sent, the packet is processed using 
the saved transmit time.

We've been doing that for a long time.

If you are just after privacy from advertisers, I don't think the randomness 
needs to be crypto quality.  But it's on the client side where CPU cycles 
aren't critical so there is no reason not to use crypto quality randomness.  
It might slow down any serious bad guys a bit.

-------

> Btw, I haven't seen any jitter reduction with --disable-fuzz at all (as
> expected), contrary to what has been reported from others (I'm using PPS via
> GPIO into the NMEA driver and have the main crystal ovenized).  I'm curious
> in what circumstances it would start to show. 

I took a quick look at the code and didn't see any fuzzing action in the PPS 
path so I guess that isn't too surprising.



-- 
These are my opinions.  I hate spam.