Vulnerability in x25519: no main subgroup check before scalar multiplication

[stark12381-wq]

This bug (or vulnerability) resembles GHSA-mrfv-m5wm-5w6w (https://nvd.nist.gov/vuln/detail/CVE-2025-69277) but affects checking of points for x25519 curve. Function crypto_scalarmult_curve25519_ref10 in file x25519_ref10.c doesn't perform check of main subgroup (like _crypto_scalarmult_ed25519 (for ed25519 curve) does by calling recently corrected function ge25519_is_on_main_subgroup). As far as there is implementation of check on main subgroup is done before scalar multiplication for ed25519 Edwards curve, it would be naturally from average user of library (say, without a PhD on implementation of ECC :) ) to expect the same functionality for x25519. But function crypto_scalarmult_curve25519_ref10 rejects only points from small subgroups. As result, points, that are not in small and at the same time not in the main subgroups can pass this check.
Best regards,
Oleg Taraskin

[jedisct1]

How do I validate Curve25519 public keys?

Don't. The Curve25519 function was carefully designed to allow all 32-byte strings as Diffie-Hellman public keys.

X25519 is the only operation implemented over Curve25519.

[stark12381-wq]

Yes, that's all correct for DH. But my concerns are not about DH, but basic ECC functionality like scalar multiplication of Curve25519 with crypto_scalarmult_curve25519_ref10 - it can be used in a bunch of different scenarios that are not DH at all (and not even something that looks like DH stuff (for example PAKE)). Please, take a look at xeddsa signature: https://signal.org/docs/specifications/xeddsa/. What regards ed25519, it occurs not only in signatures: PAKE implementation on ed25519 ( https://github.com/jedisct1/spake2-ee)
Good example of "custom" protocol that uses basic Libsodium ECC functionality (ed25519 for signatures and Ristretto for BulletProof+ ZKP ) is Monero CT (Confidential Transactions) (https://github.com/monero-project/monero). I believe that probability, that someone can also create such complex project (not exactly CT, but also something not trivial) with almost everything done "by hand", but with Curve25519, is not zero...
By the way, I've noticed that in 2017 Monero implemented their own main subgroup check function (https://github.com/monero-project/monero/blob/6f284e87790c5b9710e0c83e29f98afc3e2af650/src/ringct/rctOps.cpp#L239) to protect from double-spend attack (https://www.getmonero.org/ru/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html), instead of using Libsodium's vulnerable main subgroup check for ed25519 (now fixed). Anyway, I hope, that Libsodium community will perform more security reviews to catch such bugs.