Those who seek to go a step further and actually implement elliptic curves should see the ECC Hacks talk by djb and Tanja Lange: https://www.youtube.com/watch?v=vEt-D8xZmgE
A couple claims there are a little outdated (we now have better ways of dealing with short Weierstraß curves), but the advice there is sound.
> we now have better ways of dealing with short Weierstraß curves
We do? The complete Renes/Costello/Batina formulas for point addition are significantly slower at a factor of 1.4.[1] The complete formulas presented by Hamburg are still somewhat slower than what you can get on twisted Edwards and almost certain to be patent encumbered by the end of the year.[2] Did I miss something?
SafeCurves discounts Renes/Costello/Batina and the like because “many of these formulas are considerably slower and more complicated than standard incomplete scalar-multiplication formulas, creating major conflicts between simplicity, efficiency, and security”.[3]
Correct, but my point was that even if they're slower, we do have complete formulas that aren't the nightmare djb describes.
I do reckon however that having to chose between speed and safety is a big problem. Someone is bound to go the fast route and screw up some special case, or leak timing information.
I didn't know about possible patents, that sucks. (I live in the EU though, so I can still give them the finger if I need to.)
In any case, the best general purpose thing we have now is probably Decaf/Ristretto over (twisted) Edwards curves. Fast complete formulas and a prime order group. Dealing with the cofactor is not too hard, but it's not trivial either: http://loup-vaillant.fr/tutorials/cofactor
(I still love Montgomery curves for variable base scalar multiplication.)
> I didn't know about possible patents, that sucks. (I live in the EU, though, so I can still give them the finger if I need to.)
Hamburg made this IP risk pretty clear in the paper, for a bit more context on it, see [1]. Because in the U.S. you have a full year before you even need to file a patent after publishing, we'll still have to wait and see if Hamburg's employer files a patent on his method. If they don't, nice; if they do, fucking hell this is why we can't have nice things. Renes/Costello/Batina is unencumbered as far as I know.
I have no idea. I'm self taught, and I tend to limit myself to implementation techniques. My tutorials on the subjects are mostly implementation focused:
If you want a to get this stuff into your head reasonably fast, go implement a curve. Then do it again, but in Rust (or C) and in constant-time. Then do it again, but actually computationally efficiently (i.e. optimize the hell out of a Rust or C implementation once it works). Choose a different curve each time. Then go and cook your own curve for shits and giggles.
You may easily spend a year upwards on this, but by the time you're done, you've basically run into every resource worth knowing about and are able to decently reason about elliptic curves (but by no means are in a position to write papers still).
Basically, doing this now. I tried to implement x25519 in a highly optimized way in cpp/c and I’m in my 8 month. I dogged through countless of articles and learned a ton of abstract algebra. Though, I still feel like a beginner in this field.
I’ve done a few hard projects in my career (compilers, and graphic editor). And I think implementing a elliptic curve in a optimized way, without a math library, must be one of the hardest thing in programming.
A couple claims there are a little outdated (we now have better ways of dealing with short Weierstraß curves), but the advice there is sound.