Closed Lekensteyn closed 5 years ago
Regarding your suggestion to split generate into generateClient/generateServer, I have decided to do that for now since it would either result in some more code duplication or a special if/else case in kexHybridSIDHp503X25519.generate. This can be done later if desired.
As for renaming "Client" -> "Initiator" (the party that generates a key share first) and "Server" -> "Responder" (the party that receives the key share first before generating a new key share and shared secret), I think it might be more confusing for the TLS handshake so I have decided against it. I'll just add a comment to the ESNI code.
LGTM
The key agreement protocols only need a source of randomness for key generation and agreement (for KEM), and the role (client or server), so pass these explicitly.
Make keyAgreementClient and keyAgreementServer independent of the tls.Conn instance to allow reuse for ESNI.
In the TLS handshake, we have:
For ESNI, we have:
As you can see the roles are reversed. It didn't seem correct to call keyAgreementClient as a server and vice versa. Neither am I sure if the "Alice" and "Bob" role should be reversed for SIDH. For ESNI I plan to support ECDHE only.
TheThe kex interface is maintained, instead keyAgreementXxx have been made independent of Conn. For ESNI I simply do not use the PQ algorithms, so the difference between keyAgreementClient/Server does not matter.ecdheKex
interface is adapted for the TLS handshake (with PQ support), but for ESNI, this interface will directly be used.It is possible to specialize the "generate" method, for TLS it could receive "isClient" but in ECDHE there is no distinction so I could drop it. Thoughts?