2016-11-11 21:23:39 +00:00
|
|
|
.\" Copyright (C) 2008, George Spelvin <linux@horizon.com>,
|
|
|
|
.\" and Copyright (C) 2008, Matt Mackall <mpm@selenic.com>
|
|
|
|
.\" and Copyright (C) 2016, Laurent Georget <laurent.georget@supelec.fr>
|
|
|
|
.\" and Copyright (C) 2016, Nikos Mavrogiannopoulos <nmav@redhat.com>
|
|
|
|
.\"
|
|
|
|
.\" %%%LICENSE_START(VERBATIM)
|
|
|
|
.\" Permission is granted to make and distribute verbatim copies of this
|
|
|
|
.\" manual provided the copyright notice and this permission notice are
|
|
|
|
.\" preserved on all copies.
|
|
|
|
.\"
|
|
|
|
.\" Permission is granted to copy and distribute modified versions of
|
|
|
|
.\" this manual under the conditions for verbatim copying, provided that
|
|
|
|
.\" the entire resulting derived work is distributed under the terms of
|
|
|
|
.\" a permission notice identical to this one.
|
|
|
|
.\"
|
|
|
|
.\" Since the Linux kernel and libraries are constantly changing, this
|
|
|
|
.\" manual page may be incorrect or out-of-date. The author(s) assume.
|
|
|
|
.\" no responsibility for errors or omissions, or for damages resulting.
|
|
|
|
.\" from the use of the information contained herein. The author(s) may.
|
|
|
|
.\" not have taken the same level of care in the production of this.
|
|
|
|
.\" manual, which is licensed free of charge, as they might when working.
|
|
|
|
.\" professionally.
|
|
|
|
.\"
|
|
|
|
.\" Formatted or processed versions of this manual, if unaccompanied by
|
|
|
|
.\" the source, must acknowledge the copyright and authors of this work.
|
|
|
|
.\" %%%LICENSE_END
|
|
|
|
.\"
|
2016-11-22 14:02:56 +00:00
|
|
|
.\" The following web page is quite informative:
|
|
|
|
.\" http://www.2uo.de/myths-about-urandom/
|
|
|
|
.\"
|
add_key.2, execve.2, fork.2, fsync.2, getrandom.2, getrlimit.2, getxattr.2, inotify_add_watch.2, ioctl.2, ioctl_fat.2, kcmp.2, keyctl.2, link.2, listxattr.2, lseek.2, madvise.2, mincore.2, mlock.2, nanosleep.2, poll.2, posix_fadvise.2, read.2, readv.2, recv.2, request_key.2, select.2, send.2, setxattr.2, sigaction.2, stat.2, statfs.2, syscall.2, tkill.2, truncate.2, unlink.2, vfork.2, write.2, __ppc_set_ppr_med.3, aio_suspend.3, backtrace.3, bcmp.3, bcopy.3, bzero.3, exec.3, fopen.3, fts.3, ftw.3, getline.3, getmntent.3, getopt.3, memccpy.3, memchr.3, memcmp.3, memcpy.3, memfrob.3, memmem.3, memmove.3, memset.3, random.3, random_r.3, resolver.3, scandir.3, scanf.3, sem_post.3, sem_wait.3, setjmp.3, sleep.3, strerror.3, strverscmp.3, system.3, random.4, core.5, intro.5, resolv.conf.5, slabinfo.5, environ.7, ip.7, keyrings.7, man.7, persistent-keyring.7, pipe.7, process-keyring.7, random.7, session-keyring.7, signal-safety.7, signal.7, thread-keyring.7, unix.7, user-keyring.7, user-session-keyring.7, ld.so.8: tstamp
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2017-03-13 20:14:49 +00:00
|
|
|
.TH RANDOM 7 2017-03-13 "Linux" "Linux Programmer's Manual"
|
2016-11-11 21:23:39 +00:00
|
|
|
.SH NAME
|
|
|
|
random \- overview of interfaces for obtaining randomness
|
|
|
|
.SH DESCRIPTION
|
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>
2016-11-20 09:03:52 +00:00
|
|
|
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.
|
aio.7, arp.7, attributes.7, boot.7, cgroups.7, cpuset.7, credentials.7, fanotify.7, fifo.7, glob.7, hier.7, hostname.7, icmp.7, inode.7, inotify.7, keyrings.7, libc.7, mailaddr.7, mount_namespaces.7, mq_overview.7, nptl.7, numa.7, path_resolution.7, persistent-keyring.7, pid_namespaces.7, pipe.7, pkeys.7, process-keyring.7, pthreads.7, pty.7, random.7, sched.7, sem_overview.7, session-keyring.7, shm_overview.7, signal-safety.7, signal.7, spufs.7, standards.7, symlink.7, termio.7, thread-keyring.7, time.7, unicode.7, user-keyring.7, user-session-keyring.7, user_namespaces.7, utf-8.7, xattr.7: ffix
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2017-08-17 22:59:04 +00:00
|
|
|
.PP
|
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>
2016-11-20 09:03:52 +00:00
|
|
|
The following interfaces provide access to output from the kernel CSPRNG:
|
2016-11-11 21:23:39 +00:00
|
|
|
.IP * 3
|
|
|
|
The
|
|
|
|
.I /dev/urandom
|
|
|
|
and
|
|
|
|
.I /dev/random
|
|
|
|
devices, both described in
|
|
|
|
.BR random (4).
|
2016-11-15 06:18:08 +00:00
|
|
|
These devices have been present on Linux since early times,
|
|
|
|
and are also available on many other systems.
|
2016-11-11 21:23:39 +00:00
|
|
|
.IP *
|
2016-11-15 06:18:08 +00:00
|
|
|
The Linux-specific
|
2016-11-11 21:23:39 +00:00
|
|
|
.BR getrandom (2)
|
|
|
|
system call, available since Linux 3.17.
|
|
|
|
This system call provides access either to the same source as
|
|
|
|
.I /dev/urandom
|
|
|
|
(called the
|
|
|
|
.I urandom
|
2016-11-11 21:36:09 +00:00
|
|
|
source in this page)
|
2016-11-11 21:23:39 +00:00
|
|
|
or to the same source as
|
|
|
|
.I /dev/random
|
|
|
|
(called the
|
|
|
|
.I random
|
2016-11-11 21:36:09 +00:00
|
|
|
source in this page).
|
2016-11-11 21:23:39 +00:00
|
|
|
The default is the
|
|
|
|
.I urandom
|
2016-12-12 09:47:17 +00:00
|
|
|
source; the
|
2016-11-11 21:23:39 +00:00
|
|
|
.I random
|
2016-11-11 21:36:09 +00:00
|
|
|
source is selected by specifying the
|
2016-11-11 21:23:39 +00:00
|
|
|
.BR GRND_RANDOM
|
|
|
|
flag to the system call.
|
2017-01-22 22:31:38 +00:00
|
|
|
(The
|
|
|
|
.BR getentropy (3)
|
|
|
|
function provides a slightly more portable interface on top of
|
|
|
|
.BR getrandom (2).)
|
2016-11-11 21:23:39 +00:00
|
|
|
.\"
|
|
|
|
.SS 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.
|
2016-11-15 21:14:52 +00:00
|
|
|
.SS Choice of random source
|
2016-11-12 12:19:10 +00:00
|
|
|
Unless you are doing long-term key generation (and most likely not even
|
2016-11-19 10:26:10 +00:00
|
|
|
then), you probably shouldn't be reading from the
|
2016-11-15 05:57:51 +00:00
|
|
|
.IR /dev/random
|
2016-11-19 10:26:10 +00:00
|
|
|
device or employing
|
2016-11-11 21:23:39 +00:00
|
|
|
.BR getrandom (2)
|
|
|
|
with the
|
|
|
|
.BR GRND_RANDOM
|
2016-11-15 05:57:51 +00:00
|
|
|
flag.
|
2016-11-19 10:26:10 +00:00
|
|
|
Instead, either read from the
|
2016-11-15 05:57:51 +00:00
|
|
|
.IR /dev/urandom
|
2016-11-19 10:26:10 +00:00
|
|
|
device or employ
|
2016-11-11 21:23:39 +00:00
|
|
|
.BR getrandom (2)
|
|
|
|
without the
|
|
|
|
.B GRND_RANDOM
|
2016-11-15 05:57:51 +00:00
|
|
|
flag.
|
2016-11-11 21:23:39 +00:00
|
|
|
The cryptographic algorithms used for the
|
|
|
|
.IR urandom
|
2016-11-11 21:36:09 +00:00
|
|
|
source are quite conservative, and so should be sufficient for all purposes.
|
aio.7, arp.7, attributes.7, boot.7, cgroups.7, cpuset.7, credentials.7, fanotify.7, fifo.7, glob.7, hier.7, hostname.7, icmp.7, inode.7, inotify.7, keyrings.7, libc.7, mailaddr.7, mount_namespaces.7, mq_overview.7, nptl.7, numa.7, path_resolution.7, persistent-keyring.7, pid_namespaces.7, pipe.7, pkeys.7, process-keyring.7, pthreads.7, pty.7, random.7, sched.7, sem_overview.7, session-keyring.7, shm_overview.7, signal-safety.7, signal.7, spufs.7, standards.7, symlink.7, termio.7, thread-keyring.7, time.7, unicode.7, user-keyring.7, user-session-keyring.7, user_namespaces.7, utf-8.7, xattr.7: ffix
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2017-08-17 22:59:04 +00:00
|
|
|
.PP
|
2016-11-11 21:23:39 +00:00
|
|
|
The disadvantage of
|
|
|
|
.B GRND_RANDOM
|
|
|
|
and reads from
|
|
|
|
.I /dev/random
|
2016-11-15 06:18:08 +00:00
|
|
|
is that the operation can block for an indefinite period of time.
|
2016-11-11 21:23:39 +00:00
|
|
|
Furthermore, dealing with the partially fulfilled
|
|
|
|
requests that can occur when using
|
|
|
|
.B GRND_RANDOM
|
|
|
|
or when reading from
|
|
|
|
.I /dev/random
|
|
|
|
increases code complexity.
|
|
|
|
.\"
|
2016-11-27 13:34:03 +00:00
|
|
|
.SS Monte Carlo and other probabilistic sampling applications
|
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>
2016-11-20 09:03:52 +00:00
|
|
|
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.
|
2016-11-11 21:23:39 +00:00
|
|
|
.\"
|
|
|
|
.SS 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.
|
|
|
|
.B GRND_NONBLOCK
|
|
|
|
is a flag that can be used to control the blocking behavior of
|
|
|
|
.BR getrandom (2).
|
2016-11-15 06:40:35 +00:00
|
|
|
The final column of the table considers the case that can occur
|
|
|
|
in early boot time when the entropy pool is not yet initialized.
|
2016-11-11 21:23:39 +00:00
|
|
|
.ad l
|
|
|
|
.TS
|
|
|
|
allbox;
|
2016-11-15 06:40:35 +00:00
|
|
|
lbw13 lbw12 lbw14 lbw18
|
2016-11-11 21:23:39 +00:00
|
|
|
l l l l.
|
|
|
|
Interface Pool T{
|
|
|
|
Blocking
|
|
|
|
\%behavior
|
|
|
|
T} T{
|
2016-11-15 06:40:35 +00:00
|
|
|
Behavior when pool is not yet ready
|
2016-11-11 21:23:39 +00:00
|
|
|
T}
|
|
|
|
T{
|
|
|
|
.I /dev/random
|
|
|
|
T} T{
|
|
|
|
Blocking pool
|
|
|
|
T} T{
|
2016-11-12 22:00:40 +00:00
|
|
|
If entropy too low, blocks until there is enough entropy again
|
2016-11-11 21:23:39 +00:00
|
|
|
T} T{
|
|
|
|
Blocks until enough entropy gathered
|
|
|
|
T}
|
|
|
|
T{
|
|
|
|
.I /dev/urandom
|
|
|
|
T} T{
|
|
|
|
CSPRNG output
|
|
|
|
T} T{
|
|
|
|
Never blocks
|
|
|
|
T} T{
|
|
|
|
Returns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)
|
|
|
|
T}
|
|
|
|
T{
|
|
|
|
.BR getrandom ()
|
|
|
|
T} T{
|
|
|
|
Same as
|
|
|
|
.I /dev/urandom
|
|
|
|
T} T{
|
2016-11-15 06:40:35 +00:00
|
|
|
Does not block once is pool ready
|
2016-11-11 21:23:39 +00:00
|
|
|
T} T{
|
|
|
|
Blocks until pool ready
|
|
|
|
T}
|
|
|
|
T{
|
|
|
|
.BR getrandom ()
|
|
|
|
.B GRND_RANDOM
|
|
|
|
T} T{
|
|
|
|
Same as
|
|
|
|
.I /dev/random
|
|
|
|
T} T{
|
2016-11-12 22:00:40 +00:00
|
|
|
If entropy too low, blocks until there is enough entropy again
|
2016-11-11 21:23:39 +00:00
|
|
|
T} T{
|
|
|
|
Blocks until pool ready
|
|
|
|
T}
|
|
|
|
T{
|
|
|
|
.BR getrandom ()
|
|
|
|
.B GRND_NONBLOCK
|
|
|
|
T} T{
|
|
|
|
Same as
|
|
|
|
.I /dev/urandom
|
|
|
|
T} T{
|
2016-11-15 06:40:35 +00:00
|
|
|
Does not block once is pool ready
|
2016-11-11 21:23:39 +00:00
|
|
|
T} T{
|
|
|
|
.B EAGAIN
|
|
|
|
T}
|
|
|
|
T{
|
|
|
|
.BR getrandom ()
|
|
|
|
.B GRND_RANDOM
|
|
|
|
+
|
|
|
|
.B GRND_NONBLOCK
|
|
|
|
T} T{
|
|
|
|
Same as
|
|
|
|
.I /dev/random
|
|
|
|
T} T{
|
|
|
|
.B EAGAIN
|
|
|
|
if not enough entropy available
|
|
|
|
T} T{
|
|
|
|
.B EAGAIN
|
|
|
|
T}
|
|
|
|
.TE
|
|
|
|
.ad
|
|
|
|
.\"
|
|
|
|
.SS Generating cryptographic keys
|
|
|
|
The amount of seed material required to generate a cryptographic 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 operations to break) so a key generator
|
|
|
|
needs only 128 bits (16 bytes) of seed material from
|
|
|
|
.IR /dev/random .
|
aio.7, arp.7, attributes.7, boot.7, cgroups.7, cpuset.7, credentials.7, fanotify.7, fifo.7, glob.7, hier.7, hostname.7, icmp.7, inode.7, inotify.7, keyrings.7, libc.7, mailaddr.7, mount_namespaces.7, mq_overview.7, nptl.7, numa.7, path_resolution.7, persistent-keyring.7, pid_namespaces.7, pipe.7, pkeys.7, process-keyring.7, pthreads.7, pty.7, random.7, sched.7, sem_overview.7, session-keyring.7, shm_overview.7, signal-safety.7, signal.7, spufs.7, standards.7, symlink.7, termio.7, thread-keyring.7, time.7, unicode.7, user-keyring.7, user-session-keyring.7, user_namespaces.7, utf-8.7, xattr.7: ffix
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2017-08-17 22:59:04 +00:00
|
|
|
.PP
|
2016-11-11 21:23:39 +00:00
|
|
|
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
|
|
|
|
.I not
|
|
|
|
skillfully implemented.
|
|
|
|
.\"
|
|
|
|
.SH SEE ALSO
|
|
|
|
.BR getrandom (2),
|
2016-12-13 08:59:32 +00:00
|
|
|
.BR getauxval (3),
|
2017-01-22 22:25:24 +00:00
|
|
|
.BR getentropy (3),
|
2016-11-11 21:23:39 +00:00
|
|
|
.BR random (4),
|
|
|
|
.BR urandom (4),
|
|
|
|
.BR signal (7)
|