A deterministic random-bit generator called CTR DRBG defined in NIST SP 800-90A is seeded by the output from the conditioner, providing cryptographically secure random numbers to applications requesting them via the RDRAND instruction.
[19] An astrophysical Monte Carlo simulator examined the time to generate 107 64-bit random numbers using RDRAND on a quad-core Intel i7-3740 QM processor.
On processors with the mitigations applied, each affected instruction incurs additional latency and simultaneous execution of RDRAND or RDSEED across cores is effectively serialised.
Scientific application of RDRAND in a Monte Carlo simulator was evaluated, focusing on performance and reproducibility, compared to other random number generators.
To quote from the [New York Times article[26]]: "By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to insert back doors..." Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea.Linus Torvalds dismissed concerns about the use of RDRAND in the Linux kernel and pointed out that it is not used as the only source of entropy for /dev/random, but rather used to improve the entropy by combining the values received from RDRAND with other sources of randomness.
[28][29] However, Taylor Hornby of Defuse Security demonstrated that the Linux random number generator could become insecure if a backdoor is introduced into the RDRAND instruction that specifically targets the code using it.
It will still be possible to access hardware random number generators, that is, RDRAND, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more.
[35] On 9 June 2020, researchers from Vrije Universiteit Amsterdam published a side-channel attack named CrossTalk (CVE-2020-0543) that affected RDRAND on a number of Intel processors.
[36] They discovered that outputs from the hardware digital random number generator (DRNG) were stored in a staging buffer that was shared across all cores.
[36] The researchers developed a proof-of-concept exploit[37] which extracted a complete ECDSA key from an SGX enclave running on a separate CPU core after only one signature operation.
The updated microcode ensures that off-core accesses are delayed until sensitive operations – specifically the RDRAND, RDSEED, and EGETKEY instructions – are completed and the staging buffer has been overwritten.
Intel introduced an opt-out option, configurable via the IA32_MCU_OPT_CTRL MSR on each logical processor, which improves performance by disabling the additional security checks for instructions executing outside of an SGX enclave.