3 ms·

Am I misreading this or is Ted T'so really suggesting that we should all just stop worrying and love the secret and compeltely unauditable RNG offered by the sa

Am I misreading this or is Ted T'so really suggesting that we should all just stop worrying and love the secret and compeltely unauditable RNG offered by the same company that has literally backdoored every CPU they've sold in the past 12 years? Doesn't it all depend on how you are using it? As far as I recall, 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, the argumentation is that it is safe. The potentially backdoored RDRAND is problematic as a source of random numbers or when the entropy has too little entropy (since RDRAND would determine the entropy).

boring_twenties 7y ago
Well yes. Except if, as others have noted, the hypothetical malicious RDRAND can read the state of the entropy pool as well. Of course that's a totally different and more complex attack. Is it still plausible enough to possibly worry about? I have no idea, honestly -- this is way outside my area of expertise. What I do know is that hardware RNGs made from open-source and verifiable hardware is readily available for about US$50 for qty 1, cheaper in bulk. Given that, it doesn't seem worth more than a couple of minutes investigating whether or not RDRAND can be trusted. If there is the slightest hint of doubt, I just disable it and move on with life.
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 ago
  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.
  - dependenttypes 7y ago
    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.
    - tptacek 7y ago
      This is an extremely weird threat model, in that it implies an actively adversarial CPU that can't be trusted with or without RDRAND.
    - tzs 7y ago
      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?

boring_twenties 7y ago

Well yes. Except if, as others have noted, the hypothetical malicious RDRAND can read the state of the entropy pool as well. Of course that's a totally different and more complex attack. Is it still plausible enough to possibly worry about? I have no idea, honestly -- this is way outside my area of expertise. What I do know is that hardware RNGs made from open-source and verifiable hardware is readily available for about US$50 for qty 1, cheaper in bulk. Given that, it doesn't seem worth more than a couple of minutes investigating whether or not RDRAND can be trusted. If there is the slightest hint of doubt, I just disable it and move on with life.

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 ago
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.
- dependenttypes 7y ago
  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.
  - tptacek 7y ago
    This is an extremely weird threat model, in that it implies an actively adversarial CPU that can't be trusted with or without RDRAND.
  - tzs 7y ago
    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?