On Tuesday, October 29, 2019, 11:42:42 AM PDT, coderman <[email protected]> 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-chip/?gclid=CjwKCAjwxt_tBRAXEiwAENY8hU5d5R0aujGaQjDCHS6Ej_gwwLk8Sz9Z6XG71zec2o9HlcTyjHPaIhoC7HMQAvD_BwE 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
