xref: /netbsd-src/share/man/man9/rnd.9 (revision 5bbd2a12505d72a8177929a37b5cee489d0a1cfd)
1.\"	$NetBSD: rnd.9,v 1.22 2012/07/12 00:07:36 pgoyette Exp $
2.\"
3.\" Copyright (c) 1997 The NetBSD Foundation, Inc.
4.\" All rights reserved.
5.\"
6.\" This documentation is derived from text contributed to The NetBSD
7.\" Foundation by S.P.Zeidler (aka stargazer).
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 December 17, 2011
31.Dt RND 9
32.Os
33.Sh NAME
34.Nm RND ,
35.Nm rnd_attach_source ,
36.Nm rnd_detach_source ,
37.Nm rnd_add_data ,
38.Nm rnd_add_uint32
39.Nd functions to make a device available for entropy collection
40.Sh SYNOPSIS
41.In sys/rnd.h
42.Ft void
43.Fn rnd_attach_source "krndsource_t *rnd_source" "char *devname" "uint32_t source_type" "uint32_t flags"
44.Ft void
45.Fn rnd_detach_source "krndsource_t *rnd_source"
46.Ft void
47.Fn rnd_add_data "krndsource_t *rnd_source" "void *data" "uint32_t len" "uint32_t entropy"
48.Ft void
49.Fn rnd_add_uint32 "krndsource_t *rnd_source" "uint32_t datum"
50.Sh DESCRIPTION
51These
52.Nm
53functions make a device available for entropy collection for
54the kernel entropy pool, which provides key material for the
55.Xr cprng 9
56and
57.Xr rnd 4
58.Pa ( /dev/random )
59interfaces.
60.Pp
61Ideally the first argument
62.Fa rnd_source
63of these functions gets included in the devices' entity struct,
64but any means to permanently (statically) attach one such argument
65to one incarnation of the device is ok.
66Do not share
67.Fa rnd_source
68structures between two devices.
69.Pp
70.Bl -tag -width 8n
71.It Fn rnd_attach_source "krndsource_t *rnd_source" "char *devname" "uint32_t source_type" "uint32_t flags"
72This function announces the availability of a device for entropy collection.
73It must be called before the source struct pointed to by
74.Fa rnd_source
75is used in any of the following functions.
76.Pp
77.Fa devname
78is the name of the device.
79It is used to print a message (if the kernel is compiled with
80``options RND_VERBOSE'') and also for status information printed with
81.Xr rndctl 8 .
82.Pp
83.Fa source_type
84is
85.Dv RND_TYPE_NET
86for network devices,
87.Dv RND_TYPE_DISK
88for physical disks,
89.Dv RND_TYPE_TAPE
90for a tape drive,
91.Dv RND_TYPE_TTY
92for a tty,
93.Dv RND_TYPE_RNG
94for a random number generator, and
95.Dv RND_TYPE_ENV
96for an environment sensor.
97.Dv RND_TYPE_UNKNOWN
98is not to be used as a type.
99It is used internally to the rnd system.
100.Pp
101.Fa flags
102are the logical OR of
103.Dv RND_FLAG_NO_COLLECT
104(don't collect or estimate)
105.Dv RND_FLAG_NO_ESTIMATE
106(don't estimate)
107to control the default setting for collection and estimation.
108Note that devices of type
109.Dv RND_TYPE_NET
110default to
111.Dv RND_FLAG_NO_ESTIMATE .
112.Pp
113.It Fn rnd_detach_source "krndsource_t *rnd_source"
114This function disconnects the device from entropy collection.
115.It Fn rnd_add_uint32 "krndsource_t *rnd_source" "uint32_t datum"
116This function adds the value of
117.Va datum
118to the entropy pool.
119No entropy is assumed to be collected from this value, it merely helps
120stir the entropy pool.
121All entropy is gathered from jitter between the timing of events.
122.Pp
123Note that using a constant for
124.Va datum
125does not weaken security, but it does
126not help.
127Try to use something that can change, such as an interrupt status register
128which might have a bit set for receive ready or transmit ready, or other
129device status information.
130.Pp
131To allow the system to gather the timing information accurately, this call
132should be placed within the actual hardware interrupt service routine.
133Care must be taken to ensure that the interrupt was actually serviced by
134the interrupt handler, since on some systems interrupts can be shared.
135.Pp
136This function loses nearly all usefulness if it is called from a scheduled
137software interrupt.
138If that is the only way to add the device as an entropy source, don't.
139.Pp
140If it is desired to mix in the
141.Va datum
142and to add in a timestamp, but not to actually estimate entropy from a source
143of randomness, passing
144.Dv NULL
145for
146.Va rnd_source
147is permitted, and the device does not need to be attached.
148.It Fn rnd_add_data "krndsource_t *rnd_source" "void *data" "uint32_t len" "uint32_t entropy"
149adds (hopefully) random
150.Fa data
151to the entropy pool.
152.Fa len
153is the number of bytes in
154.Fa data
155and
156.Fa entropy
157is an "entropy quality" measurement.
158If every bit of
159.Fa data
160is known to be random,
161.Fa entropy
162is the number of bits in
163.Fa data .
164.Pp
165Timing information is also used to add entropy into the system, using
166inter-event timings.
167.Pp
168If it is desired to mix in the
169.Va data
170and to add in a timestamp, but not to actually estimate entropy from a source
171of randomness, passing
172.Dv NULL
173for
174.Va rnd_source
175is permitted, and the device does not need to be attached.
176.El
177.Sh INTERNAL ENTROPY POOL MANAGEMENT
178When a hardware event occurs (such as completion of a hard drive
179transfer or an interrupt from a network device) a timestamp is
180generated.
181This timestamp is compared to the previous timestamp
182recorded for the device, and the first, second, and third order
183differentials are calculated.
184.Pp
185If any of these differentials is zero, no entropy is assumed to
186have been gathered.
187If all are non-zero, one bit is assumed.
188Next, data is mixed into the entropy pool using an LFSR (linear
189feedback shift register).
190.Pp
191To extract data from the entropy pool, a cryptographically strong hash
192function is used.
193The output of this hash is mixed back into the pool using the LFSR,
194and then folded in half before being returned to the caller.
195.Pp
196Mixing the actual hash into the pool causes the next extraction to
197return a different value, even if no timing events were added to the
198pool.
199Folding the data in half prevents the caller to derive the
200actual hash of the pool, preventing some attacks.
201.Pp
202In the
203.Nx
204kernel, values should be extracted from the entropy pool
205.Em only
206via the
207.Xr cprng 9
208interface.
209Direct access to the entropy pool is unsupported and may be dangerous.
210There is no supported API for direct access to the output of the entropy pool.
211.\" .Sh ERRORS
212.Sh FILES
213These functions are declared in src/sys/sys/rnd.h and defined in
214src/sys/kern/kern_rndq.c.
215.Sh SEE ALSO
216.Xr rnd 4 ,
217.Xr rndctl 8 ,
218.Xr cprng 9
219.Sh HISTORY
220The random device was introduced in
221.Nx 1.3 .
222.Sh AUTHORS
223This implementation was written by Michael Graff \*[Lt]explorer@flame.org\*[Gt]
224using ideas and algorithms gathered from many sources, including
225the driver written by Ted Ts'o.
226.Sh BUGS
227The only good sources of randomness are quantum mechanical, and most
228computers avidly avoid having true sources of randomness included.
229Don't expect to surpass "pretty good".
230