CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 18 Bitcoin

rust/keystore: make bip39 unlocking async

BB1bd474ef View source ↗
Public commit record

What the developer wrote

Authored by Marko Bencun

80/100 · Strong
rust/keystore: make bip39 unlocking async

This uses `to_seed_normalized_async(...).await` over
`to_seed_normalized(...)` in bip39 unlocking, propagating the
async/await keywords up the stack.

This commit by itself is not functional yet, as the unlock animation
is still timer-interrupt based, which leads to chaos. The next commit
converts the animation into an async task of its own, not depending on
interrupts.

The bip39 unlock loop is made to yield to the executor in each of the
2048 PBKDF2 stretch rounds. In the simulator however, we don't yield
and finish the computation in a blocking fashion like before, due to a
limitation of the simulator: it does not busy-loop the
mainloop (otherwise CPU would be at 100%), but only when there is an
incoming USB packet, so yielding in BIP39 would make unlocking in the
simulator *very* slow. Running the mainloop quicker in the simulator
does not work well: either CPU load is too high, or unlock is too slow.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit is a large internal refactoring of the BitBox02 firmware's BIP39 wallet-unlocking code. It converts the slow PBKDF2 key-stretching loop from a blocking (synchronous) operation into an asynchronous one, so the device can briefly pause each round to handle other tasks such as USB messages and screen animations. The commit also vendors the futures-core, futures-lite, and pin-project-lite Rust crates so the firmware can use async/await. The change is explicitly described by the authors as not yet fully functional on its own; a follow-up commit is needed to make the unlock animation work with the new async model. There is no direct evidence in the commit that this fixes or introduces a security vulnerability; it is primarily an architectural/performance change.

Recommended action

Treat this as a non-security-critical refactoring commit. Review the follow-up commit that completes the async animation integration to ensure the BIP39 unlock path remains timing-attack resistant and that yielding does not leak intermediate state or allow re-entrancy bugs. Audit the newly vendored futures crates for compatibility with the firmware's no_std/embedded constraints and verify their checksums match published crates.io versions.

Security signals we found

01

Large dependency addition (futures-core, futures-lite, pin-project-lite) increases firmware attack surface and supply-chain exposure.

02

Async conversion of a security-critical key-derivation path introduces new concurrency and state-machine correctness requirements.

03

Commit explicitly notes the change is not yet functional on its own, indicating potential for incomplete/partial security behavior in this snapshot.

04

No direct diff evidence of a vulnerability fix or introduction; signals are architectural rather than exploit-specific.

Risk score

Why this scored 18/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 3/15
Confidence 8/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.

More from BitBox02 firmware

Related watches

Low 39 AI analysisMessage 73 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

rust: initialize C output buffers

This commit fixes a class of low-level memory-safety bugs where Rust code was given buffers containing uninitialized bytes. Rust's rules require every byte of a slice to be initialized, even if the function will overwrite them. Passing uni…

Undefined behavior at C/Rust FFI due to uninitialized buffers being treated as Rust slicesPotential optimizer-dependent behavior from violating Rust slice initialization rulesHardening of cryptographic output paths (SHA-256, HMAC-SHA256, HMAC-SHA512)
511018eaby benma's agent+52−2713 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 69 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Limit SD erase file size

This commit fixes a bug in how the BitBox02 hardware wallet wipes files from its SD card. Before erasing a file, the device now checks the file's reported size against a safe maximum. Without this check, a tampered SD card could claim a fi…

CVE-2026-6682 referenced in commit messageMalformed FAT directory entry could cause excessive overwrite loopDenial-of-service via SD card tampering
2453f528by Marko Bencun+4−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 70 AI analysisMessage 66 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Validate mounted FAT geometry

This update adds a safety check when the BitBox02 hardware wallet mounts a microSD card. A malicious or deliberately malformed FAT filesystem could trick the device's file-system library into placing user data inside attacker-controlled bo…

Fixes integer-wrap / geometry confusion in FAT mount logicAdds explicit post-mount validation of filesystem metadataPrevents data area from landing inside attacker-controlled FAT sectors
01c017d6by Marko Bencun+21−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗