5 ms·

> Do we just make it act like /dev/urandom by default, and add a new flag for "wait for entropy"? Dear God. The CSPRNG situation on Linux is deeply depressing.

> Do we just make it act like /dev/urandom by default, and add a new flag for "wait for entropy"? Dear God. The CSPRNG situation on Linux is deeply depressing. /dev/urandom is useless because it spews non-random data if it hasn't been seeded yet. /dev/random is useless because it starts blocking if you try to read too much data from it, because of a mistaken belief that a properly seeded CSPRNG can run out of entropy. Plus they're both slow as hell, so people try to implement their own PRNGs, often having bugs in the generator or seeding, leading to security issues. Meanwhile the BSDs have handled this correctly for years. But inexplicably, instead of actually fixing /dev/(u)random, the Linux engineers decide to add a new getrandom() syscall which implements the correct behaviour of only blocking if the PRNG hasn't been seeded. 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! The kernel has plenty of ways to securely seed a PRNG at boot on modern systems; IRQ timings, multicore tricks, sensor data, etc. Run some statistical tests on it to ensure you have a couple hundred bits of randomness and you're done.

xyzzyz 7y ago
/dev/urandom is useless because it spews non-random data if it hasn't been seeded yet. Does it? Under what circumstances? Where can I read about it?
- yjftsjthsd-h 7y ago
  `man 4 random` states, > When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. If this is of concern in your application, use getrandom(2) or /dev/random instead.
- CodeHz 7y ago
  it happened in my system in last boot, dmesg says dbus-daemon tried (twice!) to read urandom before its seeded, and the next message (same second, about 200ms) is about urandom has been seeded, it is a race condition!
ploxiln 7y ago
> 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.
gnud 7y ago
Whenever I read these discussions, I always see references to BSD vs Linux. The BSD "way" seems cleaner to me, but I'm certainly no expert. But does anyone know what Windows and OSX (and iOs for that matter) does to "warm up" entropy?
- asveikau 7y ago
  On Windows, I believe RtlGenRandom is pretty similar to getrandom() etc. Including the "it won't fail due to failure to open a device" aspect.
- comex 7y ago
  On macOS, /dev/random never blocks. From the beginning up until 2014 or so, this was blatantly insecure: the only initial entropy was the system clock! In microseconds, not seconds, thankfully, but that's still a very low amount of entropy. securityd in userland would send the kernel more entropy once it came up, but before that point, /dev/random would just spew low-quality random numbers. Since 2014, however, macOS has expected to get a random seed from the bootloader, which in turn gets it from rdrand if available, or some complicated timer stuff if not. I'm not sure how secure the latter is, but as of Mojave, there are no longer any supported Macs without rdrand, making the issue moot...
masklinn 7y ago
> inexplicably, instead of actually fixing /dev/(u)random, the Linux engineers decide to add a new getrandom() syscall which implements the correct behaviour of only blocking if the PRNG hasn't been seeded. FWIW the OpenBSD folks first implemented getentropy() and recommended that Linux do the same[0], because devices causes various issues (e.g. chrooting, attacker-controlled FD exhaustion, …) having a reliable syscall is extremely valuable. Sadly the Linux folks way over-engineered the thing with all kinds of tuning knobs so that you can get any preexisting behaviour you want: by default getrandom will read from the "urandom source" but block until the entropy pool has been initialised once. However, you can also: * GRND_RANDOM to have it read from the "random source" and block if "no random bytes are available" * GRND_NONBLOCK to have it never block on lack of entropy, whether from the entropy pool not being initialised at all (!GRND_RANDOM) or because "there are no random bytes" (GRND_RANDOM), in which case it can also fail (getentropy should only fail if you give it an invalid buffer address or you request more than 256 bytes) [0] https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00041.html https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00... also through the libressl project complaining about the lack of safe way to get good random data[1] [1] https://github.com/libressl-portable/openbsd/blob/4e9048830a68da79247f30aba182b1599da139b9/src/lib/libcrypto/crypto/getentropy_linux.c#L87 https://github.com/libressl-portable/openbsd/blob/4e9048830a...
kbumsik 7y ago
> Meanwhile the BSDs have handled this correctly for years. How BSDs handle it correctly?

xyzzyz 7y ago

/dev/urandom is useless because it spews non-random data if it hasn't been seeded yet. Does it? Under what circumstances? Where can I read about it?

yjftsjthsd-h 7y ago
`man 4 random` states, > When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. If this is of concern in your application, use getrandom(2) or /dev/random instead.
CodeHz 7y ago
it happened in my system in last boot, dmesg says dbus-daemon tried (twice!) to read urandom before its seeded, and the next message (same second, about 200ms) is about urandom has been seeded, it is a race condition!

ploxiln 7y ago

> 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.

gnud 7y ago

Whenever I read these discussions, I always see references to BSD vs Linux. The BSD "way" seems cleaner to me, but I'm certainly no expert. But does anyone know what Windows and OSX (and iOs for that matter) does to "warm up" entropy?

asveikau 7y ago
On Windows, I believe RtlGenRandom is pretty similar to getrandom() etc. Including the "it won't fail due to failure to open a device" aspect.
comex 7y ago
On macOS, /dev/random never blocks. From the beginning up until 2014 or so, this was blatantly insecure: the only initial entropy was the system clock! In microseconds, not seconds, thankfully, but that's still a very low amount of entropy. securityd in userland would send the kernel more entropy once it came up, but before that point, /dev/random would just spew low-quality random numbers. Since 2014, however, macOS has expected to get a random seed from the bootloader, which in turn gets it from rdrand if available, or some complicated timer stuff if not. I'm not sure how secure the latter is, but as of Mojave, there are no longer any supported Macs without rdrand, making the issue moot...

masklinn 7y ago

> inexplicably, instead of actually fixing /dev/(u)random, the Linux engineers decide to add a new getrandom() syscall which implements the correct behaviour of only blocking if the PRNG hasn't been seeded. FWIW the OpenBSD folks first implemented getentropy() and recommended that Linux do the same[0], because devices causes various issues (e.g. chrooting, attacker-controlled FD exhaustion, …) having a reliable syscall is extremely valuable. Sadly the Linux folks way over-engineered the thing with all kinds of tuning knobs so that you can get any preexisting behaviour you want: by default getrandom will read from the "urandom source" but block until the entropy pool has been initialised once. However, you can also: * GRND_RANDOM to have it read from the "random source" and block if "no random bytes are available" * GRND_NONBLOCK to have it never block on lack of entropy, whether from the entropy pool not being initialised at all (!GRND_RANDOM) or because "there are no random bytes" (GRND_RANDOM), in which case it can also fail (getentropy should only fail if you give it an invalid buffer address or you request more than 256 bytes) [0] https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00041.html https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00... also through the libressl project complaining about the lack of safe way to get good random data[1] [1] https://github.com/libressl-portable/openbsd/blob/4e9048830a68da79247f30aba182b1599da139b9/src/lib/libcrypto/crypto/getentropy_linux.c#L87 https://github.com/libressl-portable/openbsd/blob/4e9048830a...

kbumsik 7y ago

> Meanwhile the BSDs have handled this correctly for years. How BSDs handle it correctly?