Revised draft of random(7) man page for review

Revised draft of random(7) man page for review

[Michael Kerrisk (man-pages)]

[-- Attachment #1: Type: text/plain, Size: 11639 bytes --]

Hello all,

Here's one more draft of the random(7) man page for review. I wanted to 
recirculate this one more time, because I came up with  couple of
questions (shown in FIXMEs below). 

Ted, I'd be especially happy if you could take a look at those questions, 
but I also welcome any input from others, as well as any further comments
on the remainder of the page.

Rendered version of the page is below; source is attached.

Cheers,

Michael


RANDOM(7)              Linux Programmer's Manual             RANDOM(7)

NAME
       random - overview of interfaces for obtaining randomness

DESCRIPTION
       The  kernel  provides  the following interfaces to the kernel's
       cryptographically   secure   pseudorandom   number    generator
       (CSPRNG):

       *  The  /dev/urandom and /dev/random devices, both described in
          random(4).  These devices have been present on  Linux  since
          early times, and are also available on many other systems.

       *  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.

   Initialization of the entropy pool
       The kernel collects bits of entropy from the environment.  When
       a sufficient number of random  bits  has  been  collected,  the
       entropy pool is considered to be initialized.

   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.

       Instead,  use  either  the  /dev/urandom device or getrandom(2)
       without the GRND_RANDOM  flag.   The  cryptographic  algorithms
       used  for  the  urandom  source  are quite conservative, and so
       should be sufficient for all purposes.

       The disadvantage of GRND_RANDOM and reads from  /dev/random  is
       that  the operation can block for an indefinite period of time.
       Furthermore, dealing with the partially fulfilled requests that
       can occur when using GRND_RANDOM or when reading from /dev/ran‐
       dom increases code complexity.

   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.


       ┌─────────────────────────────────────────────────────┐
       │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/algo‐
       rithms which are doing probabilistic  sampling.   Indeed,  such
       usage  will  be slow, and is unnecessary, because such applica‐
       tions 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.

   Comparison between getrandom, /dev/urandom, and /dev/random
       The  following  table  summarizes  the  behavior of the various
       interfaces that can be used to  obtain  randomness.   GRND_NON‐
       BLOCK is a flag that can be used to control the blocking behav‐
       ior of getrandom(2).  The final column of the  table  considers
       the  case  that  can  occur in early boot time when the entropy
       pool is not yet initialized.

       ┌──────────────┬──────────────┬────────────────┬────────────────────┐
       │Interface     │ Pool         │ Blocking       │ Behavior when pool │
       │              │              │ behavior       │ is not yet ready   │
       ├──────────────┼──────────────┼────────────────┼────────────────────┤
       │/dev/random   │ Blocking     │ If entropy too │ Blocks until       │
       │              │ pool         │ low, blocks    │ enough entropy     │
       │              │              │ until there is │ gathered           │
       │              │              │ enough entropy │                    │
       │              │              │ again          │                    │
       ├──────────────┼──────────────┼────────────────┼────────────────────┤
       │/dev/urandom  │ CSPRNG out‐  │ Never blocks   │ Returns output     │
       │              │ put          │                │ from uninitialized │
       │              │              │                │ CSPRNG (may be low │
       │              │              │                │ entropy and        │
       │              │              │                │ unsuitable for     │
       │              │              │                │ cryptography)      │
       ├──────────────┼──────────────┼────────────────┼────────────────────┤
       │getrandom()   │ Same as      │ Does not block │ Blocks until pool  │
       │              │ /dev/urandom │ once is pool   │ ready              │
       │              │              │ ready          │                    │
       ├──────────────┼──────────────┼────────────────┼────────────────────┤
       │getrandom()   │ Same as      │ If entropy too │ Blocks until pool  │
       │GRND_RANDOM   │ /dev/random  │ low, blocks    │ ready              │
       │              │              │ until there is │                    │
       │              │              │ enough entropy │                    │
       │              │              │ again          │                    │
       ├──────────────┼──────────────┼────────────────┼────────────────────┤
       │getrandom()   │ Same as      │ Does not block │ EAGAIN             │
       │GRND_NONBLOCK │ /dev/urandom │ once is pool   │                    │
       │              │              │ ready          │                    │
       ├──────────────┼──────────────┼────────────────┼────────────────────┤
       │getrandom()   │ Same as      │ EAGAIN if not  │ EAGAIN             │
       │GRND_RANDOM + │ /dev/random  │ enough entropy │                    │
       │GRND_NONBLOCK │              │ available      │                    │
       └──────────────┴──────────────┴────────────────┴────────────────────┘
   Generating cryptographic keys
       The  amount  of  seed  material  required to generate a crypto‐
       graphic key equals the effective key  size  of  the  key.   For
       example,  a  3072-bit  RSA or Diffie-Hellman private key has an
       effective key size of 128 bits (it requires about 2^128  opera‐
       tions  to  break)  so  a  key generator needs only 128 bits (16
       bytes) of seed material from /dev/random.

       While some safety margin above that minimum is reasonable, as a
       guard  against  flaws in the CSPRNG algorithm, no cryptographic
       primitive available today can hope to  promise  more  than  256
       bits  of  security,  so 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  skill‐
       fully implemented.

SEE ALSO
       getrandom(2), random(4), urandom(4), signal(7)

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[-- Attachment #2: random.7 --]
[-- Type: application/x-troff-man, Size: 7381 bytes --]

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

[Theodore Ts'o]

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?"

>    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.

>        ┌─────────────────────────────────────────────────────┐
>        │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).

	  	     	    		       - Ted
--
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

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

[Michael Kerrisk (man-pages)]

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

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

[Nikos Mavrogiannopoulos]

----- 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. 

regards,
Nikos
--
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

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

[Michael Kerrisk (man-pages)]

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

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

[Nikos Mavrogiannopoulos]

On Sun, 2016-11-20 at 10:14 +0100, Michael Kerrisk (man-pages) wrote:
> Hello Nikos,

> > > 
> > > 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?

Looks fine to me.

regards,
Nikos

--
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

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

[Michael Kerrisk (man-pages)]

Hello Nikos,

On 11/22/2016 11:20 AM, Nikos Mavrogiannopoulos wrote:
> On Sun, 2016-11-20 at 10:14 +0100, Michael Kerrisk (man-pages) wrote:

>> Thanks. This makes sense to me. Following your suggestion, 
>> I plan to apply the patch below. Does it seem okay to you?
> 
> Looks fine to me.

Thanks for checking, and thanks for all the other help.
I think we're done with this page for now.

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