Boffin: Dump hardware number generators for encryption and instead look within Chip timing could be as effective and harder to hack October 1, 2018 https://www.theregister.co.uk/2018/10/01/hardware_random_numbers/ Paper (PDF): https://regmedia.co.uk/2018/10/01/roig_paper.pdf
Wouldn't it be ironic if Meltdown and Spectre yielded these HWRNG! On the other hand, there is an element of security-by-obscurity if the CPU of the target system is used for this entropy, if only because the CPU is equally accessible to malware that likely knows the algorithm and therefore can potentially characterize the individual CPU. Of course, that has the merit of raising the costs for the attacker, perhaps that's all one can reasonably do. On the other hand, I think the warning of Meltdown and Spectre is that you must have secrets which are outside the address space of the general purpose computer.
I never 100% trust RNG regardless of hardware or software, and somewhat feels sorry when ppl too easily talks about "truly random". I'm not specifically talking about Dual_EC_DRBG, DUHK, PS3-key crack, nor this. The most trusted way to produce probably-true-random numbers is using EPR correlation. All others including CRNG w/ supposedly random entropy source are pseudo random, tho in theory some known tests should guarantee certain level of security. Especially it's hard to trust MS' CryptGenRandom given its history: https://en.wikipedia.org/wiki/CryptGenRandom#Security and I have no control over entropy pool nor can see it's state unlike Linux. But even when I use /dev/{u}random (it also had weakness found in 2006, tho mostly for embedded or LiveCD devices. And in 2014 DJB criticized it tho it won't be much relevant for my use) to make random characters, I substitute 1 or 2 char manually. Tho it may possibly weaken randomness, I think that's better than using possibly weak RNG.
