> Using Intel CPU's and simultaneously saying, "but we can't trust RDRAND because could be backdoored" is completely insane. The claim is not "can't trust RDRA

> Using Intel CPU's and simultaneously saying, "but we can't trust RDRAND because could be backdoored" is completely insane. The claim is not "can't trust RDRAND [to keep your system secure] because could be backdoored", the claim is "can't trust RDRAND [to generate unique unguessable numbers] because could be backdoored. RDRAND not only can be backdoored, but its implementation flawed or too weak for some attackers. Or it can be a pinnacle of RNGs(unlikely). In any case, it is reasonable to not trust it to generate unique unguessable numbers. That trust requires control of the generation. The impact this distrust has on decision of using Intel CPU's is specific to the use case. I trust my Intel CPU to do deterministic computational work for me, because in some cases I can rerun the job and compare the results, or check the results in another way. But I don't trust it to generate unguessable numbers for me. That is better done by separate HW device, ideally one that I would construct and control. I don't have to trust implicitly in my computer to use it. At the same time, I do not want my kernel to rely on RDRAND to get random numbers, if more trustworthy source is viable. No that perfect randomness is required, but if the authors can do better than rely on RDRAND, they should. > The bottom line is the entire CPU can not be audited. So trust it. Or don't trust it. I can trust it to evaluate 1234+1234, or play a video for me, but I don't trust it to generate unique unguessable numbers.