On Fri, 29 Apr 2016 20:54:18 +0200 Jeff Burdges <burdges@xxxxxxxxxx> wrote: > On Sun, 2016-04-03 at 15:36 +0000, Yawning Angel wrote: > > http://cacr.uwaterloo.ca/techreports/2014/cacr2014-20.pdf > > > > Is "optimized" in that, it is C with performance critical parts in > > assembly (Table 3 is presumably the source of the ~200 ms figure > > from the wikipedia article). As i said, i just took the > > performance figures at face value. > > > > I'm sure it'll go faster with time, but like you, I'm probably not > > going to trust SIDH for a decade or so. > > There is a new SIDH library from MS Research : > https://eprint.iacr.org/2016/413.pdf > https://research.microsoft.com/en-us/projects/sidh/ Yeah, it's neat and I'm glad people are poking at it (I honestly do like the paper). On a i7-5600U (Turbo Boost, Planatary Alignment, etc grain of salt), Alice's side of the SIDH benchmarks at: * ~25 ms (Generate/Exchange) * ~40 ms (Generate/Validate/Exchange) Using BigMont adds a few ms, while I think it's cute, X448 exists. (Yes, I know 384 bits > 224 bits, but it's not worth the perf/key size penalty for what amounts to "using bigger numbers makes my Tin Foil Hat crinkle less"). ... and in the context of tor, we do X25519 on the side anyway ... The general construct in the Tor proposal is flexible as to which PQ key exchange algorithm is used, so I'm some what more inclined to push for shipping something that is deployable sooner (being wrong here at worst means having to switch algorithms), than waiting for things to solidify more. Regards, -- Yawning Angel
Attachment:
pgpO9TCgeJcEK.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev