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

sigcache: harden proof cache keys with length-prefixed hashing

Public commit record

What the developer wrote

Authored by Byron Hambly

83/100 · Strong
sigcache: harden proof cache keys with length-prefixed hashing

Switch range-proof and surjection-proof cache hashers from raw CSHA256
concatenation to CHashWriter (SER_GETHASH). This serializes each field
with a length prefix, so distinct argument tuples with byte-identical
raw concatenations no longer collide to the same cache key.

A cache entry is a positive verification result; a collision would let
an attacker bypass verification. The fix affects two caches:

- ComputeEntryRangeProof: proof, commitment, asset_commitment, scriptPubKey
- ComputeEntrySurjectionProof: add vTags to key (was missing entirely)

Both caches retain the per-process 64-byte salted midstate
(nonce || PADDING_RANGE_PROOF / PADDING_SURJECTION_PROOF) for domain
separation between the two proof types.

Expose thin test-only hooks (TestComputeEntryRangeProof /
TestComputeEntrySurjectionProof) so unit tests can reach the
anonymous-namespace cache internals.

(cherry picked from commit 94000967f6dc05b1afd435e79b1bbc597e29f816)
✓ 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 fixes a cache-key collision bug in Elements' proof verification caches. Previously, the cache key for range proofs and surjection proofs was built by simply concatenating raw bytes, so two different sets of inputs could accidentally produce the same key. Because a cache hit means 'this proof was already verified, skip checking it again,' an attacker who could trigger such a collision could potentially make the node accept an invalid proof. The fix switches to length-prefixed serialization so distinct inputs can no longer collide, and also adds a missing input (vTags) to the surjection-proof cache key. The commit message explicitly calls this a hardening fix against verification bypass.

Recommended action

Treat this as a security hardening fix and include it in the next maintenance release. Add or review unit tests using the new TestComputeEntryRangeProof/TestComputeEntrySurjectionProof hooks to verify that distinct inputs produce distinct cache keys and that domain separation between range and surjection caches holds. Audit any other caches in the codebase that still use raw concatenation for key construction.

Security signals we found

01

Cache-key collision in proof verification cache could allow bypass of cryptographic verification

02

Raw concatenation of variable-length fields in cache-key construction

03

Missing input (vTags) in surjection-proof cache key

04

Fix uses length-prefixed serialization (CHashWriter/SER_GETHASH) to ensure distinct tuples produce distinct keys

05

Commit message explicitly states 'A cache entry is a positive verification result; a collision would let an attacker bypass verification'

Risk score

Why this scored 68/100

Our methodology →
Potential impact 22/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 12/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.