Hardware wallets, randomness, and the vaults behind every device
Your random number generator can be perfect. Your process is where the black swans live.
By Pavel Nikolov, November 7, 2026On October 29, 2026, Binance lost about $6.3 billion, the largest crypto theft on record. Binance says it has found no evidence that a private key leaked. The attackers spent months working through engineers' laptops, reached the exchange's internal signing service, and had it sign for them.
Every security posture, whether it protects a retail crypto holder, a neobank's card program, or a custodian with billions on balance sheet, eventually reduces to one question: where does the private key live, and who can make it sign? Firewalls, fraud models, and compliance programs all sit above that question. If the key leaks or is predictable, nothing above it matters.
For the fintech founders, bank technology leaders, and custody teams reading this, I see hardware wallets as the most visible, single-purpose example of a pattern that now runs through almost every device we own: a small, isolated piece of silicon that generates keys from physical randomness, never exports them, and signs only when policy allows.
The same pattern shows up under different names. Apple calls it the Secure Enclave. Google calls it Titan M2 and StrongBox. Microsoft calls it TPM and Pluton. Banks call it an HSM. Ledger, Trezor, and Coldcard call it a secure element. The marketing differs, but the security model rests on two shared primitives.
Randomness that cannot be predicted
A key is only as strong as the entropy used to create it. Most real-world key compromises in crypto came from weak random number generation, with the cryptography left intact.
Isolation that cannot be bypassed
A key is only as safe as the boundary around it. The question is whether that boundary is a separate chip, a separate processor core, or just a separate process on a shared CPU.
I read both primitives through Nassim Taleb. Billions of atoms in the coffee cup on your desk move at random, yet the cup never jumps, because countless small fluctuations cancel out. A sound hardware random number generator behaves the same way. The cup still breaks when someone knocks it off the desk. You can have the best random number generator in the world, and your process can still expose you to black swans.
In this deep dive, I break down how pseudo-random and true random generators differ and where they failed in Milk Sad, Randstorm, the $160 million Wintermute loss, Coldcard's 2026 seed bug and the eMudhra certificate keys. I apply Taleb's Mediocristan and Extremistan to key custody, map the hardware vault family from TEEs to HSMs, and compare how iPhones, MacBooks, Android phones, Windows PCs, security keys, and hardware wallets use them. I take apart the Bybit and Binance breaches and the tampered Ledger devices step by step and close with a five-layer custody model for fintechs and banks.
A timeline of key failures, 2008 to 2026
Every incident in this piece, newest first. The tag shows which layer failed: the randomness behind the key, the hardware holding it, or the process around it. Each name links to its source, and the right-hand link goes to the part that covers it.
Randomness as the first security primitive: pseudo vs true random generators
A 256-bit private key offers 2256 possibilities only if every bit was chosen unpredictably. If the generator that produced it only had 32 bits of real uncertainty, the attacker's search space collapses to roughly 4.3 billion candidates, which a powerful GPU cluster can sweep in hours to weeks. The elliptic-curve math stays intact, and the key is still broken.
I find it useful to separate three classes of generator, because the industry often blurs them under the single word "random."
| Generator | How it works | Predictability | Typical use | Where it fails |
|---|---|---|---|---|
Non-cryptographic PRNG (Mersenne Twister mt19937, LCGs, legacy Math.random()) | Deterministic algorithm expanding a small seed | Fully predictable once seed or a few outputs are known | Simulations, games, sampling | Small seeds (often 32 bits), state recoverable from output |
| Cryptographically secure PRNG / DRBG (CTR_DRBG, HMAC_DRBG, ChaCha20, Fortuna) | Deterministic algorithm seeded with high-quality entropy, reseeded over time | Unpredictable as long as the seed is secret and large | OS RNGs (getrandom, /dev/urandom), TLS, key generation | Garbage in, garbage out: a weak or repeated seed yields weak keys |
| True RNG / hardware entropy source (ring oscillator jitter, thermal or avalanche noise) | Samples a physical process, then conditions the output | Physically unpredictable, but biased and sometimes faulty | Seeding DRBGs inside secure elements, enclaves, TPMs, HSMs | Silent degradation, environmental attack, no health testing |
Every serious design uses both a TRNG and a CSPRNG. Physical noise is slow and statistically messy, so a conditioning function and a deterministic random bit generator stretch it into fast, uniform output. NIST formalizes this split: SP 800-90B covers the entropy source and its health tests, SP 800-90A covers the DRBG, and SP 800-90C covers how to combine them.
Why the failures are almost always on the software side
When I review the history of crypto key compromises, attackers rarely beat the cryptography. They beat the entropy.
eMudhra
In October a researcher showed that the private keys of eight eMudhra intermediate CA certificates had only a fraction of the expected entropy, because a flaw in a wrap/unwrap step of key generation produced weak P-384 keys. According to Help Net Security, anyone could recover the keys from the public certificates in under a second, eMudhra traced the flaw to a faulty script used in its April 2025 key ceremony, and the company then announced it would leave the global TLS certificate business. With those keys, an attacker could have issued trusted certificates for any domain.
Coldcard
Coldcard hardware wallets had a hardware true random number generator, but from March 2021 their firmware created seeds with a weak software generator instead: a build setting disabled the hardware source, and the code checked only whether that setting existed. Coinkite put the result at about 40 bits of entropy on Mk2 and Mk3 devices and about 72 bits on newer models. Starting on July 30, 2026, attackers drained about 1,816 BTC, roughly $116 million, from more than 5,200 addresses. A firmware update could not repair seeds that already existed, so owners had to create new ones and move their coins.
Milk Sad
Libbitcoin Explorer's bx seed command used the mt19937 Mersenne Twister, which limited internal entropy to 32 bits regardless of settings. The CVE record notes it was exploited in the wild in June and July 2023.
Profanity and Wintermute
The Profanity vanity-address generator picked a 32-bit seed and expanded it into 256-bit private keys. After 1inch disclosed the weakness, the market maker Wintermute lost about $160 million. It had moved ether off its Profanity-generated address but left that address as an admin of its vault.
Randstorm
Early BitcoinJS imported the JSBN library, which tried to call window.crypto.random. That function no longer existed in mainstream browsers, so the call failed silently and entropy fell back to Math.random(), which had weak implementations across major browsers until they moved to XorShift128+ by 2016. Unciphered estimated roughly 1.4 million BTC sat in potentially weak wallets.
Earlier precedents
A 2008 Debian change to OpenSSL left the process ID as the only seed, which cut the possible keys to fewer than 32,768 of each type and size. In 2013 a flaw in Android's SecureRandom made Bitcoin wallets sign with repeated ECDSA nonces, which let attackers recover private keys and steal funds.
Entropy failures are silent. A wallet with 32-bit entropy works perfectly, displays a valid 24-word phrase, and passes every functional test. Randomness is also consumed twice in a signing system: once to create the key and again for every ECDSA signature nonce. Reusing or biasing a nonce leaks the private key just as surely as a weak seed. That is why modern wallets use deterministic nonces (RFC 6979) or Schnorr signatures with hedged nonces, so signing no longer depends on runtime randomness at all.
A dedicated security chip with its own tested physical noise source removes the dependency on whatever browser, OS, or library happens to be generating keys. Randomness stays imperfect, but fewer components have to be right. Coldcard shows the limit: the chip helps only if the firmware asks it for the numbers. As Kraken's chief security officer pointed out, audits can confirm that a device has an approved random number generator without confirming that production firmware uses it.
Continue to Part 2: A Taleb lens