CSPRNG designs are divided into two classes: • Designs based on cryptographic primitives such as
ciphers and
cryptographic hashes • Designs based on mathematical problems thought to be
hard Designs based on cryptographic primitives • A secure
block cipher can be converted into a CSPRNG by running it in
counter mode using, for example, a special construct that the
NIST in SP 800-90A calls
CTR DRBG. CTR_DBRG typically uses
Advanced Encryption Standard (AES). • AES-
CTR_DRBG is often used as a random number generator in systems that use AES encryption. • The NIST CTR_DRBG scheme erases the key
after the requested randomness is output by running additional cycles. This is wasteful from a performance perspective, but does not immediately cause issues with forward secrecy. However, realizing the performance implications, the NIST recommends an "extended AES-CTR-DRBG interface" for its
Post-Quantum Cryptography Project submissions. This interface allows multiple sets of randomness to be generated without intervening erasure, only erasing when the user explicitly signals the end of requests. As a result, the key could remain in memory for an extended time if the "extended interface" is misused. Newer "fast-key-erasure" RNGs erase the key with randomness as soon as randomness is requested. • A stream cipher can be converted into a CSPRNG. This has been done with RC4,
ISAAC, and
ChaCha20, to name a few. • A cryptographically secure
hash might also be a base of a good CSPRNG, using, for example, a construct that NIST calls
Hash DRBG. • An
HMAC primitive can be used as a base of a CSPRNG, for example, as part of the construct that NIST calls
HMAC DRBG.
Number-theoretic designs • The
Blum Blum Shub algorithm has a security proof based on the difficulty of the
quadratic residuosity problem. Since the only known way to solve that problem is to factor the modulus, it is generally regarded that the difficulty of
integer factorization provides a conditional security proof for the Blum Blum Shub algorithm. However the algorithm is very inefficient and therefore impractical unless extreme security is needed. • The
Blum–Micali algorithm has a security proof based on the difficulty of the
discrete logarithm problem but is also very inefficient. • Daniel Brown of
Certicom wrote a 2006 security proof for
Dual EC DRBG, based on the assumed hardness of the
Decisional Diffie–Hellman assumption, the
x-logarithm problem, and the
truncated point problem. The 2006 proof explicitly assumes a lower
outlen (amount of bits provided per iteration) than in the Dual_EC_DRBG standard, and that the
P and
Q in the Dual_EC_DRBG standard (which were revealed in 2013 to be probably backdoored by NSA) are replaced with non-backdoored values.
Practical schemes "Practical" CSPRNG schemes not only include an CSPRNG algorithm, but also a way to initialize ("
seed") it while keeping the seed secret. A number of such schemes have been defined, including: • Implementations of
/dev/random in Unix-like systems. •
Yarrow, which attempts to evaluate the entropic quality of its seeding inputs, and uses SHA-1 and 3DES internally. Yarrow was used in
macOS and other Apple OS' up until about December 2019, after which it switched to Fortuna. •
Fortuna, the successor to Yarrow, which does not attempt to evaluate the entropic quality of its inputs; it uses SHA-256 and "any good block cipher". Fortuna is used in FreeBSD. Apple changed to Fortuna for most or all Apple OSs beginning around Dec. 2019. • The Linux kernel CSPRNG, which uses ChaCha20 to generate data, and
BLAKE2s to ingest entropy. •
arc4random, a CSPRNG in Unix-like systems that seeds from . It originally is based on
RC4, but all main implementations now use
ChaCha20. •
CryptGenRandom, part of
Microsoft's
CryptoAPI, offered on Windows. Different versions of Windows use different implementations. •
ANSI X9.17 standard (
Financial Institution Key Management (wholesale)), which has been adopted as a
FIPS standard as well. It takes as input a
TDEA (
keying option 2) key bundle
k and (the initial value of) a 64-bit
random seed s. Each time a random number is required, it executes the following steps:{{olist Obviously, the technique is easily generalized to any block cipher;
AES has been suggested. If the key
k is leaked, the entire X9.17 stream can be predicted; this weakness is cited as a reason for creating Yarrow. All these above-mentioned schemes, save for X9.17, also mix the state of a CSPRNG with an additional source of entropy. They are therefore not "pure" pseudorandom number generators, in the sense that the output is not completely determined by their initial state. This addition aims to prevent attacks even if the initial state is compromised. ==Standards==