Changes to RDRAND integration in OpenSSL

By John P Mechalas, Published: 10/03/2014, Last Updated: 10/03/2014

Beginning with the 1.0.1f release of OpenSSL the RDRAND engine is no longer loaded by default*.

The impact of this from the users' and developers' perspectives is that, for the near future, random numbers obtained from the RAND_bytes() function will come from OpenSSL's software-based PRNG rather than directly from the RDRAND instruction. This change was made in part due to concerns in the user community around OpenSSL's reliance on a single entropy source for random number generation.  Essentially, OpenSSL did not want to force end developers and users onto a single entropy source without them being aware that it was happening.

Unfortunately, this change also means that RDRAND is no longer OpenSSL's random number generator by default.

What does this change mean for OpenSSL and RDRAND in the future?

This change to the handling of the RDRAND engine is permanent. OpenSSL will not load the RDRAND engine by default from version 1.0.1f and on.

RDRAND still has a place in OpenSSL's future, however. In upcoming 1.0.2 releases, the PRNG within OpenSSL will actually call upon both the RDRAND and RDSEED instructions (if available) to augment its output. It will do this in two ways, by:

  1. XOR'ing random values obtained from the software PRNG with values obtained from RDRAND (in non-FIPS modes)
  2. Using RDSEED or RDRAND as an entropy source to seed the software PRNG (in both FIPS and non-FIPS modes)

This new behavior of the built-in PRNG has been committed into the 1.0.2-stable branch of the OpenSSL source tree. There's no release version or date targeted for these changes, but they will likely not make it in the initial 1.0.2 release which was feature-frozen before these changes were implemented. It's also not known whether or not this will be back-ported into the 1.0.1 branch.

What should developers do in the mean time?

What's a developer to do given these changes in the OpenSSL architecture? Well, it depends on your goals, and how much work you want to do.

Explicitly enable the RDRAND engine

If you want to guarantee that the RAND_bytes() function returns numbers that come from the RDRAND instruction, then you can explicitly enable the RDRAND engine as described in the article, "How to use the rdrand engine in OpenSSL for random number generation". By doing this you are essentially returning to the pre-1.0.1f behavior of OpenSSL through manual intervention. You'll also  ensure this behavior going forward, no matter which version of OpenSSL the end user has installed on their system.

Do nothing

Alternatively, you can do nothing, and accept the default behavior of OpenSSL's RAND_bytes() function. This means the source of the random numbers from the RAND_bytes() will change with the OpenSSL version. If the end user upgrades from 1.0.1e to 1.0.1f then they will no longer benefit from the RDRAND instruction. When they upgrade to a 1.0.2 release that re-enables RDRAND support, they will  still get the OpenSSL PRNG but it will mix in values from RDRAND.

Fortunately, this interim period where RDRAND is not integrated into the RAND_bytes() function by default should not last for long.

 

§

* Strictly speaking, it's loaded but not enabled. It will still show up in the list of engines if you run "openssl engine".

Product and Performance Information

1

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804