Please describe the implementation of RDRAND/RDSEED instructions

Hi,

 

In order to be able to trust RDRAND/RDSEED instructions for anything more serious than a college project, it is important to be sure these instructions return high quality randomness that isn't "backdoor"-able.

 

As far as I know Intel's implementation of RDRAND/RDSEED involve a NIST-approved (on-die(?)) co-processor of some sort. They do not reveal any useful information on how the co-processor is implemented, making it impossible to know whether the data returned from the instructions can be trusted, even when statistical analysis reveals the high quality of the random data returned. This is the reason why these instructions aren't trusted and referred to as "ah, those backdoored instructions, right?".

 

AMD's implementation of the instruction, at the first blush anyway, does not seem to use a co-processor. Performance characteristics of the instruction also seem to suggest the implementation can only generate 32 bits or random data every "tick" (which with Ryzen seem to be approx 320ns, a number that isn't affected much by clock speed). Implementation not being co-processor based is probably why there's not even a submission for approval by NIST (who trusts NIST anyway?).

 

http://crypto.stackexchange.com/a/43750 suggests a source of true randomness is used (which could explain lack of NIST-anything, as it is then mostly superfluous); namely the electrical noise generated by ring oscillators. This sounds like a great, and die-area wise -- cheap, way to implement the instructions. What is missing, however is an official confirmation. To the actual question, then: Are the RDRAND/RDSEED instructions in Ryzen implemented using parallel ring oscillators? If not, could the implementation strategy be described, please?