Hacker News Reader

Comment by pstrateman | Hacker News Reader

The problem is immediately after boot before anything has seeded the entropy pool.

Like say when sshd generates host keys!

> The problem is immediately after boot before anything has seeded the entropy pool.

With getrandom() on Linux it will block if you don't set GRND_NONBLOCK and the pool isn't initialized - http://man7.org/linux/man-pages/man2/getrandom.2.html - the desired behaviour.

Which is why the getrandom() syscall is preferred; it draws from the urandom pool, but will block until a quantity of initial entropy has been fed into the pool (ie, at early boot).

Is there any actual reason why /dev/random doesn't do that?

getrandom() has a mode where it acts fully like /dev/random - and it's for some (misguided but very important to some big businesses) security certifications

Stubbornness of Linux kernel maintainers. My understanding that your proposed behavior is the behavior on FreeBSD and OS X, and people have proposed bringing Linux in line.

I'm not sure why this is supposed to be a tricky problem. Seed urandom from /dev/random, just for the side-effect of blocking, before you generate host keys. Never use /dev/random again.

But you keep explicitly telling people not to do this?

I understand what you are saying - so I hope nobody downvotes you. I've spent hours reading the HN, and Stack Exchange stuff on this - and I think the conclusion is, "/dev/random is really bad, because it blocks, breaking all sorts of programs, and 99.99% of people who use it instead of /dev/urandom aren't getting anything that they couldn't get from /dev/urandom, except the blocking behavior. The one possible exception is on a system in which /dev/urandom hasn't yet been seeded, but there are many ways to fix that, the most straighforward of which is to seed /dev/urandom from /dev/random, and then never look at /dev/random again. Or, better yet, use http://man7.org/linux/man-pages/man2/getrandom.2.html which provides a guarantee of entropy, as well as non-blocking nature once it's been properly seeded. The only time it would ever block would be on boot-up prior to it collecting the very few (approx 256?) bits required to generate effectively endless bytes."

AFAICT to do that reliably for all applications using /dev/urandom, you'd have to insert a step blocking all applications at startup until /dev/urandom was seeded. Even applications that have no need for anything from /dev/{u,}random.

(EDIT: I suppose one might try to replace /dev/urandom with some pipe-like thing running in userspace, but that seems error prone and rather contrary to /dev just being "devices".)

[1] Without just doing it at the kernel level, which the Linux kernel developers seemingly still stubbornly refuse to do.

Geht yourself a real OS. In OpenBSD the bootloader takes care oft this. Thats good enough to geht random data right wenn the kernel starts, and by the time init runs it's gathered way more entropie.

Umm, is there something wrong with your keyboard?

Reply on news.ycombinator.com