3 ms·
You, me, or djb still have to select a curve -- that's where I expect the pitfalls will be.
by ohazi 6y ago
You, me, or djb still have to select a curve -- that's where I expect the pitfalls will be.
- ggm 6y agoLibsodium. Djb or his equivalent did that already and if there is a timing attack, it will get found and fixed faster.
- ohazi 6y agoI'm not referring to implementation bugs, I'm referring to choice of curve, which can't be changed after the fact. Look at the table at the bottom of: https://safecurves.cr.yp.to/ https://safecurves.cr.yp.to/ Today, Curve25519 is a good choice because it's popular and checks all the boxes. But how many undiscovered columns are in this table? My top level comment seems unpopular, so for what it's worth, I'll clarify that I definitely agree that there are fewer knobs for the non-cryptographer implementer to get wrong with ECC. But that's because the only way to implement an ECC system exactly as specified by the cryptographers. That's clearly an improvement over RSA, but I remain unconvinced that the cryptographers designing the curves are infallible. There are curves and curve parameters that, for various reasons, are bad. Maybe there's a proof that it's impossible to do better than Curve25519, but if there is, I haven't seen it, and tptacek would rather be snarky than provide a reference. Is it impossible for more columns to show up in that safecurves table? If so, prove it. Otherwise, I think my top level suspicion is reasonable.