Responder's first reply

[staltz]

Fix mismatch with Secret Handshake paper

In the Secret Handshake paper, the responder's first reply is:

$$b_p, hmac[K|a*b](b_p)$$

i.e. the HMAC key is the network key and and product of the new ephemerals keys.

In Secret Handshake v1, the responder's first reply was:

$$hmac[K](b_p), b_p$$

i.e. the HMAC key is only the network key.

(And the order of concatenation is reversed.)

Secret Handshake v2 makes sure to follow the paper for this HMAC key.

Secret Handshake v2 also follows the paper for the order of concatenations on the first two messages:

• Initiator Hello: $a_p, hmac[K](a_p)$
• Responder Hello: $a_p, hmac[K|a*b](a_p)$

Because this is consistent with the ordering of (ciphertext, auth_tag) in ChaCha20-Poly1305 (IETF).

What was the motivation here? To follow the paper more closely? In that case, we might want to check with Dominic and/or Keks if there was a reason why the implementation differed from the paper. In my experience, sometimes papers/concepts are written before implementation and may not be the most accurate description of the real-world algorithm (specs would be).

[ahdinosaur]

oops, i forgot to link to auditdrivencrypto/secret-handshake#7.

the missing step in the implementation was by accident. but it also doesn't have meaningful security implications. i figured it's best to add the missing step from the paper, since there's an elegance where every step gets one more shared secret, and i reckon the paper has been peer reviewed more than the implementation has (because i noticed the paper about the vulnerability used the logic in the paper, not the implementation).

as for the concat order differences, i reckon the implementation diverged to be consistent with secretbox. i'm changing the order back to be consistent with my replacement for secretbox.

[staltz]

Great! I'm onboard.