chore(core): change encoding of `code_code_entry` used in CPace [no changelog]
What the developer wrote
Authored by M1nd3r
chore(core): change encoding of `code_code_entry` used in CPace
[no changelog]
What changed, and why it matters
This commit changes how a numeric pairing code is converted into bytes before being used in a cryptographic protocol called CPace. Previously the code was treated as a raw 6-byte binary number; now it is formatted as a 6-digit ASCII string (e.g., '000123') and then encoded to bytes. The change is described as a routine chore with no changelog. On its own, the diff does not show a fix for a known vulnerability, but it removes a potentially risky encoding choice that could have interacted badly with the CPace protocol.
Treat this as a low-signal change requiring further review. Verify whether the old big-endian byte encoding violated the CPace specification (RFC 8236 / CPace draft) or produced equivalent inputs for different codes. Request the vendor or maintainers to clarify the motivation and add regression tests for CPace code encoding.
Security signals we found
Change to cryptographic input encoding in CPace pairing protocol
Removal of fixed-width big-endian integer encoding for a user-supplied code
No changelog entry despite touching security-critical pairing code
No accompanying tests or documentation explaining the encoding rationale
Evidence from the diff
In core/src/apps/thp/pairing.py, the CPace key generation input changed from ctx.code_code_entry.to_bytes(6, ‘big’) to f”{ctx.code_code_entry:06}”.encode(‘ascii’). The old encoding produced a fixed 6-byte big-endian integer representation, which for small codes would have leading zero bytes. The new encoding produces a 6-byte (or longer) ASCII decimal string, left-padded with ‘0’. CPace expects the password/code to be encoded in a protocol-defined way; using a raw big-endian integer byte string may not match the expected mapping and could affect the discrete-log equivalence class or hash-to-curve inputs. The commit is minimal and lacks tests or explanatory comments, so it is unclear whether this is a hardening change or a compatibility fix.
Changed components
core/src/apps/thp/pairing.pyTrezor hardware wallet CPace pairing flow (THP - Trezor Host Protocol)Inspect captured patch +1 / −1
diff --git a/core/src/apps/thp/pairing.py b/core/src/apps/thp/pairing.py
index 281bdf459..2b1cdb51a 100644
--- a/core/src/apps/thp/pairing.py
+++ b/core/src/apps/thp/pairing.py
@@ -245,7 +245,7 @@ async def _handle_code_entry_is_selected_first_time(ctx: PairingContext) -> None
ctx.channel_ctx.get_handshake_hash(),
)
assert ctx.code_code_entry is not None
- ctx.cpace.generate_keys(ctx.code_code_entry.to_bytes(6, "big"))
+ ctx.cpace.generate_keys(f"{ctx.code_code_entry:06}".encode("ascii"))
await ctx.write_force(
ThpCodeEntryCpaceTrezor(cpace_trezor_public_key=ctx.cpace.trezor_public_key)
)
Why this scored 26/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.