OSC-2026-0007 · github.com/rust-bitcoin/rust-secp256k1
info clean-run claude-fable-5 2026-08-04 signed: nostr
- Repository
- github.com/rust-bitcoin/rust-secp256k1
- Commit
- 9fc86f756f0cd24a5167c131551b31b748c8cdb3
- Scope path
- src/ecdsa/mod.rs
- Model
- claude-fable-5
- Harness
- claude-code
- Prompts
- prompts/entropy-rng-audit-v1.md
- Independent runs
- 1
- Transcript sha256
- 1e59ef7ad726b8aa20453152226b2739cd54d1df99578c3db57070e5d8ad4529
- Auditor
- TheIcarusWings (theicaruswings)
- Signature
- nostr-schnorr · npub19tzp8lf3klmqj3dz9mz0qnuvjp7uyy9993gmljmyaxs8phztj7wsnujvq5
Scope. ECDSA nonce generation in the signing path of the Rust bindings at HEAD 9fc86f75, the layer beneath BDK, LDK and Liana. In scope: which nonce function the bindings select, whether randomness is introduced, and whether a fallback implementation could be selected silently. EXPLICITLY NOT in scope: libsecp256k1 itself (the correctness of secp256k1_nonce_function_rfc6979 is an upstream property and would need its own attestation), Schnorr/BIP-340 paths, ECDH, key generation helpers, and the rand feature's use in keypair generation.
Findings
info OSC-2026-0007-F1 unreviewed
No weakness found in scope. Both ECDSA signing entry points explicitly pin libsecp256k1's deterministic nonce function (ffi::secp256k1_nonce_function_rfc6979, src/ecdsa/mod.rs:249 and :302), so signing consumes no RNG at all and the Coldcard failure class - a weak or silently-substituted random source backing key material - cannot arise on this path. The variant accepting caller-supplied extra data keeps the nonce a deterministic function of (key, message, extra data) rather than introducing randomness, so it cannot produce a repeated nonce across different messages, which is the condition that leaks a private key. Unlike embit (OSC-2026-0004), there is no pure-Rust fallback implementation that could be selected silently, so no equivalent silent-degradation risk exists. Scope boundary stated plainly: this covers the bindings, not libsecp256k1 itself.