The Difference Between RDRAND and RDSEED

Intel recently announced the addition of the RDSEED instruction to the Intel® 64 and IA-32 Architectures. An addition to Intel® Secure Key, this new instruction will appear in future generations of Intel processors.

Like RDRAND the RDSEED instruction returns random numbers, and with two instructions that appear to do the same thing it is only natural for the software developer to ask, "Which one should I use?" I'll provide both a short and long answer: the short answer is for developers who just want to know which instruction to use and when, and the long answer is for those who are interested in some of the theory behind the answer.

The short answer

The decision process for which instruction to use is mercifully simple, and based on what the output will be used for.

  • If you wish to seed another pseudorandom number generator (PRNG), use RDSEED
  • For all other purposes, use RDRAND

That's it. RDSEED is intended for seeding a software PRNG of arbitrary width. RDRAND is intended for applications that merely require high-quality random numbers.

The long answer

Both RDRAND and RDSEED return random numbers that are compliant to the U.S. National Institute of Standards and Technology (NIST) standards on random number generators.


NIST Compliance

RDRANDCryptographically secure pseudorandom number generatorSP 800-90A
RDSEEDNon-deterministic random bit generatorSP 800-90B & C (drafts)

The numbers returned by RDSEED are referred to as "seed-grade entropy" and are the output of a true random number generator (TRNG), or an ehanced non-deterministic random number generator (ENRNG) in NIST-speak.  RDSEED is intended for use by software vendors who have an existing PRNG, but would like to benefit from the entropy source of Intel Secure Key. With RDSEED you can seed a PRNG of any size.

The numbers retuned by RDSEED have multiplicative prediction resistance. If you use two 64-bit samples with multiplicative prediction resistance to build a 128-bit value, you end up with a random number with 128 bits of prediction resistance (2128 * 2128 = 2256). Combine two of those 128-bit values together, and you get a 256-bit number with 256 bits of prediction resistance. You can continue in this fashion to build a random value of arbitrary width and the prediction resistance will always scale with it. Because its values have multiplicative prediction resistance RDSEED is intended for seeding other PRNGs.

In contrast, RDRAND is the output of a 128-bit PRNG that is compliant to NIST SP 800-90A. It is intended for applications that simply need high-quality random numbers. The numbers returned by RDRAND have additive prediction resistance because they are the output of a pseurandom number generator. If you put two 64-bit values with additive prediction resistance togehter, the prediction resistance of the resulting value is only 65 bits (264 + 264 = 265). To ensure that RDRAND values are fully prediction-resistant when combined together to build larger values you can follow the procedures in the DRNG Software Implementation Guide on generating seed values from RDRAND, but it's generally best and simplest to just use RDSEED for PRNG seeding.



Intel® Architecture Instruction Set Extensions Programming Reference

Intel® Digital Random Number Generator (DRNG) Software Implementation Guide

For more complete information about compiler optimizations, see our Optimization Notice.



Thank you for the clarification! So it is like this:

RDSEED: gives true random values but at slow data rate

RDRAND: gives very good random values, good enough for all but the most demanding (e.g. tightest security) applications, at data rate much higher than RSEED


johnm's picture

RDRAND is, indeed, faster than RDSEED because it comes from a hardware-based pseudorandom number generator. One seed value (effectively, the output from one RDSEED command) can provide up to 511 128-bit random values before forcing a reseed. The underlying PRNG serves those random numbers at data rates that exceed the bussing capabilities of the system architecture, which is why we recommend that you use a fixed loop of "retry 10 times if there's a failure" when invoking RDRAND directly. The probability of a properly-functioning DRNG failing to return a valid result in response to a RDRAND command is so low that 10 failures in a row is a reliable indicator of a faulty part.

RDSEED, on the other hand, is directly tied to the physical entropy. It is possible to execute RDSEED instructions faster than the seeds themselves can be generated, thus draining the queue of seeds. (Note, however, that the entropy used to feed RDSEED is not the same pipeline as the entropy used to seed the PRNG behind RDRAND, so attempting to DoS RDSEED will not impact RDRAND).

For this reason, you only use RDSEED for applications that need the higher grade of prediction resistance in their random numbers. Seeds for software-based pseudorandom number generators are the primary application. Creating static encryption keys that will have a long lifetime might be another.

The answer is not fully exhaustive.

It suggests that RDSEED is totally superior to RDRAND, so I can see no reason why to ever prefer RDRAND over RDSEED, especially if I fails to recognize my particular case as belonging to one of the 2 described vague usage categories.

I suspect that RDRAND may be faster to give valid result (set carry flag), which would translates in better performance, and that would make it better choice in some situations, but is this the case? If so, please let us know.


Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.