-----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@xxxxxxxxxxxxxxx > 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----- -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
