[src/netbsd-8]: src/share/man/man4 Pull up following revision(s) (requested b...

[bouyer <bouyer%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/578fa85adff2
branches:  netbsd-8
changeset: 465859:578fa85adff2
user:      bouyer <bouyer%NetBSD.org@localhost>
date:      Thu Dec 05 16:57:11 2019 +0000

description:
Pull up following revision(s) (requested by riastradh in ticket #1467):
        share/man/man4/rnd.4: revision 1.26
        share/man/man4/rnd.4: revision 1.27
        share/man/man4/rnd.4: revision 1.28
        share/man/man4/rnd.4: revision 1.25
Update man page to reflect switch from CTR_DRBG to Hash_DRBG.
Replace slightly wrong rant by shorter and slightly less long rant.
(If X and Y in Z/2Z are independent, then so are X and X+Y.  What was
I thinking.)
Update NIST SP800-90A reference.
New sentence, new line. Use \(em.

diffstat:

 share/man/man4/rnd.4 |  90 ++++++++++++++++++---------------------------------
 1 files changed, 32 insertions(+), 58 deletions(-)

diffs (146 lines):

diff -r 56b5514bcb43 -r 578fa85adff2 share/man/man4/rnd.4
--- a/share/man/man4/rnd.4      Thu Dec 05 16:54:59 2019 +0000
+++ b/share/man/man4/rnd.4      Thu Dec 05 16:57:11 2019 +0000
@@ -1,4 +1,4 @@
-.\"    $NetBSD: rnd.4,v 1.24 2017/01/18 22:38:00 abhinav Exp $
+.\"    $NetBSD: rnd.4,v 1.24.4.1 2019/12/05 16:57:11 bouyer Exp $
 .\"
 .\" Copyright (c) 2014 The NetBSD Foundation, Inc.
 .\" All rights reserved.
@@ -27,7 +27,7 @@
 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\" POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd November 16, 2014
+.Dd September 3, 2019
 .Dt RND 4
 .Os
 .Sh NAME
@@ -187,8 +187,8 @@
 Systems with nonvolatile storage should store a secret from
 .Pa /dev/urandom
 on disk during installation or shutdown, and feed it back during boot,
-so that the work the operating system has done to gather entropy --
-including the work its operator may have done to flip a coin! -- can be
+so that the work the operating system has done to gather entropy \(em
+including the work its operator may have done to flip a coin! \(em can be
 saved from one boot to the next, and so that newly installed systems
 are not vulnerable to generating cryptographic keys predictably.
 .Pp
@@ -205,7 +205,7 @@
 which is enabled by default; see
 .Xr rc.conf 5 .
 .Sh LIMITATIONS
-Some people worry about recovery from state compromise -- that is,
+Some people worry about recovery from state compromise \(em that is,
 ensuring that even if an attacker sees the entire state of the
 operating system, then the attacker will be unable to predict any new
 future outputs as long as the operating system gathers fresh entropy
@@ -404,9 +404,9 @@
 or
 .Pa /dev/urandom
 and first reads from it, the kernel draws from the entropy pool to seed
-a cryptographic pseudorandom number generator, the NIST CTR_DRBG
-(counter-mode deterministic random bit generator) with AES-128 as the
-block cipher, and uses that to generate data.
+a cryptographic pseudorandom number generator, the NIST Hash_DRBG
+(hash-based deterministic random bit generator) with SHA-256 as the
+hash function, and uses that to generate data.
 .Pp
 To draw a seed from the entropy pool, the kernel
 .Bl -bullet -offset abcd -compact
@@ -489,10 +489,10 @@
 .%A Elaine Barker
 .%A John Kelsey
 .%T Recommendation for Random Number Generation Using Deterministic Random Bit Generators
-.%D January 2012
+.%D June 2015
 .%I National Institute of Standards and Technology
-.%O NIST Special Publication 800-90A
-.%U http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
+.%O NIST Special Publication 800-90A, Revision 1
+.%U https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final
 .Re
 .Rs
 .%A Daniel J. Bernstein
@@ -551,59 +551,33 @@
 .Sh ENTROPY ACCOUNTING
 The entropy accounting described here is not grounded in any
 cryptography theory.
-It is done because it was always done, and because it gives people a
-warm fuzzy feeling about information theory.
-.Pp
-The folklore is that every
-.Fa n Ns -bit
-output of
-.Fa /dev/random
-is not merely indistinguishable from uniform random to a
-computationally bounded attacker, but information-theoretically is
-independent and has
-.Fa n
-bits of entropy even to a computationally
-.Em unbounded
-attacker -- that is, an attacker who can recover AES keys, compute
-SHA-1 preimages, etc.
-This property is not provided, nor was it ever provided in any
-implementation of
-.Fa /dev/random
-known to the author.
+.Sq Entropy estimation
+doesn't mean much: the kernel hypothesizes an extremely simple-minded
+parametric model for all entropy sources which bears little relation to
+any physical processes, implicitly fits parameters from data, and
+accounts for the entropy of the fitted model.
 .Pp
-This property would require that, after each read, the system discard
-all measurements from hardware in the entropy pool and begin anew.
-All work done to make the system unpredictable would be thrown out, and
-the system would immediately become predictable again.
-Reverting the system to being predictable every time a process reads
-from
-.Fa /dev/random
-would give attackers a tremendous advantage in predicting future
-outputs, especially if they can fool the entropy estimator, e.g. by
-sending carefully timed network packets.
+Past versions of the
+.Nm
+subsystem were concerned with
+.Sq information-theoretic
+security, under the premise that the number of bits of entropy out must
+not exceed the number of bits of entropy in \(em never mind that its
+.Sq entropy estimation
+is essentially meaningless without a model for the physical processes
+the system is observing.
 .Pp
-If you filled your entropy pool by flipping a coin 256 times, you would
-have to flip it again 256 times for the next output, and so on.
-In that case, if you really want information-theoretic guarantees, you
-might as well take
-.Fa /dev/random
-out of the picture and use your coin flips verbatim.
-.Pp
-On the other hand, every cryptographic protocol in practice, including
-HTTPS, SSH, PGP, etc., expands short secrets deterministically into
-long streams of bits, and their security relies on conjectures that a
-computationally bounded attacker cannot distinguish the long streams
-from uniform random.
+But every cryptographic protocol in practice, including HTTPS, SSH,
+PGP, etc., expands short secrets deterministically into long streams of
+bits, and their security relies on conjectures that a computationally
+bounded attacker cannot distinguish the long streams from uniform
+random.
 If we couldn't do that for
 .Fa /dev/random ,
 it would be hopeless to assume we could for HTTPS, SSH, PGP, etc.
 .Pp
 History is littered with examples of broken entropy sources and failed
 system engineering for random number generators.
-Nobody has ever reported distinguishing AES ciphertext from uniform
-random without side channels, nor reported computing SHA-1 preimages
+Nobody has ever reported distinguishing SHA-256 hashes with secret
+inputs from uniform random, nor reported computing SHA-1 preimages
 faster than brute force.
-The folklore information-theoretic defence against computationally
-unbounded attackers replaces system engineering that successfully
-defends against realistic threat models by imaginary theory that
-defends only against fantasy threat models.