Seed Generation

Imagine wanting an easy-to-remember wallet backup and choosing words from a favourite book. They may seem unusual to you, but an attacker can specifically try quotations and familiar human patterns. BIP39 therefore starts with computer-generated randomness and only then represents it as words. Entropy describes its unpredictability. The words are a readable record of secret data, not an invitation to invent a sentence. [1]

A wallet must actually obtain random data, not simply call a function with the right name. Linux, for example, provides getrandom(), which waits for the system source to be ready under its default settings. With GRND_NONBLOCK it may instead report EAGAIN, meaning the data is not yet available. Software must check the result and the number of bytes, or data units, obtained. Continuing after a failure as though secret input had been created could produce an apparently working but insecure wallet. [2]

Browsers also provide an interface for secure random data. Web Crypto getRandomValues() fills an integer array with cryptographically secure bytes; requests above 65536 bytes fail with QuotaExceededError. But this describes one function, not a security assessment of the website. A page could obtain good randomness and subsequently leak the backup words. The loaded code and what it does with the result must also be examined. [3]

If you copy a word incorrectly, a wallet may detect the mistake using a checksum: a short check calculated from the original data. BIP39 adds 4 checksum bits to 128 input bits to form 12 words; 256 input bits plus 8 checksum bits form 24 words. A bit is a basic unit of information. The check bits come from a data fingerprint calculated by SHA256, rather than providing further independent entropy. A valid checksum therefore says nothing about whether the words are secret or were generated securely. [1]

Words are convenient for a backup; software needs to turn them into precisely defined data. BIP39 uses the derivation function PBKDF2-HMAC-SHA512 with 2048 iterations to produce a 512-bit seed. Alongside the phrase it uses a parameter called salt: here, the literal text mnemonic followed by the passphrase, or an empty string if none is used. The phrase and this parameter use UTF-8 NFKD, which standardises character representation. A longer output cannot supply missing randomness: its length does not prove 512 bits of input entropy. [1]

BIP32 describes the next step. It derives a master private key and a chain code, accompanying data used to derive further keys. This lets a wallet create new addresses from a common starting point. Technically, it applies HMAC-SHA512 with the fixed text Bitcoin seed as the function’s key and splits the output. That public text is not your secret. A derived private key of zero or outside the permitted range is invalid. The seed is therefore not simply renamed a private key. [4]

Developers need to know whether their software performs the calculation correctly. Test vectors provide known inputs and expected results. BIP39 publishes sets containing entropy, words and a seed, including the test passphrase TREZOR. Matching the result checks conversion of that input; it does not show that the live generator produces unpredictable secrets. Because the test data is public, it must not serve as a secret backup for real funds. [1]

Several stages connect the randomness source, the words and the stored backup. NIST SP 800-90C describes how entropy sources combine with mechanisms for generating random data. Assessing a wallet also requires checking its particular software version, error handling and transfer of data between stages. A well-tested component cannot by itself guarantee that another part will not lose or disclose the secret. The aim is to follow the entire process, not look for a single reassuring label. [5]