Thu Dec 5 16:23:23 2019 UTC ()
Pull up following revision(s) (requested by riastradh in ticket #1715):
	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.


(bouyer)
diff -r1.20.10.1 -r1.20.10.1.2.1 src/share/man/man4/rnd.4
cvs diff -r1.20.10.1 -r1.20.10.1.2.1 src/share/man/man4/rnd.4 (expand / switch to unified diff)

--- src/share/man/man4/rnd.4 2015/03/18 07:54:26 1.20.10.1
+++ src/share/man/man4/rnd.4 2019/12/05 16:23:22 1.20.10.1.2.1
@@ -1,14 +1,14 @@ @@ -1,14 +1,14 @@
1.\" $NetBSD: rnd.4,v 1.20.10.1 2015/03/18 07:54:26 snj Exp $ 1.\" $NetBSD: rnd.4,v 1.20.10.1.2.1 2019/12/05 16:23:22 bouyer Exp $
2.\" 2.\"
3.\" Copyright (c) 2014 The NetBSD Foundation, Inc. 3.\" Copyright (c) 2014 The NetBSD Foundation, Inc.
4.\" All rights reserved. 4.\" All rights reserved.
5.\" 5.\"
6.\" This code is derived from software contributed to The NetBSD Foundation 6.\" This code is derived from software contributed to The NetBSD Foundation
7.\" by Taylor R. Campbell. 7.\" by Taylor R. Campbell.
8.\" 8.\"
9.\" Redistribution and use in source and binary forms, with or without 9.\" Redistribution and use in source and binary forms, with or without
10.\" modification, are permitted provided that the following conditions 10.\" modification, are permitted provided that the following conditions
11.\" are met: 11.\" are met:
12.\" 1. Redistributions of source code must retain the above copyright 12.\" 1. Redistributions of source code must retain the above copyright
13.\" notice, this list of conditions and the following disclaimer. 13.\" notice, this list of conditions and the following disclaimer.
14.\" 2. Redistributions in binary form must reproduce the above copyright 14.\" 2. Redistributions in binary form must reproduce the above copyright
@@ -17,27 +17,27 @@ @@ -17,27 +17,27 @@
17.\" 17.\"
18.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS 18.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
19.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 19.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
20.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 20.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
21.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS 21.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
22.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 22.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
23.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 23.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
24.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 24.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
25.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 25.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
26.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 26.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
27.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 27.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
28.\" POSSIBILITY OF SUCH DAMAGE. 28.\" POSSIBILITY OF SUCH DAMAGE.
29.\" 29.\"
30.Dd November 16, 2014 30.Dd September 3, 2019
31.Dt RND 4 31.Dt RND 4
32.Os 32.Os
33.Sh NAME 33.Sh NAME
34.Nm rnd 34.Nm rnd
35.Nd random number generator 35.Nd random number generator
36.Sh DESCRIPTION 36.Sh DESCRIPTION
37The 37The
38.Pa /dev/random 38.Pa /dev/random
39and 39and
40.Pa /dev/urandom 40.Pa /dev/urandom
41devices generate bytes randomly with uniform distribution. 41devices generate bytes randomly with uniform distribution.
42Every read from them is independent. 42Every read from them is independent.
43.Bl -tag -width /dev/urandom 43.Bl -tag -width /dev/urandom
@@ -177,45 +177,45 @@ and the observations are combined into a @@ -177,45 +177,45 @@ and the observations are combined into a
177The 177The
178.Xr rndctl 8 178.Xr rndctl 8
179command queries information about entropy sources and the entropy pool, 179command queries information about entropy sources and the entropy pool,
180and can control which entropy sources the operating system uses or 180and can control which entropy sources the operating system uses or
181ignores. 181ignores.
182.Pp 182.Pp
183256 bits of entropy is typically considered intractible to guess with 183256 bits of entropy is typically considered intractible to guess with
184classical computers and with current models of the capabilities of 184classical computers and with current models of the capabilities of
185quantum computers. 185quantum computers.
186.Pp 186.Pp
187Systems with nonvolatile storage should store a secret from 187Systems with nonvolatile storage should store a secret from
188.Pa /dev/urandom 188.Pa /dev/urandom
189on disk during installation or shutdown, and feed it back during boot, 189on disk during installation or shutdown, and feed it back during boot,
190so that the work the operating system has done to gather entropy -- 190so that the work the operating system has done to gather entropy \(em
191including the work its operator may have done to flip a coin! -- can be 191including the work its operator may have done to flip a coin! \(em can be
192saved from one boot to the next, and so that newly installed systems 192saved from one boot to the next, and so that newly installed systems
193are not vulnerable to generating cryptographic keys predictably. 193are not vulnerable to generating cryptographic keys predictably.
194.Pp 194.Pp
195The boot loaders in some 195The boot loaders in some
196.Nx 196.Nx
197ports support a command to load a seed from disk before the 197ports support a command to load a seed from disk before the
198kernel has started. 198kernel has started.
199For those that don't, the 199For those that don't, the
200.Xr rndctl 8 200.Xr rndctl 8
201command can do it once userland has started, for example by setting 201command can do it once userland has started, for example by setting
202.Dq Va rndctl=YES 202.Dq Va rndctl=YES
203in 203in
204.Pa /etc/rc.conf ; 204.Pa /etc/rc.conf ;
205see 205see
206.Xr rc.conf 5 . 206.Xr rc.conf 5 .
207.Sh LIMITATIONS 207.Sh LIMITATIONS
208Some people worry about recovery from state compromise -- that is, 208Some people worry about recovery from state compromise \(em that is,
209ensuring that even if an attacker sees the entire state of the 209ensuring that even if an attacker sees the entire state of the
210operating system, then the attacker will be unable to predict any new 210operating system, then the attacker will be unable to predict any new
211future outputs as long as the operating system gathers fresh entropy 211future outputs as long as the operating system gathers fresh entropy
212quickly enough. 212quickly enough.
213.Pp 213.Pp
214But if an attacker has seen the entire state of your machine, 214But if an attacker has seen the entire state of your machine,
215refreshing entropy is probably the least of your worries, so we do not 215refreshing entropy is probably the least of your worries, so we do not
216address that threat model here. 216address that threat model here.
217.Pp 217.Pp
218The 218The
219.Nm 219.Nm
220subsystem does 220subsystem does
221.Em not 221.Em not
@@ -394,29 +394,29 @@ and @@ -394,29 +394,29 @@ and
394.Pa /dev/urandom 394.Pa /dev/urandom
395devices.) 395devices.)
396.Pp 396.Pp
397Samples from entropy sources are fed 32 bits at a time into the entropy 397Samples from entropy sources are fed 32 bits at a time into the entropy
398pool, which is an array of 4096 bits, or 128 32-bit words, representing 398pool, which is an array of 4096 bits, or 128 32-bit words, representing
39932 linear feedback shift registers each 128 bits long. 39932 linear feedback shift registers each 128 bits long.
400.\" XXX Finish this description so it is implementable. 400.\" XXX Finish this description so it is implementable.
401.Pp 401.Pp
402When a user process opens 402When a user process opens
403.Pa /dev/random 403.Pa /dev/random
404or 404or
405.Pa /dev/urandom 405.Pa /dev/urandom
406and first reads from it, the kernel draws from the entropy pool to seed 406and first reads from it, the kernel draws from the entropy pool to seed
407a cryptographic pseudorandom number generator, the NIST CTR_DRBG 407a cryptographic pseudorandom number generator, the NIST Hash_DRBG
408(counter-mode deterministic random bit generator) with AES-128 as the 408(hash-based deterministic random bit generator) with SHA-256 as the
409block cipher, and uses that to generate data. 409hash function, and uses that to generate data.
410.Pp 410.Pp
411To draw a seed from the entropy pool, the kernel 411To draw a seed from the entropy pool, the kernel
412.Bl -bullet -offset abcd -compact 412.Bl -bullet -offset abcd -compact
413.It 413.It
414computes the SHA-1 hash of the entropy pool, 414computes the SHA-1 hash of the entropy pool,
415.It 415.It
416feeds the SHA-1 hash word-by-word back into the entropy pool like an 416feeds the SHA-1 hash word-by-word back into the entropy pool like an
417entropy source, and 417entropy source, and
418.It 418.It
419yields the xor of bytes 419yields the xor of bytes
420.Pf 0.. Fa n 420.Pf 0.. Fa n
421with bytes 421with bytes
422.Fa n Ns +0.. Ns Fa n Ns Pf + Fa n 422.Fa n Ns +0.. Ns Fa n Ns Pf + Fa n
@@ -479,30 +479,30 @@ Uniform random byte source. @@ -479,30 +479,30 @@ Uniform random byte source.
479May block. 479May block.
480.It Pa /dev/urandom 480.It Pa /dev/urandom
481Uniform random byte source. 481Uniform random byte source.
482Never blocks. 482Never blocks.
483.El 483.El
484.Sh SEE ALSO 484.Sh SEE ALSO
485.Xr arc4random 3 , 485.Xr arc4random 3 ,
486.Xr rndctl 8 , 486.Xr rndctl 8 ,
487.Xr cprng 9 487.Xr cprng 9
488.Rs 488.Rs
489.%A Elaine Barker 489.%A Elaine Barker
490.%A John Kelsey 490.%A John Kelsey
491.%T Recommendation for Random Number Generation Using Deterministic Random Bit Generators 491.%T Recommendation for Random Number Generation Using Deterministic Random Bit Generators
492.%D January 2012 492.%D June 2015
493.%I National Institute of Standards and Technology 493.%I National Institute of Standards and Technology
494.%O NIST Special Publication 800-90A 494.%O NIST Special Publication 800-90A, Revision 1
495.%U http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf 495.%U https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final
496.Re 496.Re
497.Rs 497.Rs
498.%A Daniel J. Bernstein 498.%A Daniel J. Bernstein
499.%T Entropy Attacks! 499.%T Entropy Attacks!
500.%D 2014-02-05 500.%D 2014-02-05
501.%U http://blog.cr.yp.to/20140205-entropy.html 501.%U http://blog.cr.yp.to/20140205-entropy.html
502.Re 502.Re
503.Rs 503.Rs
504.%A Nadia Heninger 504.%A Nadia Heninger
505.%A Zakir Durumeric 505.%A Zakir Durumeric
506.%A Eric Wustrow 506.%A Eric Wustrow
507.%A J. Alex Halderman 507.%A J. Alex Halderman
508.%T Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices 508.%T Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices
@@ -541,69 +541,43 @@ even if entropy estimates were accurate  @@ -541,69 +541,43 @@ even if entropy estimates were accurate
541long for 541long for
542.Pa /dev/random 542.Pa /dev/random
543to stop blocking. 543to stop blocking.
544.Pp 544.Pp
545Many people are confused about what 545Many people are confused about what
546.Pa /dev/random 546.Pa /dev/random
547and 547and
548.Pa /dev/urandom 548.Pa /dev/urandom
549mean. 549mean.
550Unfortunately, no amount of software engineering can fix that. 550Unfortunately, no amount of software engineering can fix that.
551.Sh ENTROPY ACCOUNTING 551.Sh ENTROPY ACCOUNTING
552The entropy accounting described here is not grounded in any 552The entropy accounting described here is not grounded in any
553cryptography theory. 553cryptography theory.
554It is done because it was always done, and because it gives people a 554.Sq Entropy estimation
555warm fuzzy feeling about information theory. 555doesn't mean much: the kernel hypothesizes an extremely simple-minded
 556parametric model for all entropy sources which bears little relation to
 557any physical processes, implicitly fits parameters from data, and
 558accounts for the entropy of the fitted model.
556.Pp 559.Pp
557The folklore is that every 560Past versions of the
558.Fa n Ns -bit 561.Nm
559output of 562subsystem were concerned with
560.Fa /dev/random 563.Sq information-theoretic
561is not merely indistinguishable from uniform random to a 564security, under the premise that the number of bits of entropy out must
562computationally bounded attacker, but information-theoretically is 565not exceed the number of bits of entropy in \(em never mind that its
563independent and has 566.Sq entropy estimation
564.Fa n 567is essentially meaningless without a model for the physical processes
565bits of entropy even to a computationally 568the system is observing.
566.Em unbounded 569.Pp
567attacker -- that is, an attacker who can recover AES keys, compute 570But every cryptographic protocol in practice, including HTTPS, SSH,
568SHA-1 preimages, etc. 571PGP, etc., expands short secrets deterministically into long streams of
569This property is not provided, nor was it ever provided in any 572bits, and their security relies on conjectures that a computationally
570implementation of 573bounded attacker cannot distinguish the long streams from uniform
571.Fa /dev/random 574random.
572known to the author. 
573.Pp 
574This property would require that, after each read, the system discard 
575all measurements from hardware in the entropy pool and begin anew. 
576All work done to make the system unpredictable would be thrown out, and 
577the system would immediately become predictable again. 
578Reverting the system to being predictable every time a process reads 
579from 
580.Fa /dev/random 
581would give attackers a tremendous advantage in predicting future 
582outputs, especially if they can fool the entropy estimator, e.g. by 
583sending carefully timed network packets. 
584.Pp 
585If you filled your entropy pool by flipping a coin 256 times, you would 
586have to flip it again 256 times for the next output, and so on. 
587In that case, if you really want information-theoretic guarantees, you 
588might as well take 
589.Fa /dev/random 
590out of the picture and use your coin flips verbatim. 
591.Pp 
592On the other hand, every cryptographic protocol in practice, including 
593HTTPS, SSH, PGP, etc., expands short secrets deterministically into 
594long streams of bits, and their security relies on conjectures that a 
595computationally bounded attacker cannot distinguish the long streams 
596from uniform random. 
597If we couldn't do that for 575If we couldn't do that for
598.Fa /dev/random , 576.Fa /dev/random ,
599it would be hopeless to assume we could for HTTPS, SSH, PGP, etc. 577it would be hopeless to assume we could for HTTPS, SSH, PGP, etc.
600.Pp 578.Pp
601History is littered with examples of broken entropy sources and failed 579History is littered with examples of broken entropy sources and failed
602system engineering for random number generators. 580system engineering for random number generators.
603Nobody has ever reported distinguishing AES ciphertext from uniform 581Nobody has ever reported distinguishing SHA-256 hashes with secret
604random without side channels, nor reported computing SHA-1 preimages 582inputs from uniform random, nor reported computing SHA-1 preimages
605faster than brute force. 583faster than brute force.
606The folklore information-theoretic defence against computationally 
607unbounded attackers replaces system engineering that successfully 
608defends against realistic threat models by imaginary theory that 
609defends only against fantasy threat models.