[tor-dev] Proposal 338: Use an 8-byte handshake in NETINFO cells

Jim Newsome jnewsome at torproject.org
Mon Mar 14 19:43:50 UTC 2022


On 3/14/22 14:40, Nick Mathewson wrote:
> 
> 
> On Mon, Mar 14, 2022 at 3:18 PM Jim Newsome <jnewsome at torproject.org 
> <mailto:jnewsome at 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.

Makes sense to me. Thanks!


More information about the tor-dev mailing list