> 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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
