Random, Pseudorandom, or Cryptographically Secure? What 'Seed' Actually Means

The one-sentence version

A pseudorandom number generator (PRNG) produces a sequence that looks random but is fully determined by a starting value called a seed — same seed, same sequence, forever. A cryptographically secure generator (CSPRNG) is built so that even someone who sees part of its output can’t predict the rest. Use a PRNG when reproducibility helps you; use a CSPRNG when anyone would benefit from guessing the next value. Mixing these up is a common, consequential mistake.

PRNGs and seeds: determinism as a feature

A PRNG is an algorithm, not a physical process. Feed it a seed — a number — and it churns out a sequence of values through deterministic math (common examples: xorshift, PCG, Mersenne Twister). The output passes statistical randomness tests: no obvious pattern, roughly uniform distribution, no easy correlation between consecutive values. But it isn’t random in the “unknowable” sense — knowing the algorithm and the seed means knowing the entire sequence, instantly, without running anything.

That sounds like a weakness, and for some uses it is. But for a huge range of everyday needs, it’s exactly what you want: reproducible tests that fail the same way every run so you can actually debug them instead of chasing a moving target; shareable results, where a game level or shuffled deck is more useful if you can hand someone the seed and say “you’ll get exactly what I got”; and debuggable simulations, where scientific or statistical runs need to be replayed and audited.

Tools like the Random Number Generator and Distribution Sampler support seeding for exactly this reason — sometimes you want a fresh draw, sometimes you want to regenerate the exact one you got yesterday.

Why seeded output must never be a password or a token

The same determinism that makes a PRNG great for reproducible tests makes it actively dangerous for anything meant to be a secret.

If an attacker can guess or narrow down the seed — and seeds are often small, time-based, or otherwise guessable — they can regenerate the entire sequence your “random” password or token came from. Even without knowing the seed, some widely used PRNGs have a further problem: observing enough output lets you reconstruct internal state and predict everything that comes next. The Mersenne Twister, for instance, can be fully reconstructed from 624 consecutive outputs — well documented, not theoretical. PRNGs are designed to be statistically well-distributed, not to resist an adversary reverse-engineering them; those are different goals.

A seeded PRNG is perfect for a shuffled deck in a casual game. It is never appropriate for a session token, an API key, a password reset link, or anything where someone benefits from predicting the value ahead of you.

What crypto.getRandomValues does differently

Browsers and modern runtimes expose a separate API — crypto.getRandomValues() in JavaScript, or equivalents elsewhere — that draws from the OS’s cryptographically secure random source (/dev/urandom on Linux/macOS, CryptGenRandom on Windows), continuously fed by real entropy: hardware noise, interrupt timing jitter, other physical unpredictability.

The practical difference isn’t just “seeded from better randomness once.” A CSPRNG is engineered so that observing its past output gives no useful advantage in predicting future output, even knowing the algorithm — there’s no small, guessable seed behind it that an attacker could brute-force offline. This is why every password generator, token generator, and cryptographic key needs this API rather than a general-purpose PRNG.

The Password Generator and Secure Token Generator both draw exclusively from this source, deliberately with no seed option — a “reproducible password” is a contradiction.

Entropy, in plain terms

“Entropy” gets thrown around loosely, but the idea is simple: it’s a measure of how many equally likely possibilities there are, expressed in bits. If a value could be any one of N equally likely outcomes, it has log₂(N) bits of entropy. A fair coin flip has 1 bit (2 outcomes); a 4-digit PIN has about 13.3 bits (10,000 possibilities); a 16-character password from a 94-character set has around 105 bits.

Entropy determines how hard something is to brute-force: each additional bit doubles the guesses needed. This is also why randomness isn’t binary — a value can be some random (a die roll, ~2.58 bits) without being anywhere near enough for a security credential, which typically wants well over 80 bits to be safe against realistic attack budgets.

The decision rule

One question settles it:

Does anyone benefit from predicting this value before you reveal it?

• Yes — a password, an API token, a session ID, a cryptographic key, a lottery draw with money attached → use a CSPRNG (crypto.getRandomValues or your platform’s equivalent). No seed, no shortcuts.
• No — a dice roll for a board game, a shuffled quiz order, sample data for a demo, a procedurally generated maze → a seeded PRNG is fine, and its reproducibility is usually a bonus rather than a cost.

The failure mode almost always runs in one direction: people use a fast, convenient PRNG for something that needed to be unpredictable, not the other way around — the mistake that actually happens in the wild is using Math.random() for a password reset token, not using a CSPRNG where a seeded PRNG would’ve been fine.

Common mistakes

Using Math.random() for tokens. JavaScript’s Math.random() is a general-purpose PRNG (V8 uses a variant of xorshift128+), not a cryptographic one, and has shown up repeatedly in real-world vulnerability reports as the root cause behind guessable password-reset tokens.

Assuming a seed is secret. A seed is just a number. If it’s derived from something guessable — a timestamp, a small integer range, a user ID — treat the sequence it produces as guessable too.

Conflating “passes randomness tests” with “cryptographically secure.” A PRNG can produce output statistically indistinguishable from random while still being fully predictable to someone who’s recovered the seed or internal state. Statistical quality and unpredictability-under-attack are different properties.

FAQ

Can I make a PRNG secure by using a really unpredictable seed? Not reliably. Many general-purpose PRNGs let an attacker recover internal state from observed output, predicting everything downstream regardless of the seed. Use a generator actually designed for security instead.

Is a seeded PRNG “less random” than a CSPRNG? Statistically, often no — a good PRNG’s output can pass the same distribution tests. The difference is predictability under adversarial conditions, not how uniform the numbers look.

Why would a tool let me pick a seed at all if it’s risky? Reproducibility is genuinely useful outside security contexts — sharing a dataset, replaying a test, resolving a rules dispute in a game. The risk only appears when seeded output gets used somewhere unpredictability was needed instead.

Does more entropy always mean more secure? Only if the generator producing it is actually unpredictable. High entropy from a weak, guessable-seed PRNG doesn’t help — an attacker who can reconstruct the generator’s state doesn’t need to brute-force anything.