4 ms·
> Linux does not use RDRAND is a direct source for random numbers, but rather mixes it with the entropy pool. Since xor'ing with (potentially) low-entropy data
by dependenttypes 7y ago
> Linux does not use RDRAND is a direct source for random numbers, but rather mixes it with the entropy pool. Since xor'ing with (potentially) low-entropy data does not reduce the entropy
And this is still insecure https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html
- cryptonector 7y agoDJB 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.
- dependenttypes 7y agoHe is saying that using a malicious source of entropy that can read the current state of the pool (such as RDRAND) can harm security.