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

Yawning Angel yawning at schwanenlied.me
Fri Apr 22 11:10:27 UTC 2016


On Fri, 22 Apr 2016 11:41:30 +0200
Jeff Burdges <burdges at gnunet.org> wrote:
> I'd imagine everyone in this thread knows this, but New Hope requires
> that "both parties use fresh secrets for each instantiation".  

Yep.  Alice can cache the public 'a' parameter, but everything else
needs to be fresh, or really really bad things happen.

> I suppose any key exchanges designed around this meshes well enough
> with ntor, so that's okay.  It leaves you relying on ECDH for the key
> exchange with long term key material though. 

Or having a mythical "usable" PQ signature algorithm and doing SIGMA-I
or SIGMA-R.

> I have not read the papers on doing Ring-LWE key exchanges with long
> term key material, but presumably they increase the key side. 

It's not a massive priority now because active adversaries with quantum
computers aren't going to exist for a while IMO.

> On Wed, 2016-04-20 at 19:00 +0000, Yawning Angel wrote:
> > And my gut feeling is RingLWE will have performant, well defined
> > implementations well before SIDH is a realistic option.  
> 
> This is undoubtedly true because too few people are looking into
> SIDH. 
> 
> I've been chatting with Luca about writing a "more production ready"
> implementation, like optimizing the GF(p^2) field operations and
> things. If that happens, maybe it'll spur more interest. 

I'll be looking forward to seeing the results.

> There is some chance SIDH might wind up being preferable for key
> exchanges with long term key material. 

Maybe.  Some people have hinted at an improved version of SPHINCS256
being in the works as well.  SIDH will result in less bytes on the wire
(which is a major advantage in it's favor).

nb: I'm not totally dismissing SIDH, and I do think it has potential.
That said, engineering efforts to protect against "giant datacenters
in Utah" is something that should have been started a decade ago, and
getting something that is adequate and deploy-able "soon" is more
important to me than "waiting on perfection".

-- 
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/20160422/fa771070/attachment-0001.sig>


More information about the tor-dev mailing list