4 ms·
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 Int
by 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 agoRDRAND 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 agoThis 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 agoFTR, 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...