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

eth: make sighash computation streaming/async

Public commit record

What the developer wrote

Authored by Marko Bencun

78/100 · Adequate
eth: make sighash computation streaming/async

So it can handle ETH transactions with very large data fields that
can't be sent by the host in one USB packet.

The Go code to produce the tests has been adjusted to work with the
updated go-ethereum package, and to output the data using the
`SimpleProducer`.
✓ 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 refactors how the BitBox02 hardware wallet computes the Ethereum transaction hash (sighash) when the transaction contains a very large 'data' field. Previously, the entire data field had to be held in memory at once, which could fail if it was too large for a single USB message. The change makes the hashing process 'streaming' or 'asynchronous', so the device can receive and hash the data in smaller chunks. The commit itself is a feature/robustness improvement, not a direct security fix, but it touches the core cryptographic hashing path for Ethereum transactions.

Recommended action

Review the updated `sign.rs` caller to ensure the async boundary and any new producer implementation correctly enforce length consistency between the streamed chunks and the declared `len()` / `first_byte()` values. Verify that the `Counter` length computation and the `Hasher` streaming path cannot diverge (e.g., producer returns fewer or more bytes than `len()`). Run the updated unit tests and consider adding a test for chunked producers to validate streaming correctness.

Security signals we found

01

Refactoring of core Ethereum sighash computation to async/streaming model

02

Introduction of `RefCell` around data producer, adding interior mutability

03

New async trait methods and `block_on` usage in tests

04

Large data field handling change to avoid single-packet USB limitation

05

No explicit security relevance, CVE, or attribution in commit message or diff

Risk score

Why this scored 33/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/15
Confidence 7/10
Evidence quality 3/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.