4 ms·
The problem is immediately after boot before anything has seeded the entropy pool. Like say when sshd generates host keys!
by pstrateman 11y ago
The problem is immediately after boot before anything has seeded the entropy pool.
Like say when sshd generates host keys!
- elithrar 11y ago> 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 http://man7.org/linux/man-pages/man2/getrandom.2.html - the desired behaviour.
- tangent128 11y agoWhich 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).
- AnthonyMouse 11y agoIs there any actual reason why /dev/random doesn't do that?
- ploxiln 11y agogetrandom() 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
- KMag 11y agoStubbornness 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.
- tptacek 11y agoI'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.
- anon1385 11y agoBut you keep explicitly telling people not to do this?
- ghshephard 11y agoI 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 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."
- lomnakkus 11y agoAFAICT 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.
- ben_bai 11y agoGeht 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.
- DroidX86 11y agoUmm, is there something wrong with your keyboard?