478 / 736H

Cryptographic Entropy

What makes a secret hard to guess

A long, complicated string is not necessarily secure. With a wallet, what matters most is how its secret was created and what someone else might know about it.

In cryptography, entropy describes the uncertainty left to an attacker guessing a secret value. For a Bitcoin wallet, it matters from the moment the basis for its keys is created. The question is not whether the characters look complicated, but how many outcomes were genuinely possible, how likely they were and what the attacker knows about the process.

Imagine someone creates a secret from the date and time a wallet was set up. Once encoded, it might look like a long jumble of characters. But if an attacker knows the approximate time and the method, they may only need to try a small range of possibilities. A longer representation will not necessarily make their job harder. That is why RFC 4086 distinguishes unpredictability from merely looking random. You cannot assess entropy by looking at one key; you need to know how it was made. [3]

A bit is a basic unit of stored data with the value 0 or 1. The number of bits alone does not tell you how much uncertainty remains for an attacker. When a wallet creates a Seed Phrase under BIP39, it first needs random input. Only then does it turn that input into words. A 12-word phrase encodes 128 input bits and 4 checksum bits; a 24-word phrase encodes 256 input bits and 8 checksum bits. The checksum helps detect some recording errors, but adds no entropy: it is calculated from the existing input. A longer word list therefore cannot repair poorly generated randomness. How the backup was created matters, not just its word count. [4]

A wallet does not have to take a new physical measurement for every new byte, a group of 8 bits. It can use a cryptographic generator called a DRBG: an algorithm that produces further values from a secret initial state. With proper design and use, its outputs are hard to predict without knowing that state. Yet the algorithm is deterministic: the same complete state and inputs produce the same continuation. Generating more bytes does not automatically create more fresh physical entropy. Both the initial input and the protection of the internal state matter. [2]

A hash function calculates a fixed-length fingerprint of data that can look random. But someone who knows the input can calculate the same result. Fully known inputs do not become a secret this way. The technical term conditioning refers to processing that can reduce bias and concentrate uncertainty already available. It does not create a secret from nothing. Nor can you automatically add the entropy of several sources: they may be related and supply the same information. [1] [3]

An electronic noise source can fail or change its behavior with environmental conditions. NIST SP 800-90B therefore requires checks on unprocessed noise at startup and during operation, before conditioning. These checks look for signs of failure; they do not prove that every output is secure. Developers must understand the source, its limits and possible dependencies. A detected failure must be reported to the application using the data. A persistently faulty source must stop producing output. A chip labelled as a random generator is not enough by itself. [1]

If an attacker obtains a DRBG’s internal state, they may be able to predict subsequent outputs, depending on its design. Restoring unpredictability requires enough fresh input unknown to the attacker; adding such entropy is called reseeding. Simply continuing to calculate, or adding a known time, does not guarantee that protection. Also distinguish repairing a generator from securing existing funds: restoring the generator does not invalidate a key that has already leaked. [2]

A statistical test may reveal suspicious repetition, for example. But it cannot establish with certainty whether an attacker knows the secret input or a way to predict the output. NIST SP 800-22 explicitly acknowledges this limit. Tests are a useful part of an assessment, not a substitute for examining the whole generator. A file full of apparently random numbers is therefore not, by itself, evidence that a wallet is secure. [5]

Beginners do not need to calculate their wallet’s entropy by hand. It is more useful to look for a documented generation process: where its randomness comes from, how it is processed, how failures are handled and how secrets are protected. NIST SP 800-90C addresses exactly this combination of entropy sources and a DRBG into a complete generator. A reference to a standard or a familiar chip does not establish that a particular wallet version uses it correctly. What matters is evidence about the actual implementation. [1] [6]

For the clearest picture, read this entry together with Entropy Bit, CSPRNG, Dice Roll Entropy, Private Key. The reverse links also lead from BIP85, Dice Roll Entropy, Entropy Bit, Brute Force Search Space.

DOC · 001NIST SP 800-90B — Entropy source design and health testsSpecification DOC · 002NIST SP 800-90A Rev. 1 — Deterministic generation and reseedingSpecification DOC · 003RFC 4086 — Unpredictability and source limitationsSpecification DOC · 004BIP39 — Entropy, checksum and mnemonic encodingSpecification DOC · 005NIST SP 800-22 Rev. 1a — Limits of statistical testingDocumentation DOC · 006NIST SP 800-90C — Complete random bit generator constructionsSpecification
Revised: Source-first · No investment advice