On Fri, 29 Apr 2016 20:54:18 +0200 Jeff Burdges burdges@gnunet.org 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,