A Random Number Generator supplies values for a chosen purpose. Cryptographic use requires that an adversary cannot feasibly predict them under the stated assumptions. A physical entropy source, a deterministic generator and an operating-system interface are distinct layers; the RNG label alone does not specify their properties.
An entropy source provides uncertainty, conditioning prepares input, and a deterministic generator produces output from internal state. NIST SP 800-90C combines mechanisms from 90A with sources under 90B. Each returned bit therefore need not correspond to a fresh physical measurement. [NIST SP 800-90C — RBG constructions]
A sequence may pass statistical tests while already being known to an attacker. RFC 4086 warns about clocks, serial numbers and predictable initial values. A simulation generator cannot therefore be treated as suitable for cryptography merely because of its name or output distribution. [RFC 4086 — Unpredictability and weak inputs]
NIST SP 800-90B evaluates a noise source, conditioning and health tests at startup and during operation. These tests detect source faults; they do not establish the security of an entire wallet. Failure handling belongs in the design: faulty-path output must not silently be presented as validated randomness. [NIST SP 800-90B — Source health and failure handling]
Linux getrandom() normally waits for the urandom source to initialize. With GRND_NONBLOCK it can return EAGAIN instead. After initialization, urandom requests of at most 256 bytes are guaranteed complete reads without signal interruption; larger requests have no such guarantee. Applications must respect the return status. [Linux getrandom(2) — Initialization and return behavior]
Web Crypto getRandomValues() fills supported integer arrays with cryptographically strong values; requests above 65536 bytes raise QuotaExceededError. The specification recommends generateKey() for creating keys. Availability of the interface does not establish a page’s trustworthiness or protect secrets from code able to access them. [W3C Web Crypto — getRandomValues and key generation]
BIP39 first encodes 128 to 256 bits of initial entropy with a derived checksum. Only then does it derive a 512-bit seed from the words and optional passphrase using PBKDF2. Neither the checksum nor a longer derived output fixes predictable input; choosing words yourself cannot replace random generation. [BIP39 — Initial entropy and mnemonic-to-seed derivation]
A deterministic generator needs protected state and correct initialization. NIST SP 800-90A distinguishes instantiation, generation, reseeding and uninstantiation. Recovery after state disclosure needs an appropriate mechanism and fresh entropy unknown to the attacker; merely calling the generator again is no general recovery guarantee. [NIST SP 800-90A Rev. 1 — DRBG lifecycle and reseeding]
A review should identify the source, algorithm, initialization, interface and failure behavior of the version under assessment. Labels such as hardware or offline do not establish that chain. The cited standards explain generation requirements; they do not certify a particular wallet or prevent a later leak of its backup. [NIST SP 800-90C — RBG constructions] [RFC 4086 — Unpredictability and weak inputs]
For the clearest picture, read this entry together with Cryptographic Entropy, CSPRNG, Seed Generation, Brute Force Search Space. The reverse links also lead from CSPRNG, Deterministic RNG, True Random Number Generator, Seed Generation.