Do not prescribe “random” before diagnosing the job

Five properties. Very different failure modes.

Keys must resist guessing. Nonces often need non-repetition. Shuffles need fair mapping. Simulations need replay. Public draws need verifiable governance. Start with the requirement, then choose the source and algorithm.

Browse all entries ↓Take the guided lesson

Diagnostic card

Ask the right question first.

01
Secret & unpredictable
Can the attacker predict it?
02
Fresh or unique
Could it repeat where repetition is dangerous?
03
Uniform or fair
Does each outcome get the promised chance?
04
Reproducible randomness
Can we replay and debug the same run?
05
Public or distributed
Who can verify or influence the draw?

The common-use index

Browse by required property.

Some applications need more than one property. Each entry is placed under its dominant randomness requirement, then names the other controls that complete the system.

01

Secret & unpredictable

The value must remain hard for an adversary to guess, even when they know how it was made.

Symmetric encryption keys

One shared secret locks and unlocks data with algorithms such as AES.

Needs: A key sampled across the algorithm’s supported key space, without a smaller predictable seed hiding underneath.

Inspect the case

Private signing & key-agreement keys

Public-key systems begin with a private value that must be selected correctly and kept secret.

Needs: Generation that follows the scheme’s exact distribution and range rules, using a cryptographic random generator.

Inspect the case

Wallet seeds & recovery phrases

A compact root secret deterministically derives many cryptocurrency keys.

Needs: A standards-conforming seed from a trusted cryptographic generator, protected like the assets it controls.

Inspect the case

Ephemeral handshake secrets

Short-lived secret values help two parties establish a fresh session key.

Needs: An unpredictable value generated for the scheme, normally anew for each handshake.

Inspect the case

Signature nonces

Some signature schemes use a one-time secret number for each message.

Needs: A unique, secret, correctly distributed nonce—or a vetted deterministic derivation tied to the key and message.

Inspect the case

Session & bearer tokens

Possession of an unguessable token can grant access without re-entering a password.

Needs: Enough unpredictability for the number of issued tokens, exposure window, and online or offline guessing surface.

Inspect the case

Recovery & one-time codes

Short codes trade typing convenience against a smaller guessing space.

Needs: Uniform generation plus strict limits on attempts, lifetime, and reuse.

Inspect the case

Blinding values

Random masking prevents intermediate computations from exposing a secret through timing or power.

Needs: Fresh values sampled from the exact mathematical domain expected by the blinding construction.

Inspect the case

Secret sharing & masking shares

A secret can be split so that only a threshold of participants can reconstruct it.

Needs: Independent uniform coefficients or masks in the scheme’s finite field.

Inspect the case

Generated passwords & passphrases

Entropy comes from the selection process, not from how complicated the result looks.

Needs: Uniform independent choices from a known list or alphabet, sized for the attacker’s guessing budget.

Inspect the case

Differential-privacy noise

Carefully calibrated random noise limits what a published result reveals about one person.

Needs: The specified noise distribution, protected generation, and privacy accounting across repeated releases.

Inspect the case

02

Fresh or unique

The important property is usually non-repetition in a defined scope; secrecy may be irrelevant.

AEAD nonces

Authenticated-encryption modes often require a nonce that never repeats under one key.

Needs: Uniqueness under the same key according to the mode’s contract; some modes permit random nonces, others prefer counters.

Inspect the case

Initialization vectors

An IV makes repeated encryption of similar data behave differently, but each mode defines different rules.

Needs: The exact property required by the encryption mode: unpredictable, unique, or both.

Inspect the case

Password salts

A salt separates equal passwords and defeats one precomputed table from serving every account.

Needs: A distinct value per password record; it is stored openly beside the verifier.

Inspect the case

Protocol challenges

A verifier sends a fresh challenge so an old valid response cannot simply be replayed.

Needs: Unpredictability before issue and non-repetition during the protocol’s acceptance window.

Inspect the case

Random unique identifiers

A large random space makes accidental collisions unlikely without a central counter.

Needs: Enough space for the number of identifiers and an explicit policy for the rare collision.

Inspect the case

Backoff & contention jitter

Small random delays stop many devices from retrying in lockstep.

Needs: Enough independent variation to spread retries over the available window.

Inspect the case

03

Uniform or fair

Every allowed outcome—or every participant under the stated rules—should receive the intended chance.

Card shuffling

A fair shuffle should be able to reach every permutation with the intended probability.

Needs: Uniform selection plus an unbiased shuffle algorithm such as correctly implemented Fisher–Yates.

Inspect the case

Games, dice & loot tables

Random choices create uncertain play, but “fair” means matching the published distribution.

Needs: Correct weighted sampling, clear odds, and—when money or adversaries are involved—tamper resistance.

Inspect the case

Lotteries & public drawings

A high-stakes draw needs both unbiased selection and confidence that nobody controlled it.

Needs: A reviewed process covering source, mapping, custody, timing, observation, and independent verification.

Inspect the case

Randomized audits & sampling

A sample can make a large population inspectable when selection is genuinely representative.

Needs: A documented sampling frame, intended probabilities, and a draw that cannot be quietly steered.

Inspect the case

Clinical & experimental assignment

Random assignment helps separate treatment effects from pre-existing differences.

Needs: Allocation concealment, the intended balance or stratification, and reproducible audit records.

Inspect the case

04

Reproducible randomness

A recorded seed recreates a run exactly. Unpredictability is optional and sometimes undesirable.

Monte Carlo estimation

Many sampled scenarios approximate quantities that are difficult to calculate directly.

Needs: A generator with suitable statistical quality, a recorded seed, and enough independent-looking samples for the estimator.

Inspect the case

Scientific simulation

Pseudorandom sequences stand in for uncertain processes inside a model.

Needs: A generator whose period, dimensional behavior, and stream-splitting fit the simulation.

Inspect the case

Property-based & randomized testing

Generated inputs explore more cases than a small hand-written test list.

Needs: A seed printed with every failure so the exact case can be replayed and minimized.

Inspect the case

Fuzzing

A fuzzer mutates inputs to find crashes, hangs, and security bugs.

Needs: Efficient exploration, coverage feedback, and durable recording of any crashing input.

Inspect the case

Procedural generation

A compact seed can recreate a world, texture, level, or musical pattern.

Needs: Stable deterministic mapping from seed to result and a generator with acceptable visual variety.

Inspect the case

Randomized algorithms

Random choices can improve expected runtime, balance structures, or avoid pathological inputs.

Needs: A generator appropriate to whether inputs are benign or adversarial, plus unbiased bounded sampling.

Inspect the case

Machine-learning initialization

Seeds influence initial weights, data order, augmentation, and sampling.

Needs: Controlled independent streams and enough repeated runs to measure sensitivity to chance.

Inspect the case

05

Public or distributed

Many parties need a result that is timely, unbiased, verifiable, or difficult for one party to control.

Public randomness beacons

A beacon publishes timestamped random values that anyone can reference and verify.

Needs: Unpredictability before publication, availability, authentication, and an unambiguous round identifier.

Inspect the case

Distributed leader selection

A network chooses who proposes or coordinates the next step without one party deciding alone.

Needs: Unbiasable or bias-resistant shared randomness, verifiable eligibility, and resistance to grinding.

Inspect the case

Sortition & civic selection

Random selection can distribute civic duties or scarce opportunities without a chooser.

Needs: A fixed eligible population, declared selection probabilities, transparent mapping, and credible randomness.

Inspect the case

Threshold & commit–reveal randomness

Several contributors combine inputs so no single contributor chooses the final value.

Needs: Commitments that bind later reveals, enough honest participation, and rules for missing contributors.

Inspect the case