1 .\" $NetBSD: libcrypto.pl,v 1.3 2007/11/27 22:16:03 christos Exp $
3 .\" Automatically generated by Pod::Man 2.16 (Pod::Simple 3.05)
6 .\" ========================================================================
7 .de Sh \" Subsection heading
15 .de Sp \" Vertical space (when we can't use .PP)
19 .de Vb \" Begin verbatim text
24 .de Ve \" End verbatim text
28 .\" Set up some character translations and predefined strings. \*(-- will
29 .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
30 .\" double quote, and \*(R" will give a right double quote. \*(C+ will
31 .\" give a nicer C++. Capital omega is used to do unbreakable dashes and
32 .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
33 .\" nothing in troff, for use with C<>.
35 .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
39 . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
40 . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
53 .\" Escape single quotes in literal strings from groff's Unicode transform.
57 .\" If the F register is turned on, we'll generate index entries on stderr for
58 .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
59 .\" entries marked with X<> in POD. Of course, you'll have to process the
60 .\" output yourself in some meaningful fashion.
63 . tm Index:\\$1\t\\n%\t"\\$2"
73 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
74 .\" Fear. Run. Save yourself. No user-serviceable parts.
75 . \" fudge factors for nroff and troff
84 . ds #H ((1u-(\\\\n(.fu%2u))*.13m)
90 . \" simple accents for nroff and troff
100 . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
101 . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
102 . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
103 . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
104 . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
105 . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
107 . \" troff and (daisy-wheel) nroff accents
108 .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
109 .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
110 .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
111 .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
112 .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
113 .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
114 .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
115 .ds ae a\h'-(\w'a'u*4/10)'e
116 .ds Ae A\h'-(\w'A'u*4/10)'E
117 . \" corrections for vroff
118 .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
119 .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
120 . \" for low resolution devices (crt and lpr)
121 .if \n(.H>23 .if \n(.V>19 \
134 .\" ========================================================================
137 .TH rand 3 "2002-08-05" "1.1.0-dev" "OpenSSL"
138 .\" For nroff, turn off justification. Always turn off hyphenation; it makes
139 .\" way too many mistakes in technical documents.
143 rand \- pseudo\-random number generator
147 .IX Header "SYNOPSIS"
149 \& #include <openssl/rand.h>
151 \& int RAND_set_rand_engine(ENGINE *engine);
153 \& int RAND_bytes(unsigned char *buf, int num);
154 \& int RAND_pseudo_bytes(unsigned char *buf, int num);
156 \& void RAND_seed(const void *buf, int num);
157 \& void RAND_add(const void *buf, int num, int entropy);
158 \& int RAND_status(void);
160 \& int RAND_load_file(const char *file, long max_bytes);
161 \& int RAND_write_file(const char *file);
162 \& const char *RAND_file_name(char *file, size_t num);
164 \& int RAND_egd(const char *path);
166 \& void RAND_set_rand_method(const RAND_METHOD *meth);
167 \& const RAND_METHOD *RAND_get_rand_method(void);
168 \& RAND_METHOD *RAND_SSLeay(void);
170 \& void RAND_cleanup(void);
172 \& /* For Win32 only */
173 \& void RAND_screen(void);
174 \& int RAND_event(UINT, WPARAM, LPARAM);
177 .IX Header "DESCRIPTION"
178 Since the introduction of the \s-1ENGINE\s0 \s-1API\s0, the recommended way of controlling
179 default implementations is by using the \s-1ENGINE\s0 \s-1API\s0 functions. The default
180 \&\fB\s-1RAND_METHOD\s0\fR, as set by \fIRAND_set_rand_method()\fR and returned by
181 \&\fIRAND_get_rand_method()\fR, is only used if no \s-1ENGINE\s0 has been set as the default
182 \&\*(L"rand\*(R" implementation. Hence, these two functions are no longer the recommened
183 way to control defaults.
185 If an alternative \fB\s-1RAND_METHOD\s0\fR implementation is being used (either set
186 directly or as provided by an \s-1ENGINE\s0 module), then it is entirely responsible
187 for the generation and management of a cryptographically secure \s-1PRNG\s0 stream. The
188 mechanisms described below relate solely to the software \s-1PRNG\s0 implementation
189 built in to OpenSSL and used by default.
191 These functions implement a cryptographically secure pseudo-random
192 number generator (\s-1PRNG\s0). It is used by other library functions for
193 example to generate random keys, and applications can use it when they
196 A cryptographic \s-1PRNG\s0 must be seeded with unpredictable data such as
197 mouse movements or keys pressed at random by the user. This is
198 described in \fIRAND_add\fR\|(3). Its state can be saved in a seed file
199 (see \fIRAND_load_file\fR\|(3)) to avoid having to go through the
200 seeding process whenever the application is started.
202 \&\fIRAND_bytes\fR\|(3) describes how to obtain random data from the
205 .IX Header "INTERNALS"
206 The \fIRAND_SSLeay()\fR method implements a \s-1PRNG\s0 based on a cryptographic
209 The following description of its design is based on the SSLeay
212 First up I will state the things I believe I need for a good \s-1RNG\s0.
214 A good hashing algorithm to mix things up and to convert the \s-1RNG\s0 'state'
217 An initial source of random 'state'.
219 The state should be very large. If the \s-1RNG\s0 is being used to generate
220 4096 bit \s-1RSA\s0 keys, 2 2048 bit random strings are required (at a minimum).
221 If your \s-1RNG\s0 state only has 128 bits, you are obviously limiting the
222 search space to 128 bits, not 2048. I'm probably getting a little
223 carried away on this last point but it does indicate that it may not be
224 a bad idea to keep quite a lot of \s-1RNG\s0 state. It should be easier to
225 break a cipher than guess the \s-1RNG\s0 seed data.
227 Any \s-1RNG\s0 seed data should influence all subsequent random numbers
228 generated. This implies that any random seed data entered will have
229 an influence on all subsequent random numbers generated.
231 When using data to seed the \s-1RNG\s0 state, the data used should not be
232 extractable from the \s-1RNG\s0 state. I believe this should be a
233 requirement because one possible source of 'secret' semi random
234 data would be a private key or a password. This data must
235 not be disclosed by either subsequent random numbers or a
236 \&'core' dump left by a program crash.
238 Given the same initial 'state', 2 systems should deviate in their \s-1RNG\s0 state
239 (and hence the random numbers generated) over time if at all possible.
241 Given the random number output stream, it should not be possible to determine
242 the \s-1RNG\s0 state or the next random number.
244 The algorithm is as follows.
246 There is global state made up of a 1023 byte buffer (the 'state'), a
247 working hash value ('md'), and a counter ('count').
249 Whenever seed data is added, it is inserted into the 'state' as
252 The input is chopped up into units of 20 bytes (or less for
253 the last block). Each of these blocks is run through the hash
254 function as follows: The data passed to the hash function
255 is the current 'md', the same number of bytes from the 'state'
256 (the location determined by in incremented looping index) as
257 the current 'block', the new key data 'block', and 'count'
258 (which is incremented after each use).
259 The result of this is kept in 'md' and also xored into the
260 \&'state' at the same locations that were used as input into the
262 believe this system addresses points 1 (hash function; currently
263 \&\s-1SHA\-1\s0), 3 (the 'state'), 4 (via the 'md'), 5 (by the use of a hash
266 When bytes are extracted from the \s-1RNG\s0, the following process is used.
267 For each group of 10 bytes (or less), we do the following:
269 Input into the hash function the local 'md' (which is initialized from
270 the global 'md' before any bytes are generated), the bytes that are to
271 be overwritten by the random bytes, and bytes from the 'state'
272 (incrementing looping index). From this digest output (which is kept
273 in 'md'), the top (up to) 10 bytes are returned to the caller and the
274 bottom 10 bytes are xored into the 'state'.
276 Finally, after we have finished 'num' random bytes for the caller,
277 \&'count' (which is incremented) and the local and global 'md' are fed
278 into the hash function and the results are kept in the global 'md'.
280 I believe the above addressed points 1 (use of \s-1SHA\-1\s0), 6 (by hashing
281 into the 'state' the 'old' data from the caller that is about to be
282 overwritten) and 7 (by not using the 10 bytes given to the caller to
283 update the 'state', but they are used to update 'md').
285 So of the points raised, only 2 is not addressed (but see
286 \&\fIRAND_add\fR\|(3)).
288 .IX Header "SEE ALSO"
289 \&\fIBN_rand\fR\|(3), \fIRAND_add\fR\|(3),
290 \&\fIRAND_load_file\fR\|(3), \fIRAND_egd\fR\|(3),
291 \&\fIRAND_bytes\fR\|(3),
292 \&\fIRAND_set_rand_method\fR\|(3),
293 \&\fIRAND_cleanup\fR\|(3)