4 ms·

> So finally with getrandom() Linux has a way to securely generate random data without unnecessarily blocking, and now Linus seems to be floating the idea to br

> So finally with getrandom() Linux has a way to securely generate random data without unnecessarily blocking, and now Linus seems to be floating the idea to break it again! Yes, getrandom() works pretty much the "right" way. But the problem is that it still can block during boot, indefinitely. And nobody really wants their computer to just stop working, because it can't guarantee that the entropy is not theoretically possibly "bad". Real users do not want this. But it happens. The root of this is security paranoia. Security people didn't want the RDRAND instruction to be trusted. SystemD didn't credit the entropy pool when adding the saved seed file from the previous boot, until very recently it got an option to credit the entropy pool. These things are all mixed into the pool, and on any desktop machine /dev/urandom is absolutely fine, but security expert pressure has forced these systems to not trust that real entropy has been added from the many sources that are already implemented. You might be surprised how many people make this problem go away by running havaged, which provides very dubious entropy.

the8472 7y ago
> Security people didn't want the RDRAND instruction to be trusted. The recent AMD issues have shown that you certainly shouldn't trust rdrand blindly. Even using it after running some statistical tests would still have blocked the kernel bootup on affected machines. > And nobody really wants their computer to just stop working I would rather have my computer stop working than initiate cryptographic keys from an all-1s seed. Of course filling the entropy pool should keep making progress, no matter how slowly, e.g. via the jitter RNG and eventually unblock the systeem. But until there's not enough entropy available for userspace it shouldn't pretend there is.
jlgaddis 7y ago
> You might be surprised how many people make this problem go away by running havaged, [sic] which provides very dubious entropy. My personal favorite is: # rngd -r /dev/urandom -o /dev/random
- masklinn 7y ago
  TBF that's a proper fix for the stupidity that is the entropy estimator.

the8472 7y ago

> Security people didn't want the RDRAND instruction to be trusted. The recent AMD issues have shown that you certainly shouldn't trust rdrand blindly. Even using it after running some statistical tests would still have blocked the kernel bootup on affected machines. > And nobody really wants their computer to just stop working I would rather have my computer stop working than initiate cryptographic keys from an all-1s seed. Of course filling the entropy pool should keep making progress, no matter how slowly, e.g. via the jitter RNG and eventually unblock the systeem. But until there's not enough entropy available for userspace it shouldn't pretend there is.

jlgaddis 7y ago

> You might be surprised how many people make this problem go away by running havaged, [sic] which provides very dubious entropy. My personal favorite is: # rngd -r /dev/urandom -o /dev/random

masklinn 7y ago
TBF that's a proper fix for the stupidity that is the entropy estimator.