Cryptographic Random Number Generation: Cryptography Deep Dive

1. Introduction and Core Concepts

Cryptographic random number generation is the process of producing random values that are suitable for use in security-sensitive contexts where unpredictability is not just desirable but mandatory. Unlike statistical randomness used for simulations or games, cryptographic randomness must withstand active adversarial attempts to predict future outputs even when an attacker has observed past outputs. This property, known as unpredictability, forms the foundation of modern cryptography, securing everything from encrypted web traffic to digital signatures and blockchain consensus.

At its core, cryptographic random number generation addresses a fundamental problem: computers are deterministic machines. Given the same initial state and inputs, they will always produce the same outputs. True randomness, which requires a source of physical entropy such as thermal noise, atmospheric noise, or quantum phenomena, is scarce and slow to harvest. Cryptographic systems therefore rely on Cryptographically Secure Pseudorandom Number Generators (CSPRNGs), which take a small amount of high-quality entropy (a seed) and deterministically expand it into a long sequence of bits that is computationally indistinguishable from true randomness to any efficient adversary.

To qualify as cryptographically secure, a generator must satisfy two rigorous requirements defined by NIST SP 800-90A and related standards. First, it must pass the next-bit test: given the first k bits of the output, no polynomial-time algorithm should be able to predict the (k+1)th bit with probability significantly better than 50%. Second, it must provide backtracking resistance (also called forward secrecy): compromise of the internal state at time t must not allow an adversary to reconstruct outputs generated before time t. Many CSPRNGs also provide prediction resistance, where a state compromise does not allow prediction of future outputs after sufficient fresh entropy is injected. These properties distinguish a CSPRNG from a standard Pseudorandom Number Generator (PRNG) like the Mersenne Twister, which is designed for statistical uniformity and speed but is completely predictable after observing 624 outputs.

• Entropy: A measure of unpredictability in a physical source, typically measured in bits. A source with n bits of entropy requires 2^n guesses on average to predict.
• Seed: A secret, high-entropy value used to initialize the internal state of a CSPRNG.
• Deterministic Random Bit Generator (DRBG): The NIST term for a CSPRNG algorithm that expands a seed using a cryptographic primitive such as a hash function or block cipher.
• Nonce and IV: Numbers used once that must be unique and unpredictable to prevent replay and cryptographic attacks; often generated by a CSPRNG.

2. How It Works

A cryptographic random number generator operates as a stateful system with three distinct phases: seeding, generation, and reseeding. During the seeding phase, the system collects entropy from one or more entropy sources. On modern operating systems, these sources include hardware events such as interrupt timings, mouse movements, disk I/O jitter, and dedicated hardware random number generators (HRNGs) like Intel's RDRAND or ARM's TRNG. This raw entropy is noisy and biased, so it is passed through a conditioning component, typically a cryptographic hash function like SHA-256 or SHA-512, which compresses and whitens the input into a uniformly distributed seed with full entropy.

The generation phase is where the Deterministic Random Bit Generator takes over. The DRBG maintains an internal state consisting of a secret key, a counter, and a value V. When random bytes are requested, the DRBG applies its underlying primitive to the state to produce output blocks and then updates the state. For example, Hash_DRBG repeatedly hashes the internal value V to produce output, while CTR_DRBG encrypts successive counter values with AES under a secret key. Crucially, the state update is a one-way function: even if an attacker learns the current state, they cannot reverse it to obtain previous states or outputs, which provides backtracking resistance. The generation algorithm is designed to be efficient, producing many bytes from a single seed without requiring new entropy for each call.

Reseeding is the mechanism that provides prediction resistance and long-term security. Over time, if an attacker were to compromise the internal state, all future outputs would become predictable until fresh entropy is introduced. To mitigate this, CSPRNGs periodically mix new entropy into the state. The operating system kernel's CSPRNG, such as /dev/urandom on Linux or BCryptGenRandom on Windows, continuously adds entropy from system events into an entropy pool. NIST recommends reseeding after at most 2^48 generate requests for Hash_DRBG or after a configurable reseed interval. A robust design also includes a health test that continuously monitors entropy sources for failure and a personalization string that allows applications to add additional context to the seed, ensuring domain separation between different uses of the same generator.

Entropy Pooling and Conditioning

Raw entropy sources are unreliable. A single source might fail or become predictable. Modern designs like Fortuna, designed by Bruce Schneier and Niels Ferguson, use multiple entropy pools to address this. In Fortuna, entropy is distributed round-robin across 32 pools, and pool i is used for reseeding only every 2^i reseeds. This ensures that even if an attacker controls some sources, at least one pool will accumulate sufficient entropy from honest sources to recover security. Conditioning with SHA-256 ensures that even biased sources with only partial entropy contribute securely without leaking structure.

3. Implementation

Application developers should almost never implement a CSPRNG from scratch. Instead, they should use the vetted implementation provided by their operating system or language standard library. In Python, the secrets module (introduced in Python 3.6) and os.urandom() provide access to the OS CSPRNG, which on Linux reads from the ChaCha20-based CRNG and on Windows uses BCryptGenRandom. These are suitable for generating tokens, keys, passwords, and nonces. The random module, by contrast, uses the Mersenne Twister and must never be used for security purposes.

import secrets
import os

# Best practice: Use secrets module for all cryptographic randomness
# secrets.token_bytes uses os.urandom() internally (OS CSPRNG)

# Generate a 256-bit (32-byte) symmetric key for AES-256
aes_key = secrets.token_bytes(32)
print(f"AES-256 Key: {aes_key.hex()}")

# Generate a URL-safe token for password reset (43 chars ~ 256 bits)
reset_token = secrets.token_urlsafe(32)
print(f"Reset Token: {reset_token}")

# Generate a cryptographically secure random integer in range
# Use secrets.randbelow instead of random.randint
secure_roll = secrets.randbelow(100) + 1  # 1 to 100 inclusive
print(f"Secure roll: {secure_roll}")

# For comparison: os.urandom is the low-level interface
raw_bytes = os.urandom(16)
print(f"Raw entropy: {raw_bytes.hex()}")

For educational purposes or when implementing a DRBG for compliance with NIST SP 800-90A, you can build a simplified Hash_DRBG using SHA-256. The following example demonstrates the core logic of instantiate, generate, and update. Note that this is a simplified illustration and omits health tests, derivation functions, and proper error handling required for a production implementation. It shows how a seed is expanded into an arbitrary length output while updating the internal state with a one-way hash.

import hashlib

class SimplifiedHashDRBG:
    def __init__(self, entropy: bytes, personalization: bytes = b""):
        # Instantiate: seed = Hash(entropy || personalization)
        # In real Hash_DRBG, use Hash_df derivation function
        seed_material = entropy + personalization
        self.V = hashlib.sha256(seed_material).digest()
        self.C = hashlib.sha256(b"\x00" + self.V).digest()
        self.reseed_counter = 1

    def _hash(self, data: bytes) -> bytes:
        return hashlib.sha256(data).digest()

    def generate(self, num_bytes: int) -> bytes:
        if self.reseed_counter > 10000:
            raise RuntimeError("Reseed required")

        output = b""
        temp_V = self.V

        # Generate blocks by hashing V, V+1, V+2, ...
        while len(output) < num_bytes:
            temp_V = self._hash(temp_V)
            output += temp_V

        # Update state for backtracking resistance: V = Hash(V || C || reseed_counter)
        self.V = self._hash(self.V + self.C + self.reseed_counter.to_bytes(8, 'big'))
        self.reseed_counter += 1

        return output[:num_bytes]

# Usage: seed with 32 bytes of OS entropy
seed = os.urandom(32)
drbg = SimplifiedHashDRBG(seed, personalization=b"flyfishnwa-example")
print(drbg.generate(64).hex())

A CTR_DRBG construction based on AES is the most widely deployed DRBG in hardware and TLS implementations due to its high throughput. It uses a block cipher in counter mode, where the internal state is a key and a counter. The following example uses AES-256 from the cryptography library to illustrate the principle. Each generate call encrypts incrementing counter values to produce pseudorandom blocks, then updates the key and counter.

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
import os

class SimplifiedCTRDRBG:
    def __init__(self, entropy: bytes):
        # Instantiate: Use first 32 bytes as key, next 16 as initial counter (V)
        # Real CTR_DRBG uses Block_Cipher_df and complex update
        assert len(entropy) >= 48, "Need 48 bytes entropy"
        self.key = entropy[:32]  # AES-256 key
        self.V = int.from_bytes(entropy[32:48], 'big')
        self.reseed_counter = 1

    def _encrypt_block(self, counter_val: int) -> bytes:
        counter_bytes = counter_val.to_bytes(16, 'big')
        cipher = Cipher(algorithms.AES(self.key), modes.ECB())
        encryptor = cipher.encryptor()
        return encryptor.update(counter_bytes) + encryptor.finalize()

    def generate(self, num_bytes: int) -> bytes:
        if self.reseed_counter > 2**48:
            raise RuntimeError("Reseed required - exceeded limit")

        output = b""
        temp_V = self.V

        # Generate output by encrypting V+1, V+2, ...
        while len(output) < num_bytes:
            temp_V = (temp_V + 1) % (2**128)
            output += self._encrypt_block(temp_V)

        # Update key and V for backtracking resistance
        # Generate 48 bytes to refresh key (32) + V (16)
        temp_data = b""
        for _ in range(3):
            temp_V = (temp_V + 1) % (2**128)
            temp_data += self._encrypt_block(temp_V)

        self.key = temp_data[:32]
        self.V = int.from_bytes(temp_data[32:48], 'big')
        self.reseed_counter += 1

        return output[:num_bytes]

# Instantiate with OS entropy
entropy = os.urandom(48)
ctr_drbg = SimplifiedCTRDRBG(entropy)
print(ctr_drbg.generate(32).hex())

The final implementation pattern demonstrates secure random number generation for common application tasks such as creating salts, nonces, and UUIDs. It emphasizes correct range handling to avoid modulo bias, a subtle bug where using rand % n creates a non-uniform distribution if n does not divide the generator's range evenly.

import secrets

def secure_random_int_uniform(low: int, high: int) -> int:
    """Generate uniform random int in [low, high] without modulo bias."""
    # secrets.randbelow handles rejection sampling correctly
    range_size = high - low + 1
    return low + secrets.randbelow(range_size)

def generate_salt(num_bytes: int = 16) -> bytes:
    """Generate a salt for password hashing (e.g., bcrypt, Argon2)."""
    return secrets.token_bytes(num_bytes)

def generate_nonce(num_bytes: int = 12) -> bytes:
    """Generate a 96-bit nonce for AES-GCM - must never repeat for same key."""
    return secrets.token_bytes(num_bytes)

# Example: Generate 5 unique nonces and check for collisions
nonces = [generate_nonce() for _ in range(5)]
print("Nonces:", [n.hex() for n in nonces])

# Secure password generation with required character sets
alphabet = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%"
password = ''.join(secrets.choice(alphabet) for _ in range(20))
print(f"Secure password: {password}")

# Uniform dice roll without bias
print(f"Uniform roll 1-6: {secure_random_int_uniform(1, 6)}")

4. Step-by-Step Example

To illustrate how a Hash_DRBG expands a seed, let us walk through a concrete, simplified example using SHA-256 with small values. Suppose we have collected 32 bytes of entropy from the OS: entropy = 0x8a3f...c1 and a personalization string "session-keys". The instantiate step first derives the initial internal state V. It computes V = SHA-256(entropy || personalization). Assume this yields V0 = 0x5e96...a2 (32 bytes). It then derives a constant C as C = SHA-256(0x00 || V0) = 0x9b12...7f. The reseed counter is set to 1. At this point the DRBG is ready to generate.

A caller requests 48 bytes of random output. The generate algorithm does not return V directly. Instead, it enters a loop: it computes w0 = SHA-256(V0) = 0x4a8d...e1 (32 bytes), which becomes the first 32 bytes of output. Since 48 bytes are needed, it computes w1 = SHA-256(w0) = 0x71c3...b9 and appends the first 16 bytes of w1 to reach 48 bytes. The output returned is w0 || first_16_bytes(w1). An attacker observing this output cannot recover V0 because SHA-256 is preimage resistant.

Immediately after generating, the DRBG updates its state to ensure backtracking resistance. It computes V1 = SHA-256(V0 || C || reseed_counter) where reseed_counter is 1 encoded as 8 bytes. Assume this yields V1 = 0x3f8a...d4. The reseed_counter increments to 2. If the internal state (V1, C, counter) is compromised at this moment, the attacker can predict future outputs (until reseeded) but cannot reverse the hash to obtain V0 or the previous output w0. This one-way update is the core security guarantee. When the counter reaches its limit or when prediction resistance is requested, the DRBG will require a reseed: V_new = SHA-256(V1 || entropy_new || C), mixing fresh entropy into the state.

5. Complexity Analysis

Cryptographic random number generation is designed to be computationally efficient after the initial seeding, as it is on the critical path for TLS handshakes, key generation, and nonce creation. The time complexity is dominated by the underlying cryptographic primitive. For Hash_DRBG and HMAC_DRBG, each output block requires one hash compression function invocation. For CTR_DRBG, each block requires one block cipher encryption. Therefore, generating n bytes has a linear time complexity of O(n) with a very small constant factor, as hash functions and AES are highly optimized in hardware.

Space complexity is constant, O(1), with respect to the number of bytes generated. The internal state size is fixed: Hash_DRBG with SHA-256 maintains a 440-bit state (V and C), CTR_DRBG with AES-256 maintains 384 bits (256-bit key plus 128-bit counter), and HMAC_DRBG maintains similar sized state. The entropy pool in the OS may be larger (typically 4096 bits) but is also constant. Reseeding and instantiation are more expensive than generation because they involve entropy collection, which may block if the system has insufficient entropy at boot time, and additional hashing for conditioning.

The critical performance bottleneck is not CPU time but entropy availability and reseeding latency. On embedded devices or virtual machines after a snapshot restore, entropy starvation can cause blocking or insecure fallback. Modern Linux kernels mitigate this with a ChaCha20-based CRNG that never blocks after initial seeding, while still providing cryptographic security. The following table summarizes the complexity characteristics of the core DRBG operations.

* b = block size (32 bytes for SHA-256, 16 bytes for AES). k = entropy input length. All operations are constant time with respect to security parameter after seeding.

6. Variations and Optimizations

NIST SP 800-90A standardizes three primary DRBG constructions, each with different trade-offs. Hash_DRBG, based on SHA-256, SHA-384, or SHA-512, is the most flexible and easiest to implement correctly without side-channel concerns. It provides strong backtracking resistance and is stateless in terms of key schedule. HMAC_DRBG, based on HMAC with SHA-256, offers the strongest security proofs and is the basis for deterministic ECDSA nonce generation (RFC 6979), which prevents catastrophic private key leakage from biased nonces as seen in the PlayStation 3 ECDSA failure. CTR_DRBG, based on AES or Triple-DES, offers the highest throughput on systems with AES-NI hardware acceleration, often exceeding several gigabytes per second, making it ideal for high-volume servers generating many TLS nonces.

Beyond the NIST standards, several important variations exist. Fortuna, mentioned earlier, improves upon the older Yarrow algorithm by using multiple entropy pools and AES-256 in counter mode, eliminating the need for entropy estimation, which is notoriously difficult to do accurately. ChaCha20-based DRBGs, used in the Linux kernel since version 4.8 and in OpenBSD's arc4random, replace AES with the ChaCha20 stream cipher. ChaCha20 is faster in software without hardware acceleration, is constant-time by design (resistant to cache-timing attacks), and has a simpler implementation. The Linux CRNG maintains a ChaCha20 key that is rekeyed every 5 minutes or after 2^20 bytes, providing excellent performance and security.

Optimizations for cryptographic RNGs focus on reducing contention, avoiding blocking, and ensuring fork safety. In multi-threaded servers, a single global CSPRNG with a lock becomes a bottleneck. Modern implementations use per-thread or per-CPU DRBG instances that are periodically reseeded from a global entropy pool, eliminating lock contention. Another critical optimization is fork safety: after a process forks, both parent and child share the same DRBG state, leading to duplicate outputs if not handled. Libraries like OpenSSL 1.1.1+ and Python's os.urandom detect forks via getpid checks or pthread_atfork handlers and automatically reseed the child. Hardware acceleration via RDRAND/RDSEED or ARMv8.5 RNDR instructions provides direct access to on-chip entropy, but it should be used to seed a software DRBG rather than used directly, to hedge against potential hardware backdoors or failures.

7. Real-World Applications

Cryptographic random number generation is ubiquitous in modern computing infrastructure, often invisible to the end user but critical to security. In web servers and TLS, every HTTPS connection requires multiple CSPRNG outputs: a 32-byte client random and server random for the handshake, ephemeral Diffie-Hellman private keys for forward secrecy, and per-record nonces for AES-GCM or ChaCha20-Poly1305. A single busy NGINX or Apache server may generate thousands of CSPRNG outputs per second. Databases use CSPRNGs to generate unpredictable row IDs, password reset tokens, and to encrypt data at rest with per-row keys. Networks rely on CSPRNGs for TCP initial sequence numbers, DNS query IDs, and ASLR (Address Space Layout Randomization) offsets that mitigate buffer overflow exploits.

In application security, CSPRNGs underpin authentication and authorization. Session identifiers, CSRF tokens, OAuth state parameters, and API keys must be unpredictable to prevent session hijacking and account takeover. Password hashing requires a unique, random salt per password to defeat rainbow table attacks; this salt is generated by a CSPRNG. Cryptocurrency wallets and blockchain systems depend entirely on CSPRNGs for generating private keys; a single biased bit in a 256-bit ECDSA private key can allow an attacker to brute-force the key, as demonstrated by the 2013 Android SecureRandom bug that led to theft of Bitcoin funds.

Emerging applications include secure enclaves, IoT devices, and post-quantum cryptography. Intel SGX and ARM TrustZone use CSPRNGs to generate attestation keys inside isolated enclaves. IoT devices, which often lack traditional entropy sources like disk and mouse, must carefully harvest entropy from sensor noise or radio jitter, making robust DRBG design even more critical. The following table summarizes common use cases and their specific requirements.

8. Comparison with Alternatives

Choosing the right random number generator requires understanding the threat model. Using a non-cryptographic PRNG where a CSPRNG is required is a critical vulnerability, while using a hardware TRNG directly without conditioning can be slow and may expose biases. The key distinction lies in predictability: a CSPRNG remains secure even when an adversary observes its output, whereas a PRNG does not. True Random Number Generators (TRNGs/HRNGs) provide physical entropy but are not suitable as direct replacements for CSPRNGs due to limited throughput and potential failure modes.

Non-cryptographic PRNGs like Mersenne Twister (MT19937), Xoshiro256++, and Linear Congruential Generators (LCGs) are designed for speed and statistical uniformity for simulations, Monte Carlo methods, and procedural generation. They are extremely fast, with periods of 2^19937-1 for MT19937, but their internal state can be reconstructed from a small number of outputs. In contrast, CSPRNGs are slower but provide security guarantees. TRNGs extract randomness from physical phenomena but require health monitoring and conditioning; they are best used as entropy sources to seed a CSPRNG, not as direct generators for bulk output. The hybrid approach, used by all modern operating systems, combines the best of both: a TRNG seeds a CSPRNG, which then provides fast, secure, and reliable output.

9. Common Mistakes and Best Practices

The most catastrophic mistake is using random instead of secrets in Python, or Math.random() in JavaScript, or rand() in C for security purposes. These generators are not CSPRNGs. In 2013, a vulnerability in Android's SecureRandom implementation, where it failed to properly seed the PRNG, resulted in duplicate ECDSA nonces and allowed attackers to compute private keys and steal funds from Bitcoin wallets. Similarly, early versions of Netscape SSL used predictable seeds based on time of day and process ID, allowing session keys to be brute-forced in minutes. Always use secrets, os.urandom(), getrandom(), or BCryptGenRandom for any security-sensitive value.

Another common pitfall is modulo bias when mapping random bytes to a smaller range. Writing secrets.token_bytes(1)[0] % 6 to simulate a dice roll introduces a slight bias because 256 is not divisible by 6; values 0-3 appear slightly more often than 4-5. The correct approach is rejection sampling, which the secrets.randbelow(n) function implements internally: it generates enough random bits to cover the range and discards values that would cause bias. Similarly, generating ECDSA private keys requires rejection sampling to ensure the key is uniformly distributed in the interval [1, n-1] where n is the curve order, not just any 256-bit number.

Best practices include never seeding a CSPRNG manually with low-entropy data like timestamps or PIDs, never reusing nonces with the same key in AES-GCM or ChaCha20-Poly1305 (which breaks confidentiality entirely), and ensuring fork safety in multi-process applications. After forking, immediately reseed or use a fork-aware CSPRNG. For long-running services, implement periodic reseeding and monitor the OS entropy pool health. When generating multiple keys, use distinct personalization strings or context separation to ensure outputs are cryptographically independent. Finally, always zeroize sensitive random material from memory after use when possible, and prefer high-level APIs that handle these details correctly rather than attempting to implement DRBG logic yourself.

• Do use secrets module for tokens, passwords, and nonces.
• Do use os.urandom() or getrandom() for keys and seeds.
• Do not use random module for security.
• Do not truncate or modulo random values without rejection sampling.
• Do ensure fork safety and reseed after VM snapshot restore.
• Do validate that your HRNG health tests pass before seeding.

10. Interview Questions

Interview questions on cryptographic random number generation test both theoretical understanding and practical security awareness. Candidates are expected to articulate the difference between statistical and cryptographic randomness, explain DRBG internals, and demonstrate knowledge of real-world failures.

Q1: Why is Mersenne Twister unsuitable for generating session tokens, even though it passes statistical randomness tests?

Mersenne Twister is designed for uniformity and speed, not unpredictability. It has a 624-word internal state that can be completely reconstructed after observing 624 consecutive 32-bit outputs. An attacker who captures that many tokens can clone the generator and predict all future tokens, leading to session hijacking. It also lacks backtracking and prediction resistance. A CSPRNG, by contrast, uses one-way functions like SHA-256 or AES so that observing outputs gives no information about the internal state or future outputs. Statistical tests like Diehard or TestU01 only measure distribution, not security against an intelligent adversary.

Q2: Explain backtracking resistance and prediction resistance. How does a DRBG achieve them?

Backtracking resistance ensures that compromise of the current state does not allow an attacker to compute past outputs. It is achieved by updating the state with a one-way function after each generate call, for example V_new = Hash(V_old || C). Since hash functions are preimage resistant, the old state cannot be recovered from the new one. Prediction resistance ensures that a state compromise does not allow prediction of future outputs after the generator is reseeded with fresh entropy. This is achieved by mixing new entropy into the state: V_new = Hash(V_old || entropy_new). Without fresh entropy, a compromised state remains compromised. NIST requires reseeding for prediction resistance.

Q3: What is entropy starvation and how do modern operating systems handle it?

Entropy starvation occurs when a system has not collected enough unpredictable physical events to seed its CSPRNG, typically at first boot on headless servers, VMs, or IoT devices. Early Linux /dev/random would block until sufficient entropy was estimated, causing boot delays, while /dev/urandom would return potentially predictable data. Modern kernels (Linux 5.6+, with ChaCha20 CRNG) solve this by using a single CRNG that blocks only until it has been initially seeded with 256 bits of entropy from the CPU's RDRAND, interrupt timings, and device-specific seeds saved to disk. After that, it never blocks and provides cryptographically secure output even if entropy estimation is imperfect, relying on the security of ChaCha20 rather than conservative entropy counting.

Q4: You need to generate a random 256-bit ECDSA private key. Why can't you just use 32 random bytes directly?

ECDSA private keys must be uniformly random integers in the range [1, n-1], where n is the order of the elliptic curve group (for P-256, n is slightly less than 2^256). If you use 32 random bytes as a big integer, values greater than or equal to n are invalid and must be rejected, otherwise the distribution is biased. Moreover, using modulo reduction random_bytes % n introduces modulo bias because 2^256 is not a multiple of n. The correct method is rejection sampling: generate 32 bytes, interpret as integer, and if it is 0 or >= n, discard and generate again. Alternatively, use RFC 6979 deterministic nonce generation with HMAC_DRBG, which is the industry standard to avoid bias and catastrophic nonce reuse.

Q5: Describe a real-world failure caused by weak random number generation.

A classic example is the 2008 Debian OpenSSL vulnerability. A developer commented out a line that fed entropy into OpenSSL's PRNG to silence a Valgrind warning about uninitialized memory. This reduced the entropy to only the process ID (15 bits), making the key space only 32,767 possibilities. All keys generated on Debian and Ubuntu for nearly two years were predictable and had to be revoked. Another example is the PlayStation 3 ECDSA failure where Sony reused the same random nonce k for different messages, allowing anyone to solve for the private key using simple algebra. Both cases highlight that failures in random number generation completely break the security of otherwise sound cryptographic algorithms.