Anybody taking care of refclock_trimble?

[ASSI]

Hal Murray via devel writes:
> I don't think there is any need for crypto randomness when fuzzing the low 
> bits of time.  If anybody has other opinions, please sing out.

No, you only need unbiased "white" statistics that stays iid in not too
many dimensions.  That point was never questioned.

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 think we should dump ntp_random and use either random() or 
> RAND_bytes/RAND_priv_bytes as appropriate.

You shouldn't use random() directly, at all.  Again, while it's bad at
multidimensional randomness due to having too few state bits, it
otherwise is OK on Linux.  You just don't know what you'll get on other
systems.  Since there are inlineable, faster _and_ better generators
available it just doesn't make any sense to me to stick with random().

> In the old days, ntp_random had its own built-in pseudo random number scheme.  
> So there was no cryptographically strong randomness in ntpd.  (or I missed 
> something in the old code)  That was removed in 2015 when we started using 
> libsodium.
>
> NTS uses RAND_bytes.

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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables