Research . Original

The presale PRNG & IV weakness

Part of our weak-randomness research: see the Weak randomness in crypto wallets overview.

The 2014 presale wallet generator relied on the browser’s Math.random in places it shouldn’t have. Our research examines whether that predictability opens a recovery path for otherwise-locked presale wallets.

Mis à jour en juillet 2026 · KeychainX — Récupération de portefeuilles depuis 2017

This is original KeychainX research, and we present it as an open investigation rather than a finished exploit. The 2014 Ethereum presale wallet generator used browser randomness — Math.random() — as part of how it produced encryption parameters. Where randomness is predictable, recovery may be possible. Here is what we’ve found.

Background: how the presale wallet was made

A presale wallet is a JSON keystore that encrypts your private key with your password using PBKDF2 and AES. Encryption needs an initialisation vector (IV) and other per-wallet values, and these were generated in the browser at creation time. A properly random IV is not itself a secret — but the way the generator gathered randomness is where the interesting weakness lives, because parts of it leaned on Math.random() rather than a cryptographic source.

Why Math.random is weak!

Math.random() is a pseudo-random generator seeded from limited, often time-derived state — it was never meant for cryptography. If a value that should be unpredictable was instead produced by Math.random() seeded from something bounded, then the space of possible values is small enough to enumerate. This is the same principle behind Randstorm and MilkSad: the algorithm is fine, but the seed is predictable.

The Firefox “undefinedundefined” collapse

Our key finding concerns a browser-specific quirk. The generator mixed in mouse-movement coordinates as an entropy source, but in Firefox, under certain conditions, those coordinates came back as the literal string “undefinedundefined” — contributing no real entropy. When that happened, the unknown randomness collapses toward the remaining source: a millisecond timestamp. And that timestamp is bounded, because a presale wallet was created in a window around the moment its funding transaction hit the Bitcoin chain.

What it means for recovery

The implication is a dramatically reduced search space for affected wallets. If the entropy really collapses to a millisecond timestamp bounded by on-chain funding times, the candidate space becomes enumerable, and a structured search — a beam search over the plausible time window, reconstructing the generator state — could reproduce the values needed to assist decryption. We have outlined this methodology; it is promising for a specific subset of Firefox-created wallets and is not a universal presale skeleton key. Most presale recoveries still come down to the password encoding issues we document separately.

Why this matters for lost crypto

The 2014 presale wallets are among the most valuable dormant assets in all of crypto, and a meaningful share sit locked because their owners can no longer decrypt them. Any credible method that reduces the search space for even a subset of them is worth pursuing, because the stakes per wallet are so high. That is why we treat the PRNG angle seriously despite its narrow applicability: for the specific wallets where the entropy collapse occurred, the difference between an unbounded and a bounded search is the difference between hopeless and recoverable. Research that widens the set of recoverable wallets, even modestly, has outsized value here.

The methodology in more depth

Concretely, the approach is a bounded reconstruction. First, establish the funding window from the wallet’s on-chain history, which brackets the creation time. Second, for each candidate millisecond in that window, reconstruct the generator state that would have resulted given the collapsed entropy, and derive the encryption parameters it would have produced. Third, test those parameters against the encrypted keystore, ruling candidates in or out by whether the derivation is internally consistent. A beam search keeps the most promising candidate states alive rather than exhausting every possibility blindly. It is careful, wallet-specific work — not a batch attack — which is appropriate given it applies only where the specific conditions held.

An honest status

We present this as active research. The conditions have to line up — the specific browser, the specific entropy collapse, and a well-bounded funding time — and each candidate wallet has to be assessed individually. We publish it because it’s a genuine, under-examined angle on some of the most valuable dormant wallets in existence, and because being transparent about a promising-but-unfinished method is more useful to owners than either overclaiming or staying silent.

Which wallets this could apply to

To be precise about scope: the strongest candidates are presale wallets created in Firefox during the window where the mouse-coordinate entropy source failed, and where a funding transaction gives a tight creation-time bound. Wallets made in other browsers, or where the entropy source worked as intended, don’t exhibit the collapse and aren’t addressed by this route. That is why we assess each wallet individually rather than promising a blanket solution: the same presale JSON might be recoverable through the encoding route, through this PRNG route, or through neither, and only an inspection of the specific wallet and its on-chain context tells us which.

Our documentation

This analysis is KeychainX’s own, developed while investigating dormant presale wallets (see our dormant presale ETH study) and our broader weak-randomness work alongside Randstorm and MilkSad. We date it here to record the finding, and we welcome collaboration from researchers examining the same generator.

Foire aux questions