On Fri, 22 Apr 2016 11:41:30 +0200 Jeff Burdges <burdges@xxxxxxxxxx> 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
Attachment:
pgpzbDQLs8IKG.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev