A twelve-word recovery phrase can appear unpredictable while its creator had only a few billion possible outcomes. That distinction—not the number of words displayed—is what determines whether a stranger can reconstruct a wallet. Two documented failures, Trust Wallet’s browser-extension entropy weakness and Libbitcoin Explorer’s “Milk Sad” incident, show why seed generation deserves as much scrutiny as private-key storage. The important retail question is not whether a wallet has ever been online. It is whether its keys were unknowable before anyone had an opportunity to steal them. [1][2][3]
A Twelve-Word Phrase Is Not Automatically 128 Bits of Security
BIP-39 turns computer-generated entropy into a human-readable mnemonic. A standard twelve-word phrase represents 128 bits of input entropy plus a four-bit checksum; a twenty-four-word phrase represents 256 bits plus an eight-bit checksum. The words are an encoding and backup mechanism, not an independent source of randomness. Replacing unpredictable input with a clock value, a small numerical seed or a broken pseudorandom generator does not restore the entropy just because the resulting phrase looks convincingly random. [1][8]
Imagine a defective implementation that selects among only 2^32 possible seeds, then runs those through perfectly respectable cryptographic transformations. The resulting addresses look ordinary. Yet the underlying secret has at most 32 bits of unpredictability, rather than 128. Its maximum candidate population is 4,294,967,296, compared with approximately 3.4 × 10^38 at 128 bits. The gap is roughly 7.9 × 10^28 in candidate-space size. Those are mathematical counts, not estimates of how quickly any real attack can be completed. Address-derivation overhead, available public information, and the attacker’s hardware all matter.
More importantly, the distribution matters as well as the number of possibilities. NIST’s min-entropy framework asks how probable the single most likely outcome is; a biased generator can be weaker than a naive bit-count suggests. A 128-bit-looking byte string with predictable fields or correlated draws may deliver much less than 128 bits of effective security. [7][12]
What the Trust Wallet and Milk Sad Cases Actually Established
| Issue | Defect | Risk Boundary |
| Trust Wallet browser extension (2022–23) | 32-bit entropy in affected WASM generator | Wallets generated by affected extension versions |
| Libbitcoin Explorer 3.x (2023 disclosure) | 32-bit seeded Mersenne Twister in bx seed | Users who used its output as wallet entropy |
| Key exfiltration malware | Correctly generated key copied to attacker | Compromise after initialization; different failure |
In April 2023 Ledger Donjon described a weakness in Trust Wallet’s early browser extension. The issue involved the WebAssembly random-number implementation and a Mersenne Twister generator seeded from a 32-bit value. The affected browser-extension builds were versions 0.0.172 through 0.0.182, according to the published vulnerability record. Ledger’s researchers said that, with an account address, the flawed wallet key could be derived without user interaction. This was a key-generation weakness, not proof that the browser extension was actively transmitting a correctly generated private key. [2][3][4]
A separate 2023 investigation, tracked as CVE-2023-39910, found that the bx seed command in Libbitcoin Explorer 3.0.0–3.6.0 likewise produced entropy with a 32-bit bottleneck. Researchers documented thefts involving wallets whose seed material originated from the affected process. Libbitcoin disputed aspects of the vulnerability characterization, arguing that the command had been documented as unsuitable for cryptographically secure wallet generation. Both points belong in the record: the product’s stated intended use does not make funds created with weak entropy safe, and a vulnerability should not be generalized to every wallet using Libbitcoin. [5][6][10]
This matters for historical wallet safety. A patched generator protects newly created wallets; it cannot retrospectively improve a seed phrase generated years earlier. Re-importing that same phrase into a hardware wallet changes the signing environment, not the underlying secret. The Milk Sad research FAQ explicitly distinguishes repairing software from moving assets to a wallet derived from fresh, strong randomness. [9]
The Economics of Guessing the Wrong Kind of Seed
The original difference can be modeled without publishing any attack instructions. At 32 bits there are about 4.3 billion candidates. At 64 bits the pool expands to 18.4 quintillion. At 128 bits it is approximately 3.4 × 10^38. Every additional 32 effective bits multiplies the theoretical search space by 4.3 billion. The chart below expresses candidate count, not time-to-crack: implementations impose different costs per candidate, and wallet-specific checks can radically alter performance.
Figure 1. Theoretical candidate-space magnitude by effective entropy; original calculation from 2^n.
At a purely illustrative throughput of one million candidate evaluations per second, enumerating 2^32 candidates would take about 71.6 minutes; 2^64 would take roughly 585,000 years; 2^128 is outside any plausible such exercise. The model intentionally ignores acceleration, derivation costs, optimizations and parallelism, because it is illustrating magnitude, not providing a feasible attack recipe. Nor is every 32-bit defect automatically exploitable from an address alone. The exposed set must be deterministically related to the public wallet material.
For a household holding $25,000 in a vulnerable wallet, the loss is not limited to the device’s replacement cost. Exposure is the entire set of assets controlled by the seed, across supported networks and accounts. A phrase derived from bad randomness creates correlated vulnerability across many addresses that appear separate on-screen. Conversely, creating a genuinely independent new wallet and transferring the assets changes the private-key lineage. Moving only one token while leaving others attached to the old seed leaves residual exposure.
Why Wallet Checksums and Hardware Security Do Not Solve This
A BIP-39 checksum helps detect incorrect transcription. It does not prove that the entropy originally supplied to the wallet was unpredictable. A legitimate-looking phrase can pass its checksum perfectly and still come from a tiny candidate pool. Similarly, strong encryption of the seed at rest protects against an attacker who steals an encrypted file, but not an attacker who can independently derive the seed from poor initial randomness. [1][8]
A hardware device can keep keys isolated from a connected computer. It cannot repair an imported weak phrase. That is why how to check a hardware wallet for tampering addresses a different trust boundary from seed randomness. The device may be genuine while the seed supplied to it was already guessable. Some devices allow independent entropy sources, but careless mixing, unofficial firmware and manually composed mnemonic words can introduce new mistakes. The manufacturer’s documented initialization procedure is normally preferable to improvised schemes.
Users also need to separate this threat from wallet-drainer phishing. In our checklist for identifying wallet scams before connecting, the critical risk is consent or signature abuse. A weak seed may compromise a wallet without a recent signature, web connection or suspicious approval. The forensic questions differ: What generated the wallet originally? Which software version? Was it a newly generated phrase or a restored older one? Did the loss recur across unrelated blockchains sharing one seed?
Figure 3. A human-readable mnemonic and checksum do not add unpredictability to weak inputs.
How an Investor Should Investigate a Suspect Wallet
A practical assessment begins with provenance. Identify when and where the recovery phrase was generated, not just where it is stored today. Document the wallet software and version if available, note whether a browser-extension or command-line generator created the phrase, and compare this against published advisories. Many older wallets will have no trustworthy provenance record. Absence of evidence is not proof of vulnerable randomness; the aim is to identify a specific affected generator or a credible reason to suspect it.
If the seed came from an affected version, the response is to create a completely new wallet through an up-to-date, trusted initialization path and move every relevant asset to addresses derived from that new secret. Check gas requirements and token permissions before moving; test with a small transfer when operationally appropriate. Do not paste the old phrase into unfamiliar online “seed checkers,” because doing so creates an immediate and separate disclosure risk. For hardware-device procurement and firmware integrity, see our examination of pre-purchase hardware-wallet attacks.
An incident investigation should preserve transaction hashes, wallet-generation records and communications, while assuming that any seed with demonstrated insufficient entropy remains unsafe indefinitely. Wallet users cannot fix randomness retroactively by rotating an application password or installing an update. Those actions are helpful against other risks, but the secret itself must be replaced.
A Simple Portfolio-Exposure Model
Consider an investor holding $100,000 across five blockchains derived from one recovery phrase. If the phrase was created with compromised entropy, moving the phone app to a new device changes none of the five exposed accounts. If a new independent seed receives $98,000 while $2,000 remains under the old seed, the directly exposed asset value falls by 98% in this scenario. It does not imply a 98% reduction in the probability of exploitation; the unknown attack probability is unchanged for the old secret. The distinction between monetary exposure and probability is essential.
Figure 2. Illustrative asset exposure after seed migration, not an estimate of exploit probability.
Splitting a portfolio between independently generated wallets reduces concentration but introduces recovery and operational costs. Five accounts under the same mnemonic are not five independent security domains. Two unrelated phrases may create independent domains, subject to the caveat that identical flawed software or compromised entropy hardware can defeat that independence. An audited generator and transparent initialization process matter more than accumulating recovery phrases.
What Would Disprove a Weak-Entropy Explanation?
A suspicious withdrawal alone is not diagnostic. Evidence that the phrase came from a secure, independently reviewed generator outside any affected version weakens the specific weak-randomness hypothesis. Discovery of a recent malicious approval, browser compromise or shared clipboard history may better explain the loss. A claimed proof based solely on a “pattern” in mnemonic words is generally unreliable; properly encoded words are not expected to look evenly distributed to human intuition.
For providers, the meaningful assurance is evidence of tested entropy acquisition, correct use of a cryptographically secure generator, build reproducibility, dependency review and response procedures when defects are discovered. The trust chain includes the operating system or secure element supplying entropy, the wallet code transforming it, and the release process delivering that code. A beautiful interface does not measure any of those properties.
What Investors Should Do Now
| Risk Signal | Investor Response |
| Known affected generation version | Generate new independent wallet; transfer all assets |
| Unknown seed provenance | Document wallet lineage; avoid untrusted tests |
| Wallet only imported to new device | Old seed remains unchanged; do not equate import with migration |
Users who generated seeds with a clearly affected tool should treat that seed as compromised and migrate assets, even if their funds remain untouched. Users with no such evidence should avoid panic-driven migrations triggered by social-media guesses. The right questions are provenance, software-version history, key-generation independence and recovery readiness. Password length, biometrics and hardware-wallet branding protect different parts of the process.
The practical conclusion is that a twelve- or twenty-four-word phrase is secure only to the extent its entropy and generation chain are secure. A mnemonic can be perfectly formatted and disastrously predictable. That is the hidden failure mode behind weak seed phrase security: theft may be possible not because the wallet subsequently leaked its keys, but because those keys were never as secret as they appeared.
What About Hand-Selected Words and “Brainwallets”?
A user may think choosing memorable words improves recovery, but the mnemonic standard explicitly assumes the words encode computer-generated entropy. A personally composed sentence reflects human language habits, preferences and repetition, often creating a much smaller and more predictable search distribution than a uniformly generated seed. Adding unusual punctuation, dates or a long phrase does not necessarily make the derivation cryptographically unpredictable if the input process is systematic. BIP-39 itself warns that its design is not a scheme for turning user-created sentences into secure keys. [1]
The checksum reinforces this point. Randomness does not come from vocabulary size multiplied across twelve positions, because most arbitrary sequences are not valid checksummed mnemonics and compliant wallets are not sampling natural-language phrases. The meaningful variable is entropy at the input stage. A user should therefore not improvise a seed phrase, modify individual words to make a phrase “more random,” or combine pieces from unknown generators without understanding the documented procedure.
Can an Address Reveal That Its Seed Was Weak?
Ordinary addresses do not display an entropy score. Public keys and addresses are designed to look unrelated to their private inputs; on-chain explorers generally cannot certify the origin of a wallet seed. Researchers sometimes identify historically affected wallets by combining publicly known address sets with knowledge of a flawed generation method, but that is not a general-purpose consumer test. The lack of a recognizable address pattern should never be used to reassure users who know their phrase originated from a compromised generator.
A forensic service promising to “test your mnemonic safety” may itself demand the one secret it should never receive. Supplying the phrase to such a site creates an unnecessary disclosure even if the original generator was safe. For investors, a well documented generation history and vendor security notices are more relevant than purported online entropy scores or elaborate screenshots of a seed phrase. Responsible providers should publish precise affected version ranges, mitigation advice and whether simply updating prevents new exposure or also resolves historical keys.
How the Risk Changes With Wallet Size and Key Reuse
The vulnerability scales with accessible assets, not with the number of visible wallet applications. In an illustrative portfolio, $2,000 is retained in a weakly seeded hot wallet while $98,000 is moved to an independent strongly generated seed. A theft of the remaining exposed seed can still remove the full $2,000, but cannot by itself authorize transfer from the independent wallet. This is segregation of value, not a probability-based forecast. A user who instead creates 100 addresses from the same weak mnemonic has changed account organization without diversifying the root secret.
There is an additional uncertainty that a value-at-risk chart cannot capture: future incoming payments. Even after migrating current balances, an address book, saved exchange withdrawal destination or merchant payment instruction can send new funds to the vulnerable old addresses. A sound migration therefore updates recurring payment and withdrawal settings as well as moving existing balances. It also verifies that the new backup can actually restore the intended accounts before abandoning access to the old setup.
Methodology and Limitations
The candidate-space comparison uses 2^n equiprobable inputs at n bits, and the illustrative enumeration time divides that count by one million evaluations per second. Neither assumption represents measured key-recovery performance in a real wallet. Portfolio exposure examples assume all named assets are controlled by the affected seed and exclude network fees, market movement and remediation costs. Incident facts refer to the specifically affected Trust Wallet and Libbitcoin implementations, not wallet software generally. The analysis is current through October 24, 2026.
Sources
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574