3 ms·

Here's a writeup of a serious security flaw traced directly to the use of /dev/urandom instead of /dev/random: https://factorable.net/ https://factorable.net/

by rst 11y ago

Here's a writeup of a serious security flaw traced directly to the use of /dev/urandom instead of /dev/random: https://factorable.net/ https://factorable.net/ In brief, wifi routers need to generate unique crypto keys. The programmers started off using /dev/random, observed that blocking, and switched to /dev/urandom. The problem was that they were generating the keys at first boot, before any entropy had accumulated, with the result that many, many devices wound up with similar or identical keys.

derefr 11y ago
Pedantic version, then: use /dev/urandom unless your software is itself part of the OS's boot sequence.
- comex 11y ago
  What is the definition of "part of the OS's boot sequence"? In the factorable.net paper[1], a test system didn't generate 192 bits of entropy until 66 seconds(!) after boot. The problem was apparently exacerbated by Linux not mixing the entropy into the /dev/urandom pool at all until that threshold was reached, but even if it started doing so immediately, standard server processes like ssh would still start up long before there was enough entropy to make urandom sufficiently unpredictable. Sure, this is something of an extreme case... and as mentioned in the paper, there are various tools used on Linux to save a random seed to disk, so maybe the OS should ensure that happens before it starts any other services... but software that responds to an easy-to-make configuration mistake by silently behaving insecurely is the polar opposite of good security design. The right answer is Linux's new getrandom syscall, whose default mode "blocks if the entropy pool has not yet been initialized", but thereafter acts like /dev/urandom. But on systems where that syscall is not available, I'm skeptical that using /dev/urandom is sane design. [1] https://factorable.net/weakkeys12.conference.pdf https://factorable.net/weakkeys12.conference.pdf
  - derefr 11y ago
    Yes, getrandom(3) is good. It's just a patch for a broken architecture, though; the right answer, architecturally, is that userland services (like sshd) should not be started at all until /dev/urandom has been seeded. To put it another way: /dev/urandom is effectively a service that can be in a "starting" or "started" state. When you, as a service, depend on another service, the idiomatic thing to do is to teach your init/supervisor daemon about that dependency. Then, instead of your service coming up and sitting around doing voodoo to your pipes/sockets to try to figure out whether your dependencies are up, your supervisor can just delay starting your service until it knows the dependent service is up. (Or, to get really clever about it, you could just make /dev/urandom itself a socket attached to a "service" whose job is to, on startup, do a blocking-seed of the "real" /dev/urandom device, and thereafter become a dumb pipe over to the "real" /dev/urandom device. Then all your services just block on reading /dev/urandom [the socket] the first time, with the first one of them to try reading from it in fact causing the reseeding to happen. Socket activation!)
    - abortz 11y ago
      No need to get clever about it, or rather it's already been done. ;-) Except for the reseeding bit, getrandom() does that for you by default: blocks if /dev/urandom hasn't been seeded yet. At least according to the man page.

by rst 11y ago

derefr 11y ago

Pedantic version, then: use /dev/urandom unless your software is itself part of the OS's boot sequence.

comex 11y ago
What is the definition of "part of the OS's boot sequence"? In the factorable.net paper[1], a test system didn't generate 192 bits of entropy until 66 seconds(!) after boot. The problem was apparently exacerbated by Linux not mixing the entropy into the /dev/urandom pool at all until that threshold was reached, but even if it started doing so immediately, standard server processes like ssh would still start up long before there was enough entropy to make urandom sufficiently unpredictable. Sure, this is something of an extreme case... and as mentioned in the paper, there are various tools used on Linux to save a random seed to disk, so maybe the OS should ensure that happens before it starts any other services... but software that responds to an easy-to-make configuration mistake by silently behaving insecurely is the polar opposite of good security design. The right answer is Linux's new getrandom syscall, whose default mode "blocks if the entropy pool has not yet been initialized", but thereafter acts like /dev/urandom. But on systems where that syscall is not available, I'm skeptical that using /dev/urandom is sane design. [1] https://factorable.net/weakkeys12.conference.pdf https://factorable.net/weakkeys12.conference.pdf
- derefr 11y ago
  Yes, getrandom(3) is good. It's just a patch for a broken architecture, though; the right answer, architecturally, is that userland services (like sshd) should not be started at all until /dev/urandom has been seeded. To put it another way: /dev/urandom is effectively a service that can be in a "starting" or "started" state. When you, as a service, depend on another service, the idiomatic thing to do is to teach your init/supervisor daemon about that dependency. Then, instead of your service coming up and sitting around doing voodoo to your pipes/sockets to try to figure out whether your dependencies are up, your supervisor can just delay starting your service until it knows the dependent service is up. (Or, to get really clever about it, you could just make /dev/urandom itself a socket attached to a "service" whose job is to, on startup, do a blocking-seed of the "real" /dev/urandom device, and thereafter become a dumb pipe over to the "real" /dev/urandom device. Then all your services just block on reading /dev/urandom [the socket] the first time, with the first one of them to try reading from it in fact causing the reseeding to happen. Socket activation!)
  - abortz 11y ago
    No need to get clever about it, or rather it's already been done. ;-) Except for the reseeding bit, getrandom() does that for you by default: blocks if /dev/urandom hasn't been seeded yet. At least according to the man page.