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

keystore: port copy_seed and retain_seed to Rust

Public commit record

What the developer wrote

Authored by Marko Bencun

60/100 · Adequate
keystore: port copy_seed and retain_seed to Rust

Same as with the bip39 seed in the previous commit.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
The short version

What changed, and why it matters

This commit rewrites two internal seed-handling functions from C to Rust as part of an ongoing porting effort. It moves where the encrypted wallet seed is stored and how it is decrypted, but keeps the same encryption design. There is no direct evidence in the commit that this fixes or introduces a security bug; it is primarily a code-rewrite change.

Recommended action

Treat as a routine refactoring commit. If auditing, verify that the new Rust `RETAINED_SEED` static is zeroized on `keystore_lock()`, that `copy_seed()` correctly returns an error when locked, and that the C-to-Rust FFI boundary does not introduce race conditions or lifetime issues. No immediate security patch or incident response is indicated by the diff alone.

Security signals we found

01

Memory safety improvement potential: moving seed retention from C globals to Rust reduces manual memory management and may lower risk of use-after-free or buffer mishandling, but this is a hypothesis, not proven by the diff.

02

No change to cryptographic design: the same AES-HMAC encryption, random key generation, and key-stretching salt-based construction are retained.

03

Lock-state logic change: `_is_unlocked_device` is replaced by checking whether `RETAINED_SEED` is `Some`. This is functionally equivalent in the diff paths shown, but any inconsistency in state transitions could affect security.

04

Testing-only mock random value is now hardcoded inline in Rust; this is test code and does not affect production firmware.

Risk score

Why this scored 26/100

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