On Mon, Mar 14, 2022 at 3:18 PM Jim Newsome <jnews...@torproject.org> wrote:
> On 3/14/22 11:44, Nick Mathewson wrote: > > <snip> > > > Currently Tor relays use a 4-byte timestamp (in seconds since the Unix > > epoch) in their NETINFO cells. Notoriously, such a timestamp will > > overflow on 19 January 2038. > > > > Let's get ahead of the problem and squash this issue now, by expanding > > the timestamp to 8 bytes. (8 bytes worth of seconds will be long enough > > to outlast the Earth's sun.) > > <snip> > > With all those extra bits, would there be any value to using a more > granular time measure? e.g. microseconds? > I don't think so, necessarily. We aren't doing full NTP here; in fact, we're just trying to detect clock skew that's big enough to break Tor. (Like, on the order of hours.) I don't think we'll get anything useful out of sub-second observations. If not, would it be worth saving some bytes and only expanding to 5 > bytes? (I know; it *feels* wrong, but I can't think of much real downside) > Hm, possibly. One downside is that 5-byte decoder/encoder functions aren't exactly common, so we'd require everybody to build one. (Or to do something like u8 ts_high; u32 ts_low; ) Since the extra 3 bytes are only used once per connection attempt, I'm pretty comfortable letting them be useless until 36812 CE or whenever.
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
