AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 26 Bitcoin

sha256: cross-check caller supplied compression function

Public commit record

What the developer wrote

Authored by furszy

83/100 · Strong
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.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit strengthens the library's startup self-test for SHA-256 compression functions that users can plug in. It adds a more thorough 'smoke test' that compares the user-supplied function against the built-in one across many message lengths and memory alignments. The goal is to catch buggy or incompatible custom SHA-256 code early, before it silently produces wrong hashes. It is a defensive hardening change, not a fix for an active security hole.

Recommended action

No urgent action is required. Users who build libsecp256k1 with a custom SHA-256 compression function should ensure the new smoke test passes at context creation time. Downstream integrators may treat this as a routine hardening improvement and include it in their next update cycle.

Security signals we found

01

Defensive self-test hardening for pluggable cryptographic primitive

02

Expanded test coverage for multi-block, unaligned-input, and non-IV state cases

03

Startup-time detection of faulty SHA-256 compression functions

04

No change to cryptographic algorithms or wire/protocol behavior

Risk score

Why this scored 26/100

Our methodology →
Potential impact 5/30
Exploitability 2/25
Stealth signal 3/15
Affected reach 4/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.