Usage difference between x86 RDRAND and RDSEED

Question

Modern x86 CPUs often have the RDRAND and RDSEED instructions for hardware generation of random numbers. I just don't understand the difference between them.

Intel has this document: https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed

But I don't understand how this affects the usage of RDRAND and RDSEED. Namely, in what situations can I use each, for features like generating an encryption key, or for initial seeding of a PRNG?

As for the possibility of an NSA backdoor, that really isn't an issue for us.

Answer 1

The processors come, at a first approximation, with three components:

1. A hardware noise source;
2. A pseudorandom generator that's periodically seeded from that noise source, whose output is available through the RDRAND instruction;
3. A true random generator that's driven off the noise source, whose output is available through the RDSEED instruction.

Intel's longer documentation has some explanations and a number of useful diagrams, which in turn refer to NIST's documents on random bit generators (SP800-90A, B and C). But if I were to summarize the security goals of these two instructions, I think they are this:

• No bit of the output of RDSEED should be predictable to a computationally unlimited attacker who observes any other output bits at any other time.
• No bit of the output of RDRAND should be predictable to a computationally limited attacker who observes any other output bits at any other time.
  • But some such bits might be predictable to a computationally unlimited attacker under some circumstances.

In practical pseudorandom generators, even ones that reseed themselves periodically from fresh entropy input, it's generally the case that output bits are predictable from nearby bits, given enough computational effort. For example, Intel's document tells us that their implementation of RDRAND uses NIST's CTR_DRBG algorithm. This algorithm uses a block cipher in CTR mode to produce blocks of output data in caller-requested sizes, and the generator is only reseeded between output blocks. So given a sufficient fragment of such a block, a brute force key recovery attack can predict the rest of the block with a better than chance success rate.

---

The document also tells us that both instructions use an "AES-CBC-MAC Based Conditioner" to process the output of the hardware entropy source. This concept is explained in NIST SP800-90B (second draft) (p. 5):

The optional conditioning component is a deterministic function responsible for reducing bias and/or increasing the entropy rate of the resulting output bits (if necessary to obtain a target value).

Basically, AES is here being used in a mode that, given true random but biased inputs, produces less biased, true random outputs.

---

Intel's document doesn't go at length about the "ENRNG" ("Enhanced Nondeterministc Random Number Generator," Intel's own term) used by RDSEED, but they refer us to NIST SP800-90B and SP800-90C. Looking at the latter in particular suggests that this "ENRNG" might also use AES, but again in a mode that maps true random inputs to true random outputs. There doesn't seem to be enough information to tell exactly what's going on here, but reading between the lines I'm guessing it's one of the NRGB ("Nondeterministic Random Bit Generator") constructions from SP800-90C, section 9 (pp. 32ff), which combine the true random output with that of a pseudorandom generator in an entropy-preserving fashion, as a practical safety mechanism:

The advantages of using these NRBGs include the following:

• If the underlying DRBG mechanism in the NRBG has been instantiated securely, and the entropy source fails in an undetected manner, the NRBG will continue to provide random outputs, but at the security strength of the DRBG instantiation (the “fall-back” security strength), rather than providing outputs with full entropy.
• Small deviations in the behavior of the entropy source in an NRBG will be masked by the DRBG output.

Answer 2

The answer for usage, as intended with the design of the DRNG is this:

1) Use RdRand when you need a low latency random number - Rdrand won't underflow (cf never returns as 0). The docs say retry up to 10 times. This is not because RdRand will underflow. This is the claim Intel is making about future products - that a 10 round retry loop will always work on future products with a functioning RNG. To date no product has exhibited underflows on RdRand, but that is specifically not a guaranteed instruction behavior in future products.

2) RdRand can be safely used for cryptographic purposes in applications with a security strength up to O(2^128). This was fine in 2011. There is reason to want larger keys these days, which is where RdSeed comes in.

3) RdRand can be safely used for cryptographic purposes in applications with a security strength beyond O(2^128) by applying one of the algorithms in the SDG, but this is not super efficient and better to use RdSeed.

4) RdSeed can be used where full entropy is required - RdRand offers a computational prediction resistance lower bound, not full entropy.

5) RdSeed should be used when concatenating RdSeed numbers to make keys and other cryptographic random numbers that are larger than 128 bits. E.G. If you want a 256 bit secure random number, execute RdSeed until you have 256 bits of random data and concatenate it into the resulting 256 bit number.

Answer 3

Note: most of those informations are Intel specific since there don't seem to be any AMD documents on how they do it.

RDRAND

Uses built-in AES-NI capability to generate high-entropy data for you. This includes some key whitening and produces different output every time you call it (since it generates this number just for you).

Is usually recommended if you just need high-entropy data, but possibly you might want to use OS-built CSPRNG instead (for example for PC's that don't have RDRAND).

RDSEED

Gives you current data from included entropy generator. Data is whitened on Intel CPU's (using AES-CBC). It can also report that no seed is currently available (when entropy source has been depleted), then return value will be 0, and target register set to 0 (confirmed on hardware). Seed isn't shared with RDRAND seed, but has same quality (goes trough same process of conditioning).

Recommended as entropy source for CSPRNGs. This should only be used for CSPRNGs vendors (possibly with other entropy sources, as PC might not have RDSEED).

When to use

When you need high-entropy numbers in low rates, use OS-built CSPRNGs. If you need high-entropy numbers in high rates and all your destination platforms have RDRAND (and you trust your CPU vendor), use RDRAND. If you are CSPRNG vendor, use RDSEED to gather additional entropy.