How Poor Entropy Still Drains Millions in Crypto

On 31 July 2026, an attacker emptied about 500 Bitcoin wallets in 25 minutes. The sweep moved roughly 594 BTC, worth around $38 million, and every wallet it touched belonged to someone who had bought a hardware wallet specifically to avoid this outcome.
 

Coinkite disclosed that COLDCARD firmware had been generating keys using a software pseudorandom number generator rather than the hardware generator built into the device. Two functions in the codebase shared the same name and signature, so the linker selected the wrong one, and the build produced no warning.
 

This is the newest entry in a long list. Over the past decade, the largest cryptocurrency losses have come less often from exotic exploits than from something more basic: randomness that was not random enough.

What’s behind the private key?

Cryptocurrency wallets, whether in an app, a browser extension, or a hardware device, depend on one job done right: generating numbers no one else can guess or recreate. That’s what entropy means in this context: the amount of unpredictability in a generated number.

Entropy is the raw randomness a wallet uses to create a private key, measured in bits. More bits mean a larger space of keys that an attacker must search. It enters a wallet at setup. Every key, address, and signature after that follows fixed mathematical rules, so no new randomness arrives later.

Entropy source

In principle, a wallet can get randomness from a pseudorandom number generator (PRNG): an algorithm that stretches a small amount of “true” entropy into as much as it needs, but only if the starting seed is itself unpredictable. 

Software running in a browser tab or on a freshly booted phone often starts life in a kind of sensory deprivation chamber. To generate a truly random number, a program needs “noise”; unpredictable inputs from the world outside pure computation. This might come from timing variations in the processor, mouse movements, or specialized hardware components.

In the first milliseconds after a device powers up, those noise pools may be empty or only partly initialized. If a cryptographic library calls the random number generator too soon, it may be drawing from a shallow well, thus producing numbers that are technically random, but drawn from a space small enough to search exhaustively.

Browsers add their own constraints. JavaScript’s Math.random() was never designed for security, and even the safer crypto.getRandomValues() depends on the operating system’s underlying entropy pool. If that pool is weak, as it can be in mobile sandboxes, virtual machines, or stripped-down IoT devices, the randomness is compromised before it ever reaches the code that generates your private key.

Randomness in transaction signing

When you sign a Bitcoin or Ethereum transaction, you don’t use your private key directly. Instead, you generate a nonce: a one-time, random number, and combine it with your private key in the Elliptic Curve Digital Signature Algorithm (ECDSA) to produce a signature.

But here’s the catch: if the same nonce is used twice with the same private key, the math gives an attacker everything they need to solve for that private key.
ECDSA signatures are a pair of numbers, (r, s), that satisfy a specific equation involving:

• the private key (d),
• the nonce (k), and
• the hashed transaction message (z).

If k is the same for two different messages, the equations line up, allowing anyone who sees both signatures to calculate k. Once k is known, d—the private key—falls out with a couple of multiplications and a modular inverse.

In 2013, a flaw in Android’s SecureRandom function caused early Bitcoin wallets on the platform to produce predictable nonces. Funds vanished from wallets before most users had any idea there was a problem.

Unlike a typical coding error, you can’t detect low-quality randomness by just reading the source. The function calls may look correct, but unless you measure the actual bits being produced and run statistical tests to verify their unpredictability, a fatal weakness can hide in plain sight for months or years, waiting for someone patient enough to exploit it.

The reason why entropy remains a persistent vulnerability can be summarized:

• Startup entropy drought: Devices that have just powered on may not have accumulated enough environmental noise to seed PRNGs.

• Browser limitations: JavaScript’s Math.random() is not secure; even crypto.getRandomValues() depends on the host environment’s entropy pool.

• Unsafe tooling: Vanity address generators, offline scripts, or poorly maintained libraries often skimp on randomness for speed or reproducibility.

• Human input: “Brainwallets” and user-chosen phrases have been cracked by simply guessing from dictionaries.

Cryptographers have long preferred hardware random number generators (HRNGs), also called true RNGs. They convert physical phenomena such as electronic jitter, thermal noise, and radioactive decay into random bits, and they can continuously test themselves for failure or bias.

How hardware fixes this

In high-assurance systems, the solution is straightforward: generate the keys inside a chip that contains a certified HRNG, and never let those keys be duplicated.

A secure element is a purpose-built, tamper-resistant microcontroller. It is a fortified chip designed to store secrets and perform cryptographic operations without revealing the underlying keys. They are the same class of component used in passports to prevent cloning, SIM cards to authenticate devices to mobile networks, and contactless payment cards to authorize transactions.

A secure element can house a hardware random number generator that draws its unpredictability from physical noise, such as thermal fluctuations or oscillator jitter, rather than from mathematical algorithms alone. 

These HRNGs are not just “once-and-done” devices. Under standards such as NIST SP 800-90B, they must perform continuous health tests, checking every output stream for statistical bias, stuck bits, or other failures that could degrade randomness over time. If anything looks suspicious, the chip can halt key generation immediately. In a good hardware wallet, the secure element’s HRNG feeds randomness directly into the key-generation process inside the chip itself. 

Not all “hardware” is created equal

The term hardware wallet encompasses a wide spectrum of designs, and not all provide the same level of protection for randomness and key isolation.

At the lower end are devices built on general-purpose microcontrollers, chips designed for flexibility rather than withstanding physical or side-channel attacks. Many of these include a basic random number generator. 

Still, it may be a pseudorandom generator seeded from the device’s internal state, rather than a fully compliant HRNG tested to the required standards. In such designs, key generation may happen in firmware, with the resulting private key temporarily stored in RAM or flash memory. That means a flaw in the firmware, a successful side-channel attack, or physical tampering could expose the key.
 

By contrast, secure element–based wallets place both the entropy source and the key-generation logic within a tamper-resistant environment. This model also enforces strict access control: cryptographic operations (signing, derivation) are performed inside the chip, with only the final signature or public key leaving it, never the secret itself.

Standards already exist

The randomness problem is not a matter of unsolved science. Cryptographers have already codified what good entropy looks like. The U.S. National Institute of Standards and Technology (NIST) has issued the SP 800-90 series of standards, which breaks the problem into clear pieces.

SP 800-90B describes how to evaluate an entropy source; the raw physical or software process that produces unpredictable bits. It requires rigorous statistical analysis to estimate the true entropy of each bitstream, as well as built-in health tests to continuously monitor the source for bias or failure.

SP 800-90C explains how to combine that entropy with deterministic random bit generators (DRBGs) so the output remains strong even if one source degrades.

A compliant device doesn’t just produce random numbers once and hope for the best. It continually checks its own pulse: if the HRNG’s noise pattern shifts, if a bit gets “stuck,” or if the output fails statistical thresholds, the system halts key generation to avoid minting weak keys.

How to tell if you’re at risk

Most users can’t measure entropy directly, but you can question where and how your keys were generated. If they were created “in a web page” or “on an old Android app," particularly before the mid-2010s, these keys should be weak. The most secure approach is to generate a new wallet on a hardware device that uses certified, documented randomness, and then transfer your funds to it.

A timeline of entropy attacks 

Weak entropy removes the need to work backward. The attacker enumerates the small set of keys the broken generator could have produced, derives the addresses for each candidate, and then checks those addresses against the blockchain for a balance. Here's a history:

• 2018—The IOTA seed generator scam: Users were told to create their wallet seeds using a website. The site’s operator kept a copy of those seeds and drained funds later, stealing roughly $4 million. The randomness here was zero: the attacker already knew the numbers.
   

• 2019—The Blockchain Bandit: Security researchers identified 732 weak Ethereum private keys in the wild. An unknown attacker had been watching those addresses for years, siphoning roughly 45,000 ETH as soon as funds appeared.
   

• 2022—Profanity’s vanity address catastrophe: The open-source Profanity tool generated custom Ethereum addresses from seeds with only 32 bits of entropy, about four billion possibilities. A modern GPU can search that space in hours. Wintermute, a London market maker, lost about $160 million this way.
   

• 2023—Trust Wallet browser extension flaw: In a disclosure from Ledger’s security team, the browser extension was found to produce wallet seeds with about 32 bits of entropy. It was fixed quickly, and Trust Wallet reimbursed some users, but for months, anyone generating a wallet there was at risk.
   

• 2025—The LuBian allegation: Arkham’s claim is still unverified, but if the loss of 127,426 BTC really traces to predictable key generation, it would be the crowning example of how a single misstep at creation can doom billions in assets. 
   

• 2026: COLDCARD: Coinkite disclosed that a software pseudorandom generator had replaced the intended hardware generator in shipped firmware. The fallback entered the upstream dependency in May 2018 and reached key generation in March 2021.

  Coinkite estimates about 40 bits of effective search space on Mk3 hardware, and about 72 bits on later models that mixed in secure element data. Both figures sit below the 128-bit target.

  A guard existed to prevent exactly this. It tested whether a configuration macro was defined, rather than whether its value was non-zero; the macro was set to zero, so the check passed and the error never fired.

Considering a switch from COLDCARD?

Tangem generates your key inside a certified secure element chip using a hardware random number generator. 

If you are sick and tired of worrying about seed phrases, our seedless setup means no 12- or 24-word phrases to write down, photograph, or lose; the exact thing most past wallet hacks have come back to.

Independently audited by Cure53, Kudelski, and Riscure. Built for exactly this moment.

Move your coins where the randomness is actually random. Get Tangem Wallet.