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


Performance varies by use, configuration and other factors. Learn more at