All cryptocurrency wallets use the same mechanism: the privacy key. A key must be generated in a way that no one can guess. If the key is created with weak randomness, the wallet is compromised before the first transaction records are added to the blockchain.
More than ten years ago, this mute worm resurfaced in new forms, enabling hackers to control unsuspecting victims and make away with their money. The absence of cryptography or advanced maths is not the issue; the problem is that the numbers wallets depend on cannot be made genuinely random.
A trail of failures across the years
The record of entropy failures in crypto is long and costly. Each case shows how even minor weaknesses in randomness lead directly to theft.
Android RNG Bug (2013): The Android RNG used to perform Bitcoin transactions had a flaw that did not provide unique values. Those involved in attacks identified the vulnerability, retrieved the personal keys in duplicated signature messages, and cleaned the affected wallets in a few hours.
Brainwallets: A popular method of creating wallets by early adopters was the brainwallet (a password-based wallet). Human decisions are, however, not random. They were easy targets to these wallets with common phrases, lyrics, and words as seen in dictionaries. Scripts that automate the guesses exhausted thousands of addresses by making billions of attempts.
Profanity Exploit (2022): Ethereum Profanity tool helped users to create vanity addresses using their desired prefix. To accelerate generation the tool minimized entropy. Hackers used this to pre-compute very large numbers of possible keys, resulting in one of the biggest individual wallet hacks on record. Wintermute, a market maker, lost about $160 million by itself.
Trust Wallet Extension Bug (2023): The entropy pool used to generate keys in the browser extension version of Trust Wallet had a bug. The vulnerability was used to steal newly generated addresses. Even when well-established wallet providers were used, a failure in randomness turned out to be a dangerous phenomenon.
Each of these events stemmed from the exact root cause: private keys that were not as unpredictable as they needed to be.
Why predictability equals theft
When a key is weak, breaking it does not take a complex hack. The blockchain is public, so attackers can scan it for addresses created with low-entropy methods. Once found, those addresses are immediately swept.
This makes entropy failures different from phishing or malware. Victims do not need to click a bad link or download malicious software. Their wallets are doomed from the moment the key is created.
The speed of these thefts is another challenge. Because key prediction can be automated, attacks scale to millions of addresses. When users notice anything wrong, their funds are often long gone.
The limits of software-based randomness
Most digital systems run on pseudo-random number generators (PRNGs). These algorithms generate numbers that are randomly looking but predictable in the end. This is okay for ordinary computation, but it could be disastrous in cryptography.
Wallets that depend on software PRNGs are exposed to several risks:
- Poor sources of entropy: If a system boots without sufficient environmental randomness, keys can be weak.
- Browser constraints: Web apps and extensions are typically executed in sandboxes with limited access to strong entropy.
- Coding mistakes: Even small errors in seeding or implementation can open the door to predictable outputs.
- Human “randomness”: If users attempt to provide randomness themselves, e.g., via brainwallets, the outcome is practically always guessable. Humans are famously bad at randomness.
The lesson here is that if randomness is generated solely by software, it can never be truly secure.
Case study: how attacks scale
Consider the Profanity exploit again. Attackers knew that the tool’s shortcut reduced the keyspace. With modern hardware, they could compute huge batches of possible keys and match them against existing funded addresses on Ethereum. Once a match was found, the funds were transferred out within seconds.
This was not a brute-force attack against cryptography. It was the exploitation of predictability. The math behind Ethereum’s keys remains secure. The flaw was in the random numbers used to generate them.
Why hardware offers a path forward
Over the years, one thing has become clear: software-based randomness isn’t enough. When random numbers are generated purely by software, there’s always a risk they can be predicted or reproduced under certain conditions. Hardware offers a more reliable alternative.
Ledger’s Nano S Plus, Nano X, and Stax models lean heavily on the security guarantees of their secure element (SE) chips. These chips contain hardware true random number generators (TRNGs) that derive entropy from unpredictable physical phenomena such as oscillator jitter and subtle electrical fluctuations. By embedding this process within a Common Criteria EAL5+ certified secure element, Ledger ensures that not only is the randomness itself robust, but the environment in which it is generated is highly resistant to tampering and side-channel attacks.
Trezor, on the other hand, adopts a more open and flexible design philosophy. Instead of a closed secure element, its devices rely on the microcontroller’s built-in hardware RNG, which also extracts entropy from low-level electronic noise. To strengthen this foundation, Trezor supplements the device-generated randomness with entropy contributed by the host during wallet initialization. The idea is that mixing multiple entropy sources, one internal and one external, reduces the likelihood of compromise if a single source is weak or manipulated.
Tangem’s wallets take a stricter stance by embedding their TRNGs directly into secure element chips, certified under Common Criteria standards EAL6+. All entropy is generated within the chip, and private keys never leave this tamper-resistant boundary. Tangem opts for a fully encapsulated model in which randomness generation and key storage are inseparable. This design reduces the attack surface, ensuring that even a compromised host environment cannot influence or observe the entropy process, making it resistant to remote exploits and hardware probing.
Coldcard’s Mk4 introduces an interesting hybrid strategy. It employs the TRNG embedded in its secure element as the primary entropy source, but it also layers in redundancy by drawing from the microcontroller’s RNG. Beyond these internal mechanisms, Coldcard uniquely allows users to manually contribute entropy through dice rolls. This user-verifiable randomness can be combined with hardware-generated entropy, offering transparency and a way to audit the key generation process.
The role of standards and audits
Trust cannot be assumed, even when using hardware. Existing certified secure elements are tested to international randomness and tamper standards. Additional confidence can be found in independent audits of wallet code and hardware design.
As history tells us, assumptions that are never checked, such as the operating system handles entropy appropriately or users will select secure passphrases, are frequently mistaken. Randomness is not merely lip service and formal testing; certification ensures the same.
Entropy as crypto’s original sin
Looking back, one theme emerges: weak randomness has been crypto custody’s original sin. The pattern keeps repeating from Android wallets in 2013 to modern browser extensions. Millions or even billions are lost each time, and the cause is the same.
The thefts are not clever tricks. They are preventable design flaws. The cycle will repeat if wallets continue to depend on fragile software entropy.
Hardware-grade randomness inside secure elements is not a silver bullet for every risk in self-custody. But it is the most straightforward answer to a flaw that has undermined the entire idea of private keys for more than a decade.
Closing thought
Crypto was founded on the fact that not your keys, not your coins. Yet, if these keys are predictable, then ownership is an illusion. The industry has been warned for more than a decade. Over the next decade, it remains to be seen what lesson it has learned: unless randomness is completely random, self-custody can never be safe.
