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:

quoted

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

quoted

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

quoted

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