Pseudo-Random vs. True Random Numbers - How Do You Actually Tell Them Apart?

Conversations about random numbers go off the rails quickly, because very different things all get called by the single word random. A sequence computed by something like Math.random() and a sequence obtained from physical phenomena like thermal noise or clock jitter both look reasonably scattered if you only judge by appearance.

In practice, though, if you leave this distinction vague, you become prone to misjudgments like these:

• You want reproducible simulation runs, yet the results drift every time
• You generate password-reset tokens with easily predictable random numbers
• You pass a statistical test suite and conclude that this must be true randomness
• Or, conversely, you hear the word pseudo and assume it is all dangerous

This article lays out, in a form that is easy to act on in practice, what pseudo-random numbers are, what true random numbers are, and how to tell them apart. The emphasis is on judging by the construction of the generator, not by how the output looks.

The content is based on NIST, IETF, OS, and language-official documentation verifiable as of April 2026.

Table of Contents

1. The Conclusion First (in One Breath)
2. What This Article Means by “Pseudo-Random” and “True Random”
3. One-Page Overview
   • 3.1. Relationship Diagram
   • 3.2. The Shortest Possible Glossary
4. What Is a Pseudo-Random Number?
   • 4.1. In One Sentence
   • 4.2. Treat Ordinary PRNGs and CSPRNGs Separately
5. What Is a True Random Number?
   • 5.1. In One Sentence
   • 5.2. Even Physical Randomness Is Not Necessarily Used Raw
6. What Actually Differs
   • 6.1. Source of Generation
   • 6.2. Reproducibility
   • 6.3. Predictability
   • 6.4. Speed and Operations
7. How to Tell Them Apart
   • 7.1. Output Alone Cannot, in Principle, Settle It
   • 7.2. Look at the Generator’s Design First
   • 7.3. Then Use Statistical Tests to Hunt for Obvious Defects
   • 7.4. For Security Uses, Take the Attacker’s Point of View
8. Which to Use for Which Purpose
   • 8.1. Minimal Usage Examples
9. Common Misconceptions
10. A Decision Table for When You’re Stuck
11. Summary
12. References

Knowledge map for this article

This article sorts out the difference between pseudo-random numbers (PRNG), which produce a sequence deterministically from a seed and internal state, and true random numbers (NRBG), which take a physical phenomenon such as thermal noise as their entropy source, and shows that most of the secure random number APIs used in practice are a hybrid construction: a CSPRNG or DRBG seeded from a physical entropy source. The two cannot be told apart from the appearance of the output alone, and statistical testing (NIST SP 800-22) only detects defects rather than proving randomness, so the distinction should be made by checking how the generator is built, such as its generation algorithm and the origin of its seed. For security uses such as keys, tokens, nonces, and session IDs, seeding from a predictable value such as the current time can let an attacker guess a token and lead to account takeover, so the article recommends using the secure RNG APIs provided by the OS and the language standard library, such as BCryptGenRandom, RandomNumberGenerator in .NET, and secrets in Python.

flowchart LR
    accTitle: Pseudo-random versus true random numbers
    accDescr: Diagram showing the difference between pseudo-random numbers (PRNG) and true random numbers (NRBG), how the CSPRNG and DRBG used in practice are a hybrid construction combined with an entropy source, how statistical testing only detects defects rather than proving randomness, and how a predictable seed leads to a token prediction attack
    prng["PRNG (Pseudorandom Number Generator)"]
    true_random_number_generator["True Random Number Generator (TRNG/NRBG)"]
    csprng_drbg["Cryptographic PRNG (CSPRNG/DRBG)"]
    entropy_source["Entropy Source"]
    statistical_test_suite["Statistical Tests (NIST SP 800-22)"]
    predictable_seed["Predictable Seed (Time, PID)"]
    seed_prediction_attack["Seed Prediction Attack"]
    account_takeover["Account Takeover"]
    bcryptgenrandom["BCryptGenRandom"]
    dotnet_randomnumbergenerator[".NET RandomNumberGenerator"]
    linux_getrandom["getrandom() (Linux)"]
    python_secrets_module["Python secrets Module"]
    java_securerandom["Java SecureRandom"]
    security_token_generation["Generating Keys, Tokens, and Session IDs"]
    simulation_reproducibility["Reproducible Simulations and Tests"]
    session_id["Session ID"]
    csprng_drbg -->|"requires"| entropy_source
    true_random_number_generator -->|"requires"| entropy_source
    csprng_drbg -.->|"verified by"| statistical_test_suite
    true_random_number_generator -.->|"verified by"| statistical_test_suite
    predictable_seed -->|"may cause"| seed_prediction_attack
    seed_prediction_attack -.->|"may cause"| account_takeover
    csprng_drbg -->|"prevents"| seed_prediction_attack
    bcryptgenrandom -.->|"implements"| csprng_drbg
    dotnet_randomnumbergenerator -->|"uses"| csprng_drbg
    linux_getrandom -->|"uses"| csprng_drbg
    python_secrets_module -->|"uses"| csprng_drbg
    java_securerandom -->|"uses"| csprng_drbg
    csprng_drbg -->|"recommended for"| security_token_generation
    prng -->|"not recommended for"| security_token_generation
    prng -->|"recommended for"| simulation_reproducibility
    prng -->|"not recommended for"| session_id

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (16 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

1. The Conclusion First (in One Breath)

Stated crudely but in terms that are useful at work:

• Pseudo-random numbers are sequences produced deterministically from internal state and an algorithm
• True random numbers are sequences whose entropy source is a physical phenomenon such as thermal noise or jitter
• However, most of the secure random APIs used in practice do not return raw physical randomness — they return a DRBG / CSPRNG seeded from an entropy source
• So you cannot tell them apart by whether the output looks random. What you must look at is the generator’s construction, how the seed enters, reseeding, and health tests
• In simulations and reproducible testing, the reproducibility of pseudo-random numbers is a real asset
• For security uses such as keys, tokens, and nonces, the baseline is to use the secure random API provided by the OS or the language

In short, you rarely go wrong if you first separate these three:

1. Is this about an ordinary PRNG?
2. Is this about a cryptographic PRNG / CSPRNG / DRBG?
3. Is this about an NRBG / TRNG with a physical entropy source?

2. What This Article Means by “Pseudo-Random” and “True Random”

For this discussion, just saying random numbers is too broad. So let us fix the meanings first.

• Pseudo-random numbers (PRNG): sequences generated by a deterministic procedure from a seed and internal state. Under the same conditions, the same sequence comes out
• Cryptographically secure pseudo-random numbers (CSPRNG / DRBG): a kind of pseudo-random number, but one that prioritizes unpredictability. NIST SP 800-90A defines this deterministic random bit generator
• True random numbers: in everyday language this usually means genuine or physical randomness. In NIST terminology, the closest term is NRBG (non-deterministic random bit generator), described as a generator that always has access to an entropy source and, when operating correctly, produces full-entropy output

Because the naming differs from field to field, it is worth fixing the mapping between everyday words and standards terminology up front as well. From here on, this article uses the names in the leftmost column.

Two footnotes on that table:

• The terms NIST SP 800-90A / 90B / 90C actually use are DRBG, NRBG, and entropy source. CSPRNG and TRNG are not standards terminology; they are simply the names that practitioners and the literature have settled on
• Japanese writes the word pseudo with either of two spellings, 疑似 and 擬似. The Japanese original of this article standardizes on 疑似乱数, and only the titles of the cited documents keep their original spelling

The important point here is that pseudo-random and dangerous random are not synonyms.

For example, fast PRNGs like linear congruential generators or simple xorshift, and CSPRNGs like CTR_DRBG or HMAC_DRBG, are all deterministic — but their security implications are very different.

3. One-Page Overview

3.1. Relationship Diagram

The fastest way in is to see the concepts’ positions on a single page.

flowchart LR
    NOISE["Physical phenomena<br/>thermal noise, jitter, etc."] --> ENT["Entropy source"]
    ENT --> SEED["seed / reseed"]
    SEED --> DRBG["DRBG / CSPRNG<br/>expands random output at speed"]
    DRBG --> API["Random numbers returned by the OS / library"]

    STATE["Internal state + formula"] --> PRNG["Ordinary PRNG"]
    PRNG --> OUT["Sequence that looks random"]

What matters here is that the output of the secure random API your application receives is a little different from both the ordinary PRNG on the right and the raw physical noise on the left.

Most implementations seed / reseed from the entropy source on the left and then return values expanded at speed by a DRBG / CSPRNG. NIST SP 800-90B and 800-90C are precisely the documents that organize this entropy source + deterministic generator construction.

3.2. The Shortest Possible Glossary

If you want the shortest mnemonic:

• An ordinary PRNG is randomness you can reproduce
• A CSPRNG is randomness that can be reproduced, but is built to be hard to predict from the outside
• True randomness is randomness that extracts entropy from physical phenomena

4. What Is a Pseudo-Random Number?

4.1. In One Sentence

A pseudo-random number generator computes a random-looking sequence while updating internal state.

Feed it the same seed, run the same algorithm, draw the same number of values, and you get the same sequence. That looks like a flaw, but for simulation, testing, and debugging it is actually a major advantage.

Precisely because it is reproducible, you can operate in terms of this seed triggers the bug or I want to compare against yesterday's run again.

4.2. Treat Ordinary PRNGs and CSPRNGs Separately

This is the most commonly misunderstood point. Pseudo-random = fake = must not be used is wrong.

NIST SP 800-90A defines deterministic random bit generators built on hash functions and block ciphers. In other words, much of the core of the randomness used for cryptographic purposes is itself a deterministic generator.

The difference is not mere random-lookingness but unpredictability from the attacker’s point of view.

• Ordinary PRNG
  • Fast
  • Easy to reproduce
  • Easy to predict once the internal state or seed leaks
• CSPRNG / DRBG
  • Also deterministic
  • But designed so that, assuming the internal state is unknown, the output is hard to predict
  • For security uses, this is the one to use

So judging safety solely by is it pseudo-random? will almost always lead you astray. What you should look at is which pseudo-random generator?.

5. What Is a True Random Number?

5.1. In One Sentence

True random numbers extract entropy from physical indeterminacy: thermal noise, oscillator jitter, avalanche noise, quantum phenomena, and the like.

In everyday language they are called genuine or physical random numbers. In NIST terminology the closest concept is the NRBG: a generator that always has access to an entropy source and, as long as it is operating correctly, produces full-entropy output.

5.2. Even Physical Randomness Is Not Necessarily Used Raw

This is important too. Being true randomness does not mean the raw measurements are handed straight to the application.

Physical sources come with several practical difficulties:

• They have bias
• They are affected by temperature, power supply, failures, and aging
• The raw output rate may not be very high
• Without health checks, a broken source is easy to miss

For this reason, NIST SP 800-90B emphasizes entropy-source design principles, the concept of min-entropy, validation testing, and health testing. And as a whole implementation, they are usually used in the entropy source + DRBG construction described in NIST SP 800-90C.

In the end, true randomness is not some mystical raw substance — it is something you handle together with the physical source, its evaluation, monitoring, and post-processing.

6. What Actually Differs

The differences between random number kinds cannot be captured by does it look random alone. At minimum, these four axes make things clear.

6.1. Source of Generation

• Pseudo-random: an algorithm and internal state
• True random: a physical entropy source

This is the most fundamental difference.

6.2. Reproducibility

• Pseudo-random: reproducible given the same seed
• True random: re-sampling under the same conditions rarely yields the same sequence

Reproducibility is a strength in testing and can be a weakness in lotteries.

6.3. Predictability

• Ordinary PRNG: once the seed or internal state is readable, much of the future is known
• CSPRNG: designed to resist look-ahead, assuming the internal state is protected
• True random: hard to predict if the physical source is healthy — but sensor defects and design flaws are a separate problem

For security, this axis is the most important. What matters is not how scattered the output looks, but whether the next value can be guessed.

6.4. Speed and Operations

• Pseudo-random: fast, stable, easy to implement
• True random: requires entropy collection and monitoring, with constraints on speed and implementation cost

That is why, in production systems, the realistic choice is neither only true randomness nor only pseudo-randomness but a CSPRNG seeded with physical entropy.

7. How to Tell Them Apart

7.1. Output Alone Cannot, in Principle, Settle It

This is the single most important answer: you cannot look at a finite output sequence and declare that it is true randomness.

The reason is simple — a deterministic program that returns exactly the same finite sequence you just observed can always be constructed. In the extreme, just embed that sequence in an array or a ROM and return it in order.

So it looks natural, therefore it is genuine does not hold. NIST SP 800-22 likewise states that statistical testing is only a first step and by no means absolute proof of a generator’s validity.

Conversely, a good CSPRNG is built so that it is very hard to distinguish from true randomness by output alone. Here, being indistinguishable is the design goal, not a problem.

7.2. Look at the Generator’s Design First

The answer in 7.1 was that output alone will not get you there. So what do you look at instead? You look at the generator itself, not what it emits.

Two sequences can look equally uniform while one is computed from a seed and the other is drawn from a physical phenomenon. No amount of staring at the sequences brings that difference to the surface. It only shows up once you check how they are produced. Telling them apart is an act of verification, not observation.

There are five things to check.

• What is the generation algorithm
  • A simple PRNG, or a DRBG / CSPRNG?
• Where does the seed come from
  • A fixed seed, the clock, a PID?
  • Or the OS entropy source?
• Does it reseed
  • Seeded once at startup and never again?
  • Or re-fed during operation?
• Is the entropy source validated
  • Min-entropy assessment
  • Health tests
  • Failure detection
• Which API is being used
  • A home-grown implementation?
  • The OS / language standard API?

You do not have to work through all five. Go down the list and stop as soon as you have an answer. In practice, the first item — what the generation algorithm is — and the last one — which API is being used — decide it almost every time.

Viewed through this lens, a great many cases can be distinguished.

• Fixing the seed yields the same sequence every time → pseudo-random
• There is a physical entropy source, with validation / health testing assumed → a design with a true randomness source
• It calls the OS's secure RNG API → usually a hybrid of physical entropy + CSPRNG

7.3. Then Use Statistical Tests to Hunt for Obvious Defects

Statistical testing is not useless — it is in fact important. But its role is closer to defect detection than to proof.

Typical aspects examined include:

• Bias between 0s and 1s
• Bias in runs
• Periodicity
• Correlation
• Approximate entropy
• Linear complexity

NIST SP 800-22 — and in Japan, CRYPTREC’s minimum set of randomness tests — are frequently referenced. They are effective for checking whether a sequence contains strange bias or structure.

But passing them does not make something true randomness. A well-built CSPRNG passes them routinely, and conversely even a physical randomness source can fail them due to sensor bias or breakage.

The position of testing is roughly:

• Passes: no blatant defect is visible, for now
• Fails: something is quite likely wrong
• Therefore proven genuine: that, it cannot say

7.4. For Security Uses, Take the Attacker’s Point of View

For password-reset tokens, session IDs, nonces, and key generation, the question is it true randomness? is not enough.

What you really must examine is whether an attacker can predict the next value.

For example:

• Seeding from the current time alone
• Just mixing in a process ID or a sequence number
• A home-grown implementation with no assessment of seed quality
• Repurposing random-family APIs for security uses

None of these are prevented by the output looking plausible.

Here is one concrete picture of what goes wrong.

Suppose password-reset tokens are produced by a PRNG seeded with the current time. The attacker starts by requesting a reset on their own account and collecting one token that arrives. With the token and the time of the request in hand, the candidate seeds narrow to the few seconds around it. From there it is just a matter of running the same algorithm for each candidate and trying, one by one, the values that come out as the target user’s token.

Note that the attacker has not broken any cryptography here. They have simply reproduced the generator on their own machine. Whether that sequence passed a statistical test suite is equally irrelevant. Once the seed candidates can be enumerated, those values are not random as far as the attacker is concerned.

The same story applies to session IDs, invitation codes, one-time passwords, and temporary file names placed in a publicly reachable folder. Anything you cannot confidently call harmless even when guessed should be produced by the secure RNG.

Japan’s IPA likewise recommends knowing the security-related APIs and existing libraries, and avoiding casual home-grown implementations. Python explicitly tells you to prefer the secrets module over random. In Java, SecureRandom occupies that position.

In the end, for security, whether you are using a safe seed / entropy and a safe API matters more than whether the generator is pseudo-random or true.

8. Which to Use for Which Purpose

The safe choices at the implementation level are:

• Native Windows: BCryptGenRandom
• .NET: System.Security.Cryptography.RandomNumberGenerator
• Linux: getrandom()
• Python: secrets
• Java: SecureRandom

For Windows, Microsoft Learn documents that the default provider behind BCryptGenRandom complies with the NIST SP800-90 CTR_DRBG. Linux’s getrandom() is likewise documented as providing random bytes usable for cryptographic purposes. .NET’s RandomNumberGenerator, Python’s secrets, and Java’s SecureRandom are each APIs designed with cryptographic uses in mind.

8.1. Minimal Usage Examples

A list alone does not get your hands moving, so here is the actual shape of the two most representative cases. What they have in common is that you never prepare a seed yourself. Sourcing the seed is the API’s job.

In C# (.NET 8), use the static methods on System.Security.Cryptography.RandomNumberGenerator.

using System;
using System.Security.Cryptography;

// Draw an integer in the range 0 to 99 without bias
int n = RandomNumberGenerator.GetInt32(0, 100);

// Take 32 bytes for a token and turn them into a URL-safe string
byte[] bytes = RandomNumberGenerator.GetBytes(32);
string token = Convert.ToBase64String(bytes)
    .Replace('+', '-')
    .Replace('/', '_')
    .TrimEnd('=');

The reason to use GetInt32 is that simply taking a byte sequence modulo the range makes the values at one end of the range come up more often. When you need a bounded range, reach for this instead of computing the remainder yourself.

In Python (3.6 and later), the module is secrets.

import secrets

# A token that is safe to put in a URL
token = secrets.token_urlsafe(32)

# An integer in the range 0 to 99
n = secrets.randbelow(100)

For contrast, here is how you must not write the same thing.

import random

# Do not do this: random is a PRNG for reproducibility, not for security uses
token = "".join(random.choices("abcdefghijklmnopqrstuvwxyz0123456789", k=32))

Both random and secrets return strings that look equally scattered. The difference is not in the output but in where the randomness came from. random is a reproducibility-oriented PRNG built on the Mersenne Twister, and the official Python documentation states plainly that secrets is what you use for managing secrets.

9. Common Misconceptions

9.1. If it passes statistical tests, it is true randomness

No. All that says is that no blatant bias is visible.

9.2. If it is true randomness, it is always safe

No. Physical-source failures, bias, implementation flaws, and missing health tests all degrade quality.

9.3. Pseudo-random numbers are all dangerous

No. CSPRNGs / DRBGs are, on the contrary, the core of practical secure random APIs.

9.4. For security, you should use only raw physical randomness directly

Not necessarily. In practice, the combination of a physical entropy source + a CSPRNG is the norm.

9.5. random or Math.random() scatters well enough, so it can be used for tokens

Wrong use case. Visual scatter and unpredictability against an attacker are different things.

10. A Decision Table for When You’re Stuck

When in doubt, think in this order:

1. Do you want to reproduce the same results?
   • Yes → ordinary PRNG
   • No → next
2. Would prediction by an attacker be a problem?
   • Yes → the OS / language standard secure RNG
   • No → choose by quality requirements and speed
3. Do you need accountability or auditing of the randomness source itself?
   • Yes → consider a physical randomness source or a certified service
4. Do you want to implement it yourself?
   • The impulse is understandable, but randomness is easy to get wrong — use the standard API first

Run through this order and you will settle on a policy far faster than agonizing over the binary pseudo or true?.

11. Summary

Stating the difference between pseudo-random and true random numbers in the crudest but most practically useful way:

• Pseudo-random numbers are made by computation
• True random numbers take entropy from physical phenomena
• But the secure random APIs of real-world practice are dominated by the in-between: entropy source + CSPRNG

In other words, what to look at is not the appearance but the construction.

• You cannot conclude from output alone whether something is genuine
• Statistical tests help detect defects, but they are not proof
• In security, can it be predicted? is the heart of the matter
• If you need reproducibility, use a PRNG; if you need unpredictability, use the OS / language standard secure RNG

Frame it this way, and you escape the crude opposition of asking whether pseudo-random numbers are fake.

12. References

1. NIST SP 800-90A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators The foundational document on deterministic random bit generators.

2. NIST SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation Organizes the thinking on entropy sources, validation, and health testing.

3. NIST SP 800-90C: Recommendation for Random Bit Generator (RBG) Constructions Organizes the entropy source + DRBG construction.

4. NIST SP 800-22 Rev. 1a: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications Explains the position of statistical testing. The key point is that testing is a first step, not proof.

5. NIST Glossary: Non-deterministic Random Bit Generator (NRBG) Useful for checking the NIST term closest to true random.

6. RFC 4086: Randomness Requirements for Security Organizes the cautions around randomness and entropy sources for security uses.

7. Microsoft Learn: BCryptGenRandom function Describes Windows’s secure RNG API and the default provider’s CTR_DRBG.

8. Linux man page: getrandom(2) The Linux randomness API usable for cryptographic purposes.

9. Microsoft Learn: RandomNumberGenerator Class .NET’s cryptographically strong RNG API.

10. Python documentation: secrets — Generate secure random numbers for managing secrets The basics of handling security-grade randomness in Python.

11. Oracle Java Documentation: SecureRandom Summarizes Java’s secure RNG and its approach to seeds / entropy.

12. IPA: Chapter 3, Section 3 — Using Cryptography That Resists Attack, and Pseudo-Random Numbers Covers the importance of seeds, testing, and cautions on API usage (in Japanese).

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What is the difference between pseudo-random numbers and true random numbers?

A pseudo-random number generator (PRNG) produces a sequence deterministically, by algorithm, from a seed and internal state, so the same conditions yield the same sequence. True randomness is a sequence whose entropy source is a physical phenomenon such as thermal noise or oscillator jitter, and re-sampling under the same conditions rarely reproduces the same values. That said, most of the secure random APIs used in practice do not return physical randomness directly: they are hybrid constructions that return a CSPRNG / DRBG seeded from a physical entropy source.

Can you tell a pseudo-random sequence from a true random one just by looking at the output?

You cannot declare a finite output sequence to be true randomness, because a deterministic program that returns exactly the observed sequence can always be constructed. When distinguishing them, the generator's construction is far more substantive than the look of the output: what the generation algorithm is, where the seed comes from, whether it reseeds, whether the entropy source is validated (min-entropy assessment and health tests), and which API is being used.

If it passes statistical tests, is it true randomness?

No. The role of statistical testing is closer to defect detection than to proof. NIST SP 800-22 itself states that statistical testing is only a first step and by no means absolute proof of a generator's validity. A well-built CSPRNG passes these tests routinely, while even a physical randomness source can fail them due to sensor bias or breakage. Passing means blatant defects are hard to see; failing means something is quite likely wrong.

Which random number API should I use for security?

For keys, tokens, nonces, and session IDs, the baseline is the secure random API provided by your OS or language: BCryptGenRandom on native Windows, System.Security.Cryptography.RandomNumberGenerator in .NET, getrandom() on Linux, the secrets module in Python, and SecureRandom in Java. Avoid home-grown implementations seeded from the current time or a process ID, and do not repurpose random-family APIs for security uses.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.