The timestamp field in auth.proto (line 20) is a uint32 carrying minutes since the project epoch. The comment describes it as a "replay-prevention nonce" checked to be "within one minute" of the Node's clock.
Because the field has minute-level granularity, every Auth message sent within the same 60-second period carries the identical timestamp value. A captured frame can be replayed at any point during that window without the check failing. The one-minute acceptance range makes this worse: a frame prepared at second 0 of minute M passes the Node's check until the end of minute M+1, giving an attacker up to 119 seconds to replay it. A true nonce must be unique per message, not per minute.
Change uint32 timestamp = 2 to uint64 carrying milliseconds since the Unix epoch, matching the type and unit already used by Ping.timestamp (ping.proto, line 16). Update the HMAC binding comment on line 22 to reflect the new serialized representation.
The
timestampfield inauth.proto(line 20) is auint32carrying minutes since the project epoch. The comment describes it as a "replay-prevention nonce" checked to be "within one minute" of the Node's clock.Because the field has minute-level granularity, every
Authmessage sent within the same 60-second period carries the identicaltimestampvalue. A captured frame can be replayed at any point during that window without the check failing. The one-minute acceptance range makes this worse: a frame prepared at second 0 of minute M passes the Node's check until the end of minute M+1, giving an attacker up to 119 seconds to replay it. A true nonce must be unique per message, not per minute.Change
uint32 timestamp = 2touint64carrying milliseconds since the Unix epoch, matching the type and unit already used byPing.timestamp(ping.proto, line 16). Update the HMAC binding comment on line 22 to reflect the new serialized representation.