Random fork-safety - Revision history

Zmiller: refer to array name in example code

2021-03-12T18:56:32Z

refer to array name in example code

Matt at 07:52, 5 April 2018

2018-04-05T07:52:36Z

Rsalz at 20:09, 4 April 2018

2018-04-04T20:09:43Z

Jwalton: Reordered Python bug by date.

2014-03-16T20:41:37Z

Reordered Python bug by date.

Jwalton: Added link to Python bug report.

2014-03-16T20:40:33Z

Added link to Python bug report.

Ppelleti: another patch for fork-safety issue

2014-01-22T08:59:23Z

another patch for fork-safety issue

Ppelleti: another blog post about Android Zygote problem with OpenSSL PRNG

2014-01-22T08:36:52Z

another blog post about Android Zygote problem with OpenSSL PRNG

Ppelleti: added link to python bug about trouble fixing the rng with pthread_atfork

2013-11-17T06:10:25Z

added link to python bug about trouble fixing the rng with pthread_atfork

Jwalton: Added link to BL's patch (rather than mailing list message).

2013-10-26T11:42:34Z

Added link to BL's patch (rather than mailing list message).

Jwalton: further improve -> enhance

2013-10-26T11:24:38Z

further improve -> enhance

@@ Line 47: / Line 47: @@
 Some of the items above recommend reading from operating system provided facilities, such as <tt>/dev/random</tt> and <tt>/dev/urandom</tt>. Since the random number generator should be in good order before the fork, you should be able to add unique information to diversify the generator states between parent and child. Unique information would include the time the call was made and the process identifier. In fact, Ben Laurie [https://github.com/openssl/openssl/commit/3cd8547a2018ada88a4303067a2aa15eadc17f39 pushed a patch to use time] as the uniqueness (unfortunately, it will be years before it gains widespread adoption in the field).
-The code below can be used to add unique information to the generator after a fork. The call to <tt>time</tt> ensures the information is unique if the PIDs wrap. The call to <tt>getpid</tt> ensures that two forks that occur back-to-back on hardware with low resolution timers are unique. <tt>long[2]</tt> and <tt>long[3]</tt> attempts to further enhance the generator's state by using random data on the stack (if present).
+The code below can be used to add unique information to the generator after a fork. The call to <tt>time()</tt> ensures the information is unique if the PIDs wrap. The call to <tt>getpid()</tt> ensures that two forks that occur back-to-back on hardware with low resolution timers are unique.  Array elements <tt>seed[2]</tt> and <tt>seed[3]</tt> attempt to further enhance the generator's state by using whatever data is on the stack.
 <pre>long long seed[4];

@@ Line 1: / Line 1: @@
 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).
-'''The situation has changed greatly, starting with OpenSSL 1.1.0 which completely rewrote RNG.  The concerns below do not really apply any more.'''
+'''The situation has changed greatly, starting with OpenSSL 1.1.1 which completely rewrote RNG.  The concerns below do not really apply any more.'''
 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.

← Older revision		Revision as of 20:09, 4 April 2018
Line 1:		Line 1:
	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).		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).
		+
		+	'''The situation has changed greatly, starting with OpenSSL 1.1.0 which completely rewrote RNG. The concerns below do not really apply any more.'''

	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.		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.

@@ Line 11: / Line 11: @@
 * [http://marc.info/?l=openssl-dev&m=130289811108150&w=2 openssl-dev: recycled pids causes PRNG to repeat - Eric Wong - Apr 15, 2011]
 * [https://bugs.ruby-lang.org/issues/4579 Ruby bug 4579: SecureRandom + OpenSSL may repeat with fork - Apr 15, 2011]
 * [http://www.postgresql.org/message-id/E1UKzBn-0006c2-Cy@gemulon.postgresql.org pgsql: Reset OpenSSL randomness state in each postmaster childprocess - Tom Lane - Mar 27, 2013]
 * [https://plus.google.com/+AndroidDevelopers/posts/YxWzeNQMJS2 Google+ discussion of Android SecureRandom issue, caused by OpenSSL PID wraparound - Aug 14, 2013]
 * [http://jbp.io/2013/08/15/android-securerandom-guess/ Android SecureRandom vulnerability guess - Joseph Birr-Pixton - Aug 15, 2013]
 * [http://www.mail-archive.com/openssl-users@openssl.org/msg71749.html openssl-users: DLL hell - Nico Williams - Aug 15, 2013]

@@ Line 11: / Line 11: @@
 * [http://marc.info/?l=openssl-dev&m=130289811108150&w=2 openssl-dev: recycled pids causes PRNG to repeat - Eric Wong - Apr 15, 2011]
 * [https://bugs.ruby-lang.org/issues/4579 Ruby bug 4579: SecureRandom + OpenSSL may repeat with fork - Apr 15, 2011]
 * [http://www.postgresql.org/message-id/E1UKzBn-0006c2-Cy@gemulon.postgresql.org pgsql: Reset OpenSSL randomness state in each postmaster childprocess - Tom Lane - Mar 27, 2013]
 * [https://plus.google.com/+AndroidDevelopers/posts/YxWzeNQMJS2 Google+ discussion of Android SecureRandom issue, caused by OpenSSL PID wraparound - Aug 14, 2013]

@@ Line 20: / Line 20: @@
 ** [https://github.com/openssl/openssl/commit/3cd8547a2018ada88a4303067a2aa15eadc17f39 commit mentioned in above message]
 * [http://bugs.python.org/issue19227 Python issue 19227: test_multiprocessing_xxx hangs under Gentoo buildbots - Oct 11, 2013]
 == Remediations ==

@@ Line 39: / Line 39: @@
 The fifth 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 '''R<sub>A</sub>''' or '''R<sub>B</sub>''' in SSL/TLS). The benefit of hedging is its resilient against fork problems, low entropy environments, and virtual machine playbacks. For details, see [http://static.usenix.org/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf When Virtual is Harder than Real: Resource Allocation Challenges in Virtual Machine Based IT Environments] and [http://www.isoc.org/isoc/conferences/ndss/10/pdf/15.pdf When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography].
-Some of the items above recommend reading from operating system provided facilities, such as <tt>/dev/random</tt> and <tt>/dev/urandom</tt>. Since the random number generator should be in good order before the fork, you should be able to add unique information to diversify the generator states between parent and child. Unique information would include the time the call was made and the process identifier. In fact, Ben Laurie [http://www.mail-archive.com/openssl-dev@openssl.org/msg33012.html pushed a patch to use time] as the uniqueness (unfortunately, it will be years before it gains widespread adoption in the field).
+Some of the items above recommend reading from operating system provided facilities, such as <tt>/dev/random</tt> and <tt>/dev/urandom</tt>. Since the random number generator should be in good order before the fork, you should be able to add unique information to diversify the generator states between parent and child. Unique information would include the time the call was made and the process identifier. In fact, Ben Laurie [https://github.com/openssl/openssl/commit/3cd8547a2018ada88a4303067a2aa15eadc17f39 pushed a patch to use time] as the uniqueness (unfortunately, it will be years before it gains widespread adoption in the field).
 The code below can be used to add unique information to the generator after a fork. The call to <tt>time</tt> ensures the information is unique if the PIDs wrap. The call to <tt>getpid</tt> ensures that two forks that occur back-to-back on hardware with low resolution timers are unique. <tt>long[2]</tt> and <tt>long[3]</tt> attempts to further enhance the generator's state by using random data on the stack (if present).