Assuming you are talking about the Renes–Costello–Batina formulas, they're complete, but not necessarily efficient. According to [1], optimized short Weierstrass with the complete formulas is still 1.5 to 3 times slower than Curve25519. I imagine the numbers won't be much better for Edwards25519, either. There's definitely a ton of potential for a better complete addition formula on Weierstrass still left.
> Ristretto is nice but so terribly complex
Ristretto is nice, terribly complex, and you don't actually need to care about the conceptual complexity. As an implementer, your only job is to execute the explicit formulas in section 5 of the Ristretto website. You do not have to be able to follow the hard math (just how you do not have to be able to follow the hard math involved in making the explicit formulas). Plus the entire thing can be trivially constant-time given a constant-time selection primitive and constant-time field arithmetic. It's not that much more difficult than doing regular point compression on your own.
[1] Peter Schwabe, Daan Sprenkels. The complete cost of cofactor h=1 (published in INDOCRYPT19), https://eprint.iacr.org/2019/1166.pdf
There were always more efficient formats (binary curves, extension fields) but they never caught on, so efficiency isn't everything.
From a cursory reading, shouldn't that paper compare timings with a Ristretto implementation? The overhead may be small but must be measured for a fair comparison.
It's good to know that implementing Ristretto is much easier than understanding it - that website is very intimidating ;) I need to study it more.
I don't think one should blindly follow an instruction without understanding why in any fields, let alone in crypto where a small, subtle difference can make or break it. Also, understanding crypto requires less math than inventing (and attacking) crypto, so it takes some effort, but it's doable even for hobbyists. If the math makes one uncomfortable, maybe one shouldn't try to roll their own crypto for production use in the first place.
Case in point: the author of this article that we're commenting on made a deadly mistake because they did not understand the math behind point conversion between Ed25519 and Curve25519 [1].
Below I also point out a mistake in their claim about malleability in EdDSA.
[1] https://www.reddit.com/r/crypto/comments/8toywt/critical_vul...
But many smart people made many such mistakes in the past. If we gatekeep it to much then we won't have anyone left to implement crypto.
First, some Maverick is going to ignore what everyone says and implement crypto for serious applications. Like yours truly.
Second, I've seen it go a bit too far when I implemented Argon2i: there was a discrepancy between the specs and the reference implementations, and the authors haven't corrected the specs. I figured this was because not enough independent implementers bugged them about that. (Now, 3 years later, the specs still aren't fixed, so maybe the authors are really really busy. At least but the issue is still open: https://github.com/P-H-C/phc-winner-argon2/issues/183 )
I said if one isn't comfortable with the math, maybe don't try to roll one's own crypto and advertise or use it as production-grade crypto.
Crypto is deep. You can get involved at the levels you feel comfortable with.
By the way, since you seem to work on Wycheproof: would you take a look at my pull request? The EdDSA test vectors would have saved me (and my users), but the front page didn't mention them, so I didn't know they even existed for over a year. I initially believed you were concentrating on other, even more error prone, primitives.
Others might be in my position: letting bugs through because they think Whycheproof is not relevant to their project. A pity, considering how amazing Whycheproof is (I'm now systematically integrating any new test vector I learn about).
Wish ristretto folks added the library to their website though.
This is not the only motivating factor for curve25519. There is also: that montgomery curves work well with the montgomery ladder, which is easy to use in constant time, and that any 32-byte string is a valid public key for ECDH.
> Now we are stuck with all these cofactor issues.
They are not a major problem for ECDH. If you are doing only ECDH and don't care about group structure, you can simply use the existing clamping mitigations.
The point of ristretto, and its precursor/similar project decaf, is to preserve group structure while using these curves, and also eliminating small subgroups.
You can also have Montgomery ladder an a 32-byte encoding with Weierstrass curve, even though it would be slower.
> The point of ristretto, and its precursor/similar project decaf, is to preserve group structure while using these curves, and also eliminating small subgroups.
Exactly. Because we are stuck with all these cofactor issues. Not to mention how clamping also "contaminated" EdDSA.
[0] https://datatracker.ietf.org/doc/draft-hdevalence-cfrg-ristr...
I kind of hope they'll also add ristretto448 since RFC 7748 and 8032 include X448/Ed448, so that the draft has feature parity (and covers the h = 4 case properly).
[1] https://mailarchive.ietf.org/arch/msg/cfrg/3RRpX9hME5ErtAzCo...
[2] https://mailarchive.ietf.org/arch/msg/cfrg/wd8pprUfJoNhvEQE0...
[3] https://mailarchive.ietf.org/arch/msg/cfrg/pT2ML68BapPAcUiSk...