Brute-forcing a seed from partial knowledge

A common idea: write down eleven of the twelve words and keep the twelfth in your head. Or hand each of three friends eight words. Or leave the words in order but swap two. It feels like a lock. Here is the arithmetic that says it isn't.

What the checksum gives away

A BIP-39 seed is random bits plus a checksum. The standard fixes the checksum length at the entropy length divided by 32: a 12-word phrase is 128 bits of entropy and 4 bits of checksum, a 24-word phrase is 256 bits and 8 bits of checksum. Each word carries 11 bits, so the last word of a 12-word phrase is 7 bits of entropy and 4 bits of check.

That checksum is for you: it catches a mistyped word at restore time. It also serves the attacker, because it tells them which guesses to throw away without doing any work. For a 12-word phrase, only one candidate in 16 passes the checksum. For 24 words, one in 256. Every candidate that fails is discarded in microseconds, before the expensive part.

The expensive part is turning a candidate phrase into addresses: PBKDF2 with 2,048 rounds of HMAC-SHA512, then the BIP-32 derivation, then a lookup to see whether any of the first few addresses has ever held coins. On an ordinary laptop that is milliseconds per candidate.

One missing word

Take the public example seed from our walk-through:

pizza educate fat kiss domain venue … (this phrase is public: never use it for real funds)

Hide any one word and give the attacker the other eleven, in order, plus one address the wallet has used.

• Position known: 2,048 candidates. About 128 pass the checksum. Done before the coffee is poured.
• Position unknown: 2,048 words times 12 positions, 24,576 candidates. About 1,536 pass the checksum and need deriving. Still minutes.

A write-up by a recovery hobbyist describes recovering a friend's 12-word wallet from eleven known words and one remembered address; the search space was 49,152 candidates (the words might have been read row-wise or column-wise), each "generated, validated, and tested in milliseconds," and the whole job took about 45 minutes including setup. A 24-word phrase missing one word is 49,152 candidates of which about 192 pass the checksum. That is an easier search than the twelve-word case, not a harder one.

Two, three, four

Two missing words, positions unknown, 12-word phrase: 2,048 squared, times 66 ways to pick two positions, is about 277 million candidates. One in 16 passes the checksum, so about 17 million go through the key derivation. At a few milliseconds each on one machine that is hours to a few days; a rented GPU box shortens it to hours. A professional recovery firm's own guidance says it is "relatively easy to brute force up to 3 missing words," and that four "can be done, but it requires a substantial financial investment to complete the search in a reasonable timeframe."

So the honest table, for someone who has everything except the missing words and knows one of your addresses:

Missing	Positions unknown, 12 words	Verdict
1	~24,000 candidates	minutes
2	~277 million	hours to days on one computer
3	~460 billion	feasible with money
4	~1014	a serious investment, still not safe

Add a wrong word order on top of a missing word and the multiplier is small: 12 factorial is large, but "I swapped two words" is only 66 cases.

What the attacker needs besides the words

Every one of those searches needs a way to tell the right candidate from the wrong ones. That means an address the wallet has used, an extended public key, or a wallet file. The free tool most people use, btcrecover's seedrecover.py, asks for exactly that: your best guess at the phrase plus "a receiving address," an xpub, or an Electrum wallet file, and it checks candidates by deriving addresses along the standard paths.

Which gives you the real lesson. The attacker who has eleven words also, very often, has an address: it was in the same drawer, on the same screenshot, or in your public transaction history once they know one address of yours. Treat "they have most of the words" as "they have the wallet."

We will never ask for a seed word or a passphrase. Never type one into this site or any tool it links to, including recovery tools. If you need to run one, run it on a machine that is offline and will be wiped afterwards.

Why "hide one word" fails and the passphrase doesn't

Hiding one word gives you 11 bits of secret, and the checksum takes back 4. A passphrase is different in kind. BIP-39 feeds the words and the passphrase through PBKDF2 together; the passphrase is not one of 2,048 choices, it is any string, and there is no checksum on it. Every passphrase produces a valid, empty-looking wallet, so the attacker can't even tell a near miss from a wild miss. The search space is whatever you make it, and 2,048 rounds of PBKDF2 per guess slow the attacker down as much as they slow you.

The same arithmetic applies to our ciphers, in reverse:

A disguised list keeps the words from being recognised. The passphrase is what keeps recognised words from being spent.

What to do with this

1. Don't split a single seed by hand. If you want pieces, use a scheme built for it (SLIP-39, Codex32, Seed XOR, or multisig) where a missing piece gives away nothing rather than nearly everything.
2. Use a passphrase, kept apart from the words, and test the restore before funding.
3. Assume that anyone who has seen most of the words has all of them.
4. Never put an address, xpub or screenshot in the same place as the words. The address is the oracle that makes the search work.

Sources