xref: /minix3/lib/libc/gen/arc4random.3 (revision 0a6a1f1d05b60e214de2f05a7310ddd1f0e590e7)
1.\"	$NetBSD: arc4random.3,v 1.19 2014/11/17 18:41:29 riastradh Exp $
2.\"
3.\" Copyright (c) 2014 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 November 16, 2014
31.Dt ARC4RANDOM 3
32.Os
33.Sh NAME
34.Nm arc4random ,
35.Nm arc4random_uniform ,
36.Nm arc4random_buf ,
37.Nm arc4random_stir ,
38.Nm arc4random_addrandom
39.Nd random number generator
40.Sh LIBRARY
41.Lb libc
42.Sh SYNOPSIS
43.In stdlib.h
44.Ft uint32_t
45.Fn arc4random "void"
46.Ft uint32_t
47.Fn arc4random_uniform "uint32_t bound"
48.Ft void
49.Fn arc4random_buf "void *buf" "size_t len"
50.Ft void
51.Fn arc4random_stir "void"
52.Ft void
53.Fn arc4random_addrandom "unsigned char *buf" "int len"
54.Sh DESCRIPTION
55The
56.Nm
57family of functions provides a cryptographic pseudorandom number
58generator automatically seeded from the system entropy pool and safe to
59use from multiple threads.
60.Nm
61is designed to prevent an adversary from guessing outputs,
62unlike
63.Xr rand 3
64and
65.Xr random 3 ,
66and is faster and more convenient than reading from
67.Pa /dev/urandom
68directly.
69.Pp
70.Fn arc4random
71returns an integer in [0, 2^32) chosen independently with uniform
72distribution.
73.Pp
74.Fn arc4random_uniform
75returns an integer in [0,
76.Fa bound )
77chosen independently with uniform distribution.
78.Pp
79.Fn arc4random_buf
80stores
81.Fa len
82bytes into the memory pointed to by
83.Fa buf ,
84each byte chosen independently from [0, 256) with uniform
85distribution.
86.Pp
87.Fn arc4random_stir
88draws entropy from the operating system and incorporates it into the
89library's PRNG state to influence future outputs.
90.Pp
91.Fn arc4random_addrandom
92incorporates
93.Fa len
94bytes, which must be nonnegative, from the buffer
95.Fa buf ,
96into the library's PRNG state to influence future outputs.
97.Pp
98It is not necessary for an application to call
99.Fn arc4random_stir
100or
101.Fn arc4random_addrandom
102before calling other
103.Nm
104functions.
105The first call to any
106.Nm
107function will initialize the PRNG state unpredictably from the system
108entropy pool.
109.Sh SECURITY MODEL
110The
111.Nm
112functions provide the following security properties against three
113different classes of attackers, assuming enough entropy is provided by
114the operating system:
115.Bl -bullet -offset abcd
116.It
117An attacker who has seen some outputs of any of the
118.Nm
119functions cannot predict past or future unseen outputs.
120.It
121An attacker who has seen the library's PRNG state in memory cannot
122predict past outputs.
123.It
124An attacker who has seen one process's PRNG state cannot predict past
125or future outputs in other processes, particularly its parent or
126siblings.
127.El
128.Pp
129One
130.Sq output
131means the result of any single request to an
132.Nm
133function, no matter how short it is.
134.Sh IMPLEMENTATION NOTES
135The
136.Nm
137functions are currently implemented using the ChaCha20 pseudorandom
138function family.
139For any 32-byte string
140.Fa s ,
141.Pf ChaCha20_ Fa s
142is a function from 16-byte strings to 64-byte strings.
143It is conjectured that if
144.Fa s
145is chosen with uniform distribution, then the distribution on
146.Pf ChaCha20_ Fa s
147is indistinguishable to a computationally bounded adversary from a
148uniform distribution on all functions from 16-byte strings to 64-byte
149strings.
150.Pp
151The PRNG state is a 32-byte ChaCha20 key
152.Fa s .
153Each request to
154an
155.Nm
156function
157.Bl -bullet -offset abcd -compact
158.It
159computes the 64-byte quantity
160.Fa x
161=
162.Pf ChaCha20_ Fa s Ns (0),
163.It
164splits
165.Fa x
166into two 32-byte quantities
167.Fa s'
168and
169.Fa k ,
170.It
171replaces
172.Fa s
173by
174.Fa s' ,
175and
176.It
177uses
178.Fa k
179as output.
180.El
181.Pp
182.Fn arc4random
183yields the first four bytes of
184.Fa k
185as output directly.
186.Fn arc4random_buf
187either yields up to 32 bytes of
188.Fa k
189as output directly, or, for longer
190requests, uses
191.Fa k
192as a ChaCha20 key and yields the concatenation
193.Pf ChaCha20_ Fa k Ns (0)
194||
195.Pf ChaCha20_ Fa k Ns (1)
196|| ... as output.
197.Fn arc4random_uniform
198repeats
199.Fn arc4random
200until it obtains an integer in [2^32 %
201.Fa bound ,
2022^32), and reduces that modulo
203.Fa bound .
204.Pp
205The PRNG state is per-thread, unless memory allocation fails inside the
206library, in which case some threads may share global PRNG state with a
207mutex.
208The global PRNG state is zeroed on fork in the parent via
209.Xr pthread_atfork 3 ,
210and the per-thread PRNG state is zeroed on fork in the child via
211.Xr minherit 2
212with
213.Dv MAP_INHERIT_ZERO ,
214so that the child cannot reuse or see the parent's PRNG state.
215The PRNG state is reseeded automatically from the system entropy pool
216on the first use of an
217.Nm
218function after zeroing.
219.Pp
220The first use of an
221.Nm
222function may abort the process in the highly unlikely event that
223library initialization necessary to implement the security model fails.
224Additionally,
225.Fn arc4random_stir
226and
227.Fn arc4random_addrandom
228may abort the process in the highly unlikely event that the operating
229system fails to provide entropy.
230.Sh SEE ALSO
231.Xr rand 3 ,
232.Xr random 3 ,
233.Xr rnd 4 ,
234.Xr cprng 9
235.Rs
236.%A Daniel J. Bernstein
237.%T ChaCha, a variant of Salsa20
238.%D 2008-01-28
239.%O Document ID: 4027b5256e17b9796842e6d0f68b0b5e
240.%U http://cr.yp.to/papers.html#chacha
241.Re
242.Sh BUGS
243There is no way to get deterministic, reproducible results out of
244.Nm
245for testing purposes.
246.Pp
247The name
248.Sq arc4random
249was chosen for hysterical raisins -- it was originally implemented
250using the RC4 stream cipher, which has been known since shortly after
251it was published in 1994 to have observable biases in the output, and
252is now known to be broken badly enough to admit practical attacks in
253the real world.
254.\" Bob Jenkins, sci.crypt post dated 1994-09-16, message-id
255.\" <359qjg$55v$1@mhadg.production.compuserve.com>,
256.\" https://groups.google.com/d/msg/sci.crypt/JsO3xEATGFA/-wO4ttv7BCYJ
257.\"
258.\" Andrew Roos, `A Class of Weak Keys in the RC4 Stream Cipher',
259.\" sci.crypt posts dated 1995-09-22, message-ids
260.\" <43u1eh$1j3@hermes.is.co.za> and <44ebge$llf@hermes.is.co.za>.
261.\"
262.\" Paul Crowley, `Small bias in RC4 experimentally verified', March
263.\" 1998, http://www.ciphergoth.org/crypto/rc4/
264Unfortunately, the library found widespread adoption and the name stuck
265before anyone recognized that it was silly.
266.Pp
267The signature of
268.Fn arc4random_addrandom
269is silly.
270There is no reason to require casts or accept negative lengths:
271it should take a
272.Vt void *
273buffer and a
274.Vt size_t
275length.
276But it's too late to change that now.
277.Pp
278.Fn arc4random_uniform
279does not help to choose integers in [0,
280.Fa n )
281uniformly at random when
282.Fa n
283> 2^32.
284.Pp
285The security model of
286.Nm
287is stronger than many applications need, and stronger than other
288operating systems provide.
289For example, applications encrypting messages with random, but not
290secret, initialization vectors need only prevent an adversary from
291guessing future outputs, since past outputs will have been published
292already.
293.Pp
294On the one hand,
295.Nm
296could be marginally faster if it were not necessary to prevent an
297adversary who sees the state from predicting past outputs.
298On the other hand, there are applications in the wild that use
299.Nm
300to generate key material, such as OpenSSH, so for the sake of
301.Nx
302users it would be imprudent to weaken the security model.
303On the third hand, relying on the security model of
304.Nm
305in
306.Nx
307may lead you to an unpleasant surprise on another operating system
308whose implementation of
309.Nm
310has a weaker security model.
311.Pp
312One may be tempted to create new APIs to accommodate different
313security models and performance constraints without unpleasant
314surprises on different operating systems.
315This should not be done lightly, though, because there are already too
316many different choices, and too many opportunities for programmers to
317reach for one and pick the wrong one.
318