lukep@tutanota.com transcribed 8.8K bytes:
- Aug 2016 15:07 by isis@torproject.org:
So it's not an either-or situation for proposals #269 and #270 — they are entirely compatible and #269 is meant to provide modularity.
Thanks - that wasn't clear to me, although I can see that they are aiming in the same direction. I agree with the principle of separating out the handshake from the protocol for modularity, but I don't think that's quite been achieved and there's some overlap/confliction between the two of them. For example in how the hybrid secret key is computed.
In #269, in the hybrid DH-KEM handshake it's computed as:
s0 := H(DH_MUL(A,x))
s1 := DH_MUL(Y,x)
s2 := KEM_DEC(C, esk)
secret := s0 | s1 | s2
On the other hand in #270, in the X25519-Newhope handshake it's computed as:
NTOR_KEY := NTOR_SHAREDA(x, X, Y, Z, ID, AUTH)
NEWHOPE_KEY := NEWHOPE_SHAREDA(M, a)
sk := SHAKE-256(NTOR_KEY || NEWHOPE_KEY)
As it stands, secret and sk are computed in a contradictory manner; these could be reconciled so they are the same, but if you are trying to write modular proposals the handshake algorithm should only be specified in one document. I think the method of computing the secret should be specified in #270 (only), and the protocol (depending on a call to the DH-KEM key exchange) should be specified in #269.
Thanks for pointing this out! The SHAKE-256() call should actually be added to #269, since it's acting as a replacement for the HKDF at the end of the original ntor handshake, and it should be performed regardless of choice of PQ KEM.
Best regards,