A Vulnerability in Libsodium

This also affected the PHP library, sodium_compat. https://github.com/FriendsOfPHP/security-advisories/pull/756

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.

I've been iterating on sodium bindings in Lean4 for about four months, and now that I've gotten to Ristretto255 I can see why the author is excited about its potential. Ristretto is a tightly designed API that allows me to build arbitrary polynomials on Curve25519 and I've been having a blast tinkering and experimenting with it! If the author by chance reads this, just want to say thank you for your work!

   Libsodium’s goal was to expose APIs to perform operations, not low-level functions. Users shouldn’t even have to know or care about what algorithms are used internally. This is how I’ve always viewed libsodium.
   ...
   Over the years, people started using these low-level functions directly. Libsodium started to be used as a toolkit of algorithms and low-level primitives.

The important point is to be able to recognize that and not coerce users into using your project only how you envisioned it and only like that. Some projects are failure on that count having switched on dictatorial direction on that aspect.

Subtle but important bug. This is a good example of how “is valid” checks in crypto are rarely as simple as they sound. Accepting points outside the prime-order subgroup can quietly undermine higher-level assumptions, even if no immediate exploit is obvious. Also a reminder that low-level primitives tend to be reused far more widely than intended, so small validation gaps can have surprisingly large blast radii.

If you work for a big company, consider trying to get Frank sponsored by your company.

Is libnacl affected

I use software compiled with libnacl every day but none compiled with "libsodium"

Such a great library. Thank you Frank Denis