Cybersecurity glossary
What is a Cryptographically Secure Pseudorandom Number Generator (CSPRNG)?
Learn what a CSPRNG is, why insecure PRNGs break cryptography, how operating-system entropy feeds secure randomness, and which generation mistakes leak secrets.
Definition
A Cryptographically Secure Pseudorandom Number Generator (CSPRNG) is a random-bit generator designed so that its outputs are unpredictable to attackers who do not know the internal state, making it suitable for keys, nonces, tokens, and other secret cryptographic material.
Why secure randomness is non-negotiable
Cryptography assumes secrets attackers cannot guess. If session tokens, private keys, or GCM nonces come from a predictable generator, the algorithm may be perfect and still fail completely. A CSPRNG is the component that makes those values unpredictable under attack.
Incidents from weak PHP rand, seeded srand(time()), or Math.random tokens show the pattern: protocol logic looked fine while the entropy story was broken.
What “cryptographically secure” means here
A CSPRNG produces bits that are computationally indistinguishable from true random for practical attackers, and it resists predicting future outputs from past outputs. Many designs are deterministic algorithms seeded and reseeded from entropy sources—secure not because they are magical, but because reversing or predicting them is infeasible without the state and seed material.
Unpredictability
Seeing previous outputs should not let an attacker forecast the next key or token.
Forward security goals
Good designs limit how much past output exposure reveals about future bits after reseeding.
OS-backed entropy
Production apps should draw from kernel or platform CSPRNG APIs rather than homebrew generators.
Right-sized outputs
Generate enough bytes for the secret class—128+ bits for tokens, full key length for ciphers.
How applications should draw secure random values
Call a vetted API
Use language primitives documented as cryptographically secure (getrandom, SecureRandom, Web Crypto).
Request the needed length
Allocate the exact byte length for keys, salts, or tokens without truncating below security margins.
Encode safely for transport
Convert to hex or base64url only after generation; encoding is not entropy.
Use once for the intended purpose
Do not reuse the same random draw as both a key and a nonce unless a standard construction requires derivation.
Protect the result
Store secrets in vaults or hashed form; avoid logging raw tokens.
Handle early-boot carefully
Embedded and first-boot systems must ensure the entropy pool is initialized before key generation.
CSPRNG vs insecure generators
| Generator type | Suitable for | Example risk |
|---|---|---|
| Platform CSPRNG | Keys, tokens, salts, many nonces | Misuse still possible if outputs are truncated or logged |
| Statistical PRNG | Simulations, games, fuzz shaping | Session tokens become guessable |
| Time/PID seeded PRNG | Nothing security-related | Offline prediction of reset links |
| Custom “secure” hash of counter | Usually none without a full design review | Hidden bias or state recovery |
Checklist for secure random use
- Ban Math.random, rand(), and similar APIs for security-sensitive values in code review.
- Prefer standard library crypto random helpers over reading device files manually when wrappers exist.
- Generate at least 128 bits of entropy for bearer tokens and password-reset secrets.
- Do not seed cryptographic libraries with timestamps, usernames, or sequential IDs.
- On VMs and containers, ensure clones do not duplicate RNG state across instances before producing keys.
- For AEAD nonces, follow the mode’s uniqueness rules; randomness alone is not always the right strategy.
- Add tests that fail builds if insecure generators are used in auth or crypto modules.
- Treat RNG failures as hard errors—never silently fall back to weak randomness.
Where weak randomness shows up in assessments
Security reviews look for predictable invite codes, short numeric OTPs generated insecurely, static IVs, and test stubs that left return 4 // chosen by fair dice roll patterns in production. Cloud snapshot cloning and IoT first-boot key generation are recurring operational footguns even when the algorithm is a real CSPRNG.
The practical takeaway
A CSPRNG supplies the unpredictability every secret depends on. Use platform cryptographic random APIs, generate enough bits, never invent seeding schemes, and treat RNG failure as a security failure—not a cosmetic warning.
Related security terms
Entropy
The unpredictability that seeds and sustains secure random generation.
Nonce
A value that often must be unique and, in many designs, unpredictable.
Initialization Vector (IV)
Per-message randomness that frequently comes from a CSPRNG.
Key Derivation Function (KDF)
Functions that turn secret inputs into keys—still needing strong random salts/seeds.
Symmetric Cryptography
Bulk encryption that collapses if keys or IVs are predictable.
Frequently asked questions
What is a CSPRNG in simple terms?
It is a random generator safe for security decisions. Attackers should not be able to predict future outputs or recover past secrets even if they see many generated values.
How is a CSPRNG different from a normal PRNG?
Toy or statistical PRNGs optimize for speed or simulation quality, not adversarial unpredictability. Cryptography needs generators that resist state recovery and prediction attacks.
Should I use /dev/random or /dev/urandom on Linux?
For nearly all applications, the kernel CSPRNG interfaces used by getrandom() or /dev/urandom are appropriate after the system has initialized. Prefer OS APIs your language documents as cryptographically secure.
Can I seed a CSPRNG with the current time?
No. Timestamps and low-entropy seeds make outputs guessable. Use OS-provided secure randomness or a properly seeded cryptographic library API.
What should be generated with a CSPRNG?
Private keys, session tokens, password reset secrets, API keys, salts, nonces/IVs (when random), and similar high-impact secrets.
Is Math.random() a CSPRNG?
In typical JavaScript engines, no. Use Web Crypto getRandomValues or server-side secure APIs for security-sensitive values.
What happens if a CSPRNG state is compromised?
Future outputs may become predictable until reseeded from fresh entropy. Protect process memory and prefer OS generators that continuously mix entropy.
References
Explore authoritative guidance and frameworks related to cryptographically secure pseudorandom number generator (csprng).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.