[tor-dev] Quantum-safe Hybrid handshake for Tor
yawning at schwanenlied.me
Thu Mar 3 20:16:58 UTC 2016
On Thu, 3 Mar 2016 16:33:42 +0000 (UTC)
lukep <lukep at tutanota.com> wrote:
> I'm trying to understand the hybrid protocol that's described here.
> The server generates the parallel secret PAR_SEC or P and then
> computes C = ENCRYPT( P | B | Y, QSPK);
> The client decrypts C to get P and then uses it combination with the
> ECC secret E: secret_input = E | P | QSPK | ID | PROTOID
> So E is secret, P is generated by the server, QSPK ID and PROTOID are
> all public. So IF ECC is broken and IF the server has been
> compromised (big IF's!) then everything is known.
If the server is compromised, the client loses regardless of handshake
mechanism because said compromised server has access to the plaintext.
> I guess my point is that the client isnt contributing any secret
> information to the quantum-safe part of KEY_SEED. Is that OK?
Yes. I'd rather both sides contribute, but since `P | B | Y` is
transmitted encrypted to a ephemeral key generated by the client,
baring the "the server is compromised" case (which is irrelevant)
the construct should hold.
See RFC 4432, RFC 5246 126.96.36.199 for this sort of thing being done with
Note: The Ring-LWE variant of this hybrid construct would fulfill the
"both sides contribute material" clause (yay).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the tor-dev