Randomness & entropy

Every other protection on this site assumes your seed was generated randomly. If it was not, a perfect steel backup in a bank vault protects nothing — an attacker can simply regenerate your keys. This page explains randomness from first principles up to doing your own dice entropy safely.

At a glance: the confidence ladder Beginner

You do not need to understand everything on this page to be safe. Most people should stop at step 1 or 2. Each step adds independence from any single maker, at the cost of more effort and more room for human error.

1. Let a reputable hardware wallet generate the seed, bought directly from the maker, with up-to-date firmware. Write the words on paper, then later on metal. Never photograph or type them.
2. Add a check that does not rely on trusting the device alone: use a device that mixes in entropy from more than one source and lets you verify that it did (for example Trezor's entropy check), or add your own dice rolls on a device that mixes them in.
3. Understand and audit the process: learn how entropy becomes words, practise with throwaway rolls, learn the bits-per-roll maths, and verify the maths on an offline computer. Compare entropy sources side by side.
4. Expert: reason about min-entropy, dice bias and the NIST SP 800-90 series, and use vendor diversity in multisig so that no single random-number generator can sink you. Learn to test vendors' entropy claims and check that passphrases, BIP85 children and SLIP-39 shares are generated as carefully as the seed.

Why randomness matters Beginner

A 12-word BIP39 phrase holds 128 bits of entropy: 2¹²⁸ ≈ 340,282,366,920,938,463,463,374,607,431,768,211,456 possibilities. Even a billion computers each testing a billion seeds per second would need around ten thousand billion years to search a meaningful fraction. That security only holds if every one of those possibilities was equally likely.

If a buggy generator effectively used only 32 bits (about 4.3 billion possibilities), a single graphics card can check them all in a day. This is not theoretical: it is exactly what happened in the Trust Wallet and Milk Sad incidents, where thieves swept thousands of wallets.

Why you cannot just pick the words yourself Beginner

People are poor random generators. When asked to "pick randomly" we favour familiar words, avoid repeats, spread choices evenly and follow patterns we do not notice. An attacker does not try every possible seed; they try the likely ones first.

• Evidence: wallets built from memorable phrases ("brain wallets") were emptied within seconds by automated crackers (Castellucci, DEF CON 23).
• The checksum catches you out: twelve hand-picked words fail the BIP39 checksum 15 times in 16 (see below), so people "fix" the last word with a website, which exposes the whole phrase.
• Even-looking is not random: a sequence such as 1-2-3-4-5-6 repeated has a perfectly even spread of faces but almost no unpredictability. Krux warns about this kind of pattern in dice input (Krux: empirical entropy measurement).

Physical randomness (dice, coins, a hat of word slips drawn with replacement) works only because the outcome is decided by physics, not by you. The rule is the same for all of them: record every result, never re-roll or skip a result you dislike.

What "true randomness" means Intermediate

• Unpredictable: no one — including the device maker — can predict or reproduce the output.
• Uniform: every value is equally likely (a fair die, not a loaded one).
• Independent: earlier results tell you nothing about later ones.

Standards: NIST SP 800-90A (DRBGs), SP 800-90B (entropy sources). Secure elements are typically evaluated under Common Criteria with RNG requirements such as Germany's BSI AIS 20/31; Ledger, for example, states that its secure-element TRNG is evaluated to EAL5+ / AIS-31 (Ledger Donjon threat model). See the expert section for how these standards fit together.

How BIP39 entropy becomes words Intermediate

The checksum word in plain English Beginner

Think of the last word as a check digit, like the final digit of a bank card number. It is worked out from everything before it, so if you copy one word wrongly, the phrase usually stops "adding up" and a wallet will refuse it. That is all it does:

• It catches mistakes. A random wrong word slips past the check only about 1 time in 16 for a 12-word phrase and about 1 time in 256 for a 24-word phrase.
• It does not make the phrase stronger. The check word is calculated, not random, so it adds no secrecy. (Strictly, the last word holds a few random bits plus the check bits; the table below gives the split.)
• It cannot be done by hand. Working it out needs a cryptographic hash (SHA-256), so a trusted offline device does it for you. Never use a website to "find" or "fix" a last word.
• A valid check says nothing about randomness. Every seed in the incidents below passed it.

The steps in detail Intermediate

1. Generate ENT random bits — 128 for 12 words, 256 for 24 words.
2. Compute the checksum: take SHA-256 of the entropy; keep the first ENT/32 bits (4 bits for 12 words, 8 bits for 24).
3. Append the checksum to the entropy → 132 or 264 bits.
4. Split into 11-bit groups → 12 or 24 numbers from 0 to 2047.
5. Look up each number in the 2,048-word list (position = number + 1 if counting from 1).

Source: the BIP39 specification (checksum length = entropy bits ÷ 32). Ledger documents the same steps for its 24-word phrases (Ledger support).

Consequence: you cannot pick the last word freely, and a randomly chosen 24th word fails the checksum 255 times in 256. This is why "write any 24 words you like" fails — and why the final word must be computed, which requires SHA-256 and therefore a computing device you trust.

Why the last word is constrained — and what the checksum is not

• Constrained: the last word carries the final few random bits plus the checksum bits, and the checksum is fixed by SHA-256 of all the entropy. With the first 11 words chosen, only 128 of the 2,048 words can follow; with 23 words chosen, only 8.
• Error detection, not security: the checksum catches most typing and transcription mistakes. It adds no unpredictability: a 12-word phrase holds 128 bits of entropy, not 132 (Block Engineering makes the same point about hashing and checksums).
• A valid checksum proves nothing about randomness. Every seed from every broken generator in the incidents below had a perfectly valid checksum.
• Illustration only (never a real phrase): word1 word2 … word11 [7 random bits + 4 checksum bits]. Picking the "nicest-looking" valid last word throws away a few bits; let the device choose from your remaining random bits.

Hardware wallet RNGs: how makers combine sources Intermediate

Reputable hardware wallets generate seeds from a true random number generator on the chip, often inside a certified secure element, and several deliberately mix in sources from outside the device as well. The principle: if independent sources are combined properly (hashing or XOR), the result is at least as unpredictable as the strongest one, so one faulty or backdoored source does not ruin the seed. The catch is independence: a malicious source that can see the others before choosing its value could cancel them out, which is why commitment schemes matter (see verifying).

Features change with firmware. Check the maker's current documentation before relying on any row; listing is not endorsement.

How devices use your dice: mixed in, or dice only Intermediate

Makers use your dice (or words drawn from a hat) in two different ways, and the difference decides what you can check:

• Mixed in: your rolls are hashed together with the device's own random value. The seed is safe if either source was good, but you can only check the result if the device also shows you its own value or proves it in some other way.
• Dice only: the seed comes from your rolls alone, hashed in a published way. You can recompute it on a second, independent tool (with throwaway rolls), but the quality and privacy of the rolls are entirely up to you.
• You choose the words, the device adds the last one: you pick 11 or 23 words at random (from a hat, by dice or by coin) and the device only works out the checksum word.

Conceptual summary only. Menus and firmware versions change; follow the maker's current guide, and practise with throwaway rolls before generating a real seed.

Verifying a device's entropy Intermediate Expert

You cannot look at a seed and tell whether it was random. What you can verify is the process: that your own entropy was really used, and that the device followed its published algorithm. Approaches, from easiest to most demanding:

Sources: Trezor: entropy check (firmware 2.8.7+ on Safe 3/Safe 5/Model T, 1.13.1+ on Model One) · Trezor firmware: entropy check workflow · COLDCARD: verifying seed mixing · SeedSigner · Krux

Offline, air-gapped practice — the ground rules

• Verify with throwaway material only. Every maker's guide says the same: prove the maths with disposable rolls, never fund that wallet, then create the real seed with fresh rolls that never leave the device.
• Use an amnesic, offline computer (for example a live system booted without networking or storage) and download the verification script beforehand. Terminal history, clipboards, logs and photos can all keep secrets.
• Roll sheets and "TRNG words" are as sensitive as the seed. Destroy them by burning or cross-cut shredding once the backup is checked.
• Privacy of the room: no phones, smart speakers or cameras that can see the dice or the screen.
• Record fingerprints, not secrets: note the wallet fingerprint and a receive address so you can later confirm a restore produced the same wallet.

Dice and coin-flip methods (offline, done properly) Expert

Generating entropy yourself removes the need to trust a device's RNG at the cost of more work and more room for human error. The safest pattern is "dice in, device computes": you roll; an air-gapped signer turns your rolls into a seed and calculates the checksum.

How many rolls?

50 / 99 d6 rolls are the figures documented by COLDCARD and SeedSigner, which hash the roll string with SHA-256; the d20 figures are from Krux. These minimums assume fair dice — see bias for why many people roll well beyond them.

Bits-per-roll maths, step by step Beginner Intermediate

"Bits" are just a way of counting possibilities. Each extra bit doubles the number of possibilities, so n bits means 2ⁿ equally likely outcomes. The figures below need no calculator: they are worked out for you.

1. One coin flip has 2 outcomes = 1 bit.
2. One fair six-sided die has 6 outcomes. 2² = 4 is too few and 2³ = 8 too many, so a roll is worth between 2 and 3 bits: about 2.585 bits.
3. 50 rolls give 6⁵⁰ ≈ 8.1 × 10³⁸ possible sequences, a little more than 2¹²⁸ ≈ 3.4 × 10³⁸. That is why 50 is the documented minimum for a 12-word (128-bit) seed: 50 × 2.585 ≈ 129 bits.
4. 99 rolls give about 255.9 bits, a fraction of one bit short of 256. Makers use 99 for 24-word seeds because the hash output is 256 bits and the shortfall makes no practical difference; Foundation's guide simply says about 100.
5. Hashing does not add entropy. SHA-256 turns any number of rolls into exactly 256 bits that look random, but 20 rolls hashed are still only about 52 bits of unpredictability.

Dice quality, bias and how to test it Intermediate

No real die is perfectly fair. Drilled pips remove different amounts of material from each face, rounded corners and soft edges let a die favour some faces, and the way you throw matters. The good news is that when rolls are hashed (as COLDCARD, SeedSigner and Krux do), a small bias costs only a little entropy per roll, and you can compensate by rolling more.

• Casino (precision) dice are machined to tight tolerances with sharp edges and flush-filled pips, so they are generally considered closer to fair. They are a common community recommendation, but they are not magic: throwing technique and independence still matter.
• Ordinary rounded dice are acceptable for hashed methods if you add a generous margin of extra rolls; they are a poor choice for manual binary methods where each roll maps directly to bits.
• Rolling technique: shake in a cup, throw against a backstop onto a hard surface, and read in a fixed order. Never "place" a die or nudge one that is cocked — re-throw cocked dice only, by a rule decided in advance.

Testing a die (conceptually): roll it many times, count how often each face appears, and compare with an even spread using a chi-squared goodness-of-fit test (NIST/SEMATECH e-Handbook). Two cautions: detecting a bias of about one percentage point takes thousands of rolls, so a short test proves little; and passing the test shows the faces are even, not that the sequence is unpredictable. Do this with a separate practice session — never with the rolls you will use for a seed. The printable dice entropy worksheet has a tally table for this, and records only counts.

Coin flips and von Neumann debiasing Intermediate

A coin gives at most one bit per flip. A 2023 study of 350,757 flips found that ordinary coins land on the same side they started about 50.8% of the time, with large differences between people (Bartoš et al., arXiv 2310.04153). That is a small bias, but it shows that "fair coin" is an assumption, not a fact.

The von Neumann trick (1951): flip in pairs. Heads-then-tails counts as one output bit, tails-then-heads as the other, and pairs that match (HH, TT) are discarded. If flips are independent with any fixed bias, the two kept outcomes are exactly equally likely (von Neumann, "Various techniques used in connection with random digits").

Playing cards: shuffles and draws Intermediate

A well-shuffled deck is a large store of randomness: a 52-card deck can be in 52! ≈ 8.07 × 10⁶⁷ orders, about 225.6 bits. That is more than a 12-word seed needs but less than 256 bits. How you use the cards matters:

• Full deck order: how much of those 225.6 bits you get depends on how well the deck was shuffled. Under the standard mathematical model of riffle shuffling, Bayer and Diaconis showed that about seven riffle shuffles are needed before a 52-card deck is reasonably close to random, and fewer leave it far from random (Bayer & Diaconis, Annals of Applied Probability, 1992). Real human shuffles are less regular than the model, and other shuffling styles can need many more passes.
• Draws with replacement: draw a card, record it, put it back, reshuffle well. Each draw is worth log₂52 ≈ 5.7 bits, so 23 draws give about 131 bits and 45 draws about 256 bits. Drawing without replacement gives a little less each time, because the deck shrinks.

Method A — Dice into an air-gapped signer (recommended)

1. Use casino-grade (precision, sharp-edged) dice if possible; ordinary rounded dice have small biases that hashing tolerates but you should still prefer good dice.
2. Roll in a cup or tray, one die at a time or several in a fixed left-to-right order. Record every roll; never re-roll because a result "looks non-random".
3. Enter the rolls directly on the device's dice-entry screen (COLDCARD, SeedSigner, Krux and others offer this), running current firmware. Do not type them into any computer or phone.
4. The device hashes the rolls and shows the resulting words, including a valid checksum word.
5. Write the words down; destroy the roll record (it is equivalent to your seed) by burning or cross-cut shredding.
6. Optional verification: repeat the exact process with a throwaway set of rolls on the device and on a second independent tool (e.g. the maker's offline verification script on an air-gapped computer) and confirm they match. Never verify your real rolls on a networked computer.

Method B — Fully manual binary, last word computed offline

1. Produce 128 (or 256) bits by coin flips or odd/even die rolls. Write them in rows of 11.
2. Convert each complete 11-bit row to a number (0–2047) and look it up in a printed BIP39 English wordlist (from the official BIP39 repository, printed in advance, offline).
3. You now have 11 words + 7 leftover bits (12-word) or 23 words + 3 bits (24-word). The final word needs the SHA-256 checksum, which cannot reasonably be done by hand.
4. Compute the final word on an air-gapped device: several signers let you enter the first 11/23 words and display the valid final-word options (e.g. SeedSigner's "calculate final word" from your remaining bits, COLDCARD's import flow). Choose the one matching your leftover bits — not a "nice-looking" one.
5. Restore the full phrase on your hardware wallet and test recovery as usual.

Verifiable entropy features Expert

Passphrases, BIP85 child seeds and SLIP-39: where their entropy comes from Intermediate Expert

Three popular features add secrets on top of a seed or split one up. Each has its own randomness rule, and getting it wrong can quietly undo a well-generated seed.

BIP39 passphrase entropy

BIP39 stretches a passphrase with PBKDF2-HMAC-SHA512 using only 2,048 iterations (BIP39 specification). That slows guessing only slightly, so a passphrase is roughly as strong as the randomness you put into it. A remembered quotation or a pet's name is a brain wallet in disguise; a randomly generated passphrase is not.

Each word from the EFF long list is worth about 12.9 bits because 7,776 = 6⁵ (five dice per word) (EFF dice-generated passphrases · EFF wordlists). Use the list offline and roll physical dice; the BIP39 word list works too, at 11 bits per word.

• Why it mattered in 2026: in the COLDCARD weak-generator case, Coinkite said a strong, unique passphrase reduced immediate exposure for affected seeds (Coinkite advisory). A passphrase cannot fix a weak seed for ever, but random ones buy time.
• Pitfalls: exact spelling, capitals and spaces all matter, and there is no "wrong passphrase" error. Losing a strong passphrase means losing the funds. Store it separately from the seed and include it in your inheritance plan. See the passphrase.

BIP85 child seeds: only as random as the master

BIP85 derives a key from the master seed on a fully hardened path such as m/83696968'/39'/0'/12'/0' (BIP39, English, 12 words, index 0), runs it through HMAC-SHA512 with the fixed key "bip-entropy-from-k", and keeps the first 128 or 256 bits as the child's entropy (BIP85 specification).

• No new randomness is created. A child seed is unpredictable only because the master is. If the master came from a weak generator, every child is weak too.
• One-way: a child phrase does not reveal the master or its siblings, so a leaked hot-wallet child does not expose the rest.
• Verifiable: the specification publishes test vectors, so experts can check a tool's output with the published test master key, never with a real one.
• Record the recipe: application, language, length and index. Without the index, rebuilding a child means trial and error. See BIP85 child seeds.

SLIP-39 shares need randomness twice

SLIP-39 (Shamir shares as words) needs good randomness when the master secret is created and again when it is split. The specification requires that the random values used to build shares "MUST be suitable for generating cryptographic keys", and that the master secret is at least 128 bits (SLIP-39 specification).

• Why at least 128 bits: each split stores a 4-byte digest so a wrong set of shares can be detected. The specification notes that someone holding one share fewer than the threshold could use that digest to cut the secret's effective entropy by 32 bits, which is why 128 bits is the floor.
• Split-time randomness: the "fewer than the threshold reveal nothing" promise assumes the share values were random. Splitting on a device with a broken generator would, in principle, weaken that promise even if the master secret was strong.
• Dice for shares: Keystone documents dice rolls for Shamir wallets as well as standard ones (Keystone). See SLIP-39.

Comparing generation methods Beginner Intermediate

A side-by-side summary of the main ways seeds are created. "Trust" means who could, in principle, know or influence your seed.

Entropy sources compared: bits, effort and pitfalls Beginner Intermediate

The table above compares who you must trust. This one compares the raw sources of randomness. Bits assume a fair source; real sources are a little worse, which is why the advice is to go beyond the minimum.

Bits per event: log₂ of the number of equally likely outcomes. Sources: COLDCARD, SeedSigner, Krux, Foundation, Bayer & Diaconis (1992), EFF, and the coin-flip study above. Hand-drawn words: if a device fills the last word's few random bits by a fixed rule, a 12-word phrase from 11 drawn words holds about 121 bits and a 24-word phrase from 23 words about 253 bits, both still far beyond brute force.

Measuring entropy: min-entropy and the NIST SP 800-90 series Expert

Shannon entropy vs min-entropy

Shannon entropy is the average surprise of a source. Min-entropy, H_min = −log₂(p_max), measures the attacker's best single guess, which is what matters for keys. A fair d6 has 2.585 bits of both; a biased die can keep a high Shannon figure while its min-entropy drops. Security standards use min-entropy and count it conservatively.

Why you cannot measure entropy from the output

A good pseudo-random generator seeded with 32 bits produces output that passes statistical test suites; only its source reveals the weakness. In the 2026 COLDCARD case, the health check that rejected repeated values was passed easily by a deterministic generator, and hashing made the output look uniform without adding a single possible seed (Block Engineering). Entropy has to be argued from a model of the physical source, then checked continuously.

How the NIST series fits together

Practical expert checklist

• Know which code path actually produces your seed, not just which RNG exists in the device. The COLDCARD bug was a link-time substitution: the intended TRNG code was present in the binary but not used for seeds (Coinkite technical backgrounder).
• XOR or hashing of two deterministic streams is still deterministic; combining only helps if at least one input is truly unpredictable and independent.
• Reseeding with a 32-bit value caps the seed space at about 2³², however strong the source behind it.
• Count user entropy conservatively (min-entropy, not face count) and add a wide margin.
• Seeds outlive firmware: record which device and firmware version created each seed so you can act on future advisories.

Verifying entropy claims and reproducible builds Expert

Marketing says "true randomness" and "certified TRNG". Each claim, even when true, proves something narrower than it sounds. This table separates what each kind of evidence shows from what it leaves open.

Reproducible builds in practice

Conceptually, every maker's process is the same: fetch the source at the release tag, build it in the documented container, strip or zero the signature area, and compare the hash with the published or installed firmware. The device-side firmware hash check then ties the result to the device in your hand.

• Maker guides: Trezor · COLDCARD (repro target) · Jade · Keystone · BitBox02 · SeedSigner OS.
• Independent per-version results: WalletScrutiny. Check the version you actually run; results can change between releases.
• See also verifying firmware on the wallets page.

Questions to ask before trusting a generator

1. Which code path creates the seed, and is it the one that calls the hardware generator? (Not just "does a TRNG exist?")
2. How many independent sources are combined, and can one source see the others before choosing its value?
3. Can I add my own entropy, and can I verify with throwaway input that it was used?
4. Is the firmware build reproducible for the version on my device, and has anyone independent checked it?
5. Has the maker had an entropy advisory before, and how quickly and openly was it disclosed?
6. Which device and firmware made each of my seeds? (Record it, so you can act on a future advisory.)

Known weak-randomness incidents Intermediate

Sourced case notes, starting with the most recent hardware-wallet case. Every one produced seeds, keys or signatures with valid formats that looked random. Summary versions are also in the Case files.

More incidents: the Milk Sad team's ongoing research catalogues further weak-PRNG wallet families. See also our Case files.

What to avoid Beginner

Not advice: this page is educational. Methods, firmware and vendor features change; follow your device maker's current documentation and consider professional help for large or complex holdings.

Last reviewed: 23 October 2026 · Educational information only — verify current details with official sources.