diff options
Diffstat (limited to 'static/netbsd/man4/rnd.4 3.html')
| -rw-r--r-- | static/netbsd/man4/rnd.4 3.html | 547 |
1 files changed, 0 insertions, 547 deletions
diff --git a/static/netbsd/man4/rnd.4 3.html b/static/netbsd/man4/rnd.4 3.html deleted file mode 100644 index b34b74c6..00000000 --- a/static/netbsd/man4/rnd.4 3.html +++ /dev/null @@ -1,547 +0,0 @@ -<table class="head"> - <tr> - <td class="head-ltitle">RND(4)</td> - <td class="head-vol">Device Drivers Manual</td> - <td class="head-rtitle">RND(4)</td> - </tr> -</table> -<div class="manual-text"> -<section class="Sh"> -<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> -<p class="Pp"><code class="Nm">rnd</code> — <span class="Nd">random - number generator</span></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> -<p class="Pp">The <span class="Pa">/dev/random</span> and - <span class="Pa">/dev/urandom</span> devices generate bytes randomly with - uniform distribution. Every read from them is independent.</p> -<p class="Pp"><span class="Pa">/dev/urandom</span> never blocks.</p> -<p class="Pp"><span class="Pa">/dev/random</span> sometimes blocks. It will - block early at boot if the system's state is known to be predictable.</p> -<p class="Pp">Applications should read from - <span class="Pa">/dev/urandom</span>, or the <a class="Xr">sysctl(7)</a> - variable <code class="Li">kern.arandom</code>, when they need randomly - generated data, e.g. key material for cryptography or seeds for simulations. - The <code class="Li">kern.arandom</code> variable is limited to 256 bytes - per read, but is otherwise equivalent to reading from - <span class="Pa">/dev/urandom</span> and always works even in a - <a class="Xr">chroot(8)</a> environment without requiring a populated - <span class="Pa">/dev</span> tree and without opening a file descriptor, so - <code class="Li">kern.arandom</code> may be preferable to use in - libraries.</p> -<p class="Pp">Systems should be engineered to judiciously read at least once - from <span class="Pa">/dev/random</span> at boot before running any services - that talk to the internet or otherwise require cryptography, in order to - avoid generating keys predictably. <span class="Pa">/dev/random</span> may - block at any time, so programs that read from it must be prepared to handle - blocking. Interactive programs that block due to reads from - <span class="Pa">/dev/random</span> can be especially frustrating.</p> -<p class="Pp">If interrupted by a signal, reads from either - <span class="Pa">/dev/random</span> or <span class="Pa">/dev/urandom</span> - may return short, so programs that handle signals must be prepared to retry - reads.</p> -<p class="Pp">Writing to either <span class="Pa">/dev/random</span> or - <span class="Pa">/dev/urandom</span> influences subsequent output of both - devices, guaranteed to take effect at next open. If you have a coin in your - pocket, you can flip it 256 times and feed the outputs to - <span class="Pa">/dev/random</span> to guarantee your system is in a state - that nobody but you and the bored security guard watching the surveillance - camera in your office can guess:</p> -<p class="Pp"></p> -<div class="Bd Bd-indent"><code class="Li">% echo - tthhhhhthhhththtthhhhthtththttth... > /dev/random</code></div> -<p class="Pp">(Sequence generated from a genuine US quarter dollar, guaranteed - random.)</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="SECURITY_MODEL"><a class="permalink" href="#SECURITY_MODEL">SECURITY - MODEL</a></h1> -<p class="Pp">The <code class="Nm">rnd</code> subsystem provides the following - security properties against two different classes of attackers, provided - that there is enough entropy from entropy sources not seen by attackers:</p> -<ul class="Bl-bullet Bd-indent"> - <li>An attacker who has seen some outputs and can supply some entropy sources' - inputs to the operating system cannot predict past or future unseen - outputs.</li> - <li>An attacker who has seen the entire state of the machine cannot predict - past outputs.</li> -</ul> -<p class="Pp">One ‘output’ means a single read, no matter how - short it is.</p> -<p class="Pp">‘Cannot predict’ means it is conjectured of the - cryptography in <span class="Pa">/dev/random</span> that any computationally - bounded attacker who tries to distinguish outputs from uniform random cannot - do more than negligibly better than uniform random guessing.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="ENTROPY"><a class="permalink" href="#ENTROPY">ENTROPY</a></h1> -<p class="Pp">The operating system continuously makes observations of hardware - devices, such as network packet timings, disk seek delays, and keystrokes. - The observations are combined into a seed for a cryptographic pseudorandom - number generator (PRNG) which is used to generate the outputs of both - <span class="Pa">/dev/random</span> and - <span class="Pa">/dev/urandom</span>.</p> -<p class="Pp" id="min-entropy">An attacker may be able to guess with - nonnegligible chance of success what your last keystroke was, but guessing - every observation the operating system may have made is more difficult. The - difficulty of the best strategy at guessing a random variable is analyzed as - the -log_2 of the highest probability of any outcome, measured in bits, and - called its - <a class="permalink" href="#min-entropy"><i class="Em">min-entropy</i></a>, - or <i class="Em">entropy</i> for short in cryptography. For example:</p> -<p class="Pp"></p> -<ul class="Bl-bullet Bd-indent Bl-compact"> - <li>A fair coin toss has one bit of entropy.</li> - <li>A fair (six-sided) die roll has a little over 2.5 bits of entropy.</li> - <li>A string of two independent fair coin tosses has two bits of entropy.</li> - <li>The toss of a pair of fair coins that are glued together has one bit of - entropy.</li> - <li>A uniform random distribution with <var class="Ar">n</var> possibilities - has log_2 <var class="Ar">n</var> bits of entropy.</li> - <li>An utterance from an accounting troll who always says ‘nine’ - has zero bits of entropy.</li> -</ul> -<p class="Pp">Note that entropy is a property of an observable physical process, - like a coin toss, or of a state of knowledge about that physical process; it - is not a property of a specific sample obtained by observing it, like the - string ‘tthhhhht’. There are also kinds of entropy in - information theory other than min-entropy, including the more well-known - Shannon entropy, but they are not relevant here.</p> -<p class="Pp">Hardware devices that the operating system monitors for - observations are called <i class="Em">entropy sources</i>, and the - observations are combined into an <i class="Em">entropy pool</i>. The - <a class="Xr">rndctl(8)</a> command queries information about entropy - sources and the entropy pool, and can control which entropy sources the - operating system uses or ignores.</p> -<p class="Pp">256 bits of entropy is typically considered intractable to guess - with classical computers and with current models of the capabilities of - quantum computers.</p> -<p class="Pp">Systems with nonvolatile storage should store a secret from - <span class="Pa">/dev/urandom</span> 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 saved from one boot to the - next, and so that newly installed systems are not vulnerable to generating - cryptographic keys predictably.</p> -<p class="Pp">The boot loaders in some <span class="Ux">NetBSD</span> ports - support a command to load a seed from disk before the kernel has started. - For those that don't, the <a class="Xr">rndctl(8)</a> command can do it once - userland has started, for example by setting - ‘<code class="Li">random_seed=YES</code>’ in - <span class="Pa">/etc/rc.conf</span>, which is enabled by default; see - <a class="Xr">rc.conf(5)</a>.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="LIMITATIONS"><a class="permalink" href="#LIMITATIONS">LIMITATIONS</a></h1> -<p class="Pp">Some people worry about recovery from state compromise — - 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 quickly - enough.</p> -<p class="Pp">But if an attacker has seen the entire state of your machine, - refreshing entropy is probably the least of your worries, so we do not - address that threat model here.</p> -<p class="Pp" id="not">The <code class="Nm">rnd</code> subsystem does - <a class="permalink" href="#not"><i class="Em">not</i></a> automatically - defend against hardware colluding with an attacker to influence entropy - sources based on the state of the operating system.</p> -<p class="Pp">For example, a PCI device or CPU instruction for random number - generation which has no side channel to an attacker other than the - <span class="Pa">/dev/urandom</span> device could be bugged to observe all - other entropy sources, and to carefully craft ‘observations’ - that cause a certain number of bits of <span class="Pa">/dev/urandom</span> - output to be ciphertext that either is predictable to an attacker or conveys - a message to an attacker.</p> -<p class="Pp">No amount of scrutiny by the system's operator could detect this. - The only way to prevent this attack would be for the operator to disable all - entropy sources that may be colluding with an attacker. If you're not sure - which ones are not, you can always disable all of them and fall back to the - coin in your pocket.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="IOCTLS"><a class="permalink" href="#IOCTLS">IOCTLS</a></h1> -<p class="Pp">The <span class="Pa">/dev/random</span> and - <span class="Pa">/dev/urandom</span> devices support a number of ioctls, - defined in the <code class="In"><<a class="In">sys/rndio.h</a>></code> - header file, for querying and controlling the entropy pool.</p> -<p class="Pp">Since timing between hardware events contributes to the entropy - pool, statistics about the entropy pool over time may serve as a side - channel for the state of the pool, so access to such statistics is - restricted to the super-user and should be used with caution.</p> -<p class="Pp">Several ioctls are concerned with particular entropy sources, - described by the following structure:</p> -<div class="Bd Pp Li"> -<pre>typedef struct { - char name[16]; /* symbolic name */ - uint32_t total; /* estimate of entropy provided */ - uint32_t type; /* RND_TYPE_* value */ - uint32_t flags; /* RND_FLAG_* mask */ -} rndsource_t; - -#define RND_TYPE_UNKNOWN -#define RND_TYPE_DISK /* disk device */ -#define RND_TYPE_ENV /* environment sensor (temp, fan, &c.) */ -#define RND_TYPE_NET /* network device */ -#define RND_TYPE_POWER /* power events */ -#define RND_TYPE_RNG /* hardware RNG */ -#define RND_TYPE_SKEW /* clock skew */ -#define RND_TYPE_TAPE /* tape drive */ -#define RND_TYPE_TTY /* tty device */ -#define RND_TYPE_VM /* virtual memory faults */ - -#define RND_TYPE_MAX /* value of highest-numbered type */ - -#define RND_FLAG_COLLECT_TIME /* use timings of samples */ -#define RND_FLAG_COLLECT_VALUE /* use values of samples */ -#define RND_FLAG_ESTIMATE_TIME /* estimate entropy of timings */ -#define RND_FLAG_ESTIMATE_VALUE /* estimate entropy of values */ -#define RND_FLAG_NO_COLLECT /* ignore samples from this */ -#define RND_FLAG_NO_ESTIMATE /* do not estimate entropy */</pre> -</div> -<p class="Pp">The following ioctls are supported:</p> -<dl class="Bl-tag"> - <dt id="RNDGETENTCNT"><a class="permalink" href="#RNDGETENTCNT"><code class="Dv">RNDGETENTCNT</code></a> - (<var class="Vt">uint32_t</var>)</dt> - <dd>Return the number of bits of entropy the system is estimated to have.</dd> - <dt id="RNDGETSRCNUM"><a class="permalink" href="#RNDGETSRCNUM"><code class="Dv">RNDGETSRCNUM</code></a> - (<var class="Vt">rndstat_t</var>)</dt> - <dd> - <div class="Bd Pp Li"> - <pre>typedef struct { - uint32_t start; - uint32_t count; - rndsource_t source[RND_MAXSTATCOUNT]; -} rndstat_t;</pre> - </div> - <p class="Pp">Fill the <var class="Fa">source</var> array with information - about up to <var class="Fa">count</var> entropy sources, starting at - <var class="Fa">start</var>. The actual number of sources described is - returned in <var class="Fa">count</var>. At most - <code class="Dv">RND_MAXSTATCOUNT</code> sources may be requested at - once.</p> - </dd> - <dt id="RNDGETSRCNAME"><a class="permalink" href="#RNDGETSRCNAME"><code class="Dv">RNDGETSRCNAME</code></a> - (<var class="Vt">rndstat_name_t</var>)</dt> - <dd> - <div class="Bd Pp Li"> - <pre>typedef struct { - char name[16]; - rndsource_t source; -} rndstat_name_t;</pre> - </div> - <p class="Pp">Fill <var class="Fa">source</var> with information about the - entropy source named <var class="Fa">name</var>, or fail with - <code class="Er">ENOENT</code> if there is none.</p> - </dd> - <dt id="RNDCTL"><a class="permalink" href="#RNDCTL"><code class="Dv">RNDCTL</code></a> - (<var class="Vt">rndctl_t</var>)</dt> - <dd> - <div class="Bd Pp Li"> - <pre>typedef struct { - char name[16]; - uint32_t type; - uint32_t flags; - uint32_t mask; -} rndctl_t;</pre> - </div> - <p class="Pp">For each entropy source of the type - <var class="Fa">type</var>, or if <var class="Fa">type</var> is - <code class="Li">0xff</code> then for the entropy source named - <var class="Fa">name</var>, replace the flags in - <var class="Fa">mask</var> by <var class="Fa">flags</var>.</p> - </dd> - <dt id="RNDADDDATA"><a class="permalink" href="#RNDADDDATA"><code class="Dv">RNDADDDATA</code></a> - (<var class="Vt">rnddata_t</var>)</dt> - <dd> - <div class="Bd Pp Li"> - <pre>typedef struct { - uint32_t len; - uint32_t entropy; - unsigned char data[RND_SAVEWORDS * sizeof(uint32_t)]; -} rnddata_t;</pre> - </div> - <p class="Pp">Feed <var class="Fa">len</var> bytes of data to the entropy - pool. The sample is expected to have been drawn with at least - <var class="Fa">entropy</var> bits of entropy.</p> - <p class="Pp">This ioctl can be used only once per boot. It is intended for - a system that saves entropy to disk on shutdown and restores it on boot, - so that the system can immediately be unpredictable without having to - wait to gather entropy.</p> - </dd> - <dt id="RNDGETPOOLSTAT"><a class="permalink" href="#RNDGETPOOLSTAT"><code class="Dv">RNDGETPOOLSTAT</code></a> - (<var class="Vt">rndpoolstat_t</var>)</dt> - <dd> - <div class="Bd Pp Li"> - <pre>typedef struct { - uint32_t poolsize; /* size of each LFSR in pool */ - uint32_t threshold; /* no. bytes of pool hash returned */ - uint32_t maxentropy; /* total size of pool in bits */ - uint32_t added; /* no. bits of entropy ever added */ - uint32_t curentropy; /* current entropy `balance' */ - uint32_t discarded; /* no. bits dropped when pool full */ - uint32_t generated; /* no. bits yielded by pool while - curentropy is zero */ -} rndpoolstat_t;</pre> - </div> - <p class="Pp">Return various statistics about entropy.</p> - </dd> -</dl> -</section> -<section class="Sh"> -<h1 class="Sh" id="SYSCTLS"><a class="permalink" href="#SYSCTLS">SYSCTLS</a></h1> -<p class="Pp">The following <a class="Xr">sysctl(8)</a> variables provided by - <code class="Nm">rnd</code> can be set by privileged users:</p> -<dl class="Bl-tag"> - <dt id="kern.entropy.collection"><a class="permalink" href="#kern.entropy.collection"><code class="Li">kern.entropy.collection</code></a> - (<var class="Vt">bool</var>)</dt> - <dd>(Default on.) Enables entering data into the entropy pool. If disabled, no - new data can be entered into the entropy pool, whether by device drivers, - by writes to <span class="Pa">/dev/random</span> or - <span class="Pa">/dev/urandom</span>, or by the - <code class="Dv">RNDADDDATA</code> ioctl.</dd> - <dt id="kern.entropy.depletion"><a class="permalink" href="#kern.entropy.depletion"><code class="Li">kern.entropy.depletion</code></a> - (<var class="Vt">bool</var>)</dt> - <dd>(Default off.) Enables ‘entropy depletion’, meaning that - even after attaining full entropy, the kernel subtracts the number of bits - read out of the entropy pool from its estimate of the system entropy. This - is not justified by modern cryptography — an adversary will never - guess the 256-bit secret in a Keccak sponge no matter how much output from - the sponge they see — but may be useful for testing.</dd> - <dt id="kern.entropy.consolidate"><a class="permalink" href="#kern.entropy.consolidate"><code class="Li">kern.entropy.consolidate</code></a> - (<var class="Vt">int</var>)</dt> - <dd>Trigger for entropy consolidation: executing - <p class="Pp"></p> - <div class="Bd Bd-indent"><code class="Li"># sysctl -w - kern.entropy.consolidate=1</code></div> - <p class="Pp">causes the system to consolidate pending entropy from per-CPU - pools into the global pool, and waits until done.</p> - </dd> -</dl> -<p class="Pp">The following read-only <a class="Xr">sysctl(8)</a> variables - provide information to privileged users about the state of the entropy - pool:</p> -<dl class="Bl-tag"> - <dt id="kern.entropy.needed"><a class="permalink" href="#kern.entropy.needed"><code class="Li">kern.entropy.needed</code></a> - (<var class="Vt">unsigned int</var>)</dt> - <dd>Number of bits of entropy the system is waiting for in the global pool - before reads from <span class="Pa">/dev/random</span> will return without - blocking. When zero, the system is considered to have full entropy.</dd> - <dt id="kern.entropy.pending"><a class="permalink" href="#kern.entropy.pending"><code class="Li">kern.entropy.pending</code></a> - (<var class="Vt">unsigned int</var>)</dt> - <dd>Number of bits of entropy pending in per-CPU pools. This is the amount of - entropy that will be contributed to the global pool at the next - consolidation, such as from triggering - <code class="Li">kern.entropy.consolidate</code>.</dd> -</dl> -<p class="Pp">The following read-only <a class="Xr">sysctl(8)</a> variables - provide information to any users, privileged or unprivileged:</p> -<dl class="Bl-tag"> - <dt id="kern.entropy.epoch"><a class="permalink" href="#kern.entropy.epoch"><code class="Li">kern.entropy.epoch</code></a> - (<var class="Vt">unsigned int</var>)</dt> - <dd>An integer that changes whenever the system determines applications should - reseed from the system entropy pool. This can happen for various reasons: - <ul class="Bl-dash Bl-compact"> - <li>The system has reached full entropy for the first time.</li> - <li>A virtual machine clone has been detected (e.g., by - <a class="Xr">acpivmgenid(4)</a>).</li> - <li>An operator has set - <code class="Li">kern.entropy.consolidate</code>.</li> - </ul> - <p class="Pp">Consulted by <a class="Xr">arc4random(3)</a>, and inside the - kernel by subsystems such as <a class="Xr">cprng(9)</a>, to decide - whether to reseed.</p> - <p class="Pp">Initially set to 2^32 - 1 (i.e., - <code class="Li">(unsigned)-1</code>) meaning the system has never - reached full entropy; never again set to 2^32 - 1. Never zero, so - applications can initialize a cache of the epoch to zero to ensure they - reseed the next time they check whether it is different from the stored - epoch.</p> - </dd> -</dl> -</section> -<section class="Sh"> -<h1 class="Sh" id="IMPLEMENTATION_NOTES"><a class="permalink" href="#IMPLEMENTATION_NOTES">IMPLEMENTATION - NOTES</a></h1> -<p class="Pp">(This section describes the current implementation of the - <code class="Nm">rnd</code> subsystem at the time of writing. It may be - out-of-date by the time you read it, and nothing in here should be construed - as a guarantee about the behaviour of the - <span class="Pa">/dev/random</span> and <span class="Pa">/dev/urandom</span> - devices.)</p> -<p class="Pp">Device drivers gather samples from entropy sources and absorb them - into a collection of per-CPU Keccak sponges called ‘entropy - pools’ using the <a class="Xr">rnd(9)</a> kernel API. The device - driver furnishes an estimate for the entropy of the sampling process, under - the assumption that each sample is independent. When the estimate of entropy - pending among the per-CPU entropy pools reaches a threshold of 256 bits, the - entropy is drawn from the per-CPU pools and consolidated into a global pool. - Keys for <span class="Pa">/dev/random</span>, - <span class="Pa">/dev/urandom</span>, <code class="Li">kern.arandom</code>, - and the in-kernel <a class="Xr">cprng(9)</a> subsystem are extracted from - the global pool.</p> -<p class="Pp">Early after boot, before CPUs have been detected, device drivers - instead enter directly into the global pool. If anything in the system - extracts data from the pool before the threshold has been reached at least - once, the system will print a warning to the console and reset the entropy - estimate to zero. The reason for resetting the entropy estimate to zero in - this case is that an adversary who can witness output from the pool with - partial entropy — say, 32 bits — can undergo a feasible brute - force search to ascertain the complete state of the pool; as such, the - entropy of the adversary's state of knowledge about the pool is zero.</p> -<p class="Pp">If the operator is confident that the drivers' estimates of the - entropy of the sampling processes are too conservative, the operator can - issue</p> -<p class="Pp"></p> -<div class="Bd Bd-indent"><code class="Li"># sysctl -w - kern.entropy.consolidate=1</code></div> -<p class="Pp">to force consolidation into the global pool. The operator can also - fool the system into thinking it has more entropy than it does by feeding - data from <span class="Pa">/dev/urandom</span> into - <span class="Pa">/dev/random</span>, but this voids the security model and - should be limited to testing purposes.</p> -<p class="Pp" id="Short"><a class="permalink" href="#Short"><i class="Em">Short</i></a> - reads from <span class="Pa">/dev/urandom</span> are served by a persistent - per-CPU Hash_DRBG instance that is reseeded from the entropy pool after any - entropy consolidation. Reads from <span class="Pa">/dev/random</span> and - <a class="permalink" href="#long"><i class="Em" id="long">long</i></a> reads - from <span class="Pa">/dev/urandom</span> are served by a temporary - Hash_DRBG seeded from the entropy pool on each read.</p> -<p class="Pp">When ‘entropy depletion’ is enabled by setting the - sysctl variable <code class="Li">kern.entropy.depletion</code> to 1, every - read from <span class="Pa">/dev/random</span> is limited to 256 bits, since - reading more than that would nearly always block again.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="FILES"><a class="permalink" href="#FILES">FILES</a></h1> -<dl class="Bl-tag Bl-compact"> - <dt><span class="Pa">/dev/random</span></dt> - <dd>Uniform random byte source. May block.</dd> - <dt><span class="Pa">/dev/urandom</span></dt> - <dd>Uniform random byte source. Never blocks.</dd> -</dl> -</section> -<section class="Sh"> -<h1 class="Sh" id="DIAGNOSTICS"><a class="permalink" href="#DIAGNOSTICS">DIAGNOSTICS</a></h1> -<p class="Pp">The <code class="Nm">rnd</code> subsystem may print the following - warnings to the console likely indicating security issues:</p> -<dl class="Bl-diag Bd-indent"> - <dt>WARNING: system needs entropy for security; see entropy(7)</dt> - <dd>A process tried to draw from the entropy pool before enough inputs from - reliable entropy sources have been entered. - <p class="Pp">The entropy may be low enough that an adversary who sees the - output could guess the state of the pool by brute force, so in this - event the system resets its estimate of entropy to none.</p> - <p class="Pp">This message is rate-limited to happen no more often than once - per minute, so if you want to make sure it is gone you should consult - <code class="Li">kern.entropy.needed</code> to confirm it is zero.</p> - </dd> -</dl> -<p class="Pp">The <code class="Nm">rnd</code> subsystem may print any of various - messages about obtaining an entropy seed from the bootloader to diagnose - saving and loading seeds on disk:</p> -<dl class="Bl-diag Bd-indent"> - <dt>entropy: entering seed from bootloader with N bits of entropy</dt> - <dd>The bootloader provided an entropy seed to the kernel, which recorded an - estimate of N bits of entropy in the process that generated it.</dd> - <dt>entropy: no seed from bootloader</dt> - <dd>The bootloader did not provide an entropy seed to the kernel before - starting the kernel. This does not necessarily indicate a problem; not all - bootloaders support the option, and the <a class="Xr">rc.conf(5)</a> - setting <code class="Li">random_seed=YES</code> can serve instead.</dd> - <dt>entropy: invalid seed length N, expected sizeof(rndsave_t) = M</dt> - <dd>The bootloader provided an entropy seed of the wrong size to the kernel. - This may indicate a bug in <a class="Xr">rndctl(8)</a>. The seed will be - ignored.</dd> - <dt>entropy: invalid seed checksum</dt> - <dd>The entropy seed provided by the bootloader was malformed. The seed will - be entered into the entropy pool, but it will be considered to contribute - no entropy.</dd> - <dt>entropy: double-seeded by bootloader</dt> - <dd>A buggy bootloader tried to provide an entropy seed more than once to the - kernel. Subsequent seeds will be entered into the entropy pool, but they - will be considered to contribute no entropy.</dd> - <dt>entropy: best effort</dt> - <dd>The system has gathered enough samples from interrupt timings and other - non-confident sources of entropy for the first time to unblock - <span class="Pa">/dev/random</span>, but it may not have full entropy from - a seed or hardware random number generator.</dd> - <dt>entropy: ready</dt> - <dd>The system has full entropy for the first time.</dd> -</dl> -</section> -<section class="Sh"> -<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE - ALSO</a></h1> -<p class="Pp"><a class="Xr">arc4random(3)</a>, <a class="Xr">acpivmgenid(4)</a>, - <a class="Xr">entropy(7)</a>, <a class="Xr">rndctl(8)</a>, - <a class="Xr">cprng(9)</a>, <a class="Xr">rnd(9)</a></p> -<p class="Pp"><cite class="Rs"><span class="RsA">Elaine Barker</span> and - <span class="RsA">John Kelsey</span>, <span class="RsT">Recommendation for - Random Number Generation Using Deterministic Random Bit Generators</span>, - <i class="RsI">National Institute of Standards and Technology</i>, - <a class="RsU" href="https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final">https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final</a>, - <span class="RsQ">United States Department of Commerce</span>, - <span class="RsD">June 2015</span>, <span class="RsO">NIST Special - Publication 800-90A, Revision 1</span>.</cite></p> -<p class="Pp"><cite class="Rs"><span class="RsA">Meltem Sönmez - Turan</span>, <span class="RsA">Elaine Barker</span>, <span class="RsA">John - Kelsey</span>, <span class="RsA">Kerry A. McKay</span>, - <span class="RsA">Mary L. Baish</span>, and <span class="RsA">Mike - Boyle</span>, <span class="RsT">Recommendations for the Entropy Sources Used - for Random Bit Generation</span>, <i class="RsI">National Institute of - Standards and Technology</i>, - <a class="RsU" href="https://csrc.nist.gov/publications/detail/sp/800-90b/final">https://csrc.nist.gov/publications/detail/sp/800-90b/final</a>, - <span class="RsQ">United States Department of Commerce</span>, - <span class="RsD">January 2018</span>, <span class="RsO">NIST Special - Publication 800-90B</span>.</cite></p> -<p class="Pp"><cite class="Rs"><span class="RsA">Daniel J. Bernstein</span>, - <span class="RsT">Entropy Attacks!</span>, - <a class="RsU" href="http://blog.cr.yp.to/20140205-entropy.html">http://blog.cr.yp.to/20140205-entropy.html</a>, - <span class="RsD">2014-02-05</span>.</cite></p> -<p class="Pp"><cite class="Rs"><span class="RsA">Nadia Heninger</span>, - <span class="RsA">Zakir Durumeric</span>, <span class="RsA">Eric - Wustrow</span>, and <span class="RsA">J. Alex Halderman</span>, - <span class="RsT">Mining Your Ps and Qs: Detection of Widespread Weak Keys - in Network Devices</span>, <i class="RsB">Proceedings of the 21st USENIX - Security Symposium</i>, <i class="RsI">USENIX</i>, - <a class="RsU" href="https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger">https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger</a>, - <a class="RsU" href="https://factorable.net/">https://factorable.net/</a>, - <span class="RsP">205-220</span>, <span class="RsD">August - 2012</span>.</cite></p> -<p class="Pp"><cite class="Rs"><span class="RsA">Edwin T. Jaynes</span>, - <i class="RsB">Probability Theory: The Logic of Science</i>, - <i class="RsI">Cambridge University Press</i>, - <a class="RsU" href="https://bayes.wustl.edu/">https://bayes.wustl.edu/</a>, - <span class="RsD">2003</span>.</cite></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1> -<p class="Pp">The <span class="Pa">/dev/random</span> and - <span class="Pa">/dev/urandom</span> devices first appeared in - <span class="Ux">NetBSD 1.3</span>.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1> -<p class="Pp">The <code class="Nm">rnd</code> subsystem was first implemented by - <span class="An">Michael Graff</span> - <<a class="Mt" href="mailto:explorer@flame.org">explorer@flame.org</a>>, - was then largely rewritten by <span class="An">Thor Lancelot Simon</span> - <<a class="Mt" href="mailto:tls@NetBSD.org">tls@NetBSD.org</a>>, and - was most recently largely rewritten by <span class="An">Taylor R. - Campbell</span> - <<a class="Mt" href="mailto:riastradh@NetBSD.org">riastradh@NetBSD.org</a>>.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="BUGS"><a class="permalink" href="#BUGS">BUGS</a></h1> -<p class="Pp">Many people are confused about what - <span class="Pa">/dev/random</span> and <span class="Pa">/dev/urandom</span> - mean. Unfortunately, no amount of software engineering can fix that.</p> -</section> -</div> -<table class="foot"> - <tr> - <td class="foot-date">August 27, 2024</td> - <td class="foot-os">NetBSD 10.1</td> - </tr> -</table> |