- 73comments
- 60comments
- 460comments
- 5comments
- 114comments
- 1comments
- 197comments
- 12comments
- 147comments
- 41comments
- 62comments
- 211comments
- 3comments
- 4comments
- 14comments
- 71comments
- 191comments
- 44comments
- 16comments
- 32comments
- 27comments
- 1comments
- 4comments
- 33comments
- 339comments
- 43comments
- 11comments
- 84comments
- 30comments
- 38comments
I could be reading this wrong but in the article it seems like SI has the advantage of key size and SL has the advantage of performance. I understand the sentiment of subtle bugs in elliptic-curve implementations and the new field of Supersingular-Isogenies, but in general algorithms are optimized and improved, but key sizes don't change too much.
If that's the case, why go with SL over SI?
It's possible that new primitives based on the same SI problem might have significant performance differences, but we're basing this on the NIST round one submissions. In that setting, there's been a decent amount of optimisation done already and the performance gap is two orders of magnitude. Since elliptic-curve implementation is pretty well studied, improvements might close that gap a little, but it's unlikely to make vast differences.
So it's a balance between adding an extra ~1.5 kB to the transaction, verses that CPU difference. In different contexts those two costs will have different weights, of course, but my feeling is that in TLS, we probably want to pay for the extra bytes.
If I am reading this correctly, there is one SI submission, SIKE. Microsoft is intimately involved, although it appears that Amazon, Texas Instruments, and Infosec have made major contributions.
https://github.com/Microsoft/PQCrypto-SIKE
A bunch of work on making Supersingular Isogeny DH (what SIKE is based on) viable was done at Microsoft Research.