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

[William Whyte]

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

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

Cheers,

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