What the developer wrote
Authored by Sebastian Falbesoner
changelog: add entry for #1821
Co-authored-by: Tim Ruffing <me@real-or-random.org>
What changed, and why it matters
This is a documentation-only commit that adds a changelog entry describing a previous code fix. The fix corrected a function in the ellswift module so it now rejects secret keys that are greater than or equal to the curve order, matching its documented behavior. The changelog explicitly states the old behavior is not considered a security issue because such keys are practically impossible to generate by chance.
No action required for this commit. If reviewing the related PR #1821, verify the code fix properly rejects secret keys >= curve order and returns 0 as documented.
Security signals we found
Changelog entry describes a prior behavior change in secret-key handling
Old behavior silently reduced out-of-range keys modulo the curve order
Vendor explicitly states old behavior is not a security issue
No code or cryptographic implementation changes in this commit
Evidence from the diff
The commit only modifies CHANGELOG.md to document pull request #1821. The entry explains that secp256k1_ellswift_xdh in the ellswift module now returns 0 for secret keys >= curve order, as documented, instead of silently reducing them modulo the order. The probability of a securely generated key falling into this range is negligible, and the project explicitly states this does not constitute a security issue. No code changes are present in this commit.
Changed components
CHANGELOG.mdModule ellswift (documentation reference only)Function secp256k1_ellswift_xdh (documented behavior only)Inspect captured patch +3 / −0
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 2145350..f9e892f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -14,6 +14,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
- Usage example `examples/silentpayments.c`.
- The `silentpayments` API currently requires full access to the transaction data (light client scanning is not implemented).
+#### Fixed
+ - Module `ellswift`: `secp256k1_ellswift_xdh` now treats secret keys greater than or equal to the curve order as invalid and returns 0 as documented. Previously, keys greater than the curve order were silently reduced modulo the order and accepted. The probability that a securely generated key is greater than the curve order is negligible, and thus the old behavior does not constitute a security issue.
+
#### Changed
- The field multiplication and squaring routines of the 5x52 (64-bit) implementation are now force-inlined. This speeds up many library functions with GCC and MSVC (Clang is largely unaffected), e.g. `secp256k1_ecdsa_verify` and `secp256k1_schnorrsig_verify` by up to ~11%, at the cost of a somewhat larger compiled library. Force-inlining is disabled in unoptimized builds and when optimizing for size.
- CMake: Shared libraries built with CMake on OpenBSD and NetBSD now create the full versioned filename (e.g. `libsecp256k1.so.6.2` instead of `libsecp256k1.so.6`) and symlink chain, matching the behavior of GNU Autotools builds.
Why this scored 19/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.