ecdsa/ecdh: Use SHA256 override if known noncefp/hashfp is passed
What the developer wrote
Authored by Tim Ruffing
ecdsa/ecdh: Use SHA256 override if known noncefp/hashfp is passed
What changed, and why it matters
This small change makes Bitcoin's cryptographic library treat two built-in functions (the default ECDSA nonce generator and the default ECDH hash function) as 'default' choices even when a caller explicitly passes them. The practical effect is that these built-in functions now receive the library context's hash function, which matters when the library is compiled with a custom hash implementation. Without this fix, a caller passing the same built-in function by name could accidentally bypass the context's hash function and use a different code path. There is no direct evidence in the commit of an exploitable vulnerability; it looks like a consistency/correctness fix.
Review whether any API documentation or release notes describe this as a security fix. If the project treats context hash overrides as a security boundary, consider backporting. Otherwise, treat as a normal correctness/consistency patch and ensure tests cover both NULL and explicit default function pointer paths.
Security signals we found
Behavioral alignment of default function pointers with context-aware hash implementation
Potential misuse path where explicit default function pointer bypassed context hash function
No explicit security claim, CVE, or vulnerability description in commit or references
Evidence from the diff
The patch modifies two call sites. In secp256k1_ecdsa_sign_inner, when noncefp is NULL OR equals secp256k1_nonce_function_rfc6979, it routes to nonce_function_rfc6979_impl with secp256k1_get_hash_context(ctx). In secp256k1_ecdh, when hashfp is NULL OR equals secp256k1_ecdh_hash_function_sha256, it routes to ecdh_hash_function_sha256_impl with the context hash. Previously only NULL triggered the context-aware path. This ensures callers who explicitly pass the library’s own default function pointer get the same context-aware behavior as callers who pass NULL. The change is defensive and aligns behavior, but the commit message and diff do not describe a concrete security bug or attack.
Changed components
src/modules/ecdh/main_impl.hsrc/secp256k1.cECDH module (secp256k1_ecdh)ECDSA signing (secp256k1_ecdsa_sign_inner)Context-aware hash function routingInspect captured patch +2 / −2
diff --git a/src/modules/ecdh/main_impl.h b/src/modules/ecdh/main_impl.h
index b0359b2..03c47ad 100644
--- a/src/modules/ecdh/main_impl.h
+++ b/src/modules/ecdh/main_impl.h
@@ -60,7 +60,7 @@ int secp256k1_ecdh(const secp256k1_context* ctx, unsigned char *output, const se
secp256k1_fe_get_b32(x, &pt.x);
secp256k1_fe_get_b32(y, &pt.y);
- if (hashfp == NULL) {
+ if (hashfp == NULL || hashfp == secp256k1_ecdh_hash_function_sha256) {
/* Use ctx-aware function by default */
ret = ecdh_hash_function_sha256_impl(secp256k1_get_hash_context(ctx), output, x, y, data);
} else {
diff --git a/src/secp256k1.c b/src/secp256k1.c
index 91b9e82..de59f44 100644
--- a/src/secp256k1.c
+++ b/src/secp256k1.c
@@ -559,7 +559,7 @@ static int secp256k1_ecdsa_sign_inner(const secp256k1_context* ctx, secp256k1_sc
while (1) {
int is_nonce_valid;
- if (noncefp == NULL) {
+ if (noncefp == NULL || noncefp == secp256k1_nonce_function_rfc6979) {
/* Use ctx-aware function by default */
ret = nonce_function_rfc6979_impl(secp256k1_get_hash_context(ctx), nonce32, msg32, seckey, NULL, (void*)noncedata, count);
} else {
Why this scored 32/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.