CSPRNGs: Why Cryptographically Secure Random Numbers Are Essential for Security
Cryptographically Secure Pseudo-Random Number Generators (CSPRNGs) produce output that is computationally indistinguishable from true randomness — meaning an attacker cannot predict future outputs even with knowledge of past outputs. Standard PRNGs (Math.random(), rand()) are deterministic and reversible. CSPRNGs use entropy from hardware sources (timing jitter, thermal noise) and cryptographic algorithms to produce unpredictable output. Always use CSPRNGs for tokens, keys, session IDs, and any security-sensitive value.
A Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) is a random number generator whose output is computationally indistinguishable from true randomness — meaning that even with knowledge of all previous outputs and unlimited computing resources (short of breaking the underlying cryptographic primitive), an attacker cannot predict future outputs. ## Why Standard PRNGs Are Insecure Standard pseudo-random number generators (like JavaScript's `Math.random()`, PHP's `lcg_value()`, or Python's `random` module) are deterministic algorithms: given the internal state, all future outputs are predetermined and the state can often be recovered from observed outputs. These generators are designed for statistical properties (uniform distribution, low autocorrelation) but not for unpredictability. Reversing Pseudo-Random Number Generators: Why PRNGs Are Predictable and Hackable ## How CSPRNGs Work CSPRNGs combine two elements: **Entropy sources:** Hardware-derived randomness from unpredictable physical processes — CPU instruction timing jitter, thermal noise in semiconductors, mouse/keyboard event timing, disk seek timing. The operating system's entropy pool (`/dev/urandom` on Linux, `BCryptGenRandom` on Windows) collects and mixes entropy from multiple sources. **Cryptographic mixing:** The raw entropy is processed through cryptographic algorithms (typically AES-CTR, ChaCha20, or SHA-based constructions) that spread entropy uniformly across the output and ensure that observing any amount of output reveals nothing about future output. ## When to Use CSPRNGs **Always for:** Session tokens, authentication codes, API keys, password reset links, CSRF tokens, encryption keys/IVs, any value where predictability = vulnerability. **Not necessary for:** Game mechanics (unless security-relevant like gambling), simulations, statistical sampling, shuffling playlists, test data generation. ## Platform-Specific APIs | Platform | CSPRNG API | |----------|-----------| | Linux/macOS | `/dev/urandom`, `getrandom()` syscall | | Erlang/Elixir | `:crypto.strong_rand_bytes/1` | | Python | `secrets` module (not `random`) | | JavaScript (browser) | `crypto.getRandomValues()` | | JavaScript (Node) | `crypto.randomBytes()` | | Go | `crypto/rand` (not `math/rand`) | | Rust | `rand::rngs::OsRng` | The common mistake: importing the language's standard `random` module for security-sensitive code instead of the `crypto` or `secrets` equivalent.