A private key is only as strong as the randomness used to create it. Randstorm is the name for a set of flaws that, in a certain era of web browsers, made that randomness far weaker than anyone intended — leaving a large number of Bitcoin wallets generated between 2011 and 2015 with keys that are, to varying degrees, predictable. For an attacker that’s a threat; for the rightful owner of a locked-out wallet, it can be the very thing that makes recovery possible.

What Randstorm is

Randstorm was named and publicly disclosed by the recovery firm Unciphered in November 2023 (they re-discovered it in 2022 while helping a customer locked out of a Blockchain.com wallet). The root cause is the SecureRandom() function in the JSBN JavaScript library, combined with weaknesses in how the major web browsers of that period implemented Math.random(). Together they produced private keys with much less entropy than a secure wallet requires.

The popular BitcoinJS library relied on that JSBN code until March 2014, when the maintainers moved away from it. Because so many browser wallets were built on BitcoinJS or copied its early code, the weakness spread across the ecosystem. Crucially, the effect is not uniform: keys generated earlier are the most predictable — wallets from before March 2012 are the easiest — while the work needed rises sharply for wallets created later, into 2014 and 2015.

Which wallets are affected

Randstorm affects wallets first generated in a web browser between 2011 and 2015 using BitcoinJS or a project built on it. That includes:

• Early bitaddress.org and BrainWallet paper/browser wallets
• Browser wallet projects such as CoinPunk and QuickCoin (now defunct)
• Early Blockchain.info / Blockchain.com web wallets from that period
• Other Bitcoin and, in some cases, Dogecoin wallets generated with the same library

What is generally not affected: wallets created by hardware devices (Trezor, Ledger), by desktop software like Bitcoin Core, or by later, patched tools. The single biggest signal is the era: if the wallet was made in a browser in the first half of the 2010s, it is worth checking.

Am I affected?

Ask three questions: was the wallet first created between 2011 and 2015; was it made in a web browser (rather than on a hardware device or in desktop software); and was it generated on a site or tool known to use BitcoinJS? If all three are yes, treat it as potentially affected. Independent checkers exist that let you test an address, and the earlier in the window your wallet was made, the more likely the weakness applies.

Randstorm and wallet recovery

This is where the flaw cuts both ways. If you are the legitimate owner and simply locked out of an affected wallet — a lost password, a wallet that won’t import, a defunct service — the reduced randomness can sometimes let us reconstruct the private key from public information you supply, and hand control of your funds back to you. It is the same mathematics that worries security researchers, applied on behalf of the person who actually owns the coins.

Two honest caveats. First, this is owner-authorised recovery only: we work exclusively on wallets you can demonstrate you own, never against third parties. Second, feasibility depends heavily on the year — a 2012 wallet is a very different proposition from a 2015 one, and some cases are simply not tractable. We assess that honestly before taking a case, and we charge only on success.

If you still control the wallet: move your funds

Where this fits our weak-randomness work

Randstorm is one of several weak-randomness problems we work with. The same discipline — understanding exactly how a given tool generated its keys and turning that into a tractable search — applies to the 2014 Ethereum presale wallets (whose early code used a browser Math.random() for an initialisation vector) and to other historical generators. We did not disclose Randstorm; what we bring is years of turning these weaknesses into recovered funds for the people who own the wallets.

Frequently asked questions