483 / 736PRNG

Deterministic RNG

Deterministic pseudorandom number generator

The same procedure, starting state and inputs produce the same result. For a deterministic generator, that is a feature, not a fault. Security also depends on whether the output can be predicted without knowing its secret starting material.

A Deterministic RNG is a pseudorandom number generator: it calculates values by a fixed procedure rather than measuring a new random physical event for each one. It starts from input called a seed and maintains an internal state, the information needed for the next calculation. Repeating the entire procedure with the same inputs reproduces the results. This helps with testing. A secure cryptographic generator also needs a sound design and sufficient entropy—uncertainty in the input from an attacker’s perspective.

Imagine pausing a calculation and saving its memory. Restoring it at the same point and supplying the same subsequent inputs can let it continue identically. NIST SP 800-90A describes such generators as DRBGs. The algorithm, settings and order of requests all matter. Adding fresh entropy, called reseeding, changes the state. An identical seed alone therefore does not guarantee identical output from different programs. [1]

Even a simple simulation program can produce random-looking numbers. That is not enough to protect a wallet. RFC 4086 warns that an attacker may predict some such sequences even when they pass statistical tests. A cryptographically strong generator should remain practically unpredictable after part of its output is revealed. Design and the secrecy and quality of the initial material matter, not just the word “deterministic”. [2]

When tracking down a bug, it helps to reproduce exactly the same situation. The libsodium function randombytes_buf_deterministic() therefore returns the same sequence for the same seed. A developer can publish the expected result for others to check. That is precisely why a published test seed must not be used for a real wallet: anyone could calculate the same “secret” from it. [3]

BIP32 uses similar repeatability to derive keys, although this is not the same procedure as general-purpose random-data generation. It creates a branching tree of keys from a single seed. A derivation path selects the branch the wallet uses. The same seed and path can therefore recover the same keys. Another derived address does not, by itself, add fresh independent entropy to the original secret. [4]

In BIP39, recovery words, called a mnemonic, are only part of the input. PBKDF2 combines them with a passphrase, an optional additional secret, to calculate the seed used for subsequent derivation. A different passphrase produces a different result even when the words are unchanged. Recovering the same keys therefore requires all the original inputs and the corresponding derivation method. Matching words alone does not establish that. [5]

A digital signature proves that the holder of the relevant secret key authorized a transaction. RFC 6979 describes calculating the auxiliary signing value k from that key and the message being signed. This step need not obtain a new random value each time. It does not remove the need for good randomness when the key was originally created. A correct signing procedure cannot repair a key that was guessable from the start. [6]

Recovering the same keys through BIP32 is desirable; accidentally repeating values that were meant to be new is not. A virtual-machine snapshot saves a computer’s state, including memory. As libsodium warns, restoring it may repeat the generator’s state and outputs too. When copying an environment, it is therefore unsafe to assume that each running copy automatically starts creating independent secrets. [3] [4]

A developer compares a result with a test vector: a known input paired with its expected output. A match shows that the program calculates that example correctly. It does not prove that the real device obtains good entropy. NIST SP 800-90A addresses mechanisms and requirements for their inputs separately. Assessment also depends on the program version, configuration and entropy replenishment; the Deterministic RNG label alone cannot establish a wallet’s security. [1]

For the clearest picture, read this entry together with CSPRNG, Random Number Generator, HD Wallet, Seed Generation. The reverse links also lead from CSPRNG, COLDCARD RNG Incident (2026).

DOC · 001NIST SP 800-90A Rev. 1 — State, inputs and reseedingSpecification DOC · 002RFC 4086 — Pseudorandom sequences and unpredictabilitySpecification DOC · 003libsodium — Deterministic output and VM snapshotsDocumentation DOC · 004BIP32 — Hierarchical deterministic key derivationSpecification DOC · 005BIP39 — Mnemonic and passphrase to seedSpecification DOC · 006RFC 6979 — Deterministic signing and initial key generationSpecification
Revised: Source-first · No investment advice