I'm planning to spend my evening checking every other Ed25519 implementation I can find to see if this check is missing any where else in the open source ecosystem.
If you didn't receive an email from me, either your implementation isn't listed on https://ianix.com/pub/ed25519-deployment.html, I somehow missed it, or you're safe.
The bindings are set and have a monadic interface, but there's some abstractions that still need refining/iterating: mostly I want to be able to formalize keyboard input and eventually build a tactic framework for zero-knowledge proofs.
And for those use cases, I personally try my best to just reproject everything back into the prime order subgroup whenever possible. Monocypher has a number of such fancy functions:
crypto_x25519_dirty_fast()
crypto_x25519_dirty_small()
crypto_elligator_map()
crypto_elligator_rev()
crypto_elligator_key_pair()
That’s where I thank DJB for designing a key exchange protocol that project the shared secret to the prime order subgroup, even when the public key it processes is not. The original intent may have been to make checks easier (low order keys all end up yielding zero), but a nice side effect is how it enabled a nice API for Mike Hamburg’s Elligator2.
> Accepting points outside the prime-order subgroup can quietly undermine higher-level assumptions, even if no immediate exploit is obvious.
If on the other hand we can prove that all computed results are low-order-component-independent (as is the case for X25519), then we know for sure we’re safe. In the end, Ristretto is only really needed when we can’t tweak the protocol to safely reproject to the prime order subgroup.
Don’t get me wrong, having a prime order group abstraction does help. But if someone is qualified to design a protocol that may require this, they’re qualified to try and make it work with a non-trivial cofactor as well — that, or prove it cannot be done.
If libsodium is useful to you, please keep in mind that it is maintained by one person, for free, in time I could spend with my family or on other projects. The best way to help the project would be to consider sponsoring it, which helps me dedicate more time to improving it and making it great for everyone, for many more years to come.
Hope that helps.
However, donating money to an open collective is prohibitively hard for most big companies. Maybe the world should be different (or maybe not, since it would be easy for employees to embezzle money if they could direct donations easily), but that's how it works currently.
AFAICT, there is also no fiscal sponsor, so the donation matching suggested in a sister comment won't apply.
This is why Geomys (https://geomys.org) works the way it does, and why it has revenue (ignoring the FIPS and tlog sides of the business) which is 30-50x of some GitHub Sponsors "success stories": we bill in a way that's compatible with how companies do business, even if effectively we provide a similar service (which is 95% focused on upstream maintenance, not customer support).
I am not saying it's for everyone, or that Frank should necessarily adopt this model, or that it's the only way (e.g. the Zig foundation raises real amounts of money, too), but I find it frustrating to see over and over again the same conversation:
- "Alice does important maintenance work, she should get professionally funded for it!"
- "How does Alice accept/request funding?"
- "Monthly credit card transactions anchored at $100/mo that are labeled donations"
- no business can move professional amounts of money that way
- "Businesses are so short-sighted, it's a tragedy of the commons!"
Anyway, looking at the model you propose, it seems like the main difference is that Frank just doesn't explicitly say "you can retain my services"? Is that all that's stopping Apple from contacting him and arranging a contract?
Having spent the last ~6 years in big tech consistently frustrated by the rigidity of the processes and finding clever ways to navigate (see: wade through the bullshit), this isn’t as easy as you’d hope. The problem is that someone has to spend a non-trivial amount of time advocating internally for something like this (a “non-standard process”) which generally means asking pinging random people across finance, procurement, and legal how to deal with it and 99% of people will just throw up their hands (especially in this case because they don’t understand the importance of it). If things don’t fit a mold in these big companies, they fall into the event horizon and are stretched out to infinity.
Otherwise, I agreed with him, and am genuinely curious whether the stopping factor here is maintainers like Frank simply not saying "you can email me to retain my services"
But it is on a case by case basis, and it does take work to get the IRS to accept it.
https://www.apple.com/careers/us/life-at-apple/benefits.html