Skip to Content
DocumentationCrypto Basics12 vs 24 Words

12 vs 24 Words

This is probably the most widely misunderstood claim in crypto: that a 24-word recovery phrase is a stronger wallet than a 12-word one.

It isn’t. The protocol you are protecting is a 128-bit protocol. Feeding it more than 128 bits of seed entropy does not raise the security of anything downstream — it only lengthens what you have to write down and re-enter correctly.

The number that does deserve your attention is whether those 128 bits were genuinely random when your wallet was created. That is where real wallets have actually been drained.

Your funds are protected by a chain of steps, not by the seed alone:

seed entropy → BIP-39 mnemonic → BIP-32 derivation → secp256k1 private key → ECDSA signature

An attacker gets to pick which link to attack. They will pick the cheapest one. So the security of your wallet is the minimum over that chain, not the maximum.

The last links cap out at roughly 128 bits. Bitcoin, Ethereum, and nearly every chain KeepKey supports sign with ECDSA on the secp256k1 curve. The curve’s group order is 256 bits, and the best known generic attack on it — Pollard’s rho — needs on the order of √n ≈ 2¹²⁸ group operations. That is the ceiling. It does not move, no matter what you do above it.

What the word counts actually mean

BIP-39 encodes a random number as words. The words are a transcription format; the number is the secret. The spec  allows 128–256 bits of entropy:

WordsSeed entropySecurity of the resulting keys
12128 bits~128 bits
18192 bits~128 bits
24256 bits~128 bits

Only the middle column changes. Choosing 24 words takes you from 128 bits of seed entropy to 256, sitting on top of keys that top out near 128 bits either way. You have doubled what you must transcribe and store correctly and left the attacker’s actual cost unchanged.

This is why KeepKey Desktop tells you, at the seed length selector:

“Added seed length does not improve overall wallet entropy.”

What 128 bits means

It is worth being concrete, because “128” sounds small next to “256.”

2¹²⁸ is about 3.4 × 10³⁸. This is not a number that gets brute-forced with more budget, better hardware, or another decade. It is not “probably fine” — it is outside the reach of any conceivable classical computing effort by many orders of magnitude. 128-bit security is the design target that AES-128 and the TLS handshakes protecting the entire web are built on.

There is no meaningful attacker who is stopped by 256 bits but would have succeeded against 128.

The number that actually matters: is your 128 bits real?

Here is the part that gets almost no attention, and it is the part that has actually cost people money.

The whole argument above assumes your seed was drawn from a genuinely unpredictable source. If it wasn’t, the word count is irrelevant — an attacker skips the curve entirely and just re-derives the small set of seeds your generator was capable of producing.

This is not theoretical. Two well-documented cases:

Milk Sad (CVE-2023-39910, 2023). Libbitcoin Explorer’s bx seed command used a Mersenne Twister PRNG seeded with 32 bits of system time. Every wallet it ever created came from a pool of only 2³² ≈ 4.3 billion possibilities — brute-forceable on consumer hardware in days. It was exploited in the wild, with hundreds of thousands of addresses affected. Critically: users who chose 24 words got exactly the same 32 bits of real entropy. The longer phrase bought nothing.

Randstorm (2011–2015). Browser-based wallets built on BitcoinJS used a SecureRandom() that effectively fell through to Math.random(). In the browsers of that era, Math.random() offered far less entropy than assumed. Unciphered, who disclosed it, estimated that on the order of 1.4 million BTC sit in wallets with weakened keys.

In both cases the mnemonics looked completely normal. Length told you nothing. The generator was the whole story.

So the ranking that matters is:

  1. A 12-word phrase from a real hardware entropy source — secure.
  2. A 24-word phrase from a broken generator — worthless.

More words on a bad source is more theater, not more security.

How KeepKey generates yours

KeepKey addresses the generation problem directly, and you can read the code — the firmware is open source.

  • Hardware entropy, not software pseudo-randomness. The device draws from the STM32’s hardware random number generator (lib/rand/rng.c), including checks of the RNG’s own seed- and clock-error status, with detection and reset if the peripheral hangs. There is no clock-seeded PRNG anywhere in this path.
  • The host cannot dictate your seed. At setup the device generates 32 bytes of internal entropy, receives entropy from the host, and mixes them: SHA-256(internal ‖ external) becomes the seed (lib/firmware/reset.c). Because both feed the hash, the result is unpredictable if either source is sound. A compromised computer cannot force a predictable seed, and a hypothetically faulty device RNG is backstopped by the host’s.
  • It happens on the device. The seed is generated and displayed on the KeepKey’s own screen. Your computer never sees the words. See Creating Your Wallet.

When a longer phrase is still the right call

The argument above is about generating a new wallet. Longer phrases are fully supported and there are legitimate reasons to use one:

  • Compatibility. Recovering an existing 24-word phrase from another wallet obviously requires 24 words. KeepKey recovers 12, 18, and 24-word phrases — see Scrambled Recovery Entry.
  • Policy. Some institutional or multi-party arrangements mandate 256-bit seeds. If that’s your situation, pick 24.
  • Personal conviction. 24 words is safe. It costs you a longer thing to write down and nothing else. If you’d sleep better, choose it.

And the real costs of choosing it, which are ergonomic rather than cryptographic:

  • Twice as many words to transcribe correctly — twice the backup-error surface.
  • Twice as many words to enter during a recovery, usually under stress.
  • More to store, split, or engrave.

If you want more than 128 bits of protection

Adding seed words is the wrong lever, because it pushes on a number that isn’t binding. The lever that actually changes your threat model is a passphrase.

A passphrase is a separate secret that is never written into your backup and never stored on the device. It defends against a threat that no amount of seed entropy touches: someone finding your written phrase. That is the realistic attack — not the elliptic curve.

The summary

  • 12 words = 128 bits = the full security the protocol can deliver. This is the recommended default.
  • 24 words = 256 bits of seed feeding ~128-bit keys. Same security, twice the phrase to manage.
  • The real risk is a weak generator at setup, not a short phrase. Milk Sad and Randstorm are what that failure looks like.
  • To go beyond 128 bits of practical protection, add a passphrase — not more words.

Sources

  • BIP-39 specification  — Palatinus, Rusnak, Voisine, Bowe. Defines the 128–256 bit entropy range and the word-count mapping.
  • Milk Sad disclosure  — full technical write-up of CVE-2023-39910.
  • Randstorm disclosure  — Unciphered.
  • KeepKey firmware source: lib/rand/rng.c (hardware RNG) and lib/firmware/reset.c (entropy mixing at setup).
Last updated on
Your Recovery PhraseTransactions & Fees