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

factorysetup: reuse SHA-256 for HMAC

Public commit record

What the developer wrote

Authored by benma's agent

78/100 · Adequate
factorysetup: reuse SHA-256 for HMAC

Use RustCrypto Hmac<Sha256> for the shared HMAC-SHA256 helper so factory
setup reuses the SHA-256 backend already linked for plain hashing.

This reduces the factory-setup image from 159,568 to 155,088 bytes,
saving 4,480 bytes. RAM usage remains 203,304 bytes.

Normal firmware still needs bitcoin_hashes for other callers. Multi
grows from 686,080 to 686,356 bytes (+276), and Bitcoin-only grows from
525,392 to 525,656 bytes (+264).

Add known-answer coverage for empty keys and keys longer than the
SHA-256 block size.
✓ 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 swaps one internal cryptography library for another when computing HMAC-SHA256 in the factory-setup code. The goal is to reduce firmware size by reusing an existing SHA-256 implementation, not to fix a security bug. New test vectors were added to confirm the new implementation still produces the correct answers.

Recommended action

No immediate security action required. Reviewers should verify that the new RustCrypto HMAC implementation is compiled with the same side-channel and constant-time properties expected for the target hardware, and confirm the added tests cover all production key lengths. Consider replacing the `.unwrap()` with an explicit error path for defensive coding.

Security signals we found

01

Cryptographic implementation change in HMAC-SHA256 helper

02

Use of `.unwrap()` on `new_from_slice`, which can panic if key length is unsupported; for HMAC-SHA256 the RustCrypto `new_from_slice` accepts any key length, so this is effectively safe but still a panic path

03

No removal of existing call sites; normal firmware still uses `bitcoin_hashes` for other callers

04

Added known-answer unit tests for edge cases

Risk score

Why this scored 18/100

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