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 “this is 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
9. Common Misconceptions
10. A Decision Table for When You’re Stuck
11. Summary
12. References

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 “does it look 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 weapon
• 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

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 “this 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, “indistinguishable” is the design goal, not a problem.

7.2. Look at the Generator’s Design First

When distinguishing, checking the following is more substantive than the look of the output.

• 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?

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 “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 “does this sequence contain 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 looks plausible”.

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, “is it using a safe seed / entropy and a safe API?” matters more than “pseudo 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.

9. Common Misconceptions

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

No. All that says is “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 “are pseudo-random numbers 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 Strong Cryptography and Pseudo-Random Numbers Covers the importance of seeds, testing, and API usage cautions (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.

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.