How Secure Random Number Generators Work

What "random" has to mean for security

In everyday language, "random" means "no visible pattern". A shuffled playlist feels random if the same artist does not play twice in a row. For security, that is not enough. A password is secure only if an attacker cannot predict it, even an attacker who knows exactly which program produced it and has studied that program carefully.

So the security question is never "does this look random?" It is "could someone who knows how it was made guess it faster than by trying everything?" Secure random number generators are built to make the answer "no".

They do this in two stages. First, they collect a small amount of genuine unpredictability. Second, they stretch it into as many random-looking numbers as needed, using cryptography so that the stretching does not create a pattern anyone can follow.

Entropy: the raw unpredictability

Entropy, in this context, measures how much unpredictability a value contains. A fair coin flip gives one bit of entropy: an attacker has a 50% chance of guessing it. Twenty fair coin flips give 20 bits: about one chance in a million.

Computers are designed to be predictable, so they have to collect entropy from the physical world. RFC 4086, a long-standing IETF best-practice document on randomness, lists examples of such sources: small fluctuations in disk drive rotation speed, the timing and content of mouse movements and key strokes, digitised sound from a microphone, and hardware circuits such as ring oscillators ^[5]. These are examples of the kind of noise systems use, not a description of what any one computer does today.

The Linux manual pages describe this stage in general terms: the kernel "relies on entropy gathered from device drivers and other sources of environmental noise" to seed its generator ^[1]. NIST has a separate standard, SP 800-90B, just for designing and testing entropy sources ^[7].

Raw noise has two problems. It is slow to collect, and it is often uneven (a key press time is more likely to land in some ranges than others). That is why systems do not hand raw noise to applications. They use it to seed a generator.

Deterministic generators: same seed, same numbers

A pseudo-random number generator (PRNG) is a formula. You give it a starting value, the seed, and it produces a long stream of numbers. The same seed always produces the same stream.

A simple illustration: a video game can store a seed with a saved level. Load the same seed and you get exactly the same "random" map. This repeatability is a feature for games, tests and simulations.

For secrets, repeatability is a risk. RFC 4086 says traditional pseudo-random sequences "are fully predictable if the initial state is known" ^[5]. If an attacker learns the seed, or the generator's internal state at any point, they can calculate its output themselves.

Cryptographically secure generators (DRBGs)

A cryptographically secure pseudo-random number generator (CSPRNG) is still deterministic. The difference is that it is built from cryptographic parts, such as hash functions or block ciphers, so that its output reveals nothing useful about its state. Seeing a million outputs should not help you predict the next one.

NIST calls these designs deterministic random bit generators, or DRBGs. SP 800-90A Rev. 1 specifies DRBG mechanisms "based on either hash functions or block cipher algorithms" ^[6]. A complete random bit generator combines a DRBG with an entropy source, and NIST SP 800-90C (final, September 2025) describes how to build those combinations ^[8].

RFC 4086 gives the core recipe in one sentence: start with a strong random seed, take cryptographically strong steps from it, and do not reveal the complete state ^[5]. An analogy: the seed is a secret starting point on a map so large that nobody can search it, and each step moves to a new point using a rule that cannot be run backwards.

A detail that often surprises people: even the browser's secure generator is pseudo-random. MDN notes that, for performance, implementations do not use a truly random generator but "a pseudo-random number generator seeded with a value with enough entropy" ^[3]. That is normal and expected. Security comes from the strength of the design and the quality of the seed, not from every bit being physical noise.

Why predictability matters: state compromise

What if an attacker does learn a generator's internal state, for example through a software bug? NIST defines two properties that limit the damage ^[9][10].

Backtracking resistance means that learning today's state does not let the attacker work out outputs produced earlier. Think of a diary written in disappearing ink: reading today's page does not reveal yesterday's.

Prediction resistance means that learning an old state does not let the attacker work out future outputs. Generators achieve this by mixing in fresh entropy, a step called reseeding, so a stolen state goes stale.

For a password generator, the practical lesson is simple. The quality of the result depends on the generator's state staying secret and being refreshed from real entropy. That is a job for carefully reviewed system code, not for application code.

The operating system's generator

Operating systems provide a shared secure generator, so applications do not have to build their own. Two documented examples follow.

On Linux, the kernel's generator is available through the getrandom() system call and the /dev/urandom device. By default, getrandom() draws from the same source as /dev/urandom ^[2]. If the generator has not been initialised yet, for example very early during boot, getrandom() waits until it is ready unless the caller asks it not to ^[2]. The manual page advises that most programs should use /dev/urandom or getrandom() without special flags, rather than the legacy /dev/random interface ^[1].

On Windows, applications can call BCryptGenRandom. Microsoft's documentation states that the default provider implements an algorithm that complies with NIST SP 800-90, specifically CTR_DRBG ^[4]. CTR_DRBG is one of the DRBG designs from SP 800-90A, built on a block cipher.

Other platforms have their own interfaces; we do not describe them here.

The browser's generator and crypto.getRandomValues()

Web pages cannot call the operating system directly. Instead, browsers expose crypto.getRandomValues(), part of the Web Crypto API. A page passes in an array of integers and the browser fills it with cryptographically strong random values ^[3].

The W3C specification says implementations should use well-established cryptographic pseudo-random number generators seeded with high-quality entropy, for example from an operating-system source such as /dev/urandom ^[11]. Note the word "should": it is strong guidance, not a single mandated design. Browsers differ in their internals, and this guide does not claim that any particular browser reads directly from the operating system for every call. What every implementation promises to the page is the same: cryptographically secure random values ^[11].

The specification also limits one call to 65,536 bytes ^[11], and MDN notes that the method works in Web Workers, which lets a site generate large batches in the background ^[3].

This is the only random source our generators use. See how our password generator creates passwords locally in your browser.

From numbers to passwords: fairness

A secure source gives you unpredictable numbers. A password needs characters. The step in between must be fair, meaning every character is exactly as likely as every other.

The common shortcut of taking the remainder (number % 62 for a 62-character alphabet) is slightly unfair whenever the number's range is not an exact multiple of 62. The fix is rejection sampling: throw away the few values that would cause the unevenness and draw again. We explain this in detail, with a worked example and tested code, in CSPRNG vs Math.random().

What this means for a password generator

Putting the pieces together: physical noise seeds the operating system's generator; browsers are advised to seed their own secure generator from such a source; crypto.getRandomValues() hands strong random numbers to the page; and the generator maps them to characters fairly. If any link uses a weaker method, such as Math.random(), the chain is only as strong as that link.

The whole chain, from physical noise to a password, looks like this:

×

You do not need to understand DRBG internals to choose a good tool. Check that a generator uses the browser's secure source, maps numbers fairly, and runs on your device. You can try all of this with our password generator.