* Revised draft of random(7) man page for review
@ 2016-11-15 6:56 Michael Kerrisk (man-pages)
[not found] ` <50af97ae-e65e-30f3-c5ec-6f2129711f39-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-11-15 6:56 UTC (permalink / raw)
To: Theodore Ts'o, Laurent Georget, Nikos Mavrogiannopoulos,
Laurent Georget, Luke Bratch, Ivan Babrou,
matt-6J8q6J5oQjkQrrorzV6ljw
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Heinrich Schuchardt,
linux-man-u79uwXL29TY76Z2rM5mHXA, Thomas Hühn,
Stephan Mueller, Carl Winbäck, mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Revised draft of random(7) man page for review
[not found] ` <50af97ae-e65e-30f3-c5ec-6f2129711f39-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-11-15 15:04 ` Theodore Ts'o
[not found] ` <20161115150407.jy7ix2i6dw5nyhbk-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Theodore Ts'o @ 2016-11-15 15:04 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Laurent Georget, Nikos Mavrogiannopoulos, Laurent Georget,
Luke Bratch, Ivan Babrou, matt-6J8q6J5oQjkQrrorzV6ljw,
Heinrich Schuchardt, linux-man-u79uwXL29TY76Z2rM5mHXA,
Thomas Hühn, Stephan Mueller, Carl Winbäck,
mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Revised draft of random(7) man page for review
[not found] ` <20161115150407.jy7ix2i6dw5nyhbk-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
@ 2016-11-15 21:51 ` Michael Kerrisk (man-pages)
2016-11-19 21:39 ` Nikos Mavrogiannopoulos
1 sibling, 0 replies; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-11-15 21:51 UTC (permalink / raw)
To: Theodore Ts'o
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Laurent Georget,
Nikos Mavrogiannopoulos, Laurent Georget, Luke Bratch,
Ivan Babrou, matt-6J8q6J5oQjkQrrorzV6ljw, Heinrich Schuchardt,
linux-man-u79uwXL29TY76Z2rM5mHXA, Thomas Hühn,
Stephan Mueller, Carl Winbäck, mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Revised draft of random(7) man page for review
[not found] ` <20161115150407.jy7ix2i6dw5nyhbk-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2016-11-15 21:51 ` Michael Kerrisk (man-pages)
@ 2016-11-19 21:39 ` Nikos Mavrogiannopoulos
[not found] ` <1261638383.493623.1479591556767.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
1 sibling, 1 reply; 7+ messages in thread
From: Nikos Mavrogiannopoulos @ 2016-11-19 21:39 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Michael Kerrisk (man-pages),
Laurent Georget, Laurent Georget, Luke Bratch, Ivan Babrou,
matt-6J8q6J5oQjkQrrorzV6ljw, Heinrich Schuchardt,
linux-man-u79uwXL29TY76Z2rM5mHXA, Thomas Hühn,
Stephan Mueller, Carl Winbäck, mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ
----- 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Revised draft of random(7) man page for review
[not found] ` <1261638383.493623.1479591556767.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-11-20 9:14 ` Michael Kerrisk (man-pages)
[not found] ` <49c33335-5933-e0bd-3e5e-d51ff051425f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-11-20 9:14 UTC (permalink / raw)
To: Nikos Mavrogiannopoulos, Theodore Ts'o
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Laurent Georget,
Laurent Georget, Luke Bratch, Ivan Babrou,
matt-6J8q6J5oQjkQrrorzV6ljw, Heinrich Schuchardt,
linux-man-u79uwXL29TY76Z2rM5mHXA, Thomas Hühn,
Stephan Mueller, Carl Winbäck, mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: Revised draft of random(7) man page for review
[not found] ` <49c33335-5933-e0bd-3e5e-d51ff051425f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-11-22 10:20 ` Nikos Mavrogiannopoulos
[not found] ` <1479810045.31825.20.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Nikos Mavrogiannopoulos @ 2016-11-22 10:20 UTC (permalink / raw)
To: Michael Kerrisk (man-pages), Theodore Ts'o
Cc: Laurent Georget, Laurent Georget, Luke Bratch, Ivan Babrou,
matt-6J8q6J5oQjkQrrorzV6ljw, Heinrich Schuchardt,
linux-man-u79uwXL29TY76Z2rM5mHXA, Thomas Hühn,
Stephan Mueller, Carl Winbäck, mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Revised draft of random(7) man page for review
[not found] ` <1479810045.31825.20.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-11-22 14:04 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-11-22 14:04 UTC (permalink / raw)
To: Nikos Mavrogiannopoulos, Theodore Ts'o
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Laurent Georget,
Laurent Georget, Luke Bratch, Ivan Babrou,
matt-6J8q6J5oQjkQrrorzV6ljw, Heinrich Schuchardt,
linux-man-u79uwXL29TY76Z2rM5mHXA, Thomas Hühn,
Stephan Mueller, Carl Winbäck, mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-11-22 14:04 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-15 6:56 Revised draft of random(7) man page for review Michael Kerrisk (man-pages)
[not found] ` <50af97ae-e65e-30f3-c5ec-6f2129711f39-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-15 15:04 ` Theodore Ts'o
[not found] ` <20161115150407.jy7ix2i6dw5nyhbk-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2016-11-15 21:51 ` Michael Kerrisk (man-pages)
2016-11-19 21:39 ` Nikos Mavrogiannopoulos
[not found] ` <1261638383.493623.1479591556767.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-11-20 9:14 ` Michael Kerrisk (man-pages)
[not found] ` <49c33335-5933-e0bd-3e5e-d51ff051425f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-22 10:20 ` Nikos Mavrogiannopoulos
[not found] ` <1479810045.31825.20.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-11-22 14:04 ` Michael Kerrisk (man-pages)
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.