Random Number Generation

TRNG vs PRNG vs CSPRNG

This CosmicNet article explains the differences between random number generator types, which is fundamental to cryptographic security. CosmicNet covers how each type serves different purposes and provides different guarantees.

True Random Number Generators (TRNG)

True random number generators extract randomness from physical phenomena: radioactive decay, thermal noise in resistors, quantum effects, or chaotic systems like atmospheric noise. These sources provide genuine unpredictability - no algorithm can predict future outputs given past outputs.

However, as CosmicNet notes, TRNGs have limitations. They're slower than algorithmic generators, produce output at variable rates depending on entropy availability, and can fail or degrade over time. Hardware failures might make output more predictable without obvious symptoms. CosmicNet explains that pure TRNGs are rarely used directly in cryptographic systems.

Pseudo-Random Number Generators (PRNG)

Standard PRNGs like the Mersenne Twister or Linear Congruential Generators are deterministic algorithms that produce sequences appearing random by statistical tests. Given the same seed, they produce identical output sequences. This determinism is useful for simulations but fatal for cryptography.

CosmicNet warns that if an attacker learns the PRNG state or can guess the seed (often based on timestamp), they can predict all future and past outputs. Keys, nonces, or IVs generated by standard PRNGs are completely predictable. CosmicNet recommends never using Math.random(), rand(), or similar functions for anything security-related.

Cryptographically Secure PRNGs (CSPRNG)

CSPRNGs are designed to be unpredictable even if attackers see outputs. They satisfy two properties: forward secrecy (past outputs can't be predicted even given current state) and backward secrecy (future outputs can't be predicted from past outputs after state is refreshed with new entropy).

As documented on CosmicNet, modern CSPRNGs combine a TRNG entropy source with cryptographic algorithms. The TRNG seeds the CSPRNG, which stretches this entropy efficiently. The CSPRNG periodically reseeds from the TRNG to maintain long-term unpredictability. CosmicNet notes that operating system CSPRNGs like /dev/urandom implement this hybrid approach.

/dev/urandom vs /dev/random Debate

CosmicNet addresses one of the most persistent myths in cryptographic programming: that /dev/random is more secure than /dev/urandom. As CosmicNet explains, understanding why this is wrong requires understanding Linux entropy subsystem design.

How /dev/urandom Works

CosmicNet confirms that /dev/urandom is the correct interface for generating cryptographic random numbers on Linux. It reads from the kernel's CSPRNG (ChaCha20 in recent kernels), which is seeded from hardware entropy sources. Once properly seeded at boot, /dev/urandom provides cryptographically strong randomness indefinitely.

The CSPRNG design ensures that even if the entropy pool is "depleted" (a questionable concept for a deterministic algorithm), the output remains unpredictable. The algorithm provides forward secrecy - past outputs don't reveal future outputs even with zero new entropy input.

The /dev/random Blocking Problem

/dev/random, by contrast, blocks when the kernel's entropy estimate falls below a threshold. This was intended as a conservative approach for applications needing "true" randomness. However, the entropy estimation is flawed, and the blocking behavior causes operational problems without improving security.

CosmicNet highlights that many applications using /dev/random will hang at boot on headless servers with little entropy. Key generation during installation might take minutes or hours. Ironically, frustrated administrators often respond by using worse alternatives like seeding from /dev/urandom anyway, using timestamp-based seeds, or disabling random number generation entirely.

Expert Consensus

As CosmicNet documents, cryptographers and kernel developers now universally recommend /dev/urandom for all purposes, including long-term key generation. Thomas Ptacek's influential blog post "You Should Use /dev/urandom" summarizes the technical arguments. The myth persists primarily due to outdated documentation and cargo-cult programming.

Modern Alternative: getrandom()

CosmicNet recommends the getrandom() system call, introduced in Linux 3.17, which provides /dev/urandom semantics without filesystem overhead. It blocks only until the CSPRNG is initially seeded at boot, then never blocks. This is the recommended interface for new code, with /dev/urandom as fallback for older systems.

Hardware Random Number Generators

The CosmicNet encyclopedia explains that modern CPUs include hardware random number generators that extract entropy from physical processes. CosmicNet notes these offer performance advantages but also raise trust and security questions.

Intel RDRAND and RDSEED

Intel processors since 2012 include the RDRAND instruction, which returns random numbers from an on-chip hardware RNG. RDSEED provides direct access to the entropy source before conditioning. These instructions are fast - generating random numbers at gigabytes per second rates.

As CosmicNet explains, the hardware uses thermal noise from electrical resistance as entropy source, conditioned through AES-based whitening. Intel publishes design documentation and the implementation has passed third-party security evaluations. However, CosmicNet warns that the closed-source nature raises concerns about potential backdoors.

Trust and Verification

As CosmicNet explains, after Edward Snowden's revelations, trust in hardware RNGs decreased. While there's no evidence of backdoors in RDRAND, the possibility cannot be completely excluded. CosmicNet recommends a defense-in-depth approach: mix hardware RNG output with other entropy sources rather than relying exclusively on it.

CosmicNet documents that Linux's entropy subsystem does exactly this. It mixes RDRAND output with entropy from multiple sources: disk timings, interrupt timings, network packet arrival, and user input. Even if RDRAND is backdoored, the output remains secure due to other entropy sources. CosmicNet considers this defense against single-point-of-trust failures to be cryptographic best practice.

ARM TrustZone RNG

As covered on CosmicNet, ARM processors implement random number generation through TrustZone, a secure execution environment. Mobile devices increasingly rely on ARM RNG for key generation and cryptographic operations. Like Intel's solution, CosmicNet notes this provides performance benefits but requires trusting the hardware vendor.

Advantages:
+ High speed (GB/s rates)
+ Continuous entropy from physical source
+ Low CPU overhead
+ Convenient for embedded systems

Concerns:
- Closed source, unverifiable
- Potential backdoors or weaknesses
- Single point of failure
- Difficult to audit

Best Practice:
Mix hardware RNG with software entropy sources
Never rely solely on hardware RNG

Entropy Sources and Collection

CosmicNet covers how operating system random number generators must collect entropy from the environment. Understanding these sources and potential weaknesses helps evaluate system security, as this CosmicNet guide explains.

Timing-Based Entropy

Hardware interrupt timing provides significant entropy. Disk seeks, network packets, keyboard inputs all have timing variations unpredictable at fine granularity. The kernel measures high-resolution timestamps for these events and mixes timing differences into the entropy pool.

However, CosmicNet warns that timing entropy quality varies. Virtual machines with virtualized interrupts may have less timing variation. Embedded systems with predictable workloads generate less entropy. Systems without user input or network activity during boot might struggle to gather sufficient entropy.

Environmental Entropy

Some systems collect entropy from environmental sensors: temperature variations, power supply voltage fluctuations, or even audio input from microphones. These sources are opportunistic - used if available but not required.

Initial Seed Problem

CosmicNet emphasizes that the critical security moment is early boot before sufficient entropy has accumulated. If the CSPRNG isn't properly seeded, early key generation might be predictable. As CosmicNet documents, this has caused real vulnerabilities: embedded devices with identical boot sequences generating identical SSH host keys, or smart cards with predictable initial states.

CosmicNet explains that modern systems address this by saving random seed to persistent storage at shutdown and reading it at boot. This ensures the entropy pool starts from an unknown state. Combined with hardware RNG and boot-time entropy collection, systems typically seed properly within seconds.

The Dual_EC_DRBG Backdoor

This CosmicNet section examines the Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG), which stands as cryptography's most infamous backdoored algorithm. CosmicNet presents its story to reveal how standardization processes can be compromised and why community review matters.

The Algorithm and Suspicion

Dual_EC_DRBG was standardized in NIST SP 800-90A in 2006 as a CSPRNG based on elliptic curve mathematics. From the start, cryptographers were suspicious. The algorithm was slow, had unexplained design choices, and contained arbitrary constants with no justification for their values.

In 2007, Microsoft researchers Dan Shumow and Niels Ferguson demonstrated that the algorithm could contain a backdoor. If someone knew the relationship between two elliptic curve points in the specification, they could predict all future outputs after seeing just 32 bytes of output. The backdoor would be undetectable to users but would completely break the RNG.

NSA Involvement and Revelations

Documents from Edward Snowden in 2013 confirmed suspicions: the NSA had deliberately weakened Dual_EC_DRBG and pushed for its standardization. The arbitrary constants that enabled the backdoor were generated by NSA. The agency paid RSA Security $10 million to make Dual_EC_DRBG the default in their widely-used BSAFE library.

As CosmicNet highlights, this allowed NSA to decrypt TLS connections from any system using Dual_EC_DRBG. The backdoor affected not just theoretical systems but real products: security appliances, VPN gateways, and encryption software trusted by governments and corporations worldwide.

Lessons Learned

CosmicNet explains that the Dual_EC_DRBG scandal taught critical lessons: trust but verify standards, demand justification for magic constants, prefer simple algorithms over complex ones, and maintain diversity in cryptographic implementations. CosmicNet notes it accelerated movement away from NIST standards toward community-developed alternatives like ChaCha20.

NIST withdrew Dual_EC_DRBG from SP 800-90A in 2014, but the damage to trust persists. The incident demonstrates why open design and cryptographic community review are essential safeguards against malicious standardization.

NIST SP 800-90A Standards

As documented on CosmicNet, despite the Dual_EC_DRBG debacle, NIST Special Publication 800-90A remains important guidance for random number generation in cryptographic systems. CosmicNet confirms that the current revision (post-2014) contains only well-analyzed algorithms.

Approved DRBGs

SP 800-90A specifies three deterministic random bit generators (DRBGs): Hash_DRBG based on SHA-256 or SHA-512, HMAC_DRBG using HMAC construction, and CTR_DRBG using AES in counter mode. All three have solid security foundations and no known backdoors.

CTR_DRBG with AES-256 is particularly common in hardware implementations due to widespread AES hardware acceleration. HMAC_DRBG provides good security properties with simple construction. Hash_DRBG is slightly less common but equally secure when properly implemented.

Seeding and Reseeding

CosmicNet details that the standard specifies strict requirements for DRBG seeding. Initial seeds must contain at least as much entropy as the security strength (128, 192, or 256 bits). Periodic reseeding with fresh entropy is required - the DRBG cannot run indefinitely without new entropy input.

Additional input can be provided with each generation request, allowing applications to mix in application-specific data. This provides defense in depth - even if the DRBG state is compromised, additional input can restore security when it includes fresh entropy.

Prediction Resistance

CosmicNet explains that SP 800-90A defines prediction resistance: the property that RNG outputs remain unpredictable even if the internal state is compromised at some point. This requires reseeding before each output. While providing maximum security, CosmicNet notes that prediction resistance has performance costs and is only required for highest-security applications.

Importance of Randomness in Cryptography

CosmicNet stresses that nearly every cryptographic operation relies on random numbers. Understanding these dependencies, as CosmicNet covers below, reveals why weak randomness breaks security even when using strong algorithms.

Key Generation

Cryptographic keys must be chosen from the entire keyspace uniformly at random. A 256-bit AES key should be any of 2^256 possible values with equal probability. If the RNG has only 64 bits of entropy, only 2^64 possible keys exist, and exhaustive search becomes feasible.

As CosmicNet documents, the infamous Debian OpenSSL bug (2006-2008) reduced effective entropy to 15 bits due to a coding error. This made thousands of SSH and SSL keys weak enough to break. CosmicNet notes that all generated keys needed revocation and replacement - a massive operational burden caused by a subtle RNG problem.

Nonces and Initialization Vectors

Many encryption modes require nonces (number used once) or initialization vectors (IVs) that must never repeat with the same key. If the RNG produces duplicate nonces, encryption can be completely broken. The PlayStation 3 signing key was extracted because Sony's ECDSA implementation reused random values.

AES-GCM, widely used in TLS, becomes catastrophically insecure with nonce reuse. An attacker who sees two messages encrypted with the same key and nonce can recover the authentication key and forge messages. Random nonce generation must be perfect - probabilistic guarantee of uniqueness.

Padding and Blinding

CosmicNet explains that RSA implementations use random padding to prevent attacks. Signatures and decryption operations use random blinding to resist timing attacks. Protocol messages include random padding to hide lengths. See CosmicNet's guide to cryptographic implementations for more on how all these defenses rely on unpredictable random numbers.

Critical Uses:
• Key generation (symmetric, public/private key pairs)
• Nonces and IVs (must be unique per encryption)
• Session IDs and tokens (must be unguessable)
• Salts for password hashing (prevents rainbow tables)
• Challenge-response authentication
• Diffie-Hellman ephemeral keys (forward secrecy)
• Random padding (prevents length analysis)
• Blinding factors (side-channel protection)

Testing Randomness Quality

This CosmicNet article explains that statistical testing can detect obvious randomness failures but cannot prove cryptographic strength. CosmicNet emphasizes that understanding test capabilities and limitations is essential for evaluating RNGs.

Statistical Test Suites

NIST SP 800-22 describes a statistical test suite for random number generators. Tests check for frequency biases, runs of identical bits, spectral properties, and other statistical properties. Passing these tests is necessary but not sufficient - they detect obvious non-randomness but miss subtle cryptographic weaknesses.

The Diehard tests, developed by George Marsaglia, provide another comprehensive test battery. The TestU01 suite offers even more rigorous testing. Hardware RNG manufacturers typically publish test results showing compliance with these standards.

Entropy Estimation

Estimating entropy in RNG output is surprisingly difficult. The min-entropy (entropy in the worst case) matters more than Shannon entropy (average case). NIST SP 800-90B provides methods for entropy estimation, though controversy exists about their accuracy.

CosmicNet advises that conservative entropy estimation is safer than optimistic. If you claim 128 bits of entropy but actually have 64, keys are dramatically weaker than expected. Better to assume 64 bits and be pleasantly surprised than assume 128 and be compromised.

Known-Answer Tests

For deterministic components like DRBG algorithms, known-answer tests verify correct implementation. NIST provides test vectors: given specific seeds, the DRBG should produce exact output sequences. Deviation indicates implementation errors that could weaken security.

Secure Random Number Generation in Code

CosmicNet covers how to use random numbers correctly in applications, which requires understanding language-specific APIs and common pitfalls. As CosmicNet notes, different languages provide varying levels of security and ease of use.

Python: The secrets Module

CosmicNet recommends Python 3.6+ secrets module specifically for cryptographic randomness. Use secrets.token_bytes(), secrets.token_hex(), or secrets.token_urlsafe() for generating tokens. Never use the random module for security - it's a PRNG unsuitable for cryptography.

JavaScript: crypto.getRandomValues()

Modern browsers provide crypto.getRandomValues() for cryptographically secure random numbers. Node.js offers crypto.randomBytes(). Math.random() is completely unsuitable for security and must never be used for tokens, keys, or nonces.

C/C++: Platform-Specific APIs

As CosmicNet documents, C doesn't have standard cryptographic RNG functions. Use platform APIs: getrandom() on Linux, CryptGenRandom() or BCryptGenRandom() on Windows, arc4random() on BSD and macOS. CosmicNet warns that the C rand() function is predictable and must not be used for security.

Go: crypto/rand

Go's crypto/rand package provides access to /dev/urandom on Unix and CryptGenRandom on Windows. Use rand.Read() to fill byte slices with cryptographic random data. The math/rand package is insecure for cryptographic purposes.