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

chore(crypto): improve constant-time comparison

Public commit record

What the developer wrote

Authored by M1nd3r

57/100 · Thin
chore(crypto): improve constant-time comparison

[no changelog]
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
The short version

What changed, and why it matters

This commit hardens how Trezor compares secret values (passwords, PINs, cryptographic tags, and checksums) so that an attacker cannot learn information by measuring how long the comparison takes. It also adds a fault-injection check: if a glitch skips the comparison loop, the device is supposed to detect that and halt. The change is defensive and reduces the risk of side-channel and fault attacks, but it does not by itself fix a known, directly exploitable bug.

Recommended action

Treat this as a security-hardening commit rather than an urgent vulnerability fix. Verify that production firmware images use the real tc_fault_handler() and not the no-op default. Review the consteq() implementation for compiler optimizations that could reintroduce short-circuiting or remove the volatile counter. Consider adding tests that simulate loop-skipping faults and timing measurements to validate constant-time behavior.

Security signals we found

01

Replaces non-constant-time memcmp with constant-time consteq in cryptographic tag verification paths (AES-GCM, Poly1305, base58 checksums, ed25519 signature verification, SLIP25 MAC)

02

Adds volatile loop counter and loop-completion fault check in consteq to mitigate fault-injection skipping of the comparison

03

Introduces tc_fault_handler() abstraction; production builds map it to a fatal error, while a no-op fallback is provided for tests/unconfigured builds

04

Removes duplicated constant-time helpers (bip39.c, ed25519-donna) in favor of a single audited implementation

Risk score

Why this scored 63/100

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