lukep@xxxxxxxxxxxx transcribed 8.8K bytes: > 5. Aug 2016 15:07 by isis@xxxxxxxxxxxxxx: > > 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, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev