4 ms·

Uh. You're saying you should compare the result of running a random number generator twice and seeing if the two values are the same?

• logfromblammo 13y ago
  No, you store the register value holding the RDRAND result into memory, then you store the register value holding the number from your other sources of entropy. Then you read them back from memory and XOR the same numbers again. You compare that result with the XOR from the register values and see if they are the same. If they are different, the chip is substituting a different XOR result whenever it is capable of determining that one of the operands is the output of an RDRAND instruction. You might presume that an efficient mixer of multiple entropy sources would just XOR all of its various inputs together, so compromising XOR would be an easy way to discard the entropy of the other inputs in a way that is not easily detected without writing assembly code specifically to check it.
  • mnw21cam 13y ago
    That doesn't protect against the CPU choosing the return value of RDRAND maliciously - just against the XOR operation being duff. To be honest, it's much easier for a CPU to have a malicious RDRAND than compromise XOR. As demonstrated in another post, returning "edx XOR <something predictable>" hoses the Linux RNG.
    • logfromblammo 13y ago
      But a malicious RDRAND is, at worst, useless, contributing zero entropy to a pool of multiple sources. A malicious XOR could reduce the entropy of the pool.