refactor(core): digest EIP-1559/EIP-7702 magic without RLP encoding
What the developer wrote
Authored by Roman Zeyde
refactor(core): digest EIP-1559/EIP-7702 magic without RLP encoding
The [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702#behavior) spec defines the hashing process as:
```
msg = keccak(MAGIC || rlp([chain_id, address, nonce]))
```
It would make more sense to use `sha.append(_MAGIC)` --- this way we do not need to rely on the assumption that RLP encodes small integers to their byte representation.
Note that the same goes for [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559#specification):
```
keccak256(0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list]))
```
[no changelog]
What changed, and why it matters
This commit is a small internal cleanup in Trezor's Ethereum signing code. It changes how two special 'magic' bytes (the transaction type markers for newer Ethereum transaction formats) are fed into the cryptographic hash. Previously the code used the general RLP encoder to write the single-byte marker; now it appends the raw byte directly. The commit message says this avoids relying on the assumption that RLP encodes small integers as a single byte. There is no direct evidence in the commit or supplied references that this fixes an exploitable vulnerability, but it removes a fragile assumption in security-critical hashing code.
Treat as a low-risk hardening change. Reviewers should verify that `sha.append(_MAGIC)` and `sha.append(_TX_TYPE)` produce exactly the same byte sequence as the previous RLP-based approach for the valid input ranges used by Trezor, and that no other code paths rely on the old `_MAGIC` byte-string type. No urgent user action is indicated by the available materials.
Security signals we found
Refactor of cryptographic hashing path for Ethereum transaction signing
Removal of implicit assumption that RLP encodes small integers as single bytes
Change affects EIP-1559 and EIP-7702 transaction type markers
No changelog entry; commit is labeled as refactor
No explicit vulnerability disclosure or CVE referenced in commit or supplied materials
Evidence from the diff
In sign_auth_eip7702.py and sign_tx_eip1559.py, the code previously initialized the Keccak digest with keccak256(_MAGIC) or rlp.write(sha, _TX_TYPE). The patch changes both to create an empty keccak256() HashWriter and then sha.append(_MAGIC) / sha.append(_TX_TYPE). _MAGIC is also changed from b"\x05" to const(5). The stated intent is to hash the EIP-7702 and EIP-1559 type bytes directly rather than via RLP, matching the specifications keccak(MAGIC || rlp(...)) and keccak256(0x02 || rlp(...)). This is a defensive refactor: it removes a dependency on RLP’s encoding of tiny integers and makes the security-critical path more explicit. The diff does not show any actual miscalculation or bug being fixed, and no changelog entry is present.
Changed components
core/src/apps/ethereum/sign_auth_eip7702.pycore/src/apps/ethereum/sign_tx_eip1559.pyInspect captured patch +6 / −3
### core/src/apps/ethereum/sign_auth_eip7702.py
@@ -1,3 +1,4 @@
+from micropython import const
from typing import TYPE_CHECKING
from trezor import TR
@@ -16,7 +17,7 @@
from .definitions import Definitions
-_MAGIC = b"\x05"
+_MAGIC = const(5)
_REVOKE_ADDRESS = b"\x00" * 20
@@ -92,7 +93,9 @@ async def sign_auth_eip7702(
)
done_msg = TR.ethereum__auth_done
- sha = keccak256(_MAGIC)
+ sha = keccak256()
+ sha.append(_MAGIC)
+
fields: rlp.RLPList = [msg.chain_id, delegate_bytes, msg.nonce]
rlp.write(sha, fields)
### core/src/apps/ethereum/sign_tx_eip1559.py
@@ -133,8 +133,8 @@ def _start_digest(msg: EthereumSignTxEIP1559) -> HashWriter:
# hash only `_TX_TYPE`, RLP header and `fields` (see above).
# calldata and access_list will be hashed later.
sha = keccak256()
+ sha.append(_TX_TYPE)
- rlp.write(sha, _TX_TYPE)
rlp.write_header(sha, length, rlp.LIST_HEADER_BYTE)
for field in fields:
rlp.write(sha, field)Why this scored 27/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.