6 ms·

The challenge of "randomness" is overlooked and leads to security issues more than most people realize. For example in php, the `rand()` function documentation

• admax88q 11y ago
  Use /dev/urandom, not /dev/random. There are no security concerns with /dev/urandom
  • jzd 11y ago
    this. also /dev/random blocks and it can be really slow
  • 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!)
          • 11y ago
• rspeer 11y ago
  That blog post is old and inaccurate. It propagates myths about CSPRNGs that some have been trying to dispel, particularly Thomas Hühn [1] and djb [2]. /dev/urandom is the same cryptographically secure PRNG as /dev/random, except that /dev/random will superstitiously block when it thinks entropy has been "consumed". (CSPRNGs do not meaningfully "consume" entropy.) If you use /dev/random for the mythical warm fuzzies, you might also be misunderstanding other things. Don't be superstitious. Use /dev/urandom. [1] http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/ [2] http://www.mail-archive.com/cryptography@randombit.net/msg04763.html http://www.mail-archive.com/cryptography@randombit.net/msg04...
  • gizmo686 11y ago
    If the system has not gathered any entropy, then /dev/random/ will output predictable numbers. You are consuming random numbers does not meaningfully consume entropy [0]. However, if you try to consume a random number before the system has generated entropy in the first place, then /dev/random will still happily give you non random numbers. Most desktop/servers will store entropy between boots, so this is mostly an issue for embeded to worry about, but still worth keeping in mind. [0] Technically, it is correct to say that we do consume entropy in an information theoretic sense. However, this is not particularly revelent, as the CSPRNG is still (believed to be) secure in a complexity theoretic sense. If it turns out that the CSPRNG is not secure in a complexity theoretic sense, then we have bigger issues to worry about then a broken RNG.
    • rspeer 11y ago
      This is a case that the pages I linked cover. Also, you mixed up random and urandom, but no matter. People should not code for the case where their distribution's boot sequence totally fucks up.
    • Too 11y ago
      I've seen virtual machines having huge problems with entropy speed for random also, it's not just an issue for embedded.