proposal for a new hash in authenticated SENDMEs
Version 1 SENDME cells' reuse of the SHA-1 rolling hash calculated for the 'Digest' field in RELAY cells creates an interdependency between the definitions of RELAY cells and SENDME cells, which makes it more difficult to eventually migrate away from the Relay protocol's current bespoke MAC-then-encrypt construction in the future.
A new SENDME cell version could have an independent, self-contained definition like:
- "When constructing a SENDME cell to send to an OR, the DIGEST must contain a [pick an algorithm] hash over the unencrypted payloads of all RELAY_DATA cells received from the OR since the previous SENDME was triggered, or, if this is the first SENDME, of all RELAY_DATA cells received from the OR so far. In other words, every RELAY_DATA cell is included in exactly one SENDME cell's hash."
The new hash should be one that's much faster to calculate than SHA-1.
Candidate: BLAKE2
BLAKE2 is the fast, standard generic hash used by libsodium and defined in RFC 7693.
OpenSSL added EVP_blake2b512()
in 1.1.0, released in 2016.
NSS technically added an implementation in 2017, but exposing BLAKE2 in the public api was blocked until it was standardized as a mechanism in PKCS #11. It's since been standardized as CKM_BLAKE2B_512
in v3.0.
Candidate: BLAKE3
BLAKE3 is faster than BLAKE2, partly because it uses only 7 rounds instead of 10. It's also much, much newer and is not as widely implemented.
Candidate: Poly1305
Poly1305 is a MAC rather than a hash, and is fast, but technically it doesn't seem to be designed for collision resistance. It was added to OpenSSL in 1.1.0.