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

refactor(core/rust/crypto): prepare crypto crate for API bindings

Public commit record

What the developer wrote

Authored by matejcik

97/100 · Strong
refactor(core/rust/crypto): prepare crypto crate for API bindings

Introduces the concept of a "copy hazard" separate from unsafety,
replacing pinning. A "copy hazard" is the possibility of Rust
auto-copying owned structs containing sensitive data.

Replaces the "memory" module with "secret", introducing well documented
helper types specifically for copy hazard:
* SecretContext is a zeroizing wrapper over the raw memory. By itself,
not super useful, except that it implements Default for types tagged
with the unsafe marker type ZeroableMemory (ffi contexts).
* SecretContextLock holds a generic DerefMut "lock" over
a SecretContext, forcing the borrow checker to prevent copy hazards:
the compiler is not free to move around memory while a live DerefMut
pointer to it exists. Zeroizes on drop.

Introduces implementation separation on hasher-like structs (that is the
various SHAs plus HMAC):
* "hazardous" base methods are implemented on a SecretContext<ffi_type>,
delegating hazard responsibility to caller,
* non-hazardous methods are implemented on a wrapper struct
(Sha256, Sha3_256 in the followup PR) that takes a SecretContextLock,
which zeroizes on drop, so whenever the computation is either
(a) finished or (b) abandoned, the memory is zeroed before unlocking.

Trezor THP already takes advantage of this split by using hazard methods
directly (with the appropriate comment), without needing a separate
NoPinSha implementations.

This is also preparation for the SDK API bindings, which will introduce
their own secure wrapper for the hasher structs.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This is a large internal refactor of how Trezor's Rust crypto code handles sensitive memory. It replaces an older pinning-based mechanism with a new 'copy hazard' framework designed to prevent Rust from accidentally duplicating secret data in memory. The change itself is defensive and does not appear to introduce a new vulnerability; rather, it is a hardening measure. However, because it touches low-level cryptographic state handling across many files, any mistake in the new abstraction could theoretically affect how secrets are cleared from memory.

Recommended action

Treat as a hardening refactor rather than a security fix. Review the new SecretContextLock and HazardGuard abstractions for soundness, ensure zeroize-on-drop is not optimized out, and verify that all call sites using HazardGuard::hazard_new (e.g., TrezorCryptoSha256 in thp/crypto.rs) are appropriately justified and audited. No urgent patch is indicated.

Security signals we found

01

Refactor of sensitive-memory handling in cryptographic code

02

Introduction of zeroizing wrapper types (SecretContext, SecretContextLock)

03

Removal of Pin-based Memory<T> in favor of explicit 'copy hazard' annotations

04

Expansion of FFI allowlists for ECDSA and SHA3/Keccak

05

Explicit 'COPY HAZARD' safety comments added around FFI context mutations

Risk score

Why this scored 20/100

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