TL;DR
A flaw was found in libsodium's low-level function crypto_core_ed25519_is_valid_point that allowed some non–main-subgroup Ed25519 points to be accepted. The issue was fixed in packages released after December 30, 2025; most high-level libsodium APIs and common signing APIs were not impacted.
What happened
The libsodium maintainer discovered a bug in the low-level validation function crypto_core_ed25519_is_valid_point while testing batch signature support. The function was intended to reject any elliptic-curve point not belonging to the main Edwards25519 subgroup (order L). The previous implementation multiplied a point by L and only checked that the X coordinate became zero; it omitted confirming that Y equals Z in the internal projective representation. That omission let certain mixed-order points (for example, a main-subgroup point combined with the order-2 point) pass validation when they should have been rejected. The fix adds the missing Y==Z check after the multiplication so both X is zero and Y equals Z are required. The maintainer pushed corrected builds and updated packages immediately; a new point release will be tagged.
Why it matters
- Accepting points outside the intended subgroup can break assumptions in custom cryptographic protocols and may enable unexpected behavior when arithmetic over Edwards25519 is used directly.
- The bug affects a low-level validation primitive, so code that relies on that specific function to check untrusted points is at risk.
- High-level signing APIs and standard keypair generation routines were not using the flawed code path and are not affected.
- Ristretto255, which encodes points without cofactor complications, is presented as a safer alternative for new custom schemes.
Key facts
- The faulty function: crypto_core_ed25519_is_valid_point().
- Root cause: missing check that Y equals Z after multiplying a point by the subgroup order L; the code only checked X == 0.
- Affected releases: point releases <= 1.0.20 or any libsodium version released before December 30, 2025.
- High-level APIs (for example crypto_sign_*) are not affected and do not call this function.
- Scalar multiplication (crypto_scalarmult_ed25519) is not shown to leak information even for points outside the main subgroup.
- Immediate fixes were released: official tarballs, Visual Studio and MingW binaries, NuGet packages (including Android), swift-sodium xcframework, Rust libsodium-sys-stable, and libsodium.js.
- A new point release containing the fix was announced; updated stable packages are available after December 30, 2025.
- The maintainer noted that libsodium has had zero CVEs in its 13-year history prior to this disclosure.
What to watch next
- Upgrade to libsodium packages published after December 30, 2025 or to a point release newer than 1.0.20 if you use the low-level validation function.
- If your project performs custom Edwards25519 arithmetic or validates untrusted points with crypto_core_ed25519_is_valid_point(), review and test whether you relied on the previous behavior.
- Adopt Ristretto255 for new protocols to avoid cofactor and subgroup pitfalls when practical.
- CVE assignment or broader advisories: not confirmed in the source
Quick glossary
- Edwards25519: A widely used elliptic-curve form for cryptographic operations, often used by Ed25519 signature schemes.
- Subgroup (main subgroup / order L): A subset of curve points whose sizes equal a prime order L; cryptographic operations generally expect points to lie in this subgroup.
- Ristretto255: An encoding and group construction built on Edwards25519 that removes cofactor-related complexities so decoded points are guaranteed to be in the intended prime-order group.
- API: Application Programming Interface — a set of functions and protocols exposed by a library for other code to call.
- Scalar multiplication: An elliptic-curve operation that multiplies a point by an integer scalar, commonly used for key agreement and other primitives.
Reader FAQ
Am I affected by this bug?
You are affected if you use a libsodium release dated before December 30, 2025 (or <= 1.0.20) and you call crypto_core_ed25519_is_valid_point() on untrusted points or implement custom Edwards25519 arithmetic.
Are high-level signing functions impacted?
No. The source states that high-level crypto_sign_* APIs do not use the flawed function and are not affected.
What is the recommended fix if I cannot update libsodium immediately?
The maintainer provided an application-level workaround function in the announcement; alternatively prefer Ristretto255 or update to the fixed packages.
Has a CVE been issued for this vulnerability?
not confirmed in the source
A vulnerability in libsodium December 30, 2025 Libsodium is now 13 years old! I started that project to pursue Dan Bernstein’s desire to make cryptography simple to use. That meant…
Sources
- A Vulnerability in Libsodium
- libsodium's Curve25519 point validation conflicts with …
- Security Issues in Matrix's Olm Library
- How to defeat Ed25519 and EdDSA using faults
Related posts
- 2025 Ranks as Second-Hottest Year, Continuing Unexplained Recent Warming
- Lead administrator quits, leaving Cyber Trust Mark program’s future doubtful
- curl eliminates strcpy usage, extending its earlier strncpy ban