Fix CVE-2025-69277.

[loganaden]

Summary

libsodium CVE CVE-2025-69277 is about missing checks for ed25519 digital signature.

Backported from libsodium upstream.

[CLAassistant]

All committers have signed the CLA.

[joe-p]

None of the high-level APIs are affected and go-algorand doesn't seem to use crypto_core_ed25519_is_valid_point directly, so I don't think this is a necessary change for go-algorand.

https://00f.net/2025/12/30/libsodium-vulnerability/

[loganaden]

@joe-p Got it. What about the downstream projects who forked from go-algorand ?

[joe-p]

crypto_core_ed25519_is_valid_point isn't even exposed anywhere in go-algorand, so if a fork is using the same vendored libsodium AND using crypto_core_ed25519_is_valid_point in newly written code then they would need to update

[cce]

In fact in #3031 in 2022, we added ge25519_is_neutral_vartime and ge25519_is_canonical_vartime as part of hardening the ed25519 validation criteria beyond libsodium's rules and supporting batch verification; these provide similar protection against edge cases like the libsodium bug (though we've never relied on the low-level method crypto_core_ed25519_is_valid_point from this CVE). Additionally, Algorand team members are credited in Taming the many EdDSAs for helping spot an ambiguity similar to this CVE's bug in that paper's is_canonical_y check implementation.

As explained in the "Taming the many EdDSAs" paper and It's 255:19AM. Do you know what your validation criteria are? different ed25519 implementations may have different and changing validation rules — for example, libsodium changed its ed25519 validation criteria between versions 1.0.15 and 1.0.16 — so when #3031 and #6440 were developed we were already aware of the need for having consistent and strict validation criteria for signature validation.