Hell Ted, On 11/15/2016 04:04 PM, Theodore Ts'o wrote: > On Tue, Nov 15, 2016 at 07:56:09AM +0100, Michael Kerrisk (man-pages) wrote: >> * The Linux-specific getrandom(2) system call, available since >> Linux 3.17. This system call provides access either to the >> same source as /dev/urandom (called the urandom source in >> this page) or to the same source as /dev/random (called the >> random source in this page). The default is the urandom >> source; the random source is selected by specifying the >> GRND_RANDOM flag to the system call. >> .... >> Choice of random device >> Unless you are doing long-term key generation (and most likely >> not even then), you probably shouldn't be using the /dev/random >> device or getrandom(2) with the GRND_RANDOM flag. >> > > Given the definition earlier, maybe the title of this section should > be called "Choice of random source?" Yes. Fixed. >> Usage recommendations >> The kernel random-number generator relies on entropy gathered >> from device drivers and other sources of environmental noise. >> It is designed to produce a small amount of high-quality seed >> material to seed a cryptographically secure pseudorandom number >> generator (CSPRNG). It is designed for security, not speed, >> and is poorly suited to generating large amounts of crypto‐ >> graphic random data. Users should be economical in the amount >> of seed material that they consume via getrandom(2), /dev/uran‐ >> dom, and /dev/random. >> >> ┌─────────────────────────────────────────────────────┐ >> │FIXME │ >> ├─────────────────────────────────────────────────────┤ >> │Is it really necessary to avoid consuming large │ >> │amounts from /dev/urandom? Various sources linked to │ >> │by https://bugzilla.kernel.org/show_bug.cgi?id=71211 │ >> │suggest it is not. │ >> │ │ >> │And: has the answer to the previous question changed │ >> │across kernel versions? │ >> └─────────────────────────────────────────────────────┘ >> Consuming unnecessarily large quantities of data via these >> interfaces will have a negative impact on other consumers of >> randomness. > > So "poorly suited" is definitely true. Also true is that urandom is > not engineered for use for non-cryptographic uses. It's always going > to be faster to use random(3) for those purposes. > > As far as whether or not it has a negative impact, it depends on how > much you trust the underlying cryptographic algorithms. If the CSPRNG > is seeded correctly with at least 256 bits of entropy that can't be > guessed by the attacker, and if the underlying cryptographic > primitives are secure, then it won't matter. But *if* there is an > unknown vulnerability in the underlying primitive, and *if* large > amounts of data generated by the CSPRNG would help exploit that > vulnerability, and *if* that bulk amount of CSPRNG output is made > available to an attacker with the capability to break the underlying > cryptographic vulnerability, then there would be a problem. > > Obviously, no one knows of such a vulnerability, and I'm fairly > confident that there won't be such a vulnerability across the > different ways we've used to generate the urandom source --- but some > people are professional paranoids, and would argue that we shouldn't > make bulk output of the CSPRNG available for no good reason, just in > case. So, is it necessary to keep the statement about avoiding consuming large amounts from the random / urandom / getrandom()? >> ┌─────────────────────────────────────────────────────┐ >> │FIXME │ >> ├─────────────────────────────────────────────────────┤ >> │Above: we need to define "negative impact". Is the │ >> │only negative impact that we may slow readers of │ >> │/dev/random, since it will block until sufficient │ >> │entropy has once more accumulated? │ >> │ │ >> │And: has the answer to the previous question changed │ >> │across kernel versions? │ >> └─────────────────────────────────────────────────────┘ > > This answer has changed across kernel versions. As of the changes > made in the 4.8 kernel and newer, we reseed the urandom pool every > five minutes (if it is in use) so it doesn't matter whether you draw > one byte or one gigabyte from the urandom source; it won't slow down > readers of the random source. > > Between 3.13 and 4.8, we cap the number of times that entropy that > will be pulled from /dev/random to once every 60 seconds, so it > mattered a bit more, but it wouldn't significantly slow down readers > from /dev/random. > > Before 3.13, it would significantly slow down readers of /dev/random > if you were pulling from /dev/urandom even by moderate amounts (for > example, by the Chrome browser, which is using /dev/urandom for > session keys for all TLS connections --- and a Chrome browser > typically opens lots of TLS connections as you browse the web). So, keep the existing man page text, or rework, do you think? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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
