News for hackers. Stuff that matters.
Re:Fixing Getrandom() by cryptonector on Tuesday October 01, 2019 @06:24PM (#21131483)
DJB is not saying that an entropy pool is insecure, as you put it. Nor is he saying that one shouldn't bother with a PRNG seeded with RDRAND and/or other hardware sources of entropy.

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.

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.
Re:Fixing Getrandom() by tptacek on Wednesday October 02, 2019 @12:12AM (#21133367)
This is an extremely weird threat model, in that it implies an actively adversarial CPU that can't be trusted with or without RDRAND.
Re:Fixing Getrandom() by tzs on Wednesday October 02, 2019 @12:16AM (#21133387)
If you only have one source that you suspect might be malicious (such as RDRAND), can't you just use that as the first source?