LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

random.7: Remove recommendation against consuming large amounts of randomness 

From the email discussion:

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

[Ted T'so:]

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

[Nikos Mavrogiannopoulos:]

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.

Reviewed-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
Reported-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2016-11-20 10:03:52 +01:00
parent c835f0e088
commit 289b177f0f
1 changed files with 15 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
man7/random.7
View File

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