Randomness, Entropy and RNGs: A Field Guide

Lire en français : README.fr.md.

This repository is a self-contained field guide to randomness, entropy and random number generators. It was born from a collaborative, iterative cross-review of a YouTube discussion thread, in which two independent analyses (and one very patient human referee) confronted their readings of the same comment until only the robust parts survived.

• A vocabulary fixer: PRNG, TRNG, CSPRNG, DRBG, RBG, entropy source.
• A misconception killer: length is not randomness, pseudo is not fake.
• A map of the real production pipeline, from physical noise to TLS keys.
• A collection of real incidents caused by bad seeding, not bad algorithms.
• A pedagogical companion for students, teachers and curious engineers.

• A cryptographic implementation tutorial. Do not roll your own crypto.
• A substitute for the NIST, BSI or IETF documents it points to.
• A claim that any single source of randomness should be trusted alone.

You never create entropy. You harvest it from unpredictable physical phenomena, you condition it, and you expand it deterministically with a cryptographically secure generator. Everything else in this guide is a footnote to that sentence.

A pseudo-random number generator is a deterministic algorithm: same seed, same sequence, forever. It creates no entropy. That does not make it useless: simulations, tests and probabilistic algorithms love fast, reproducible sequences. It makes it catastrophic for secrets when the generator is predictable, like the textbook linear congruential generator whose output exposes its internal state.

A true random number generator samples a physical phenomenon: thermal noise, oscillator jitter, avalanche noise, metastability. Raw samples are biased, correlated and may fail silently, which is why real devices add health tests and conditioning. A TRNG is an entropy source, not a magic randomness tap.

A cryptographically secure PRNG is a PRNG, full stop. It is deterministic, seeded and reseeded from entropy, and designed so that its output is computationally indistinguishable from uniform and unpredictable without the secret state. It expands a small secret seed into a long usable stream. It never increases information-theoretic entropy.

The single most common conceptual error, and the one that motivated this repository, is the claim that a CSPRNG is a high-quality TRNG. It is the opposite branch of the family tree: a CSPRNG is a deterministic expander fed by entropy, while a TRNG is the physical source of that entropy.

Concatenating the integers from 0 to 100 produces a huge number with almost zero entropy. A fair coin flip produces one bit and is genuinely random. If, and only if, bits are independent and uniform, then more bits means more entropy. Entropy is a property of a source and a model, not of an observed string.

• Shannon entropy: the average case, source coding, entropy rate.
• Min-entropy: the worst case, the workhorse of extraction and seeding.
• Smooth min-entropy: finite regimes and quantum side information.
• Collision entropy: Renyi order 2, birthday-style bounds.
• Guessing entropy: average guessing cost, central in side-channel work.

A deterministic public function cannot increase min-entropy. Hashing a weak source does not upgrade it; it only concentrates and reshapes whatever entropy the source already had. This is the practical content of the leftover hash lemma: extraction concentrates, it never manufactures.

A fair six-sided die carries log2(6), about 2.585 bits per throw. Ten throws carry at most about 25.85 bits. Hashing them into 256 bits does not produce 256 bits of entropy. Also, converting die faces to bits naively introduces modulo bias; use rejection sampling or a proper extractor.

Physical entropy sources        thermal noise, jitter, avalanche, lava lamps
        |  continuous health tests
        v
Conditioning and extraction     hash, HMAC, AES; concentrates, never creates
        v
Seed, nonce, personalization
        v
DRBG, the CSPRNG                HMAC_DRBG, CTR_DRBG, ChaCha20-DRBG, Fortuna
        |  reseeding, state compromise resistance
        v
RBG exposed by the OS           getrandom, getentropy, BCryptGenRandom,
                                RAND_bytes, randombytes_buf
        v
Applications                    keys, IVs, nonces, tokens, session IDs

• NIST SP 800-90B: entropy sources, estimation, health tests.
• NIST SP 800-90A: deterministic RNG mechanisms, reseeding, limits.
• NIST SP 800-90C: full random bit generator constructions.
• BSI AIS-31 and FIPS 140-3: evaluation and validation frameworks.

Modern systems do not let applications touch raw sensors. Linux mixes interrupt timings, hardware RNGs and jitter into a ChaCha20-based CRNG and exposes it through getrandom and /dev/urandom. Windows, macOS, OpenSSL and libsodium follow the same philosophy: one audited CSPRNG, many sources, constant reseeding.

A key is only as strong as the weakest of: its entropy, its algorithm, its implementation and its protocol. A 256-bit key seeded with 48 bits of entropy has 48 bits of security.

• Using rand, Math.random or Mersenne Twister for secrets.
• Seeding with time, PID or hostname.
• Low entropy at first boot on embedded devices and virtual machines.
• Cloned VMs and restored snapshots replaying RNG state.
• fork without reseeding in user-space generators.
• Reused or predictable ECDSA nonces.
• Debian OpenSSL, 2008: crippled entropy, keys guessable from PID space.
• PlayStation 3: constant ECDSA nonce, private key recovered.
• Android Bitcoin wallets, 2013: weak SecureRandom seeding.

The dominant failure class is not weak algorithms. It is weak entropy management.

Cloudflare films a wall of about one hundred lava lamps. The chaotic wax motion plus camera sensor noise provide unpredictability; frames are hashed, mixed with operating system entropy, and used to seed CSPRNGs that protect TLS traffic. The lamps harvest entropy; they do not create it. It is the pipeline above, made visible and famous.

Two independent language-model analyses of the same source text were cross-reviewed iteratively, with a human arbitrator. Concessions were made, scores were revised, terminology was standardized. The method matters: the best version of an analysis is the one that survived argued criticism.

• RFC 4086, Randomness Requirements for Security
• NIST SP 800-90A
• NIST SP 800-90B
• NIST SP 800-90C
• Cloudflare, lava lamp encryption
• Cloudflare, LavaRand in production
• Leftover hash lemma

Markdown files are checked in CI by markdownlint-cli2. The project configuration disables only MD013, because verbose prose and long badge lines deserve to breathe, and MD041, because badges legitimately precede the title. Every other default rule is enforced.

Corrections, precisions and new incidents are welcome. Bring sources, bring nuance, leave ego at the door.

MIT. See the LICENSE file.

This repository was born from a discussion on a YouTube video about randomness and cryptography: Video source.

Educational content only. For production cryptography, use audited libraries and operating system primitives, and never build your own.

• Why this repository exists
• How not to generate randomness
• Real world implementations
• Randomness in virtualized environments
• Hardware sources and their limits
• Threat modeling for randomness
• Myths and misconceptions
• Sponge constructions as DRBG and XOF