Hacker News Reader

Comment by marshray | Hacker News Reader

https://lkml.org/lkml/2011/7/31/139 Since there was a minor amount of confusion I want to clarify: RDRAND architecturally has weaker security guarantees than the documented interface for /dev/random, so we can't just replace all users of extract_entropy() with RDRAND.

I still don't get it.

View on HN

What don't you get? RDRAND is an interface to a non-blocking PRNG backed by a HWRNG. You can't directly get the output of the HWRNG. Intel uses the PRNG to condition the output of the HWRNG, but it will still give you numbers if the HWRNG is having trouble (HWRNG errors can be detected, but the RDRAND instruction itself doesn't trap on HWRNG failures). If you trust Intel's PRNG sufficiently, then you can use RDRAND directly for /dev/urandom, but it takes a lot more trust to use it for /dev/random.

It's documented to have the potential to not return random data, so in that sense it's blocking like Linux' /dev/random. Sample code shows some type of polling loop IIRC.

The RDRAND circuits perform continual health checks and will signal a error instead of outputting bad data. See section 3.3 of http://software.intel.com/en-us/articles/intel-digital-rando...

In NIST parlance (SP800-90{A,B,C}), RDRAND is a DRBG, while /dev/random should be a NRBG.

For what it's worth, the RDSEED instruction has been announced by Intel a while back (but not yet on current processors), which means to be an NRBG as well.

RDRAND does have non-determinism. The problem is that you can't directly measure or monitor how much non-determinism. The values you get from RDRAND come from a DRBG that is periodically and automatically re-seeded from a NRBG, but if you call RDRAND many times in rapid succession, then the DRBG may not have been re-seeded between each invocation. RDSEED differs only in that it guarantees that the DRBG is re-seeded between invocations. If you are using the instructions infrequently enough, then the two are functionally identical, but "infrequently enough" has a value known only to Intel.

This comment in linux/arch/x86/kernel/cpu/rdrand.c claims:

    /*
     * Force a reseed cycle; we are architecturally guaranteed a reseed
     * after no more than 512 128-bit chunks of random data.  This also
     * acts as a test of the CPU capability.
     */

FTR, that limit is also mentioned in the Intel manual [1, 3.2.3], and in the Cryptography Inc report [2, 2.4.2].

[1] http://software.intel.com/en-us/articles/intel-digital-rando...

[2] http://www.cryptography.com/public/pdf/Intel_TRNG_Report_201...

Reply on news.ycombinator.com