4 ms·

> While that's true, just blindly mixing all you've got is a bad idea. Let's say you have "randomness" sources A, B, C and D, and you just use A+B+C+D. Now an

> While that's true, just blindly mixing all you've got is a bad idea. Let's say you have "randomness" sources A, B, C and D, and you just use A+B+C+D. Now an attacker has total control over D. Then she could adaptively feed you with a D value that is canceling out A, B and C. Result is deterministic output. This is only true if the attacker knows A, B, and C, in which case you have already lost. > Just adding in more is not always good. You need to trust every source. Or more precisely: You need at least one source in the mix that an attacker can't predict/read out. You sort of contradict yourself here. The fact that you need a source that the attacker cannot predict is a reason why it is good to just add more. The more sources you have, the more likely there will be one that the attacker can't predict.

wahern 9y ago
Perhaps a better explanation of what randomnumber42 is getting at comes from Dan Bernstein: https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html
- benchaney 9y ago
  It's an interesting attack, but as I mentioned, it requires an attacker to know every input to the hash function, which in many ways is strong argument for including as many sources of entropy as possible. It is certainly a much stronger argument than the other argument he refutes farther down. There is also another more pressing issue, which is that if an attacker can see all of your RNG inputs, than they can predict your RNG output anyway, and they can predict your keys anyway. This renders Dan Bernstein's attack against DSA/ECDSA mute.
  - wahern 9y ago
    I think his point is that continuously adding entropy might make it easier for an active attacker to exfiltrate data undetected. Of course, the malicious device will also be able to see other sensitive information, not just x and y. But this doesn't mean that it's cheap for the attacker to exfiltrate this information! The attacker needs to find a communication channel out of the spying device. Randomness generation influenced by the device is a particularly attractive choice of channel, as I'll explain below He then goes on to explore a possible scenario in detail. The point isn't that continuously drawing entropy is necessarily worse. The point is to illustrate that it's not as risk-free as we may think. Furthermore, it doesn't provide much, if any value. In other words, why bother with the added complexity? And there is added complexity. Linux[1] and OpenBSD use ad hoc mixing schemes for injecting entropy into their PRNGs, with no proof of security. There are schemes with proofs of security, but they're more complex. More over, the ones with the strongest proofs are the most complex of all and often relatively slow, which is why Linux and OpenBSD have been resistant to simply using, e.g., Fortuna. Similarly, if you give up on constantly trying to inject data, then multiple CPU implementations are easier--just keep a simple PRNG state per CPU, without any fancy waterfall schemes. These days collecting, even without a hardware RNG, 128 bits of entropy should happen in very short order. Estimates are of no matter, you either have it or you don't, and there's no way to prompt a user, "Do you really want to proceed?" If you can't collect 128 bits of entropy by the time /bin/init loads, you're probably screwed. The best example is a VM--if you have no access to a TRNG or to the host's entropy source, you shouldn't expect the situation to appreciably improve 10 seconds or even 10 minutes later. At the very least, you should assume you're screwed and that the environment isn't a place where you should put services and assets that depend, directly or indirectly, on secure entropy generation. The logic is, why? Why bother? Especially in security, we normally shouldn't be doing things without well-quantified justifications, especially considering that engineers invariably underestimate the cost of complexity, particularly in the security domain. History has shown that not only do these behaviors create a false sense of security (they're often inadequate in ways we never initially understand[2]), but they can make matters much worse. [1] At least I think it still does. [2] No coincidence when the reason for adding them is to solve some ill-defined and poorly understood problem. If you can't quantify the solution you should be wary of relying on it. If you can neither quantify the problem nor the value of the solution (as in the case with constantly adding entropy), it's arguably poor judgment to apply the solution at all.

wahern 9y ago

Perhaps a better explanation of what randomnumber42 is getting at comes from Dan Bernstein: https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html

benchaney 9y ago
It's an interesting attack, but as I mentioned, it requires an attacker to know every input to the hash function, which in many ways is strong argument for including as many sources of entropy as possible. It is certainly a much stronger argument than the other argument he refutes farther down. There is also another more pressing issue, which is that if an attacker can see all of your RNG inputs, than they can predict your RNG output anyway, and they can predict your keys anyway. This renders Dan Bernstein's attack against DSA/ECDSA mute.
- wahern 9y ago
  I think his point is that continuously adding entropy might make it easier for an active attacker to exfiltrate data undetected. Of course, the malicious device will also be able to see other sensitive information, not just x and y. But this doesn't mean that it's cheap for the attacker to exfiltrate this information! The attacker needs to find a communication channel out of the spying device. Randomness generation influenced by the device is a particularly attractive choice of channel, as I'll explain below He then goes on to explore a possible scenario in detail. The point isn't that continuously drawing entropy is necessarily worse. The point is to illustrate that it's not as risk-free as we may think. Furthermore, it doesn't provide much, if any value. In other words, why bother with the added complexity? And there is added complexity. Linux[1] and OpenBSD use ad hoc mixing schemes for injecting entropy into their PRNGs, with no proof of security. There are schemes with proofs of security, but they're more complex. More over, the ones with the strongest proofs are the most complex of all and often relatively slow, which is why Linux and OpenBSD have been resistant to simply using, e.g., Fortuna. Similarly, if you give up on constantly trying to inject data, then multiple CPU implementations are easier--just keep a simple PRNG state per CPU, without any fancy waterfall schemes. These days collecting, even without a hardware RNG, 128 bits of entropy should happen in very short order. Estimates are of no matter, you either have it or you don't, and there's no way to prompt a user, "Do you really want to proceed?" If you can't collect 128 bits of entropy by the time /bin/init loads, you're probably screwed. The best example is a VM--if you have no access to a TRNG or to the host's entropy source, you shouldn't expect the situation to appreciably improve 10 seconds or even 10 minutes later. At the very least, you should assume you're screwed and that the environment isn't a place where you should put services and assets that depend, directly or indirectly, on secure entropy generation. The logic is, why? Why bother? Especially in security, we normally shouldn't be doing things without well-quantified justifications, especially considering that engineers invariably underestimate the cost of complexity, particularly in the security domain. History has shown that not only do these behaviors create a false sense of security (they're often inadequate in ways we never initially understand[2]), but they can make matters much worse. [1] At least I think it still does. [2] No coincidence when the reason for adding them is to solve some ill-defined and poorly understood problem. If you can't quantify the solution you should be wary of relying on it. If you can neither quantify the problem nor the value of the solution (as in the case with constantly adding entropy), it's arguably poor judgment to apply the solution at all.