A pseudo-random number generator (PRNG) expands a secret, uniformly random seed into a fast sequence of values that behaves like random output. Reusing the same seed reproduces the same sequence, but observing outputs alone should not reveal the generator’s state, future values, or past values. section 8.2 section 8.9
A cryptographically secure PRNG is useful because it:
- Turns slow entropy collection into a large supply of random values. section 8.2 section 8.3
- Supports cryptographic uses such as generating keys, connection values, and other secrets. section 8.2 section 8.9
Use the operating system’s randomness interface
Prefer a language standard library or established cryptography library. On Linux or FreeBSD, getrandom can wait for adequate seeding; Windows provides BCryptGenRandom, while many Unix-like systems expose /dev/urandom. Avoid predictable seeds such as the current time and avoid casual userland PRNGs. section 8.3 section 8.4
Figure 8.1 A pseudorandom number generator (PRNG) generates a sequence of random numbers based on a seed. Using the same seed makes the PRNG produce the same sequence of random numbers. It should be impossible to recover the state using knowledge of the random outputs (the function next is one way). It follows that it should also be impossible from observing the produced random numbers alone to predict future random numbers or to recover previously generated random numbers.
Trace how one seed produces a sequence while the one-way state update prevents output-only prediction and state recovery. section 8.2
Figure 8.2 A PRNG has forward secrecy if compromise of a state does not allow recovering previously generated random numbers.
Compare forward secrecy with ordinary state compromise: earlier generated values remain unrecoverable. section 8.2
Figure 8.3 A PRNG has backward secrecy if compromise of a state does not allow predicting future random numbers generated by the PRNG. This is true only once new entropy is produced and injected in the update function after the compromise.
See why backward secrecy depends on injecting new entropy after compromise before trusting future output. section 8.2
