On Tuesday, October 29, 2019, 11:42:42 AM PDT, coderman <coderman@protonmail.com> wrote:
What’s an RDRAND?>The microcode bug in question is a faulty response to the RDRAND instruction. Modern x86_64 CPUs—beginning with Intel's Broadwell andAMD's Zen architectures—are supposed to have high-quality onboard random number generators (RNGs), which use thermal "noise" to very rapidlyoffer high-entropy pseudorandom numbers to anybody with kernel-levelaccess who wants it. RDRAND is, in turn, the instruction that provides these random numbers.>All of this is supposed to be fairly failsafe. There's a CPUID function call that checks for the availability of RDRAND, and there's also a "carry bit" in the return value from a call to RDRAND that's supposed to let the calling application know if the CPU's RNGwas unable to generate a sufficiently random number. Unfortunately,unpatched Ryzen 3000 says "yes" to the CPUID 01H call, sets the carry bit indicating it has successfully created the mostartisanal, organic high-quality random number possible... and gives you a 0xFFFFFFFF for the "random" number, every single time.
I think that any microprocessor which purports to be able to internally-generate "random numbers" should also be equipped with an input (possibly a single line) which is intended to be connected to an external source of random numbers, intended to be mixed with the internal random source, for example: http://www.fdk.com/cyber-e/pi_ic_rpg100.html or https://www.idquantique.com/random-number-generation/products/quantis-qrng-c... orhttps://ieeexplore.ieee.org/document/847868 This should minimize the possibility that defects in one source can affect the randomness of the ultimately-used data stream, Jim Bell