Hello Nikos, On 11/19/2016 10:39 PM, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- >>> 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. > > The above is certainly accurate, however, I think that such a > discussion or text, when reflected to a man-page is going to cause > problems. The audience of a man-page are not crypto people, and > seeing such text would create confusion rather than clarify how these > devices/apis should be used. The *if* part is not put into a > perspective, suggesting that such an *if* is possible. However, if > one clarifies, i.e., in that case, your TLS or SSH connection is most > likely broken as well, and not because of any attack on /dev/urandom, > then one can see that we are heading towards a theoretical > discussion. > > My suggestion, on that particular text would be to remove it, but > make it explicit somewhere in the text that all the assurances for > the devices depend on the crypto primitives, rather than describing > risks that may arise on particular usage patterns *if* primitives are > broken. Thanks. This makes sense to me. Following your suggestion, I plan to apply the patch below. Does it seem okay to you? Cheers, Michael diff --git a/man7/random.7 b/man7/random.7 index 9e020ff..35fd9f2 100644 --- a/man7/random.7 +++ b/man7/random.7 @@ -29,8 +29,12 @@ .SH NAME random \- overview of interfaces for obtaining randomness .SH DESCRIPTION -The kernel provides the following interfaces to the kernel's -cryptographically secure pseudorandom number generator (CSPRNG): +The kernel random-number generator relies on entropy gathered from +device drivers and other sources of environmental noise to seed +a cryptographically secure pseudorandom number generator (CSPRNG). +It is designed for security, rather than speed. + +The following interfaces provide access to output from the kernel CSPRNG: .IP * 3 The .I /dev/urandom @@ -98,44 +102,15 @@ or when reading from .I /dev/random increases code complexity. .\" -.SS 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 cryptographic random data. -Users should be economical in the amount of seed -material that they consume via -.BR getrandom (2), -.IR /dev/urandom , -and -.IR /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. -.\" 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? - -These interfaces should not be used to provide large quantities -of data for Monte Carlo simulations or other -programs/algorithms which are doing probabilistic sampling. -Indeed, such usage will be slow, and is unnecessary, -because such applications do not need crytographically secure random numbers. -Instead, use these interfaces to provide a small amount of -data used to seed a user-space pseudorandom number generator -for use by such applications. +.SS Monte Carlo and other probabalistic sampling applications +Using these interfaces to provide large quantities of data for +Monte Carlo simulations or other programs/algorithms which are +doing probabilistic sampling will be slow. +Furthermore, it is unnecessary, because such applications do not +need cryptographically secure random numbers. +Instead, use the interfaces described in this page to obtain +a small amount of data to seed a user-space pseudorandom +number generator for use by such applications. .\" .SS Comparison between getrandom, /dev/urandom, and /dev/random The following table summarizes the behavior of the various -- 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
