First, an assumption: /dev/random and /dev/urandom are good CPRNGs, and the definition of a "good CPRNG" includes the ability to generate a theoretically unlimited amount of random data for daily uses. The manpage for random(4) states, in part: > The kernel random-number generator is designed to produce a small > amount of high-quality seed material to seed a cryptographic pseudo- > random number generator (CPRNG). It is designed for security, not > speed, and is poorly suited to generating large amounts of random > data. Users should be very economical in the amount of seed material > that they read from /dev/urandom (and /dev/random); unnecessarily > reading large quantities of data from this device will have a > negative impact on other users of the device. A lot developers take this paragraph as gospel, and I believe the way it is phrased "spooks" them into not trusting /dev/urandom as much as they should for daily tasks. The consequence is that they instead use OpenSSL or another user-space CPRNG instead of their kernel, or roll their own (ugh). We should clarify what "a large amount of random data" is, what being "economical" means, and what a "negative impact on other users of the device" means, and provide more specific examples of where /dev/urandom is useful. As a sounding board, is /dev/urandom acceptable for providing random bytes to assist with the following tasks? Assume I'm drawing 16 bytes on average, multiple times per second. (1) Generating numbers/nonces, etc for secure network connections (2) Generating signed cookies or session keys for a web application (3) Generating random numbers for use in games of chance References/how I ended up here: http://man7.org/linux/man-pages/man4/random.4.html http://blog.cr.yp.to/20140205-entropy.html http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://bugs.ruby-lang.org/issues/9569
For reference, I paste here an email discussion of this bug from 2015: -------- Forwarded Message -------- Subject: Re: Status for bug 71211? [random(4): clarify utility and volume] Date: Mon, 27 Jul 2015 18:34:52 +0200 From: Laurent Georget <laurent@lgeorget.eu> To: Carl Winbäck <c@tunnel53.net>, mtk.manpages@gmail.com CC: linux-man@vger.kernel.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, the text of this man page has been the subject of endless controversies for ages. CSPRNGs are confusing and the page unfortunately adds a little to the confusion. The newer getrandom(2) page is better, and I (personally, this doesn't engage Michael nor any other author) think that the random(4) page should be rewritten in the same spirit. (getrandom is a system call used to get a random number, by default, it's more or less equivalent than reading from /dev/urandom if you call it without flags and for less than 256 bytes). Compare this in random(4) > The kernel random-number generator is designed to produce a small > amount of high-quality seed material to seed a cryptographic pseudo- > random number generator (CPRNG). It is designed for security, not > speed, and is poorly suited to generating large amounts of random > data. Users should be very economical in the amount of seed material > that they read from /dev/urandom (and /dev/random); unnecessarily > reading large quantities of data from this device will have a > negative impact on other users of the device. with this in getrandom(2) > *getrandom*() relies on entropy gathered from device drivers and other > sources of environmental noise. Unnecessarily reading large > quantities of data will have a negative impact on other users of the > //dev/random/ and //dev/urandom/ devices. Therefore, *getrandom*() should > not be used for Monte Carlo simulations or other programs/algorithms > which are doing probabilistic sampling. This says exactly the same thing, but getrandom(2) is less misleading. First note that the man page for random says that /dev/urandom is "poorly suited to generating large amounts of random data", not "poorly suited to generating large amounts of *cryptographic* random data". Basically, you can use /dev/urandom for all cryptographic purposes, because you never need so many bits at once when doing cryptography. Even generating several 16-bytes (128-bits) UIDs per minute if you need them to be cryptographically secure (you may want to think about this requirement, is it strict?) is not that much. A Monte-Carlo simulation requires, say (I don't know exactly let's make a rough guess) around several MB of random numbers per minute. That's 4 or 5 orders of magnitude higher than your UIDs use case. This would be a wrong usage of /dev/urandom for two reasons: - - it would be awfully slow - - you don't need cryptographically secure random numbers, so there's no need to deplete the entropy pool. Next, compare this in random(4): > If you are unsure about whether you should use /dev/random or > /dev/urandom, then probably you want to use the latter. As a general > rule, /dev/urandom should be used for everything except long-lived > GPG/SSL/SSH keys. with this in getrandom(2): > Unless you are doing long-term key generation (and perhaps not even > then), you probably shouldn't be using GRND_RANDOM. The cryptographic > algorithms used for /dev/urandom are quite conservative, and so should > be sufficient for all purposes. The disadvantage of GRND_RANDOM is > that it can block. Furthermore, dealing with the partially fulfilled > getrandom() requests that can occur when using GRND_RANDOM increases > code complexity. Again, the two man pages say the same. getrandom(2) is more nuanced, though. To answer your question about how much you can ask /dev/urandom for : in random(4) : > if any program reads more than 256 bits (32 bytes) from the kernel random > pool per invocation, or per reasonable reseed interval (not less than > one minute), that should be taken as a sign that its cryptography is > not skillfully implemented. In getrandom(2): > Calling getrandom() to read /dev/urandom for small values (<= 256 bytes) > of buflen is the preferred mode of usage. Furthermore, it's impossible to read more than 32MB from /dev/urandom per invocation. So, actually, the random(4) page is very conservative about the reading limit. My final conclusion: as long as you use /dev/urandom for cryptographic purposes only, you should be ok, because you will never need *a lot* of random data anyway in any sensible program. For non-cryptographic usage, seed a user-space PRNG with a few bytes from /dev/urandom and you will be good. Laurent Le 26/07/2015 22:20, Carl Winbäck a écrit : > Hello Michael & Co, > > I would like to bring your attention to bug report 71211, ”random(4): > clarify utility and volume”. > > https://bugzilla.kernel.org/show_bug.cgi?id=71211 > > This report was filed over a year ago but still hasn’t received any response. > > Michael, do you have the time to take a look? > > Perhaps you, or someone else on the linux-man list, are familiar with > CSPRNGs and have some ideas on how to reword this man page? > > Unfortunately I’m not at all an expert in this area, so I’m afraid I > don’t have any specific suggestions regarding how to change this man > page. But I still think it would be helpful to the Linux community if > it could be improved, and as a result, hopefully cause less confusion > regarding getting random numbers on Linux. > > > Looking forward to hear your thoughts on this. > > Best regards, > Carl Winbäck > -- > To unsubscribe from this list: send the line "unsubscribe linux-man" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlW2XawACgkQRTidSplJch4jJQD/d4LOrShlXmQx5RClVCdj7sKL 6n7SQhlCIjfqvi86JDcA/28cCtYZ8HKL1RgWkgEjGmWoIH6ZA+AKJjgnmugk1wFj =ff9U -----END PGP SIGNATURE-----
Substantial updates have been to the latest release (4.09) of man-pages that, I believe, address the problems in this bug. See the revise random(4) page and the new random(7) page. http://man7.org/linux/man-pages/man4/random.4.html http://man7.org/linux/man-pages/man7/random.7.html I'm closing this bug. If you think there's still some unresolved issue, please reopen (wand add some detail on what problems you still see).