Re: Revised draft of random(7) man page for review

["Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html