Random Numbers - Revision history

Jflopezfernandez: Corrected the second hyperlink I added

2019-07-27T02:33:12Z

Corrected the second hyperlink I added

Jflopezfernandez: Added two sources to the introduction for further reading

2019-07-27T02:31:56Z

Added two sources to the introduction for further reading

Jwalton: /* Seeds */

2017-07-30T18:00:30Z

Seeds

Jwalton: Added link to Intel blog for RDRAND engine

2017-01-02T23:05:33Z

Added link to Intel blog for RDRAND engine

Jwalton: RAND_save_file -> RAND_write_file

2016-07-11T22:38:53Z

RAND_save_file -> RAND_write_file

Jwalton: Added info on MD5.

2014-07-18T09:37:54Z

Added info on MD5.

Jwalton: Improved flow.

2014-05-13T18:48:19Z

Improved flow.

Jwalton: Added more info on initialization.

2014-05-13T18:47:51Z

Added more info on initialization.

Jwalton: Closed tag.

2014-05-13T13:47:53Z

Closed tag.

Jwalton: Added note on default genetors.

2014-05-13T13:47:28Z

Added note on default genetors.

@@ Line 3: / Line 3: @@
 OpenSSL provides a number of software based random number generators based on a variety of sources.  A software based random number generator creates random numbers by executing a software algorithm. There are a number of algorithms specified by a number of standard bodies including NIST, ANSI X9 committee (X9.17 and X9.31) and XXX. In addition, the library can use custom hardware if the hardware has an <tt>ENIGNE</tt> interface.
-Good random numbers are notoriously hard to produce from deterministic processes such as a computer executing instructions. A number of cryptographic attacks have been developed because they are so hard to acquire<sup>[https://wiki.openssl.org/index.php?title=Random_Numbers#References]</sup>. Especially vulnerable are headless servers, embedded devices, and mobile devices, and you may have to take extra steps to ensure an adequate supply of entropy is available<sup>[https://wiki.openssl.org/index.php?title=?Random_Numbers#References]</sup>. The extra steps could include ''Hedging'' on a headless server or embedded device, and ''Finger Painting'' on a mobile device. For recent attacks on low entropy devices (such as headless servers and mobile devices), see for example, ''[http://pages.cs.wisc.edu/~rist/papers/sslhedge.html When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography ]'', ''[https://factorable.net/paper.html Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices]'', and ''[http://www.csoonline.com/article/723229/traffic-sensor-flaw-that-could-allow-driver-tracking-fixed Traffic sensor flaw that could allow driver tracking fixed]''.
+Good random numbers are notoriously hard to produce from deterministic processes such as a computer executing instructions. A number of cryptographic attacks have been developed because they are so hard to acquire<sup>[https://wiki.openssl.org/index.php?title=Random_Numbers#References]</sup>. Especially vulnerable are headless servers, embedded devices, and mobile devices, and you may have to take extra steps to ensure an adequate supply of entropy is available<sup>[https://wiki.openssl.org/index.php?title=Random_Numbers#References]</sup>. The extra steps could include ''Hedging'' on a headless server or embedded device, and ''Finger Painting'' on a mobile device. For recent attacks on low entropy devices (such as headless servers and mobile devices), see for example, ''[http://pages.cs.wisc.edu/~rist/papers/sslhedge.html When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography ]'', ''[https://factorable.net/paper.html Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices]'', and ''[http://www.csoonline.com/article/723229/traffic-sensor-flaw-that-could-allow-driver-tracking-fixed Traffic sensor flaw that could allow driver tracking fixed]''.
 == Entropy ==

@@ Line 3: / Line 3: @@
 OpenSSL provides a number of software based random number generators based on a variety of sources.  A software based random number generator creates random numbers by executing a software algorithm. There are a number of algorithms specified by a number of standard bodies including NIST, ANSI X9 committee (X9.17 and X9.31) and XXX. In addition, the library can use custom hardware if the hardware has an <tt>ENIGNE</tt> interface.
-Good random numbers are notoriously hard to produce from deterministic processes such as a computer executing instructions. A number of cryptographic attacks have been developed because they are so hard to acquire. Especially vulnerable are headless servers, embedded devices, and mobile devices, and you may have to take extra steps to ensure an adequate supply of entropy is available. The extra steps could include ''Hedging'' on a headless server or embedded device, and ''Finger Painting'' on a mobile device. For recent attacks on low entropy devices (such as headless servers and mobile devices), see for example, ''[http://pages.cs.wisc.edu/~rist/papers/sslhedge.html When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography ]'', ''[https://factorable.net/paper.html Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices]'', and ''[http://www.csoonline.com/article/723229/traffic-sensor-flaw-that-could-allow-driver-tracking-fixed Traffic sensor flaw that could allow driver tracking fixed]''.
+Good random numbers are notoriously hard to produce from deterministic processes such as a computer executing instructions. A number of cryptographic attacks have been developed because they are so hard to acquire<sup>[https://wiki.openssl.org/index.php?title=Random_Numbers#References]</sup>. Especially vulnerable are headless servers, embedded devices, and mobile devices, and you may have to take extra steps to ensure an adequate supply of entropy is available<sup>[https://wiki.openssl.org/index.php?title=?Random_Numbers#References]</sup>. The extra steps could include ''Hedging'' on a headless server or embedded device, and ''Finger Painting'' on a mobile device. For recent attacks on low entropy devices (such as headless servers and mobile devices), see for example, ''[http://pages.cs.wisc.edu/~rist/papers/sslhedge.html When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography ]'', ''[https://factorable.net/paper.html Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices]'', and ''[http://www.csoonline.com/article/723229/traffic-sensor-flaw-that-could-allow-driver-tracking-fixed Traffic sensor flaw that could allow driver tracking fixed]''.
 == Entropy ==
@@ Line 314: / Line 314: @@
 * [[Libcrypto API]]
 * [http://jbp.io/2014/01/16/openssl-rand-api/ Analysis of the OpenSSL random API]
 [[Category:Cryptography]]
 [[Category:Crypto API]]

@@ Line 59: / Line 59: @@
 Most random number generators require a seed. A seed is a secret, unpredictable sequence of bytes that is transformed and then used to set the initial state of the generator. The seed ensures that each unique instance of a generator produces a unique stream of bits. No two generators should ever produce the same sequence of random numbers, even when faced with Virtual Machine (VM) rollback attacks (which could happen accidentally by a data center operator).
-When seeding your generators, you should use at least 256 bits (32 bytes) of material. You can verify the required number of bits by grepping the source files for <tt>#define ENTROPY_NEEDED</tt>.
+You should always seed a generator unless the docs state they don't require a seed. Even if the docs state a seed is not needed, you should seed it anyway. When seeding your generators, you should use at least 256 bits (32 bytes) of material. You can verify the required number of bits by grepping the source files for <tt>#define ENTROPY_NEEDED</tt>.
 === Initialization ===

@@ Line 176: / Line 176: @@
 To integrate a hardware based random number generator, you should load the apporpriate <tt>ENGINE</tt> for the hardware based implementation. Once loaded, set the engine's <tt>RAND_method</tt> method as default with <tt>ENGINE_METHOD_RAND</tt>. After you load the engine and set <tt>RAND_method</tt> for the hardware generator, you simply use <tt>[[Manual:RAND_bytes(3)|RAND_bytes]]</tt> as discussed earlier. There are no special steps necessary after the configuration.
-If you have OpenSSL 1.0.1 and a machine with [http://semiaccurate.com/2012/04/23/intel-launches-ivy-bridge-amid-crushing-marketing-buzzwords/ 3rd generation Core i5 or i7 processor (Ivy Bridge)], then the Intel [http://software.intel.com/en-us/blogs/2012/05/14/what-is-intelr-secure-key-technology Secure Key Technology] (formerly called Bull Mountain) [[Commercial Product Disclaimer|<nowiki>[disclaimer]</nowiki>]] is available to you. The hardware generator is accessed through the <tt>ENGINE</tt> API and wraps the <tt>rdrand</tt> instruction. According to Intel, [http://software.intel.com/en-us/articles/performance-impact-of-intel-secure-key-on-openssl RDRAND-enabled version of OpenSSL outperformed the non-RDRAND version by an order of magnitude].
+If you have OpenSSL 1.0.1 and a machine with [http://semiaccurate.com/2012/04/23/intel-launches-ivy-bridge-amid-crushing-marketing-buzzwords/ 3rd generation Core i5 or i7 processor (Ivy Bridge)], then the Intel [http://software.intel.com/en-us/blogs/2012/05/14/what-is-intelr-secure-key-technology Secure Key Technology] (formerly called Bull Mountain) [[Commercial Product Disclaimer|<nowiki>[disclaimer]</nowiki>]] is available to you. The hardware generator is accessed through the <tt>ENGINE</tt> API and wraps the <tt>rdrand</tt> instruction. Also see [http://software.intel.com/en-us/blogs/2014/10/03/changes-to-rdrand-integration-in-openssl Changes to RDRAND integration in OpenSSL] on the Intel blog.
 To ensure <tt>[[Manual:RAND_bytes(3)|RAND_bytes]]</tt> uses the hardware engine, you must perform three steps:

@@ Line 110: / Line 110: @@
 === Persisting ===
-If you are worried about slow starts - or the time it takes to get the random number generator in good working order - you can write out a future seed and use it upon the next program execution. To save the future seed, use the library's <tt>RAND_save_file</tt> function. When using <tt>RAND_save_file</tt>, you only need to specify a filename. <tt>RAND_save_file</tt> returns the number of bytes written or -1 to indicate bytes were written without an appropriate seed (failure).
+If you are worried about slow starts - or the time it takes to get the random number generator in good working order - you can write out a future seed and use it at next program execution. To save the future seed, use the library's <tt>RAND_write_file</tt> function. When using <tt>RAND_write_file</tt>, you only need to specify a filename. <tt>RAND_write_file</tt> returns the number of bytes written or -1 to indicate bytes were written without an appropriate seed (failure).
-<pre>int written = RAND_save_file("prng.seed");
+<pre>int written = RAND_write_file("prng.seed");
 if(written <= 0)
-     /* RAND_save_file failed */
+     /* RAND_write_file failed */
 /* OK to proceed */</pre>
@@ Line 127: / Line 127: @@
 If possible, you should use protected storage offered by the operating system. For example, you should avoid writing the file and store the seed in the [http://developer.apple.com/library/ios/#documentation/security/Conceptual/keychainServConcepts/iPhoneTasks/iPhoneTasks.html iOS Keychain], [http://developer.android.com/reference/android/security/KeyChain.html Android KeyChain], or [http://msdn.microsoft.com/en-us/library/ms995355.aspx Windows DPAPI]. When writing the seed to the filesystem, be sure to protect the the seed through the file system's permission scheme (Linux has not realized userland needs help from the kernel when storing secrets).
 == Generation ==

@@ Line 36: / Line 36: @@
 == Generators ==
-By default, OpenSSL uses the <tt>md_rand</tt> generator. The source code is located in <tt>crypto/rand/md_rand.c</tt>.
+By default, OpenSSL uses the <tt>md_rand</tt> generator. <tt>md_rand</tt> uses the MD5 hash as the pseudorandom function. The source code is located in <tt>crypto/rand/md_rand.c</tt>.
 You can test for the generator with:

← Older revision		Revision as of 18:48, 13 May 2014
Line 131:		Line 131:

	After the generator has been seeded and is in good working order, you can extract bytes. You have three functions to extract bytes. First is <tt>[[Manual:RAND_bytes(3)\|RAND_bytes]]</tt> and the second is <tt>[[Manual:RAND_bytes(3)\|RAND_pseudo_bytes]]</tt>. Both are software based and produce a pseudo-random stream. The third method is hardware based and it reuses <tt>[[Manual:RAND_bytes(3)\|RAND_bytes]]</tt>.		After the generator has been seeded and is in good working order, you can extract bytes. You have three functions to extract bytes. First is <tt>[[Manual:RAND_bytes(3)\|RAND_bytes]]</tt> and the second is <tt>[[Manual:RAND_bytes(3)\|RAND_pseudo_bytes]]</tt>. Both are software based and produce a pseudo-random stream. The third method is hardware based and it reuses <tt>[[Manual:RAND_bytes(3)\|RAND_bytes]]</tt>.
		+
		+	If the random number generator is not properly seeded, then it will refuse to deliver random bytes and a "PRNG not seeded error" will occur.

	=== Software ===		=== Software ===

@@ Line 63: / Line 63: @@
 === Initialization ===
-OpenSSL will attempt to seed the random number generator automatically upon instantiation by calling <tt>RAND_poll</tt>.  <tt>RAND_poll</tt> seeds the random number generator using a system-specific entropy source, which is <tt>/dev/urandom</tt> on UNIX-like operating systems, and is a combination of [http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx <tt>CryptGenRandom</tt>] and other sources of entropy on Windows.
+OpenSSL will attempt to seed the random number generator automatically upon instantiation by calling <tt>RAND_poll</tt>. If the generator is not initialized and <tt>RAND_bytes</tt> is called, then the generator will also call <tt>RAND_poll</tt> (from <tt>ssleay_rand_bytes</tt> in <tt>crypto/rand/md_rand.c</tt>):
 Be careful when deferring to <tt>RAND_poll</tt> on some Unix systems because it does not seed the generator. See the code guarded with <tt>OPENSSL_SYS_VXWORKS</tt> in <tt>rand_unix.c</tt>. Additionally, <tt>RAND_poll</tt> can have negative interactions on newer Windows platforms, so your program could hang or crash depending on the potential issue. See [[#Windows_Issues|Windows Issues]] below.
 The <tt>urandom</tt> device may lack sufficient entropy for your needs, and you might want to reseed it immediately from <tt>/dev/random</tt>. On Unix and other operating systems that provide the block device, you can use <tt>[[Manual:RAND_load_file(3)|RAND_load_file]]</tt> to load directly from <tt>/dev/random</tt>.

@@ Line 53: / Line 53: @@
      rc = RAND_set_rand_method(rm);
      ASSERT(rc == 1);
+}</pre>
 == Seeds ==

← Older revision		Revision as of 13:47, 13 May 2014
Line 33:		Line 33:

	Examining random data using the tests above cannot determine whether a data source is truly random or not. However, it '''can''' indicate whether data is '''likely''' to be non-random.		Examining random data using the tests above cannot determine whether a data source is truly random or not. However, it '''can''' indicate whether data is '''likely''' to be non-random.
		+
		+	== Generators ==
		+
		+	By default, OpenSSL uses the <tt>md_rand</tt> generator. The source code is located in <tt>crypto/rand/md_rand.c</tt>.
		+
		+	You can test for the generator with:
		+
		+	<pre>RAND_METHOD* rm = RAND_get_rand_method();
		+	if(rm == RAND_SSLeay())
		+	{
		+	printf("Using default generator\n");
		+	}</pre>
		+
		+	You can change the random method using the following.
		+
		+	<pre>RAND_METHOD* rm = ...;
		+	if(rm != NULL)
		+	{
		+	rc = RAND_set_rand_method(rm);
		+	ASSERT(rc == 1);
		+	}

	== Seeds ==		== Seeds ==