ahdinosaur / secret-handshake2

🤝 Mutually authenticating key agreement to establish shared secrets over an insecure channel.

Secret Handshake v2

Mutually authenticating key agreement to establish shared secrets over an insecure channel.

A protocol for a secure key exchange, before a secure message stream.

(Note: This version has not been audited to be safe. Use at your own risk.)

Previous

• Original Paper: "Designing a Secret Handshake: Authenticated Key Exchange as a Capability System"
• Version 1: Scuttlebutt Protocol Guide: Handshake

Spec

(DRAFT)

See SPEC.md

Erotica o.O

See EROTICA.md

secret-handshake2's Issues

Responder's first reply

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).