🎲 Why Randomness is Critical in Cryptography — Understanding RNGs, PRNGs, and How They Can Fail

Randomness is more than just a technical detail in cryptography — it’s the core of everything we rely on for secure systems.

From key generation, nonces, and initialization vectors, to tokens and one-time passwords, strong randomness ensures that secrets remain unpredictable and therefore secure. When randomness is weak or predictable, attackers can break systems that appear otherwise sound.

But computers are inherently deterministic. So where does this critical randomness come from? The answer lies in Random Number Generators (RNGs) and Pseudorandom Number Generators (PRNGs).

---

🔍 What Is Randomness in Cryptography?

In cryptographic terms, randomness refers to the uncertainty and unpredictability of data. This is often measured using entropy, a concept borrowed from information theory that quantifies how unpredictable a random variable is. High entropy = hard to guess = good for security.

• 128-bit key chosen uniformly → has 128 bits of entropy

• Heavily biased or predictable values → much lower entropy → unsafe

The goal of cryptographic randomness systems is to ensure that every generated bit contributes to high-entropy, unpredictable outputs.

---

🔐 RNG vs PRNG: The Foundation of Cryptographic Randomness

Cryptosystems typically generate randomness in two stages:

1. RNGs (Random Number Generators) — harvest entropy from the environment

2. PRNGs (Pseudorandom Number Generators) — use that entropy to generate many high-quality bits

These two components work together to balance real-world entropy with practical performance.

---

🌱 RNG: Real Entropy from the Environment

RNGs are hardware or software components that collect entropy from analog sources in the physical world:

• Keyboard and mouse input timing

• Network or disk I/O timings

• Acoustic, thermal, or electrical noise

• Radioactive decay, vacuum fluctuations (in quantum RNGs)

These sources are chaotic and unpredictable, making them ideal for seeding PRNGs. However:

⚠️ Limitations of RNGs

• Slow: Real-world entropy takes time to accumulate

• Fragile: Inputs like mouse movement can be spoofed or manipulated

• Limited: Embedded devices or virtual machines may lack strong entropy sources

• Unmeasurable: It’s hard to quantify how much entropy was actually captured

That’s why RNGs aren’t used directly for every cryptographic operation.

---

⚙️ PRNG: Scalable and Secure Randomness Generation

Once an RNG provides some initial entropy, a PRNG takes over. PRNGs are deterministic algorithms that use this seed to generate large streams of pseudorandom bits that appear random and unpredictable.

✅ Key Characteristics:

• Fast: Can output millions of bits per second

• Repeatable: Given the same seed, the output is identical (which is a benefit for testing and simulations, but dangerous in real-world cryptography if misused)

• Unpredictable: When seeded securely, output is cryptographically strong

The internal structure of a PRNG includes an entropy pool and a DRBG (Deterministic Random Bit Generator).

🔁 How PRNGs Operate:

init()         → Initialize the entropy pool and internal state
refresh(R)     → Mix in fresh entropy R (typically from RNG)
next(N)        → Output N pseudorandom bits and update internal state

PRNGs never reuse the same seed twice, and cryptographic PRNGs follow strict security requirements — such as those defined in NIST SP 800-90A for DRBGs.

---

📊 Comparing RNG and PRNG

---

⚠️ When Randomness Fails: 4 Real-World Examples

Even with good tools and libraries, implementation mistakes or poor design choices can lead to catastrophic randomness failures.

Here are four real-world examples where broken randomness led to security vulnerabilities:

---

🧨 1. Netscape SSL (1996): Predictable Seed Values

Issue: The browser seeded its PRNG using predictable values like:

• seconds, microseconds, pid, ppid

• These added up to only ~47 bits of entropy, far from the needed 128 bits

Impact: SSL session keys could be brute-forced or guessed with relative ease.

Lesson: Never rely on system time or PIDs as entropy — attackers can guess them.

---

🔁 2. Identical Keys from Different Systems (2012)

Researchers scanned TLS and SSH servers and found that many devices shared the same public keys, or had shared prime factors in their RSA moduli.

Cause:

• Devices generated RSA keys on first boot

• PRNGs were seeded with insufficient entropy, often a static or identical value

Impact:

• Attackers could factor RSA keys by computing GCD between two moduli: GCD(n, n′) = shared prime → private key recovered

Lesson: Never generate cryptographic keys before sufficient entropy is collected.

---

🔓 3. MediaWiki: Using Non-Crypto PRNG for Tokens

Background: MediaWiki once used PHP’s mt_rand() (Mersenne Twister) to generate security tokens and temporary passwords:

function generateToken($salt = '') {
  $token = dechex(mt_rand()) . dechex(mt_rand());
  return md5($token . $salt);
}

Problem:

• mt_rand() is not cryptographically secure

• Researchers showed that future tokens could be predicted using just a few known values

Fix: MediaWiki was patched to use a crypto-secure PRNG like /dev/urandom.

Lesson: Never use general-purpose PRNGs for crypto — always use CSPRNGs.

---

🧮 4. Cryptocat: Modulo Bias in Random Sampling

Cryptocat, a secure chat app, tried to generate a random decimal string:

while (o.length < 16) {
  x = state.getBytes(1);
  if (x[0] <= 250) {
    o += x[0] % 10;
  }
}

Bug:

• It used mod 10 to convert a byte to a digit

• But 256 isn’t divisible by 10 → leads to biased output

• Worse: an off-by-one bug (<= 250 instead of < 250) increased the bias

Impact: Entropy was reduced, and attackers could exploit this to reduce keyspace.

Lesson: Be careful when converting random bytes — avoid modulo bias.

---

✅ Final Thoughts

Randomness in cryptography isn’t optional. It’s a critical dependency that must be treated with the same care as encryption algorithms or protocol design.

To recap:

• RNGs provide real entropy, slowly and unpredictably

• PRNGs extend that entropy to make cryptographic systems practical

• But if either is used incorrectly, even strong encryption can become useless

Best Practices:

• Use only cryptographically secure PRNGs (CSPRNGs)

• Never generate keys before collecting sufficient entropy

• Always handle sampling and seed initialization with care

Because when randomness breaks, security crumbles silently.

---