Hacker News Reader

Comment by ordinary | Hacker News Reader

It's not missing:

Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.

I invite you to read the article, because there's more.

View on HN

Yes, I did read it.

But my key point is that urandom can fail silently. /dev/random create an assertion that there is enough entropy, which is a useful assertion to do until there are guaranties from urandom of the same.

But the entropy estimates are spurious, which means /dev/random can easily fail silently. This is the whole motivation behind Bruce Schneier and Niels Ferguson developing the Fortuna algorithm. Yarrow relied upon entropy estimates to recover from state compromise. With Fortuna, you don't know how long it will take to recover from state compromise (since it's difficult to reliably estimate entropy), but you know it eventually will happen.

Also note that most POSIX systems will cat a random seed file into /dev/random at startup and save entropy from /dev/urandom to the seed file at shutdown (and also hopefully right after adding to the entropy pool at startup). As long as an attacker doesn't have access to the disk or root permissions on the host, insufficient entropy should only be a problem the first time a host boots after install, presuming it gathers enough entropy after first boot.

FreeBSD and OSX use Yarrow for /dev/random and /dev/urandom, with absolutely no difference in behavior between /dev/random and /dev/urandom. I'd like to see Linux adopt Fortuna and make /dev/random non-blocking, though I can see the case being made for making /dev/random block after each boot until the estimated pooled entropy first goes above some threshold.

What happens with live-cd's on a read-only media? What about disk-less/thin clients? What about image restoration from backup? In each of those cases, the seed will either not be there or identical for each boot.

I would like to see a smarter /dev/urandom which asserts that there is enough fresh entropy. It would increase the trust of using it, and would put /dev/random usage in the special category of one-time pads. Until then, each case which the saved seed can cause issues with will have to be addressed if one choose to use /dev/urandom.

/dev/random should not be used for one-time pads. It's still generated from a stream cipher-based CSPRNG and is not "true" randomness.

And the cost for that warm fuzzy feeling is that your program will randomly lock up when /dev/random convinces itself that it's "out of entropy" (which again is a nonsensical idea).

Note also that the only time urandom fails is on first boot. Linux distributions save seeds between boots, so your second and subsequent boots don't have this problem.

And what happens if that seed restoration fails or happens too late? You're now relying on the userspace code in the distribution being correct.

You very much already rely on that.

You are right, 'belorn, that's an important point.

This really only comes up in VM settings and some small embedded systems, I think.

I have made a mental note to see if I can find a way to make this section a bit more prominent.

Reply on news.ycombinator.com