David St-Onge

Randomness is the foundation everything else in a hardware wallet stands on. Get it wrong and nothing else matters. Not the secure element, not the air-gap, not the metal backup. Weak entropy during initialization = funds drained "remotely." No device access needed, attacker just recomputes your keys. It's the single most critical path in a hardware wallet, and we treated it that way from the very first Trezor Model One (just turned 12 years old!) by mixing device entropy with entropy from the host (computer or phone). Never trust one source. We deliberately designed it this way from the very beginning. The nightmare scenario is that test mode with weak randomness is shipped by accident. People think their wallet generated something truly random but it didn't. Anyone who knows the pattern can work backward and recreate their private keys and AI is definitely speeding this up. We run dedicated safeguards to make sure that can never happen in our builds. Trezor Model One and Model T mixed two entropy sources together (from MCU and from the host). With Trezor Safe 3 we took this further and added Optiga as an independent entropy source. Safe 7 mixes four: MCU, host, Optiga, TROPIC01. On all models this results to 128-bit entropy in default settings. On top of that, we also introduced Entropy Check back in February 2025. From a different angle: Let's finally retire the myth about air-gap. Air-gap doesn’t necessarily imply stronger security. With air-gapped wallets you miss this entropy from the host. If the randomness is not sufficient and keys are predictable, the attacker never needs to touch your hardware.