Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This commit fixes test code for the EllSwift module so that it actually checks whether encoding, decoding, and public-key loading operations succeed before using their outputs. Previously the tests silently ignored failure return values, w…
Missing return-value checks in cryptographic test codePotential silent test failures in EllSwift encode/decode roundtrip testsPotential silent test failures in public-key load operations
This commit only adds new test code. It extends the project's constant-time test suite to also exercise the silent payments module, ensuring that secret key material is not accidentally leaked through timing side channels during those oper…
Adds constant-time (side-channel) test coverage for the silent payments moduleUses memory-secret marking macros (SECP256K1_CHECKMEM_UNDEFINE/DEFINE) to detect secret-dependent branchesNo functional or cryptographic code changes
This commit adds a new feature to the secp256k1 cryptographic library: the sender-side logic for Bitcoin Silent Payments (BIP352). It lets a wallet create special one-time payment addresses for recipients without revealing which recipient …
New feature implementation for BIP352 Silent Payments sender sideExtensive input validation (ARG_CHECK) and test coverage for malformed keys and bad argumentsSensitive intermediate values (shared secrets, scalars) are explicitly cleared
This is a defensive code cleanup in a Bitcoin cryptography library. It introduces a helper function that wraps a common three-step pattern when multiplying by the generator point, ensuring that temporary sensitive Jacobian coordinate data …
New helper ensures intermediate Jacobian coordinates are always cleared after generator multiplicationCommit message states goal is to prevent accidental gej leaks of secret scalar informationRefactors existing call sites in ECDSA sign, Schnorr sign, pubkey creation, and blinding setup
This commit only fixes wording in the API documentation comments. It changes the description of a function output parameter from 'pointer to an array' to 'pointer to a signature object' in two header files. No actual code behavior changed,…
This is a small defensive cleanup in Bitcoin Core's libsecp256k1 MuSig code. The function that generates a cryptographic nonce could, in rare error cases, leave a temporary copy of the user's secret key in memory instead of wiping it. The …
secret-key material left uncleared on an error pathuse of explicit memory clearing (`secp256k1_memclear_explicit`) added to failure pathMuSig nonce generation function
This commit fixes a bug in the ElligatorSwift-based ECDH key exchange function. The function was supposed to reject secret keys that are invalid (zero or greater than or equal to the curve order), but due to a one-character bug it only che…
Cryptographic secret-key validation bypassSilent modular reduction instead of rejection for out-of-range secretsInconsistency with documented/referenced ECDH overflow handling
This commit is a straightforward code cleanup: it removes unnecessary type casts in front of memory allocation calls like malloc. In modern C, casting the result of malloc is not needed and is generally discouraged. The change does not alt…
This commit changes a CI Docker build script so that an older SHA-1-based PGP signature from the LLVM apt repository is still accepted. It is a build-infrastructure workaround, not a change to the secp256k1 cryptographic code, and it does …
Configuration relaxation of PGP signature policy in CI environmentUse of SHA-1 signature algorithm whitelisted by date extensionBuild-infrastructure-only change with no effect on shipped library
This commit adds safety checks and documentation to ensure that 'flag' values used in secret-handling code are exactly 0 or 1, not just any 'true' value. These flags control constant-time selection and memory wiping. If a caller passed a d…
constant-time masking invariant enforcementVERIFY_CHECK hardening for secret-dependent flag valuesdocumentation update clarifying 0/1 flag contract
This commit is a pure test-infrastructure change. It introduces a small internal unit-test framework for the secp256k1 cryptographic library, replacing a long hand-written main() function with a registry of test cases and adding optional p…
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Security candidateMerge bitcoin-core/secp256k1#1897: tests: check results before using outputsby merge-script · 687155df · Aug 4, 2026 · 8 filesMessage 96 · StrongTriage 0Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1897: tests: check results before using outputs
a2ad68cd81787ba70b2caff0a57998ae8a5b4834 ec: check pubkey sort test results (Lőrinc) 93280c22917c018f4e99d76e4398e66405c887bd silentpayments: check test serialization (Lőrinc) b8de1bc30f917c0ab9f05aeaeb494834e81513e2 musig: check infinity test setup (Lőrinc) 0618af81317307466e9968592880a54229885edc extrakeys: check test pubkey loads (Lőrinc) 1d3f72d3fa8e476cdc3344dbb5aebeaf7a6efe89 recovery: check exhaustive API results (Lőrinc) 564afb0b06e6124092fd6fa1239b1b397f742e41 ellswift: check test operation results (Lőrinc) 658c7edc24832592969ccbd1bdbc5c59e1ccc5d5 tests: check exhaustive ecmult success (Lőrinc)
Pull request description:
**Problem:** Several tests inspect outputs from deterministic operations without checking the result. The later output comparisons usually still exercise behavior, but a failed setup call can leave an output that accidentally satisfies a later assertion. In `pubnonce_summing_to_inf`, `secp256k1_musig_sum_pubnonces` initializes both sums to infinity before a pubnonce load can fail, so the test could pass without constructing a valid opposing-nonce pair.
**Fix:** Check the result of each deterministic operation before reading its output in the affected exhaustive, EllSwift, recovery, extrakeys, MuSig, silent-payments, and public-key sort tests. Leave deliberately ignored results alone when the test permits either result or validates a mutated value rather than an auxiliary carry, overflow, or sign flag.
ACKs for top commit: 151henry151: Tested ACK a2ad68cd81787ba70b2caff0a57998ae8a5b4834 real-or-random: utACK a2ad68cd81787ba70b2caff0a57998ae8a5b4834 theStack: ACK a2ad68cd81787ba70b2caff0a57998ae8a5b4834
sha256: cross-check caller supplied compression function
The existing selftest hashes one 63 byte string against a known digest. Which catches a compression function that is wrong everywhere, but not one that is wrong on multi-block calls, unaligned input, or a state that is not the IV.
This introduces secp256k1_sha256_smoke_test, which hashes messages of various lengths and starting offsets with both the supplied function and the built-in one, and fails if the digest differs.
The check runs once during startup, so a faulty compression function is caught early rather than silently producing incorrect output later.
Measured locally, this takes 1.5ms, which should be negligible for any application.
See the introduced test for a clear view of the bugs this catches.
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
✓ Descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
signing boundarydocumentation-only discount
Security candidateheader: Add note on SHA256 override and aux functionsby Tim Ruffing · 4147f8bd · Jul 29, 2026 · 1 fileMessage 58 · ThinTriage 15Details
Commit message · Tim Ruffing
header: Add note on SHA256 override and aux functions
Resolves one item in #1835.
58/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
Security candidateecdsa/ecdh: Use SHA256 override if known noncefp/hashfp is passedby Tim Ruffing · ed091bc4 · Jul 29, 2026 · 2 filesMessage 50 · ThinTriage 15Details
Commit message · Tim Ruffing
ecdsa/ecdh: Use SHA256 override if known noncefp/hashfp is passed
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
This context pointer has been deprecated since the rename to `_context_static` more than three and a half years ago (see PR #1126, commit 53796d2b24e813750feae73e85c0a6eee40dc391), for the first official release 0.2.0. Removing it should be fine by now.
71/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Remove deprecated `secp256k1_schnorrsig_sign` alias
This function has been deprecated since the rename to `_schnorrsig_sign32` more than three and a half years ago (see PR #1089, commit 99e6568fc6), before the first official release 0.2.0. Removing it should be fine by now.
71/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The exhaustive recovery tests decoded and verified signatures without requiring recoverable signing or conversion to succeed. Check those documented success results before consuming the outputs, matching the ordinary exhaustive signing test.
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The EllSwift tests inspected outputs without requiring encoding, decoding, or public-key loading to succeed. They also discarded the field parser result despite relying on its no-overflow precondition. Check each deterministic success result before inspecting its output.
83/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Informational 17/100
This commit fixes test code for the EllSwift module so that it actually checks whether encoding, decoding, and public-key loading operations succeed before using their outputs. Previously the tests silently ignored failure return values, which could hide bugs during testing but does not change the production library behavior or introduce a direct vulnerability in running software.
Security candidatesilentpayments: API docs and internal comment followupsby Sebastian Falbesoner · 0fa38f3d · Jul 23, 2026 · 3 filesMessage 86 · StrongTriage 15Details
Commit message · Sebastian Falbesoner
silentpayments: API docs and internal comment followups
Addresses follow-up comments and Claude nits from #1765, see - https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r3629070333 - https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r3628888249 - https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r3629066762 - https://github.com/bitcoin-core/secp256k1/pull/1765#pullrequestreview-4754517850
Note that the "hash output is not a valid scalar" error mentioning in the API docs for sending is dropped intentionally to reflect the scanning API docs, where we don't mention this negligible case either.
Co-authored-by: Tim Ruffing <me@real-or-random.org>
86/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The public nonce callback accepts `UINT_MAX`, but `nonce_function_rfc6979_impl` never returns for that attempt. Its `i <= counter` loop wraps after the final candidate and starts again.
Generate the candidate before checking whether it is the requested attempt. This preserves the result for every `unsigned int` attempt, including `UINT_MAX`, and exits before the index can wrap.
Co-authored-by: Tim Ruffing <me@real-or-random.org>
73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
cryptography-sensitive path
Security candidatesilentpayments: drop "shuffle outputs" recommendation from API docsby Sebastian Falbesoner · cea6d114 · Jul 20, 2026 · 1 fileMessage 50 · ThinTriage 15Details
Commit message · Sebastian Falbesoner
silentpayments: drop "shuffle outputs" recommendation from API docs
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Co-authored-by: Jonas Nick <2582071+jonasnick@users.noreply.github.com> Co-authored-by: Sebastian Falbesoner <91535+thestack@users.noreply.github.com>
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
constant-time or timing behavior
AI analysis · Informational 12/100
This commit only adds new test code. It extends the project's constant-time test suite to also exercise the silent payments module, ensuring that secret key material is not accidentally leaked through timing side channels during those operations. There is no change to the actual cryptographic library code that users rely on.
Add routine for scanning a transaction and returning the necessary spending data for any found outputs. This function works with labels via a lookup callback and requires access to the transaction outputs. Requiring access to the transaction outputs is not suitable for light clients, but light client support is enabled in a future release.
Add an opaque data type for passing around the prevout public key sum and the input hash tweak (input_hash). This data is passed to the scanner before the ECDH step as two separate elements so that the scanner can multiply the scan_key * input_hash before doing ECDH.
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification! Too few words to establish purpose
Add function for creating a label tweak. This requires a tagged hash function for labels. This function is used by the receiver for creating labels to be used for a) creating labeled addresses and b) to populate a labels cache when scanning.
Add function for creating a labeled spend pubkey. This involves taking a label tweak, turning it into a public key and adding it to the spend public key. This function is used by the receiver to create a labeled silent payment address.
Add a routine for the entire sending flow which takes a set of private keys, the smallest outpoint, and list of recipients and returns a list of x-only public keys by performing the following steps:
1. Sum up the private keys 2. Calculate the input_hash 3. For each recipient group: 3a. Calculate a shared secret 3b. Create the requested number of outputs
This function assumes a single sender context in that it requires the sender to have access to all of the private keys. In the future, this API may be expanded to allow for a multiple senders or for a single sender who does not have access to all private keys at any given time, but for now these modes are considered out of scope / unsafe.
Internal to the library, add:
1. A function for creating shared secrets (i.e., a*B or b*A) 2. A function for generating the "SharedSecret" tagged hash 3. A function for creating a single output public key
✓ Subject identifies a change✓ Provides detailed explanatory context! Too few words to establish purpose
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Informational 15/100
This commit adds a new feature to the secp256k1 cryptographic library: the sender-side logic for Bitcoin Silent Payments (BIP352). It lets a wallet create special one-time payment addresses for recipients without revealing which recipient is being paid on the blockchain. The change is a normal, well-documented feature addition with no indication of a security bug or vulnerability fix.
Security candidatebuild: add skeleton for new silentpayments (BIP352) moduleby Sebastian Falbesoner · a93e696a · Jul 14, 2026 · 8 filesMessage 62 · AdequateTriage 15Details
Commit message · Sebastian Falbesoner
build: add skeleton for new silentpayments (BIP352) module
62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
This affects both the sending and scanning API functions: * Sending fails if any group is exceeding the limit. * Scanning doesn't look beyond the limit.
Also add a recommendation to the API docs to shuffle the `tx_outputs` input array, which improves the worst-case by ~2x.
The macro is no longer used anywhere in the codebase. This is technically a breaking change, but it's not expected any user code actually uses this macro.
Co-authored-by: Tim Ruffing <me@real-or-random.org>
Security candidateUse __GNUC__ instead of SECP256K1_GNUC_PREREQby copilot-swe-agent[bot] · 09870e9c · Jun 17, 2026 · 2 filesMessage 85 · StrongTriage 15Details
Commit message · copilot-swe-agent[bot]
Use __GNUC__ instead of SECP256K1_GNUC_PREREQ
Replace all SECP256K1_GNUC_PREREQ version checks with plain defined(__GNUC__) checks, since the macro was only used for ancient GCC versions that are no longer worth supporting individually. Moreover, the macro was misleading because Clang claims to be GCC 4.2 by default.
All GCC versions that we reasonably support have the features previously gated behind these checks (__inline__, __builtin_expect, __restrict__, __warn_unused_result__, __nonnull__, and the __builtin_ctz* family).
Co-authored-by: Tim Ruffing <me@real-or-random.org>
85/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
cryptography-sensitive path
Security candidaterefactor: introduce `_ecmult_gen_ge` helper (preventing accidental gej leaks)by Sebastian Falbesoner · a3296d5e · Jun 7, 2026 · 5 filesMessage 100 · StrongLow 36Details
Commit message · Sebastian Falbesoner
refactor: introduce `_ecmult_gen_ge` helper (preventing accidental gej leaks)
Scalar multiplication with the generator point frequently involves a conversion to affine coordinates and clearing out the temporary Jacobian group element object after to avoid leaking secret key material, i.e. executing the following three steps: - secp256k1_ecmult_gen(ctx, &rj, ...) - secp256k1_ge_set_gej(&r, &rj) - secp256k1_gej_clear(&rj)
This commit introduces a corresponding helper to deduplicate code and mitigate the risk that last step is forgotten (which can easily happen and is not detected by tests).
The idea came up during a conversation with furszy, see https://github.com/bitcoin-core/secp256k1/pull/1765#issuecomment-4482838033
100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Low 36/100
This is a defensive code cleanup in a Bitcoin cryptography library. It introduces a helper function that wraps a common three-step pattern when multiplying by the generator point, ensuring that temporary sensitive Jacobian coordinate data is always wiped from memory. The change reduces the chance that a future developer forgets to clear that temporary data, which could theoretically leak tiny fragments of secret key information through memory side channels. It does not fix a known active bug or reported vulnerability.
Security candidatedoc: correct API docs for ECDSA signing out-params (s/array/signature object/)by Sebastian Falbesoner · 40a0d874 · Apr 29, 2026 · 2 filesMessage 55 · ThinInformational 15Details
Commit message · Sebastian Falbesoner
doc: correct API docs for ECDSA signing out-params (s/array/signature object/)
55/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Names security-relevant behavior explicitly! No meaningful explanatory body
Why it was queued
signing boundarycryptography-sensitive path
AI analysis · Informational 15/100
This commit only fixes wording in the API documentation comments. It changes the description of a function output parameter from 'pointer to an array' to 'pointer to a signature object' in two header files. No actual code behavior changed, so there is no security impact.
Security candidatemusig: always clear out secret key in `secp256k1_musig_nonce_gen_counter`by Sebastian Falbesoner · 8479eafa · Apr 28, 2026 · 1 fileMessage 73 · AdequateLow 34Details
Commit message · Sebastian Falbesoner
musig: always clear out secret key in `secp256k1_musig_nonce_gen_counter`
Even though `secp256k1_musig_nonce_gen_internal` can currently only fail if the API is misused (invalid `keypair` or `keyagg_cache` parameters), clear out the buffer holding secret key data as well in this case to follow best practices.
The issue was found and reported by l0rinc using GPT 5.5 (Thanks!).
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key material
AI analysis · Low 34/100
This is a small defensive cleanup in Bitcoin Core's libsecp256k1 MuSig code. The function that generates a cryptographic nonce could, in rare error cases, leave a temporary copy of the user's secret key in memory instead of wiping it. The patch makes sure the secret key buffer is always cleared, even when the internal function fails. The actual failure path can only be reached if the API is misused (bad keypair or cache), so this is best-practice hardening rather than an active exploit.
Security candidateecdsa: VERIFY_CHECK result of _fe_set_b32_limitby Tim Ruffing · 43fca0ff · Mar 23, 2026 · 1 fileMessage 68 · AdequateTriage 15Details
Commit message · Tim Ruffing
ecdsa: VERIFY_CHECK result of _fe_set_b32_limit
This also avoids a spurious "-Wmaybe-uninitialized" warning emitted by gcc 16 (snapshot) when compiling with -DDETERMINISTIC.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
Security candidateAdd API to override SHA256 compression at runtimeby furszy · 0753f8b9 · Mar 3, 2026 · 11 filesMessage 80 · StrongTriage 15Details
Commit message · furszy
Add API to override SHA256 compression at runtime
This introduces `secp256k1_context_set_sha256_compression()`, which allows users to provide their own SHA256 block-compression function at runtime.
This is useful in setups where the fastest implementation can only be determined dynamically based on the available CPU features, and rebuilding the library is not possible.
The callback is installed on the `secp256k1_context` and is then used by all operations that compute SHA256 hashes. As part of the setup, the library performs sanity checks to ensure that the supplied function is equivalent to the default transform.
Passing NULL to the callback setter restores the built-in implementation.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
