[tor-dev] Quantum-safe Hybrid handshake for Tor

Yawning Angel 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:
> Hi,
> 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 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).


Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160303/2be1be26/attachment.sig>

More information about the tor-dev mailing list