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

William Whyte wwhyte at securityinnovation.com
Fri Mar 4 23:39:20 UTC 2016

On Thu, Mar 3, 2016 at 3:16 PM, Yawning Angel <yawning at schwanenlied.me>

> 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.

Also: if the client has a bad RNG, the client loses whether the material it
contributes to the eventual secret is secret or public.

> > 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
> RSA.
> Note: The Ring-LWE variant of this hybrid construct would fulfill the
> "both sides contribute material" clause (yay).

Just to be careful here, both sides do contribute material (because the QS
ciphertext, which is derived from P, is hashed into secret_input). The
difference is that the client doesn't contribute *secret* material.
However, it's hard to come up with an attack model in which this actually
matters, even though there are obviously more warm fuzzies if the secret
material comes from both sides.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160304/a12afec5/attachment.html>

More information about the tor-dev mailing list