Every programming language has a random() function. Python has random.randint(), JavaScript has Math.random(), Rust has rand::thread_rng(). Most of us use these functions without ever stopping to think: are these numbers truly random?

The answer is no. And most of the time, that is fine. But sometimes, it is critical.

Pseudo-Random: A Mathematical Illusion

random() functions do not truly generate random numbers. What they produce is a sequence of numbers calculated by a mathematical formula. The starting point of this sequence is called the "seed." Give it the same seed, and you get the same sequence. Every time.

You can test this yourself in Python:

import random
random.seed(42)
print(random.randint(1, 100))  # 82
random.seed(42)
print(random.randint(1, 100))  # 82

Same seed, same result. This is what "pseudo-random" means. The numbers look random but are actually completely deterministic. Anyone who knows the seed can predict every "random" number you will ever produce.

For most applications, this does not matter. Games, simulations, A/B testing, shuffling a playlist. Nobody worries whether Python's random() is "truly random" when building a card game.

But in cryptography? When generating bank passwords? When creating blockchain private keys? When issuing API tokens? There, knowing the seed means knowing everything.

True Random: Randomness From Physics

Real randomness comes not from mathematics but from physics. When you roll a die, the result is technically deterministic, but so many variables are involved (die shape, throw force, air resistance, table surface, spin rate) that predicting the outcome is practically impossible. This is "true random."

Computers have several ways to produce true randomness. All of them come from physical processes.

RDRAND: The TRNG Inside Your CPU

Modern Intel and AMD processors have a command called RDRAND. This command reads from a hardware true random number generator (TRNG) embedded inside the processor. The principle: thermal noise on silicon. At the atomic level, electron movement is completely random. This randomness is measured by a circuit inside the CPU and converted into bits.

In Rust, calling it is this simple:

use std::arch::x86_64::_rdrand64_step;

let mut val: u64 = 0;
unsafe { _rdrand64_step(&mut val); }
// val is a true random 64-bit number

This is not a mathematical formula. It is a measurement. The result of a physical process inside the processor. There is no seed. It is not deterministic. Call the same command twice and you get two different numbers with no mathematical relationship between them.

/dev/hwrng: Kernel-Level Entropy

The Linux kernel collects entropy from multiple hardware sources: RDRAND, disk I/O timing, network packet arrival order, hardware interrupts. It mixes these sources and exposes them through /dev/hwrng. Because it operates at the kernel level, there is no single point of failure.

CPU Temperature: Thermal Noise

Processor temperature is not constant. It fluctuates on microsecond timescales. The lowest bits (least significant bits) of a temperature reading contain thermal noise. Alone, this is a slow entropy source, but when combined with other sources, it adds valuable randomness.

Timing: Nanosecond Variations

When measuring how long an operation takes, nanosecond-level differences are random. Operating system scheduling, cache hits and misses, RAM access times, all create tiny variations. These variations can be harvested as entropy.

Mixing: SHA-256 For Security

A single entropy source might be reliable, but from a security perspective, mixing multiple sources is always better. Why? Because if one source weakens or is compromised, the others maintain the overall randomness.

Our API uses four sources: RDRAND, /dev/hwrng, CPU temperature, and timing. All data from these four sources is mixed through SHA-256. SHA-256 is a one-way hash function: you cannot predict the output without knowing every input bit. And the output is influenced by every single bit of the input. So even if one source is weak, the entropy from the other sources keeps the output secure.

This approach is approved by NIST (National Institute of Standards and Technology).

Where Should True Random Be Used?

Cryptography is the most critical use case. But not the only one:

Password generation: A password must be random to be strong. "password123" is not random. A 16-character password using the full character set provides 103 bits of entropy. That is 2^103 possible combinations. Even if every computer on Earth worked together, it would take billions of years to crack. But if that password was generated with pseudo-random and the seed is known, it can be cracked in one second.

UUID generation: To produce unique IDs in a system, RFC 4122 v4 UUIDs are generated from random bytes. If the randomness is pseudo, IDs can collide. With true random, collision probability is practically zero.

API tokens and session IDs: When generating tokens for user sessions in web applications. A pseudo-random token is predictable. A true random token is not.

Blockchain private keys: Bitcoin, Ethereum, Solana wallet private keys are random numbers. If this number is generated with pseudo-random and the seed is known, your wallet can be emptied. This actually happened: in 2015, an Android SecureRandom bug caused some Bitcoin wallets to be stolen because the private keys were predictable.

Gaming and lottery: Online gambling sites must use true randomness for card shuffling and roulette outcomes. If pseudo-random is used, an attacker could predict the cards. Real gambling sites use hardware TRNGs.

Monte Carlo simulations: In scientific research, random sampling is used for calculations. Pseudo-random can introduce bias. True random produces more accurate statistical results.

entropy_bits: Measuring Password Strength

The metric that measures password strength is "entropy bits." Each additional bit doubles the number of possible combinations.

• 20 bits = 1 million combinations. Cracked instantly.
• 40 bits = 1 trillion combinations. Cracked in hours.
• 60 bits = 1 billion trillion combinations. Takes days.
• 80 bits = Strong but crackable with a large cluster.
• 103 bits = Bank-grade. Practically uncrackable.
• 128 bits = AES-128 standard. Cryptographic grade.
• 256 bits = Government grade. Practically uncrackable, even with quantum computers. Grover's algorithm reduces this to 128 bits, which is still uncrackable.

Our API produces 103 bits of entropy for a 16-character password. Because it uses the full character set (88 different characters) and generates with true random. The same length password with pseudo-random and a known seed gives 0 bits of entropy.

True RNG API

The reason I wrote this article is that we have published a true random number generator API. The API uses four entropy sources (RDRAND, /dev/hwrng, CPU temperature, timing) mixed through SHA-256 to produce true random numbers.

Endpoints:

• /random/int - True random integer
• /random/bytes - True random bytes
• /random/uuid - RFC 4122 v4 UUID
• /random/password - Cryptographic password
• /entropy/status - Entropy pool status and sources

The API is available on RapidAPI. Free plan: 100 requests per month. Try it at: https://trng.niyazi.cv

Pseudo-random is enough most of the time. But for cryptography, true randomness is essential. No mathematical formula can replace randomness that comes from physics.