Cryptographically Secure Random: APIs, Tokens, and Entropy Budgets
Anything an attacker can guess or replay breaks your system—session IDs, CSRF tokens, password reset codes, and API keys all require unpredictable bytes from a CSPRNG, not deterministic math libraries.
Platform APIs first
Browsers expose `crypto.getRandomValues`; Node and Python offer `crypto` and `secrets`. These tie into OS entropy sources—use them for byte buffers you then encode as hex, Base64, or UUID strings.
Hashes, passwords, and API keys
Random bytes are only half the story—store passwords with slow hashes and manage API keys with rotation. Cross-read hash functions and password security so generation and storage stay coherent.
Key management context
High-entropy strings are useless if leaked from repos—pair generation with API key management practices so secrets live in vaults and rotate on schedule.
Fork safety and process lifecycle
Some C libraries caution against using forked processes without re-seeding—long-running workers that fork after RNG use can theoretically duplicate state. Prefer spawning before heavy crypto or rely on OS handles that reinitialize after exec; this matters more in C extensions than in typical Node or browser code.
Byte length vs encoding overhead
Generate raw bytes first, then hex or Base64—converting strings to bytes the other direction invites charset mistakes. Document whether IDs are 128-bit random, 160-bit, or derived from hashes so incident responders know what “guessable” means in your threat model.
Compliance and audit trails
Regulated environments may require HSM-backed RNG or documented key ceremonies. Even without compliance, log when keys were minted and which service version issued them—pair with time-ordered IDs for correlation without exposing raw secrets in logs.
Recommended tools
Explore ranges and distributions for non-adversarial use.
Prototype length and charset for integration keys.
Compare v4 randomness with time-based IDs.
Generate human-memorable high-entropy phrases.
Related guides
Frequently Asked Questions
What makes randomness cryptographically secure?
A CSPRNG draws entropy from the OS and is designed so outputs are unpredictable to adversaries—unlike `Math.random()` for security.
Should I seed random myself?
In applications, use platform APIs (`crypto.getRandomValues`, `secrets` module)—do not roll your own PRNG seeds.
How do UUIDs relate to secure random?
UUID v4 uses random bits; v7 uses time plus randomness—pick the version that matches sortability and collision risk.
Are API keys and passwords the same problem?
Both need high entropy and safe storage—see password and API key guides for lifecycle, not just generation.
Is `openssl rand` enough for production?
Often yes on Unix—it wraps the same OS CSPRNG; still avoid piping binary to logs and prefer language bindings for portability.
What about VMs and early boot entropy?
Cloud images can starve entropy at first boot—use platform RNG devices or wait for `random_ready` before issuing long-lived keys.
Wrapping up
Use CSPRNGs for anything an adversary might guess, pair with correct storage and rotation, and never confuse demo randomness with production cryptography.
Random Number Generator →