Re:Fixing Getrandom()
by dependenttypes on Tuesday October 01, 2019 @07:06PM
(#21131838)
He is saying that using a malicious source of entropy that can read the current state of the pool (such as RDRAND) can harm security.
This is an extremely weird threat model, in that it implies an actively adversarial CPU that can't be trusted with or without RDRAND.
DJB has an axe to grind (and rightly so) here in that he's pushing cryptographic algorithms that need less (or no) entropy. Specifically EdDSA instead of ECDSA. And he's also dismantling some of the bad arguments about how /dev/urandom should operate.
An operating system doesn't know why an application needs entropy, just that it does, and I don't see the problem with having an SRNG for that purpose. DJB doesn't even say that a system SRNG is not good, but, rather, he's quite sensibly saying that _applications_ should stretch one good 256-bit chunk of entropy. And yes, DJB correctly points out that there's no need to have security relative to an attacker that once saw the entire state of the SRNG at an earlier point in time -- but that does not mean that a kernel-land SRNG shouldn't add entropy to its pool, just that it doesn't buy you much.