Random Number Generation & Entropy Sources

#The Invisible Foundation: True Randomness#link

The strongest encryption algorithm in the world is useless if the key is predictable. If an attacker knows your random number generator (RNG) seed, they can recreate your 'private' keys perfectly. In computing, 'random' is often a lie—most generators are actually deterministic.

PRNG vs. TRNG

Pseudo-Random Number Generators (PRNGs) use a mathematical formula to produce a sequence of numbers that *look* random. If you know the seed and the formula, you know the entire sequence. True Random Number Generators (TRNGs) derive randomness from physical phenomena, like thermal noise or radioactive decay.

import random
import secrets

# BAD: Predictable PRNG for security
bad_key = random.randint(1000, 9999)

# GOOD: CSPRNG for security
secure_key = secrets.token_hex(32)

print(f'Unsafe: {bad_key}')
print(f'Secure: {secure_key}')

The `random` module in Python uses the Mersenne Twister, which is great for simulations but completely insecure for cryptography because its state can be recovered after observing enough output.

Entropy Pools and Starvation

The OS maintains an 'entropy pool'—a reservoir of randomness gathered from hardware interrupts, mouse movements, and keyboard timings. When a process requests a random number, it draws from this pool. On headless servers (no mouse/keyboard), entropy starvation can occur, causing the system to hang while waiting for enough randomness to generate a key.

Hardening Randomness in Production

To prevent entropy starvation in cloud environments, architects use hardware RNGs (like Intel's RDRAND instruction) or software daemons like `haveged` or `rng-tools` to inject synthetic entropy into the kernel pool.

• ▪Always use `secrets` or `os.urandom` in Python
• ▪Use `/dev/urandom` over `/dev/random` in Linux for performance
• ▪Implement hardware RNGs in IoT devices
• ▪Avoid using `time.time()` as a seed for security keys