Random number generators (rng): how randomness works behind the scenes

A random number generator (random number generator, RNG) is a system that outputs values intended to be unpredictable for a given use case. Behind the scenes, most RNGs are deterministic programs (PRNGs) seeded with entropy, while a true random number generator (TRNG) measures physical noise. "Random" is about unpredictability and bias control, not about looking pattern-free to humans.

Core Concepts at a Glance

• Most random number generator software is a PRNG: fast, repeatable, and only as good as its seed and design.
• A true random number generator relies on physical entropy; it needs health checks and can be slow or noisy.
• An RNG algorithm is judged by measurable properties (bias, period, state size, forward/backward secrecy), not by "looks random."
• Seeding quality often dominates outcomes: poor seeds create predictable streams even with strong algorithms.
• "RNG generator online" tools are fine for low-stakes sampling, but risky for secrets unless you trust their entropy and transport.
• Resource constraints change the best choice: lightweight PRNGs for simulation; cryptographic RNGs (CSPRNGs) for security.

Common Misconceptions About Randomness

Myth: Random means "no patterns." In real sequences, short runs and clusters are normal. Humans overexpect alternation and underexpect streaks, so genuinely random outputs often look "too clumpy."

Myth: A single test or a chart proves randomness. Passing a few checks (or "looking random" in a plot) doesn't guarantee unpredictability, especially against an attacker who can exploit weak seeding or a flawed RNG algorithm.

Myth: Any RNG generator online is interchangeable. Many online generators are just PRNGs behind an API, and you usually cannot verify their entropy source, reseeding policy, logging, or whether outputs are reused. For security tokens or lotteries, the trust boundary matters more than convenience.

Myth: Bigger numbers are "more random." Randomness quality isn't about magnitude; it's about distribution, independence (as required), and resistance to prediction given partial observations.

What 'Random' Really Means: Mathematical Foundations

• Distribution: outputs should match the intended probability model (uniform over a range, Gaussian, weighted categories, etc.). Uniformity is a requirement only when the target distribution is uniform.
• Independence (or controlled dependence): for many uses you want minimal correlation between successive outputs; in other cases (e.g., stratified sampling) you intentionally impose structure.
• Unpredictability: given past outputs, an observer should not be able to predict future outputs beyond what the distribution allows. This is the core requirement for cryptographic RNGs.
• State: most practical generators have internal state; security often depends on keeping that state secret and periodically refreshed.
• Bias and modulo mapping: converting RNG output to a range (e.g., 1..N) can introduce bias if done with naive modulo; rejection sampling avoids this.
• Repeatability: in simulation/debugging, repeatability is a feature-fixed seeds let you reproduce runs. In security, repeatability is a vulnerability.

Pseudo vs True RNGs: How They Differ in Practice

PRNGs generate numbers algorithmically; TRNGs measure physical processes. In practice you choose based on threat model, throughput, and platform constraints.

1. Simulations and games: PRNGs are typical; you value speed, long period, and reproducibility for debugging and fairness audits.
2. Security keys, tokens, nonces: use a CSPRNG (often fed by a TRNG or OS entropy pool). A generic random number generator is not enough unless it's explicitly cryptographic.
3. Lotteries and public drawings: TRNG or auditable mixed approaches (physical entropy + published procedure) reduce suspicion; operational controls matter as much as the generator.
4. Embedded/IoT with limited resources: a lightweight PRNG may be needed for non-security randomness; for secrets, you must solve entropy and seeding first (often the hardest part on small devices).
5. Data science sampling pipelines: PRNG with fixed seeds supports reproducible experiments; you also need correct mapping to distributions and avoidance of shared global RNG state across threads.

Entropy Sources and Seeding: Where Randomness Comes From

Entropy is the "unpredictable input" used to initialize or refresh a generator. A strong PRNG seeded poorly is still weak; a TRNG without monitoring can quietly degrade.

Common entropy sources (and what to watch)

• OS entropy pool: usually the best default on desktop/server platforms; it mixes many sources and applies conditioning.
• Hardware noise (TRNG instructions/devices): useful for seeding; still requires health tests and careful integration.
• Timing jitter: can help on constrained systems, but is easy to overestimate and can be influenced by attackers in some threat models.
• User input timing: occasionally used historically; unreliable and not suitable as the only source.
• Unique device secrets: helpful as a component (e.g., stored key material), but not "entropy generation" by itself.

Seeding strategies, including limited-resource alternatives

• Prefer system CSPRNG APIs: on most platforms, get random bytes from the OS rather than rolling your own RNG algorithm.
• Seed once, then reseed on schedule or events: for long-running services, periodic reseeding reduces risk if state leaks.
• On microcontrollers: combine multiple weak sources (jitter + ADC noise + clock drift) and run a conservative conditioner; treat claims of "full entropy" skeptically until tested.
• When no true entropy is available: separate "random-looking" needs (UI shuffling, load balancing) from "secret" needs (keys). For secrets, add a hardware TRNG module or provision randomness during manufacturing.
• Don't seed with low-variability values: timestamps, PID, boot counters alone are frequently guessable, especially remotely.

Evaluating RNG Quality: Statistical Tests and Metrics

• Bias: check whether outcomes are systematically favored. Bias can come from the generator or from incorrect range mapping (e.g., modulo bias).
• Correlation: measure dependence between consecutive values; many failures show up as autocorrelation or structured artifacts in higher dimensions.
• Period and state size (for PRNGs): short periods or small state can repeat or be brute-forced; "fast" can be a red flag if it sacrifices state.
• Backtracking/forward secrecy (for CSPRNGs): if an attacker learns internal state at time T, can they reconstruct past outputs or predict future ones without reseeding?
• Test misuse: passing a test suite does not prove security; it only increases confidence in certain statistical properties for the tested sample.

Practical Applications and Implementation Pitfalls

Most production issues come from integration mistakes, not from the core generator. This is especially common when developers mix "random for sampling" with "random for secrets."

Mini example: uniform integers without modulo bias

If you need an unbiased integer in [0, n), don't do rand() % n unless the RNG range is a multiple of n. Use rejection sampling over random bytes from a CSPRNG.

# Pseudocode (language-agnostic)
# returns uniform integer in [0, n)
function uniform_below(n):
  require n > 0
  k = ceil(log2(n))          # bits needed
  while true:
    x = get_random_bits(k)   # from OS CSPRNG, not a basic PRNG
    if x < n:
      return x

Common "works in dev, breaks in prod" problems

• Accidentally deterministic seeds: container images or embedded devices boot with similar timing, producing repeated sequences.
• Shared global RNG state: multi-threaded programs contend for one RNG instance, causing correlations or performance cliffs.
• Using non-crypto RNGs for secrets: a fast PRNG is not automatically safe for session IDs, OTPs, API keys, or password reset tokens.
• Trusting a remote generator: an RNG generator online adds transport/logging risk; even HTTPS doesn't remove server-side visibility.
• Underestimating constrained devices: without a real entropy plan, "random" on IoT often means "guessable."

Practical Questions and Short Answers

Is a random number generator the same as a CSPRNG?

No. "Random number generator" is a broad term; a CSPRNG is specifically designed to resist prediction even if an attacker observes many outputs.

Can I use an RNG generator online for API keys?

Avoid it unless you fully trust the provider and your transport path. For secrets, generate keys locally using the OS CSPRNG so outputs never leave your control.

What makes a true random number generator "true"?

It measures physical entropy (noise) rather than computing outputs deterministically from a seed. It still needs health tests and conditioning to avoid bias and failure.

How do I choose random number generator software for simulations?

Pick a well-studied PRNG with good statistical behavior and reproducibility controls (explicit seeding, stream separation per thread). Security properties are usually not required for pure simulation.

What is an RNG algorithm in practical terms?

It's the update rule and output function that transform internal state into a stream. Different RNG algorithms trade off speed, memory, period, and predictability.

Why is "rand() % n" considered risky?

It can produce modulo bias when the RNG's output range isn't evenly divisible by n. Rejection sampling is the standard fix.

What should I do on a low-end microcontroller with no hardware TRNG?

For non-secret randomness, use a lightweight PRNG and accept its limits. For secrets, add an entropy source (hardware module or provisioning) and feed a CSPRNG; don't rely on timestamps alone.