3 ms·

A Cryptographically Secure Random Number Generator relies on cryptography being correct and not breakable in a useful amount of time. If that doesn’t hold what

A Cryptographically Secure Random Number Generator relies on cryptography being correct and not breakable in a useful amount of time. If that doesn’t hold what in the world are you using the random numbers for?? If it does hold then the whole idea of an “entropy pool” is useless cruft. Think of it this way: AES has to look like random noise. If there is any correlation to the input detectable by someone without the key it would be useless for crypto. A CSRNG isn’t quite the same thing but you can think of it the same way: it only needs some initial entropy, just like AES needs a key. Thereafter it must be able to generate random bytes faster than they could possibly be consumed (TB/s or more) without disclosing any information about its internal state or it is a useless CSRNG whether the entropy pool exists or not.

ajross 7y ago
> AES has to look like random noise. If there is any correlation to the input detectable by someone without the key it would be useless for crypto. Uh... AES (to pick your particular example) is a symmetric algorithm. By definition there is a 1:1 correlation to the input. If you have the key and know the input you can compute the output, and vice versa. The question at hand is not whether the algorithm is breakable but whether someone can find the key (or more generally the PRNG state). And that's what the entropy pool does: it seeds the PRNG state with values that are derived at runtime by the kernel and not under the control of an attacker, even one embedded in the system. There are side arguments about whether the entropy pool's estimates are good ones, about whether it should block by default when empty, etc... But I don't see any reasonable arguments that this isn't a useful feature for an OS kernel to provide.
- dependenttypes 7y ago
  > By definition there is a 1:1 correlation to the input But it is still not detectable without the key.
tytso 7y ago
You still need some way to securely seed a CSRNG. That's what we use the entropy pool for in Linux. The idea is that we mix multiple sources, and hopefully at least one can't be guessed by a particular attacker. For example, you might use three hardware random number generators; one might be compromised by the Chinese MSS, and one might be compromised by the KGB, and the third might be compromised by the NSA --- but hopefully they won't be all compromised, and even if they are, hopefully they aren't working together. Or maybe we're mixing randomness from the UEFI and the TPM. Neither can be audited, and we know that many firmware engieners are incompentent. But hopefully, if the UEFI BIOS has some terrible bug, or can be remotely compromised because Intel snuck in a Minux OS with a web server without telling us in their CPU's, maybe the TPM provider didn't make a similar mistake.

ajross 7y ago

> AES has to look like random noise. If there is any correlation to the input detectable by someone without the key it would be useless for crypto. Uh... AES (to pick your particular example) is a symmetric algorithm. By definition there is a 1:1 correlation to the input. If you have the key and know the input you can compute the output, and vice versa. The question at hand is not whether the algorithm is breakable but whether someone can find the key (or more generally the PRNG state). And that's what the entropy pool does: it seeds the PRNG state with values that are derived at runtime by the kernel and not under the control of an attacker, even one embedded in the system. There are side arguments about whether the entropy pool's estimates are good ones, about whether it should block by default when empty, etc... But I don't see any reasonable arguments that this isn't a useful feature for an OS kernel to provide.

dependenttypes 7y ago
> By definition there is a 1:1 correlation to the input But it is still not detectable without the key.

tytso 7y ago

You still need some way to securely seed a CSRNG. That's what we use the entropy pool for in Linux. The idea is that we mix multiple sources, and hopefully at least one can't be guessed by a particular attacker. For example, you might use three hardware random number generators; one might be compromised by the Chinese MSS, and one might be compromised by the KGB, and the third might be compromised by the NSA --- but hopefully they won't be all compromised, and even if they are, hopefully they aren't working together. Or maybe we're mixing randomness from the UEFI and the TPM. Neither can be audited, and we know that many firmware engieners are incompentent. But hopefully, if the UEFI BIOS has some terrible bug, or can be remotely compromised because Intel snuck in a Minux OS with a web server without telling us in their CPU's, maybe the TPM provider didn't make a similar mistake.