Research . Overview

Weak randomness in crypto wallets

The same mistake keeps recurring across a decade of wallet software: the cryptography was sound, but the randomness beneath it wasn’t. This is the survey of that family of failures — and why, for owners, predictability is a recovery route.

2026년 7월 업데이트 · KeychainX — 2017년부터 지갑 복구 서비스 제공

Most catastrophic wallet losses aren’t broken encryption — they’re broken randomness. A wallet’s security rests entirely on unpredictable numbers, and when those numbers turn out to be predictable, the whole thing unravels no matter how strong the algorithms are. This page ties together the major cases we research, each of which has its own detailed page, and explains the shared pattern and what it means for recovery.

Randomness is the foundation of a wallet

Every wallet begins with a secret: a private key or a seed, ideally chosen from a space so vast that no one could ever guess or enumerate it. That unguessability comes entirely from randomness. If the randomness used to create your keys was genuinely unpredictable, your wallet is secure even against unlimited computing power. If it wasn’t — if the “random” numbers came from something predictable like a clock or a flawed generator — then the vast space collapses to a small, searchable one, and the strongest encryption in the world can’t save it.

Two ways randomness fails

Weak randomness harms a wallet in two distinct places. The first is key generation: if the seed or private key was produced from predictable entropy, an attacker can regenerate the exact key. The second is signing: every transaction signature needs a fresh random value (the ECDSA nonce), and if that value is predictable or repeated, the private key can be computed directly from public transactions on the blockchain. Both are fatal, and different real-world cases fall into each category.

Randstorm — predictable browser-wallet keys

Randstorm affected millions of wallets generated in the browser between roughly 2011 and 2015 using the BitcoinJS library, whose SecureRandom routine gathered far less entropy than assumed. The result was keys drawn from a badly reduced space. This is a key-generation failure, and it touches a huge population of early wallets. See our Randstorm research for the detail.

MilkSad — a seed from the clock or worse

MilkSad (CVE-2023-39910) affected wallets whose seed came from libbitcoin-explorer’s bx seed command, which seeded a Mersenne Twister with 32-bit system time. That leaves only about four billion possible seeds — and usually far fewer, since the creation time is often known. Another key-generation failure, in a widely used tool. See our MilkSad research.

Android SecureRandom — leaking keys while signing

The 2013 Android SecureRandom flaw is the classic signing failure. Android’s random generator could return repeated values, causing Bitcoin wallets to reuse the ECDSA nonce across signatures — which lets anyone compute the private key from two public transactions. Funds were swept straight off the chain. See our Android SecureRandom research.

Trust Wallet — a modern repeat

Weak randomness isn’t only an ancient problem. In 2023 the Trust Wallet browser extension was found to generate mnemonics using a predictable pseudo-random generator, so keys created in the affected window could be enumerated — the same key-generation failure as Randstorm and MilkSad, a decade later. It is a reminder that this class of bug recurs whenever a developer reaches for a convenient but non-cryptographic source of randomness.

The 2014 presale PRNG angle

Our own research extends the pattern to the 2014 Ethereum presale generator, which leaned on the browser’s Math.random() for parts of its process. In Firefox a specific entropy collapse could reduce the unknown randomness to a bounded timestamp — a potential recovery route for a subset of those very valuable wallets. See our presale PRNG research.

The pattern: sound crypto, predictable seed

Across every one of these cases the cryptography itself was fine. AES, ECDSA and the hashing were never the weak point; the weak point was always the input — a random value that turned out to be predictable because it came from a clock, a flawed platform generator, a browser quirk, or a non-cryptographic function used where a cryptographic one was required. Recognising this pattern is what lets us look at a “secure” wallet and ask the right question: not “is the encryption strong?” but “where did the randomness actually come from?”

Why predictability cuts both ways

Here is the part that matters to an owner. The same predictability that lets an attacker regenerate a key or derive it from a signature is exactly what lets us recover a wallet for its rightful owner. If your wallet was created with weak randomness and you’ve lost access, the reduced search space that endangers it is the reason it can be reconstructed — by sweeping the enumerable seed space, or by deriving the key from your own public transactions. We do this strictly as owner recovery, for wallets a client can demonstrate they own, to return funds they’d otherwise lost.

How to tell if you might be affected

You may be exposed if your wallet was: created in a browser in the 2011–2015 era (Randstorm); generated with libbitcoin’s bx seed or a tool built on it (MilkSad); made in an early Android Bitcoin wallet around 2013 (SecureRandom); created in the affected Trust Wallet extension window; or a 2014 Ethereum presale wallet. The unsettling feature of all of these is that the wallet looks completely normal — the weakness is invisible until someone enumerates the space. If any of these describe a wallet of yours that still holds funds, treat it as at-risk and move the funds; if you’ve lost access, the same weakness may be the way back in.

What good randomness looks like

The defensive lesson is consistent: keys and seeds must come from a proper cryptographic random source, and signing must use a unique, unpredictable nonce every time (modern wallets use deterministic nonces per RFC 6979 to eliminate the reuse risk entirely). Generate seeds on trusted, current software or a reputable hardware wallet; be wary of old browser-based generators and abandoned tools; and if a wallet was made with anything on the list above, migrate to a freshly generated one. Good randomness is invisible when it works and catastrophic when it doesn’t — which is why it deserves this much attention.

Our research

Weak-randomness recovery is a core strand of KeychainX’s work, because a large share of “lost” early crypto is really weak-randomness crypto waiting to be reconstructed for its owners. Each case above has its own detailed page, and this overview ties them together as one family. We date and maintain this survey as new instances emerge — the pattern is not going away, because the temptation to reach for convenient randomness recurs with every generation of wallet software.

자주 묻는 질문