Random fork-safety
One of the most important issues in the proper cryptographic use of random numbers is that random numbers must not be reused. Since the UNIX fork() system call duplicates the entire process state, a random number generator which does not take this issue into account will produce the same sequence of random numbers in both the parent and the child (or in multiple children), leading to cryptographic disaster (i. e. people being able to read your communications).
OpenSSL's default random number generator mixes in the PID, which provides a certain degree of fork safety. However, once the PIDs wrap, new children will start to produce the same random sequence as previous children which had the same PID. This is unlikely to happen in most common cases, but it is not impossible, which makes the issue even more insidious.
The most comprehensive explanation of this problem is probably this blog post:
However, since this issue has been "rediscovered" and discussed multiple times, here are some additional links (some are also linked from the above article)
- openssl-dev: recycled pids causes PRNG to repeat - Eric Wong - Apr 15, 2011
- Ruby bug 4579: SecureRandom + OpenSSL may repeat with fork - Apr 15, 2011
- pgsql: Reset OpenSSL randomness state in each postmaster childprocess - Tom Lane - Mar 27, 2013
- Google+ discussion of Android SecureRandom issue, caused by OpenSSL PID wraparound - Aug 14, 2013
- openssl-users: DLL hell - Nico Williams - Aug 15, 2013
- openssl-dev: Patch to increase rng entropy after forking - Ernst-Udo Wallenborn - Sept 18, 2013
- openssl-dev: Mixing time into the pool - Ben Laurie - Sept 21, 2013
Remediations
OpenSSL cannot fix the fork-safety problem because its not in a position to do so. However, there are remediations available and they are listed below.
- Don't use RAND_bytes
- Call RAND_seed after a fork
- Use a hardware based generator
- Practice hedging cryptography
The first remediation is to avoid using RAND_bytes. Instead, you can use whatever the operating system provides; read directly from /dev/random, /dev/urandom or /dev/srandom; or use CryptGenRandom on Windows systems. Avoiding RAND_bytes is not practical in practice because the library will use it internally.
The second remediation is to call RAND_seed or RAND_add after a fork. Entropy can be obtained from the operating system by reading from /dev/random, /dev/urandom or /dev/srandom; or using CryptGenRandom on Windows systems. This is appropriate for most programs, but might have problems in low entropy environments such as mobile devices and headless servers. Additionally, this could have problems in virtualized environments. For details, see Random_Numbers.
The third remediation is to use a hardware based generator. This is not always practical because hardware is not always present. Additionally, hardware is not usually auditable so some question its unabridged use in the post-Snowden era. For details, see Random_Numbers and OpenSSL engine(3) man page.
The fourth remediation is to practice hedging cryptography. Hedging uses entropy gathered from a peer during key exchange or key agreement to add to the program's internal entropy pool (for example, the random RA or RB in SSL/TLS). The benefit of hedging is its resilient against fork problems, low entropy entropy environments, and virtual machine playbacks. For details, see When Virtual is Harder than Real: Resource Allocation Challenges in Virtual Machine Based IT Environments and When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography.
