1.\" $NetBSD: rnd.4,v 1.44 2024/08/28 14:39:16 riastradh Exp $ 2.\" 3.\" Copyright (c) 2014-2020 The NetBSD Foundation, Inc. 4.\" All rights reserved. 5.\" 6.\" This code is derived from software contributed to The NetBSD Foundation 7.\" by Taylor R. Campbell. 8.\" 9.\" Redistribution and use in source and binary forms, with or without 10.\" modification, are permitted provided that the following conditions 11.\" are met: 12.\" 1. Redistributions of source code must retain the above copyright 13.\" notice, this list of conditions and the following disclaimer. 14.\" 2. Redistributions in binary form must reproduce the above copyright 15.\" notice, this list of conditions and the following disclaimer in the 16.\" documentation and/or other materials provided with the distribution. 17.\" 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 20.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 21.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS 22.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 23.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 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 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 28.\" POSSIBILITY OF SUCH DAMAGE. 29.\" 30.Dd August 27, 2024 31.Dt RND 4 32.Os 33.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 34.Sh NAME 35.Nm rnd 36.Nd random number generator 37.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 38.Sh DESCRIPTION 39The 40.Pa /dev/random 41and 42.Pa /dev/urandom 43devices generate bytes randomly with uniform distribution. 44Every read from them is independent. 45.Pp 46.Pa /dev/urandom 47never blocks. 48.Pp 49.Pa /dev/random 50sometimes blocks. 51It will block early at boot if the system's state is known to be 52predictable. 53.Pp 54Applications should read from 55.Pa /dev/urandom , 56or the 57.Xr sysctl 7 58variable 59.Li kern.arandom , 60when they need randomly generated data, e.g. key material for 61cryptography or seeds for simulations. 62The 63.Li kern.arandom 64variable is limited to 256 bytes per read, but is otherwise equivalent 65to reading from 66.Pa /dev/urandom 67and always works even in a 68.Xr chroot 8 69environment without requiring a populated 70.Pa /dev 71tree and without opening a file descriptor, so 72.Li kern.arandom 73may be preferable to use in libraries. 74.Pp 75Systems should be engineered to judiciously read at least once from 76.Pa /dev/random 77at boot before running any services that talk to the internet or 78otherwise require cryptography, in order to avoid generating keys 79predictably. 80.Pa /dev/random 81may block at any time, so programs that read from it must be prepared 82to handle blocking. 83Interactive programs that block due to reads from 84.Pa /dev/random 85can be especially frustrating. 86.Pp 87If interrupted by a signal, reads from either 88.Pa /dev/random 89or 90.Pa /dev/urandom 91may return short, so programs that handle signals must be prepared to 92retry reads. 93.Pp 94Writing to either 95.Pa /dev/random 96or 97.Pa /dev/urandom 98influences subsequent output of both devices, guaranteed to take 99effect at next open. 100If you have a coin in your pocket, you can flip it 256 times and feed 101the outputs to 102.Pa /dev/random 103to guarantee your system is in a state that nobody but you and the 104bored security guard watching the surveillance camera in your office 105can guess: 106.Pp 107.Dl % echo tthhhhhthhhththtthhhhthtththttth... > /dev/random 108.Pp 109.Po 110Sequence generated from a genuine US quarter dollar, guaranteed 111random. 112.Pc 113.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 114.Sh SECURITY MODEL 115The 116.Nm 117subsystem provides the following security properties against two 118different classes of attackers, provided that there is enough entropy 119from entropy sources not seen by attackers: 120.Bl -bullet -offset abcd 121.It 122An attacker who has seen some outputs and can supply some entropy 123sources' inputs to the operating system cannot predict past or future 124unseen outputs. 125.It 126An attacker who has seen the entire state of the machine cannot predict 127past outputs. 128.El 129.Pp 130One 131.Sq output 132means a single read, no matter how short it is. 133.Pp 134.Sq Cannot predict 135means it is conjectured of the cryptography in 136.Pa /dev/random 137that any computationally bounded attacker who tries to distinguish 138outputs from uniform random cannot do more than negligibly better than 139uniform random guessing. 140.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 141.Sh ENTROPY 142The operating system continuously makes observations of hardware 143devices, such as network packet timings, disk seek delays, and 144keystrokes. 145The observations are combined into a seed for a cryptographic 146pseudorandom number generator (PRNG) which is used to generate the 147outputs of both 148.Pa /dev/random 149and 150.Pa /dev/urandom . 151.Pp 152An attacker may be able to guess with nonnegligible chance of success 153what your last keystroke was, but guessing every observation the 154operating system may have made is more difficult. 155The difficulty of the best strategy at guessing a random variable is 156analyzed as the -log_2 of the highest probability of any outcome, 157measured in bits, and called its 158.Em min-entropy , 159or 160.Em entropy 161for short in cryptography. 162For example: 163.Pp 164.Bl -bullet -offset indent -compact 165.It 166A fair coin toss has one bit of entropy. 167.It 168A fair (six-sided) die roll has a little over 2.5 bits of entropy. 169.It 170A string of two independent fair coin tosses has two bits of entropy. 171.It 172The toss of a pair of fair coins that are glued together has one bit of 173entropy. 174.It 175A uniform random distribution with 176.Ar n 177possibilities has log_2 178.Ar n 179bits of entropy. 180.It 181An utterance from an accounting troll who always says 182.Sq nine 183has zero bits of entropy. 184.El 185.Pp 186Note that entropy is a property of an observable physical process, like 187a coin toss, or of a state of knowledge about that physical process; it 188is not a property of a specific sample obtained by observing it, like 189the string 190.Sq tthhhhht . 191There are also kinds of entropy in information theory other than 192min-entropy, including the more well-known Shannon entropy, but they 193are not relevant here. 194.Pp 195Hardware devices that the operating system monitors for observations 196are called 197.Em "entropy sources" , 198and the observations are combined into an 199.Em "entropy pool" . 200The 201.Xr rndctl 8 202command queries information about entropy sources and the entropy pool, 203and can control which entropy sources the operating system uses or 204ignores. 205.Pp 206256 bits of entropy is typically considered intractable to guess with 207classical computers and with current models of the capabilities of 208quantum computers. 209.Pp 210Systems with nonvolatile storage should store a secret from 211.Pa /dev/urandom 212on disk during installation or shutdown, and feed it back during boot, 213so that the work the operating system has done to gather entropy \(em 214including the work its operator may have done to flip a coin! \(em can be 215saved from one boot to the next, and so that newly installed systems 216are not vulnerable to generating cryptographic keys predictably. 217.Pp 218The boot loaders in some 219.Nx 220ports support a command to load a seed from disk before the 221kernel has started. 222For those that don't, the 223.Xr rndctl 8 224command can do it once userland has started, for example by setting 225.Ql random_seed=YES 226in 227.Pa /etc/rc.conf , 228which is enabled by default; see 229.Xr rc.conf 5 . 230.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 231.Sh LIMITATIONS 232Some people worry about recovery from state compromise \(em that is, 233ensuring that even if an attacker sees the entire state of the 234operating system, then the attacker will be unable to predict any new 235future outputs as long as the operating system gathers fresh entropy 236quickly enough. 237.Pp 238But if an attacker has seen the entire state of your machine, 239refreshing entropy is probably the least of your worries, so we do not 240address that threat model here. 241.Pp 242The 243.Nm 244subsystem does 245.Em not 246automatically defend against hardware colluding with an attacker to 247influence entropy sources based on the state of the operating system. 248.Pp 249For example, a PCI device or CPU instruction for random number 250generation which has no side channel to an attacker other than the 251.Pa /dev/urandom 252device could be bugged to observe all other entropy sources, and to 253carefully craft 254.Sq observations 255that cause a certain number of bits of 256.Pa /dev/urandom 257output to be ciphertext that either is predictable to an attacker or 258conveys a message to an attacker. 259.Pp 260No amount of scrutiny by the system's operator could detect this. 261The only way to prevent this attack would be for the operator to 262disable all entropy sources that may be colluding with an attacker. 263If you're not sure which ones are not, you can always disable all of 264them and fall back to the coin in your pocket. 265.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 266.Sh IOCTLS 267The 268.Pa /dev/random 269and 270.Pa /dev/urandom 271devices support a number of ioctls, defined in the 272.In sys/rndio.h 273header file, for querying and controlling the entropy pool. 274.Pp 275Since timing between hardware events contributes to the entropy pool, 276statistics about the entropy pool over time may serve as a side channel 277for the state of the pool, so access to such statistics is restricted 278to the super-user and should be used with caution. 279.Pp 280Several ioctls are concerned with particular entropy sources, described 281by the following structure: 282.Bd -literal 283typedef struct { 284 char name[16]; /* symbolic name */ 285 uint32_t total; /* estimate of entropy provided */ 286 uint32_t type; /* RND_TYPE_* value */ 287 uint32_t flags; /* RND_FLAG_* mask */ 288} rndsource_t; 289 290#define RND_TYPE_UNKNOWN 291#define RND_TYPE_DISK /* disk device */ 292#define RND_TYPE_ENV /* environment sensor (temp, fan, &c.) */ 293#define RND_TYPE_NET /* network device */ 294#define RND_TYPE_POWER /* power events */ 295#define RND_TYPE_RNG /* hardware RNG */ 296#define RND_TYPE_SKEW /* clock skew */ 297#define RND_TYPE_TAPE /* tape drive */ 298#define RND_TYPE_TTY /* tty device */ 299#define RND_TYPE_VM /* virtual memory faults */ 300 301#define RND_TYPE_MAX /* value of highest-numbered type */ 302 303#define RND_FLAG_COLLECT_TIME /* use timings of samples */ 304#define RND_FLAG_COLLECT_VALUE /* use values of samples */ 305#define RND_FLAG_ESTIMATE_TIME /* estimate entropy of timings */ 306#define RND_FLAG_ESTIMATE_VALUE /* estimate entropy of values */ 307#define RND_FLAG_NO_COLLECT /* ignore samples from this */ 308#define RND_FLAG_NO_ESTIMATE /* do not estimate entropy */ 309.Ed 310.Pp 311The following ioctls are supported: 312.Bl -tag -width abcd 313.It Dv RNDGETENTCNT Pq Vt uint32_t 314Return the number of bits of entropy the system is estimated to have. 315.It Dv RNDGETSRCNUM Pq Vt rndstat_t 316.Bd -literal 317typedef struct { 318 uint32_t start; 319 uint32_t count; 320 rndsource_t source[RND_MAXSTATCOUNT]; 321} rndstat_t; 322.Ed 323.Pp 324Fill the 325.Fa source 326array with information about up to 327.Fa count 328entropy sources, starting at 329.Fa start . 330The actual number of sources described is returned in 331.Fa count . 332At most 333.Dv RND_MAXSTATCOUNT 334sources may be requested at once. 335.It Dv RNDGETSRCNAME Pq Vt rndstat_name_t 336.Bd -literal 337typedef struct { 338 char name[16]; 339 rndsource_t source; 340} rndstat_name_t; 341.Ed 342.Pp 343Fill 344.Fa source 345with information about the entropy source named 346.Fa name , 347or fail with 348.Er ENOENT 349if there is none. 350.It Dv RNDCTL Pq Vt rndctl_t 351.Bd -literal 352typedef struct { 353 char name[16]; 354 uint32_t type; 355 uint32_t flags; 356 uint32_t mask; 357} rndctl_t; 358.Ed 359.Pp 360For each entropy source of the type 361.Fa type , 362or if 363.Fa type 364is 365.Li 0xff 366then for the entropy source named 367.Fa name , 368replace the flags in 369.Fa mask 370by 371.Fa flags . 372.It Dv RNDADDDATA Pq Vt rnddata_t 373.Bd -literal 374typedef struct { 375 uint32_t len; 376 uint32_t entropy; 377 unsigned char data[RND_SAVEWORDS * sizeof(uint32_t)]; 378} rnddata_t; 379.Ed 380.Pp 381Feed 382.Fa len 383bytes of data to the entropy pool. 384The sample is expected to have been drawn with at least 385.Fa entropy 386bits of entropy. 387.Pp 388This ioctl can be used only once per boot. 389It is intended for a system that saves entropy to disk on shutdown and 390restores it on boot, so that the system can immediately be 391unpredictable without having to wait to gather entropy. 392.It Dv RNDGETPOOLSTAT Pq Vt rndpoolstat_t 393.Bd -literal 394typedef struct { 395 uint32_t poolsize; /* size of each LFSR in pool */ 396 uint32_t threshold; /* no. bytes of pool hash returned */ 397 uint32_t maxentropy; /* total size of pool in bits */ 398 uint32_t added; /* no. bits of entropy ever added */ 399 uint32_t curentropy; /* current entropy `balance' */ 400 uint32_t discarded; /* no. bits dropped when pool full */ 401 uint32_t generated; /* no. bits yielded by pool while 402 curentropy is zero */ 403} rndpoolstat_t; 404.Ed 405.Pp 406Return various statistics about entropy. 407.El 408.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 409.Sh SYSCTLS 410The following 411.Xr sysctl 8 412variables provided by 413.Nm 414can be set by privileged users: 415.Bl -tag -width abcd 416.It Li kern.entropy.collection Pq Vt bool 417(Default on.) 418Enables entering data into the entropy pool. 419If disabled, no new data can be entered into the entropy pool, whether 420by device drivers, by writes to 421.Pa /dev/random 422or 423.Pa /dev/urandom , 424or by the 425.Dv RNDADDDATA 426ioctl. 427.It Li kern.entropy.depletion Pq Vt bool 428(Default off.) 429Enables 430.Sq entropy depletion , 431meaning that even after attaining full entropy, the kernel subtracts 432the number of bits read out of the entropy pool from its estimate of 433the system entropy. 434This is not justified by modern cryptography \(em an adversary will 435never guess the 256-bit secret in a Keccak sponge no matter how much 436output from the sponge they see \(em but may be useful for testing. 437.It Li kern.entropy.consolidate Pq Vt int 438Trigger for entropy consolidation: executing 439.Pp 440.Dl # sysctl -w kern.entropy.consolidate=1 441.Pp 442causes the system to consolidate pending entropy from per-CPU pools 443into the global pool, and waits until done. 444.El 445.Pp 446The following read-only 447.Xr sysctl 8 448variables provide information to privileged users about the state of 449the entropy pool: 450.Bl -tag -width abcd 451.It Li kern.entropy.needed Pq Vt unsigned int 452Number of bits of entropy the system is waiting for in the global pool 453before reads from 454.Pa /dev/random 455will return without blocking. 456When zero, the system is considered to have full entropy. 457.It Li kern.entropy.pending Pq Vt unsigned int 458Number of bits of entropy pending in per-CPU pools. 459This is the amount of entropy that will be contributed to the global 460pool at the next consolidation, such as from triggering 461.Li kern.entropy.consolidate . 462.El 463.Pp 464The following read-only 465.Xr sysctl 8 466variables provide information to any users, privileged or unprivileged: 467.Bl -tag -width abcd 468.It Li kern.entropy.epoch Pq Vt unsigned int 469An integer that changes whenever the system determines applications 470should reseed from the system entropy pool. 471This can happen for various reasons: 472.Bl -dash -compact 473.It 474The system has reached full entropy for the first time. 475.It 476A virtual machine clone has been detected 477.Pq e.g., by Xr acpivmgenid 4 . 478.It 479An operator has set 480.Li kern.entropy.consolidate . 481.El 482.Pp 483Consulted by 484.Xr arc4random 3 , 485and inside the kernel by subsystems such as 486.Xr cprng 9 , 487to decide whether to reseed. 488.Pp 489Initially set to 2^32 \- 1 490.Pq i.e., Li "(unsigned)\-1" 491meaning the system has never reached full entropy; never again set to 4922^32 \- 1. 493Never zero, so applications can initialize a cache of the epoch to zero 494to ensure they reseed the next time they check whether it is different 495from the stored epoch. 496.El 497.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 498.Sh IMPLEMENTATION NOTES 499(This section describes the current implementation of the 500.Nm 501subsystem at the time of writing. 502It may be out-of-date by the time you read it, and nothing in here 503should be construed as a guarantee about the behaviour of the 504.Pa /dev/random 505and 506.Pa /dev/urandom 507devices.) 508.Pp 509Device drivers gather samples from entropy sources and absorb them into 510a collection of per-CPU Keccak sponges called 511.Sq entropy pools 512using the 513.Xr rnd 9 514kernel API. 515The device driver furnishes an estimate for the entropy of the sampling 516process, under the assumption that each sample is independent. 517When the estimate of entropy pending among the per-CPU entropy pools 518reaches a threshold of 256 bits, the entropy is drawn from the per-CPU 519pools and consolidated into a global pool. 520Keys for 521.Pa /dev/random , 522.Pa /dev/urandom , 523.Li kern.arandom , 524and the in-kernel 525.Xr cprng 9 526subsystem are extracted from the global pool. 527.Pp 528Early after boot, before CPUs have been detected, device drivers 529instead enter directly into the global pool. 530If anything in the system extracts data from the pool before the 531threshold has been reached at least once, the system will print a 532warning to the console and reset the entropy estimate to zero. 533The reason for resetting the entropy estimate to zero in this case is 534that an adversary who can witness output from the pool with partial 535entropy \(em say, 32 bits \(em can undergo a feasible brute force 536search to ascertain the complete state of the pool; as such, the 537entropy of the adversary's state of knowledge about the pool is zero. 538.Pp 539If the operator is confident that the drivers' estimates of the entropy 540of the sampling processes are too conservative, the operator can issue 541.Pp 542.Dl # sysctl -w kern.entropy.consolidate=1 543.Pp 544to force consolidation into the global pool. 545The operator can also fool the system into thinking it has more entropy 546than it does by feeding data from 547.Pa /dev/urandom 548into 549.Pa /dev/random , 550but this voids the security model and should be limited to testing 551purposes. 552.Pp 553.Em Short 554reads from 555.Pa /dev/urandom 556are served by a persistent per-CPU Hash_DRBG instance that is 557reseeded from the entropy pool after any entropy consolidation. 558Reads from 559.Pa /dev/random 560and 561.Em long 562reads from 563.Pa /dev/urandom 564are served by a temporary Hash_DRBG seeded from the entropy pool on 565each read. 566.Pp 567When 568.Sq entropy depletion 569is enabled by 570setting the sysctl variable 571.Li kern.entropy.depletion 572to 1, 573every read from 574.Pa /dev/random 575is limited to 256 bits, since reading more than that would nearly 576always block again. 577.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 578.Sh FILES 579.Bl -tag -width ".Pa /dev/urandom" -compact 580.It Pa /dev/random 581Uniform random byte source. 582May block. 583.It Pa /dev/urandom 584Uniform random byte source. 585Never blocks. 586.El 587.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 588.Sh DIAGNOSTICS 589The 590.Nm 591subsystem may print the following warnings to the console likely 592indicating security issues: 593.Bl -diag -offset indent 594.It WARNING: system needs entropy for security; see entropy(7) 595A process tried to draw from the entropy pool before enough inputs from 596reliable entropy sources have been entered. 597.Pp 598The entropy may be low enough that an adversary who sees the output 599could guess the state of the pool by brute force, so in this event the 600system resets its estimate of entropy to none. 601.Pp 602This message is rate-limited to happen no more often than once per 603minute, so if you want to make sure it is gone you should consult 604.Li kern.entropy.needed 605to confirm it is zero. 606.El 607.Pp 608The 609.Nm 610subsystem may print any of various messages about obtaining an entropy 611seed from the bootloader to diagnose saving and loading seeds on disk: 612.Bl -diag -offset indent 613.It entropy: entering seed from bootloader with N bits of entropy 614The bootloader provided an entropy seed to the kernel, which recorded 615an estimate of N bits of entropy in the process that generated it. 616.It entropy: no seed from bootloader 617The bootloader did not provide an entropy seed to the kernel before 618starting the kernel. 619This does not necessarily indicate a problem; not all bootloaders 620support the option, and the 621.Xr rc.conf 5 622setting 623.Li random_seed=YES 624can serve instead. 625.It entropy: invalid seed length N, expected sizeof(rndsave_t) = M 626The bootloader provided an entropy seed of the wrong size to the 627kernel. 628This may indicate a bug in 629.Xr rndctl 8 . 630The seed will be ignored. 631.It entropy: invalid seed checksum 632The entropy seed provided by the bootloader was malformed. 633The seed will be entered into the entropy pool, but it will be 634considered to contribute no entropy. 635.It entropy: double-seeded by bootloader 636A buggy bootloader tried to provide an entropy seed more than once to 637the kernel. 638Subsequent seeds will be entered into the entropy pool, but they will 639be considered to contribute no entropy. 640.It entropy: best effort 641The system has gathered enough samples from interrupt timings and other 642non-confident sources of entropy for the first time to unblock 643.Pa /dev/random , 644but it may not have full entropy from a seed or hardware random number 645generator. 646.It entropy: ready 647The system has full entropy for the first time. 648.El 649.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 650.Sh SEE ALSO 651.Xr arc4random 3 , 652.Xr acpivmgenid 4 , 653.Xr entropy 7 , 654.Xr rndctl 8 , 655.Xr cprng 9 , 656.Xr rnd 9 657.Rs 658.%A Elaine Barker 659.%A John Kelsey 660.%T Recommendation for Random Number Generation Using Deterministic Random Bit Generators 661.%D June 2015 662.%Q United States Department of Commerce 663.%I National Institute of Standards and Technology 664.%O NIST Special Publication 800-90A, Revision 1 665.%U https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final 666.Re 667.Rs 668.%A Meltem S\(:onmez Turan 669.%A Elaine Barker 670.%A John Kelsey 671.%A Kerry A. McKay 672.%A Mary L. Baish 673.%A Mike Boyle 674.%T Recommendations for the Entropy Sources Used for Random Bit Generation 675.%D January 2018 676.%Q United States Department of Commerce 677.%I National Institute of Standards and Technology 678.%O NIST Special Publication 800-90B 679.%U https://csrc.nist.gov/publications/detail/sp/800-90b/final 680.Re 681.Rs 682.%A Daniel J. Bernstein 683.%T Entropy Attacks! 684.%D 2014-02-05 685.%U http://blog.cr.yp.to/20140205-entropy.html 686.Re 687.Rs 688.%A Nadia Heninger 689.%A Zakir Durumeric 690.%A Eric Wustrow 691.%A J. Alex Halderman 692.%T Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices 693.%B Proceedings of the 21st USENIX Security Symposium 694.%I USENIX 695.%D August 2012 696.%P 205-220 697.%U https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger 698.%U https://factorable.net/ 699.Re 700.Rs 701.%A Edwin T. Jaynes 702.%B Probability Theory: The Logic of Science 703.%I Cambridge University Press 704.%D 2003 705.%U https://bayes.wustl.edu/ 706.Re 707.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 708.Sh HISTORY 709The 710.Pa /dev/random 711and 712.Pa /dev/urandom 713devices first appeared in 714.Nx 1.3 . 715.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 716.Sh AUTHORS 717.An -nosplit 718The 719.Nm 720subsystem was first implemented by 721.An Michael Graff Aq Mt explorer@flame.org , 722was then largely rewritten by 723.An Thor Lancelot Simon Aq Mt tls@NetBSD.org , 724and was most recently largely rewritten by 725.An Taylor R. Campbell Aq Mt riastradh@NetBSD.org . 726.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 727.Sh BUGS 728Many people are confused about what 729.Pa /dev/random 730and 731.Pa /dev/urandom 732mean. 733Unfortunately, no amount of software engineering can fix that. 734