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.