3 ms·

RLY? How on earth can a read from /dev/random be non blocking if it does not have sufficient entropy? My understanding is that /dev/random "promises" to retur

RLY? How on earth can a read from /dev/random be non blocking if it does not have sufficient entropy? My understanding is that /dev/random "promises" to return decent random stuff, /dev/urandom returns decently algorithmically generated random stuff. urandom is good, random is better but finicketty and can sulk for a while.

saagarjha 9y ago
Not on macOS. Both are identical and use Yarrow to generate pseudorandom numbers.
lordmax 9y ago
DJB retort on this is now stuff of crypto hall of fame: https://gist.github.com/tarcieri/6347417#file-gistfile1-txt https://gist.github.com/tarcieri/6347417#file-gistfile1-txt > --- Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that (1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but (2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.). For a cryptographer this doesn't even pass the laugh test. --- <
atoponce 9y ago
> RLY? How on earth can a read from /dev/random be non blocking if it does not have sufficient entropy? In short, to answer your question, I am not aware of any /dev/random that will not block if not sufficiently seeded with enough entropy. Linux is the only kernel where /dev/random always blocks when the input pool entropy estimate is low. This is highly criticized in most security communities. Mac OS X and iOS have implemented the FreeBSD CSPRNG, of which /dev/random is a symlink to /dev/urandom. The CSPRNG blocks on boot until it's sufficiently seeded with hardware timing events. Once seeded, it never blocks again. On NetBSD, /dev/random sometimes blocks, although not as notoriously as Linux. However, it will fully block on boot until sufficiently seeded, after which it no longer blocks. OpenBSD also provides no functional difference between /dev/random and /dev/urandom. Both will block until sufficiently seeded. As far as I know, on every Unix-like operating system, data is saved from the generator to disk on shutdown, and on boot, that data is read into the CSPRNG as an unpredictable seed. With every GNU/Linux operating system I can think of, this happens as part of the install, so on first boot, the kernel is already sufficiently seeded with random data. On FreeBSD, this seed is saved to "/var/db/entropy-file". On GNU/Linux, either "/var/lib/systemd/random-seed" or "/var/lib/urandom/random-seed" depending on whether or not you're using systemd. I'm not sure of NetBSD saves a seed to disk or not, as it's been many years since I've last run NetBSD seriously.
- JdeBP 9y ago
  The saved seed file on OpenBSD is /etc/random.seed . NetBSD has the /etc/rc.d/random_seed service, which uses the same filename as FreeBSD.

saagarjha 9y ago

Not on macOS. Both are identical and use Yarrow to generate pseudorandom numbers.

lordmax 9y ago

DJB retort on this is now stuff of crypto hall of fame: https://gist.github.com/tarcieri/6347417#file-gistfile1-txt https://gist.github.com/tarcieri/6347417#file-gistfile1-txt > --- Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that (1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but (2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.). For a cryptographer this doesn't even pass the laugh test. --- <

atoponce 9y ago

> RLY? How on earth can a read from /dev/random be non blocking if it does not have sufficient entropy? In short, to answer your question, I am not aware of any /dev/random that will not block if not sufficiently seeded with enough entropy. Linux is the only kernel where /dev/random always blocks when the input pool entropy estimate is low. This is highly criticized in most security communities. Mac OS X and iOS have implemented the FreeBSD CSPRNG, of which /dev/random is a symlink to /dev/urandom. The CSPRNG blocks on boot until it's sufficiently seeded with hardware timing events. Once seeded, it never blocks again. On NetBSD, /dev/random sometimes blocks, although not as notoriously as Linux. However, it will fully block on boot until sufficiently seeded, after which it no longer blocks. OpenBSD also provides no functional difference between /dev/random and /dev/urandom. Both will block until sufficiently seeded. As far as I know, on every Unix-like operating system, data is saved from the generator to disk on shutdown, and on boot, that data is read into the CSPRNG as an unpredictable seed. With every GNU/Linux operating system I can think of, this happens as part of the install, so on first boot, the kernel is already sufficiently seeded with random data. On FreeBSD, this seed is saved to "/var/db/entropy-file". On GNU/Linux, either "/var/lib/systemd/random-seed" or "/var/lib/urandom/random-seed" depending on whether or not you're using systemd. I'm not sure of NetBSD saves a seed to disk or not, as it's been many years since I've last run NetBSD seriously.

JdeBP 9y ago
The saved seed file on OpenBSD is /etc/random.seed . NetBSD has the /etc/rc.d/random_seed service, which uses the same filename as FreeBSD.