On Aug. 2, Arkham Intelligence dropped a claim that startled even the most jaded crypto veterans: the 2020 theft of 127,426 bitcoins, worth more than $8 billion at today’s prices, from the Chinese mining pool LuBian may have stemmed from a single, invisible flaw: predictable private keys.
If true, it would be the largest single digital asset heist in history and fit a depressingly familiar pattern. In the last decade, many high-profile cryptocurrency thefts have been traced back not to exotic zero-day exploits or inside jobs but to something so basic it’s usually taken for granted: randomness.
When the strings of numbers that form the basis of a private key aren’t truly random, when the “entropy” behind them is weak, the rest of the cryptography is just stagecraft. Anyone with a laptop and the right math can reconstruct the key, take the funds, and vanish.
What’s really behind cryptography and cryptocurrency?
Cryptocurrency wallets, whether in an app, browser extension, or hardware device, depend on one unglamorous job done right: creating numbers no one else can guess or recreate. That’s what entropy means in this context: the amount of unpredictability in a generated number.
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. In practice, that seed is where things go wrong.
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. That 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.
2023 Trust Wallet browser flaw
The 2023 Trust Wallet browser extension flaw was a stark reminder of these limits. Ledger’s security team discovered that its wallet seeds were generated from an entropy space of roughly 32 bits, a range small enough for a determined attacker to brute-force in days or even hours with modern hardware. The problem wasn’t that the developers didn’t call a random function; it was that, in the browser environment they chose, the entropy feeding that function wasn’t strong enough to begin with.
Then there are the subtler traps: developers misusing APIs, re-seeding generators with predictable values, or porting code across platforms without accounting for differences in entropy sources.
Why one bad number can expose your Bitcoin
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 in a way that lets anyone who sees both signatures 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 left early Bitcoin wallets on the platform producing predictable nonces. Funds vanished from wallets before most users had any idea there was a problem.
And here’s what makes these flaws so insidious: unlike a typical coding error, you can’t detect low-quality randomness by just reading the source. The function calls may look correct. The math may be by the book. 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.
To recap, the reason why software 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.
You can check for bad variable names, but you can’t bend the laws of physics into an algorithm that’s starting with too few unpredictable bits.
That’s why cryptographers have long preferred hardware random number generators (HRNGs), also called true RNGs. They turn physical phenomena like electronic jitter, thermal noise, and radioactive decay into random bits, and they can continuously test themselves for failure or bias.
How hardware closes the gap
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.
Inside, 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 like NIST SP 800-90B, they must perform continuous health tests, checking every stream of output 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 well-designed wallet, the secure element’s HRNG feeds randomness directly into the key-generation process inside the chip itself. The private key is created, stored, and used entirely within that sealed environment.
It never moves into system RAM, travels over a USB or Bluetooth connection, or touches the operating system or browser, the very layers where many past vulnerabilities have emerged. Even if the host device is compromised by malware, the attacker cannot extract the private key because it physically cannot leave the secure element.
This architecture does more than just make theft harder; it changes the threat model entirely. Instead of trusting an entire operating system, the user trusts a single, highly audited chip with a narrow, verifiable job: produce high-entropy keys, keep them inside, and perform cryptographic operations on demand. This is precisely how the Tangem Chip works.
Not all “hardware” is created equal
The term hardware wallet covers a wide spectrum of designs, and not all of them provide the same level of protection regarding 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, not a fully compliant HRNG tested under 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 put both the entropy source and the key-generation logic inside a tamper-resistant environment designed to resist invasive probing, fault injection, and electromagnetic analysis. The HRNG’s output never leaves the chip unprotected, and the private key is generated and stored in a part of the silicon that cannot be read even with specialized hardware.
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.
From the outside, both types of devices may look similar: a USB stick, a card, or a dongle, but the security profiles are dramatically different. One is essentially a small computer running wallet software; the other is a vault with its own lock and its own lockmaker, producing its own unguessable combination.
For a user, the difference matters most at the moment of key creation. In the history of cryptocurrency thefts, most entropy failures happened outside secure hardware, i.e, in browsers, mobile apps, or open microcontroller environments where the key’s journey was exposed to layers of code and hardware never designed to protect it.
Standards already exist; they’re just not enforced
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 how much true entropy each bitstream provides and built-in “health tests” to continuously monitor the source for bias or failure.
As mentioned earlier, 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.
While NIST’s SP 800-90 series focuses on the quality of randomness, another layer of certification addresses the entire secure element: the Common Criteria security certification. Chips are rated on an Evaluation Assurance Level (EAL) scale from EAL1 (basic functional testing) to EAL7 (formally verified design). An EAL6+ secure element, as used in some high-end crypto wallets like Tangem, signifies rigorous testing and vulnerability assessment against advanced attacks:
Fault injection to induce incorrect behavior.
Side-channel analysis to glean secrets from electromagnetic or power patterns.
Microprobing to physically tap internal circuitry and read stored values.
The “+” indicates additional measures beyond the base EAL6, often tailored to the chip’s role, such as resisting the extraction of cryptographic keys even under laboratory attack conditions.
And yet, in the crypto ecosystem, wallet developers are not required to follow either NIST or Common Criteria standards. Many open-source projects don’t document their entropy sources at all, let alone subject them to independent evaluation.
When a flaw does emerge, there’s no equivalent of a safety recall or a mandated patch notification. If it arrives, the fix may be nothing more than a GitHub commit, a forum thread, or an X post, channels that ordinary users may never see. Those users can go on generating vulnerable keys long after the flaw is public.
The playbook for secure randomness and the hardware to enforce it exists. But without adoption, enforcement, or even user awareness, the same weak-entropy failures keep repeating, sometimes on billion-dollar scales.
How to tell if you’re at risk
Most users can’t measure entropy directly. But you can ask: Where and how were my keys generated? If the answer is “in a web page” or “on an old Android app, " especially if that was before the mid-2010s, consider those keys suspect.
The safest path is to create a new wallet on a hardware device with documented, certified randomness and then transfer your funds there.
How to check if your wallet uses a secure element HRNG
Here's what you must do before getting your next crypto wallet:
Read the technical specs. Look for mentions of a secure element (SE) and an EAL certification level, for example, Common Criteria EAL5+ or EAL6+. These are formal evaluations of the chip’s security features. If the documentation doesn’t specify a secure element, the wallet may be using a general-purpose microcontroller instead.
Look for HRNG or TRNG claims. A hardware (true) random number generator should be explicitly mentioned in the specs, ideally with a reference to NIST SP 800-90B compliance or similar standards. Terms like “deterministic RNG” or “pseudo-RNG” alone are not enough.
Confirm on-chip key generation. Ask the vendor or check documentation for language stating that the private key is generated inside the secure element and is non-extractable, meaning it never leaves the chip in any form.
Check for third-party audits. Independent security audits or certifications (e.g., FIPS 140-2/3, Common Criteria) provide external validation that the HRNG works as claimed and that key isolation is enforced.
A decade of avoidable disasters
The crypto space has ignored the importance of randomness and verifying whether previously generated private keys are secure. Meanwhile, the theft continues at a steady, costly pace.
2013—Android’s entropy drought: A flaw in the SecureRandom function on Android devices meant wallets created there sometimes reused the same nonce. With two such signatures, an attacker can calculate the private key. Bitcoin.org issued an urgent alert; losses followed.
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.
The point is clear: no matter how robust the blockchain, the consensus rules, or the encryption are, a weak key is like a loose house key left on the doorstep.
Conclusions
When randomness fails, an attacker doesn’t have to break cryptography. They just solve for the missing bits. With 32 bits of entropy, that’s about four billion possibilities, small enough to search in hours or days with modern hardware.
That’s why the biggest thefts in crypto often are not as dramatic as the movies make them out to be. There’s no breach to patch, no malware to uninstall. The vulnerability is baked into the very moment of key creation, and the damage is permanent. The industry knows how to prevent this. It just has to stop pretending that software randomness, in the wrong place, is good enough.
