Entropy and generated bits
An entropy source produces nondeterministic input with measured uncertainty. A cryptographic random-bit generator uses entropy to initialize protected state and then generates bits that an attacker should not be able to predict. A deterministic generator is secure because its seed and state are unpredictable and its construction is suitable, not because every output operation samples physical noise.
Ordinary pseudo-random functions used for simulation, selection, or testing are not suitable for keys, tokens, nonces that require unpredictability, recovery codes, or session identifiers.
Use the platform primitive
Use the operating system or cryptographic library's secure random interface. Do not design an entropy collector, mix timestamps and process identifiers, or seed a general-purpose generator. Do not fall back to a weak source when the secure source fails.
Generate enough bits for the use and encode them without reducing the space through modulo bias, truncation, or a small alphabet. Estimate online and offline guessing opportunity, rate limits, lifetime, and number of values issued.
State, cloning, and failure
Protect generator state from read, overwrite, rollback, and reuse. Virtual-machine images, containers, embedded devices, and early boot can duplicate or under-seed state. Use platform guidance for fork, snapshot, restore, reseeding, and hardware entropy.
Treat generator failure as a security failure. Do not issue a key or credential from a predictable fallback. Monitor health at the platform or cryptographic module layer without logging generated values.
Failure and residual risk
Statistical tests cannot prove unpredictability. A value can look random and come from a known seed. A secure random token can leak through URLs, logs, referrers, browser history, telemetry, or storage. A long token cannot compensate for missing expiry, audience, single-use, or authorization.
Pomerium boundary
Pomerium generates and manages protocol values through its implementation and configured key material. Applications must use their own platform secure-random interface for application tokens, keys, recovery codes, nonces, and identifiers. Do not derive them from Pomerium request IDs, user claims, timestamps, or hashes of predictable data.
Evaluation checklist
- Does every security value use the platform cryptographic random interface?
- How many effective unpredictable bits remain after encoding and format constraints?
- Can fork, clone, snapshot, restore, or early boot duplicate generator state?
- Does any failure path fall back to a weak or deterministic source?
- Are issued values protected from logs, URLs, telemetry, storage, and accidental display?
- Are expiry, audience, single-use, and rate controls defined separately from randomness?
