Category: Cryptography Fundamentals
Random Number Generator (RNG)
Also known as: RNG, random number generation, random number generator
Simply put
A random number generator is a process or tool that produces a sequence of values, usually bits or numbers, that are intended to be unpredictable. Some generators draw on physical sources of randomness such as atmospheric noise, while others use algorithms to produce values that approximate randomness. The quality of the output depends on the method used and its suitability for the intended purpose.
Formal definition
An RNG is a process invoked to generate a random sequence of values, typically a sequence of bits, or an individual random value. RNGs are broadly categorized by their source of entropy: those relying on physical or environmental phenomena (for example, atmospheric noise) to produce values described as true random numbers, and algorithmic approaches that produce pseudorandom sequences. The evidence provided does not detail specific statistical or cryptographic validation criteria; practitioners should confirm the required properties and testing requirements of any RNG against the applicable published standard for their use case, as the label alone does not establish fitness for a given security purpose.
Why it matters
Random number generation underpins much of the cryptography used in payment security. Keys, initialization vectors, nonces, session identifiers, and the values used in tokenization and authentication protocols all depend on unpredictability. When the values a system generates can be predicted or reproduced by an attacker, the confidentiality and integrity protections that depend on them may be weakened or bypassed, even if the surrounding algorithms are sound. In other words, a strong cipher fed by a weak or predictable source of randomness can fail to deliver the security its design implies.
Who it's relevant to
Security engineers and cryptography implementers
Engineers who implement key generation, token generation, session handling, or protocol nonces depend on RNGs whose output is unpredictable enough for the intended security purpose. They should verify that a chosen generator meets the properties required by the applicable published standard for cryptographic use, rather than assuming suitability from the tool's name or its use of a physical entropy source.
Compliance officers and assessors
Where an RNG supports controls within scope of a PCI DSS assessment, such as those relating to cryptographic keys and key management, the governing requirements are set by the applicable version of the standard. Because requirement numbering and wording differ between versions, assessors should confirm the current published text rather than citing a fixed requirement number, and should look for evidence that the generator's properties were validated for the intended use.
Developers building tokenization or authentication features
Teams generating token values, one-time codes, or other identifiers should distinguish generators suitable for cryptographic use from general-purpose utilities intended for games or lotteries. The label alone does not establish fitness; developers should confirm the required properties and any testing requirements against the applicable published standard for their specific use case.
Inside RNG
Deterministic Random Bit Generator (DRBG)
An algorithmic RNG that produces output from a seed value using a defined deterministic function. It is intended to generate cryptographically suitable pseudo-random output provided the seed and internal state remain secret and unpredictable. Its output quality depends directly on the entropy of the seed.
Entropy Source
The underlying source of unpredictability that feeds an RNG, often derived from physical or hardware noise. Insufficient or predictable entropy at seeding time can undermine the entire generator, even when the algorithm itself is sound.
Seeding and Reseeding
The process of initializing and periodically refreshing the RNG internal state with entropy. Reseeding is intended to limit the impact of state compromise over time. The frequency and quality of reseeding affect the ongoing unpredictability of output.
Cryptographically Secure RNG (CSPRNG)
An RNG whose output is intended to be computationally infeasible to predict or reproduce, making it suitable for security-sensitive uses such as key generation, token generation, initialization vectors, and nonces. General-purpose RNGs intended for simulation or non-security uses do not meet this bar.
Role in Payment Security
RNGs help produce the unpredictable values that many cryptographic and tokenization controls depend on, including cryptographic keys, session identifiers, and surrogate token values in some designs. Their use in these contexts is intended to support confidentiality and integrity, not to be a standalone control.
Common questions
Answers to the questions practitioners most commonly ask about RNG.
Is a random number generator the same thing as a random number generator that is safe for cryptographic use?
No. Not every RNG is suitable for security purposes. General-purpose or statistical RNGs, sometimes called pseudorandom number generators, are designed to produce values that appear random for simulations or sampling, but their output can be predictable to an attacker who observes prior values or learns the seed. Security-sensitive functions such as generating encryption keys, initialization vectors, tokens, session identifiers, and nonces require a cryptographically secure RNG, whose output is intended to be computationally infeasible to predict even given knowledge of previously generated values. Using a non-cryptographic RNG where a cryptographic one is required can undermine the strength of the control it supports, regardless of how the RNG is labeled.
Does using a random number generator by itself make a token or key secure?
No. The RNG is one component, and its quality depends on the full implementation, not on the presence of randomness alone. A weak or improperly seeded generator, a predictable seed source, insufficient entropy, reuse of values that must be unique, or exposure of internal state can weaken or defeat the intended protection even when a value looks random. Randomness should be assessed alongside how values are seeded, generated, stored, and used. Whether a resulting token affects data protection or PCI DSS scope depends on the overall design and validation of the tokenization or cryptographic approach, not on the use of an RNG in isolation.
How do I choose an appropriate RNG for generating cryptographic keys and other security-sensitive values?
Select a cryptographically secure generator provided or vetted for security use rather than a general-purpose statistical function. Where applicable, favor platform-provided cryptographic facilities and established, well-reviewed libraries over custom implementations, and confirm they are configured for cryptographic rather than statistical output. When a term or control references specific requirements, confirm the exact wording and expectations against the current published standard, because requirement numbering and language differ between versions. Where formal validation of cryptographic functions is required in your environment, treat that validation as a separate consideration from simply choosing a library.
What entropy and seeding practices matter when deploying an RNG?
The strength of generated values depends heavily on the entropy available at seeding time and on how the generator is initialized. Ensure the seed is drawn from a suitable entropy source and that sufficient entropy is available before generating security-sensitive values, which can be a particular concern on freshly booted systems, virtualized environments, containers, and embedded or constrained devices that may have limited entropy early in their lifecycle. Avoid hard-coded, predictable, or reused seeds, and avoid manually reseeding a cryptographic generator with low-quality inputs in ways that could reduce its unpredictability.
How should generated random values be handled, stored, and rotated after they are created?
Treat the internal state of the generator and any long-lived secret values it produces as sensitive material that should be protected against exposure, because disclosure of state or seeds can allow prediction of past or future outputs. Values intended to be unique, such as certain nonces and initialization vectors, should not be reused where uniqueness is required by the cryptographic function they support. Key generation, storage, and lifecycle handling should follow the cryptographic and key-management practices defined for your environment, and you should confirm those expectations against the current published standard rather than assuming a fixed requirement reference.
How can I test or gain assurance that an RNG is behaving as intended?
Assurance generally combines using vetted cryptographic facilities, reviewing how the generator is configured and seeded, and, where appropriate, applying recognized statistical and health tests to detect gross failures such as stuck outputs or reduced entropy. Statistical tests can help identify some defects but do not by themselves prove that output is cryptographically unpredictable, so they should be treated as one input rather than a complete guarantee. Where formal validation of cryptographic modules or functions applies to your environment, rely on that validation and confirm the specific expectations against the current published standard.
Common misconceptions
Any RNG available in a programming language or operating system is safe for generating cryptographic keys or tokens.
General-purpose RNGs intended for non-security purposes may be predictable and are not appropriate for security-sensitive use. A cryptographically secure RNG (CSPRNG) with adequate entropy is intended for key generation, token generation, and similar functions. The label alone does not establish suitability; the implementation and its entropy source must be validated.
A strong RNG algorithm guarantees unpredictable output.
Even a sound algorithm can produce predictable output if it is seeded with insufficient or predictable entropy, if its internal state is exposed, or if it is not reseeded appropriately. Output quality depends on the entropy source and state management, not on the algorithm in isolation.
Tokenization systems that use an RNG make stored values inherently secure because the RNG is random.
An RNG can help produce unpredictable surrogate values in some tokenization designs, but the security and PCI DSS scope impact of tokenization depend on the overall implementation and validation, including how the token-to-PAN mapping is protected, not on the randomness of the generator alone.
Best practices
Use a cryptographically secure RNG (CSPRNG) for all security-sensitive purposes such as cryptographic key generation, token or session identifier generation, initialization vectors, and nonces; reserve non-security RNGs for non-security tasks only.
Confirm the RNG draws from an adequate entropy source and is properly seeded before use, since insufficient or predictable entropy can undermine an otherwise sound algorithm.
Implement appropriate reseeding to limit the impact of any internal state compromise over time, following the guidance of the specific cryptographic standard or framework you are validating against.
Protect the RNG internal state and seed material from exposure, treating them with the same care as other sensitive cryptographic material.
Do not treat RNG randomness as a standalone security control; verify how it fits into the broader cryptographic or tokenization design, including key and mapping protection, and confirm scope impact through implementation review rather than by label.
Validate RNG selection and configuration against the current published requirements of the applicable standard, since numbering and wording differ between versions, and confirm details against the authoritative source rather than assumptions.