4 ms·

https://lkml.org/lkml/2011/7/31/139 https://lkml.org/lkml/2011/7/31/139 Since there was a minor amount of confusion I want to clarify: RDRAND architecturally ha

https://lkml.org/lkml/2011/7/31/139 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.

wtallis 13y ago
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.
- marshray 13y ago
  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.
- arete 13y ago
  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-random-number-generator-drng-software-implementation-guide http://software.intel.com/en-us/articles/intel-digital-rando...
pbsd 13y ago
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.
- wtallis 13y ago
  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.
  - caf 13y ago
    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. */
    - pbsd 13y ago
      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-random-number-generator-drng-software-implementation-guide/ http://software.intel.com/en-us/articles/intel-digital-rando... [2] http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf http://www.cryptography.com/public/pdf/Intel_TRNG_Report_201...

wtallis 13y ago

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.

marshray 13y ago
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.
arete 13y ago
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-random-number-generator-drng-software-implementation-guide http://software.intel.com/en-us/articles/intel-digital-rando...

pbsd 13y ago

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.

wtallis 13y ago
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.
- caf 13y ago
  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. */
  - pbsd 13y ago
    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-random-number-generator-drng-software-implementation-guide/ http://software.intel.com/en-us/articles/intel-digital-rando... [2] http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf http://www.cryptography.com/public/pdf/Intel_TRNG_Report_201...