On Thu, Aug 22, 2013 at 12:33 PM, George Kadianakis desnacked@riseup.net wrote: [...]
2.2. AUTHENTICATE (server)
The AUTHENTICATE cell is not ordinarily sent by clients. It contains an 8-byte timestamp and a 16-byte random value. Instead, let's replace both with a 24-byte (truncated) HMAC of the current time, using a random key.
This will achieve the goal of including a timestamp in the cell (preventing replays even in the presence of bad entropy), while at the same time not including the time here.
Hey Nick,
how does the client verify the contents of the AUTHENTICATE cell (including the timestamp), if the timestamp is encrypted with a random key?
Two points and a real answer. The two points first:
* The authenticate cell is sent from a server initiator to a server responder. Clients never get them, and never verify them.
* HMAC isn't encryption. :)
The real answer:
* The contents of the timestamp are never actually checked; the protocol only includes a timestamp there in a voodoo-like imitation of the ClientRandom field. The requirement is that there be _something_ in this position, and that the entire AUTHENTICATE cell be correctly signed.