| 1 | .\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.23) |
| 2 | .\" |
| 3 | .\" Standard preamble: |
| 4 | .\" ======================================================================== |
| 5 | .de Sp \" Vertical space (when we can't use .PP) |
| 6 | .if t .sp .5v |
| 7 | .if n .sp |
| 8 | .. |
| 9 | .de Vb \" Begin verbatim text |
| 10 | .ft CW |
| 11 | .nf |
| 12 | .ne \\$1 |
| 13 | .. |
| 14 | .de Ve \" End verbatim text |
| 15 | .ft R |
| 16 | .fi |
| 17 | .. |
| 18 | .\" Set up some character translations and predefined strings. \*(-- will |
| 19 | .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left |
| 20 | .\" double quote, and \*(R" will give a right double quote. \*(C+ will |
| 21 | .\" give a nicer C++. Capital omega is used to do unbreakable dashes and |
| 22 | .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, |
| 23 | .\" nothing in troff, for use with C<>. |
| 24 | .tr \(*W- |
| 25 | .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' |
| 26 | .ie n \{\ |
| 27 | . ds -- \(*W- |
| 28 | . ds PI pi |
| 29 | . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch |
| 30 | . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch |
| 31 | . ds L" "" |
| 32 | . ds R" "" |
| 33 | . ds C` "" |
| 34 | . ds C' "" |
| 35 | 'br\} |
| 36 | .el\{\ |
| 37 | . ds -- \|\(em\| |
| 38 | . ds PI \(*p |
| 39 | . ds L" `` |
| 40 | . ds R" '' |
| 41 | 'br\} |
| 42 | .\" |
| 43 | .\" Escape single quotes in literal strings from groff's Unicode transform. |
| 44 | .ie \n(.g .ds Aq \(aq |
| 45 | .el .ds Aq ' |
| 46 | .\" |
| 47 | .\" If the F register is turned on, we'll generate index entries on stderr for |
| 48 | .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index |
| 49 | .\" entries marked with X<> in POD. Of course, you'll have to process the |
| 50 | .\" output yourself in some meaningful fashion. |
| 51 | .ie \nF \{\ |
| 52 | . de IX |
| 53 | . tm Index:\\$1\t\\n%\t"\\$2" |
| 54 | .. |
| 55 | . nr % 0 |
| 56 | . rr F |
| 57 | .\} |
| 58 | .el \{\ |
| 59 | . de IX |
| 60 | .. |
| 61 | .\} |
| 62 | .\" |
| 63 | .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). |
| 64 | .\" Fear. Run. Save yourself. No user-serviceable parts. |
| 65 | . \" fudge factors for nroff and troff |
| 66 | .if n \{\ |
| 67 | . ds #H 0 |
| 68 | . ds #V .8m |
| 69 | . ds #F .3m |
| 70 | . ds #[ \f1 |
| 71 | . ds #] \fP |
| 72 | .\} |
| 73 | .if t \{\ |
| 74 | . ds #H ((1u-(\\\\n(.fu%2u))*.13m) |
| 75 | . ds #V .6m |
| 76 | . ds #F 0 |
| 77 | . ds #[ \& |
| 78 | . ds #] \& |
| 79 | .\} |
| 80 | . \" simple accents for nroff and troff |
| 81 | .if n \{\ |
| 82 | . ds ' \& |
| 83 | . ds ` \& |
| 84 | . ds ^ \& |
| 85 | . ds , \& |
| 86 | . ds ~ ~ |
| 87 | . ds / |
| 88 | .\} |
| 89 | .if t \{\ |
| 90 | . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" |
| 91 | . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' |
| 92 | . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' |
| 93 | . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' |
| 94 | . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' |
| 95 | . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' |
| 96 | .\} |
| 97 | . \" troff and (daisy-wheel) nroff accents |
| 98 | .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' |
| 99 | .ds 8 \h'\*(#H'\(*b\h'-\*(#H' |
| 100 | .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] |
| 101 | .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' |
| 102 | .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' |
| 103 | .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] |
| 104 | .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] |
| 105 | .ds ae a\h'-(\w'a'u*4/10)'e |
| 106 | .ds Ae A\h'-(\w'A'u*4/10)'E |
| 107 | . \" corrections for vroff |
| 108 | .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' |
| 109 | .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' |
| 110 | . \" for low resolution devices (crt and lpr) |
| 111 | .if \n(.H>23 .if \n(.V>19 \ |
| 112 | \{\ |
| 113 | . ds : e |
| 114 | . ds 8 ss |
| 115 | . ds o a |
| 116 | . ds d- d\h'-1'\(ga |
| 117 | . ds D- D\h'-1'\(hy |
| 118 | . ds th \o'bp' |
| 119 | . ds Th \o'LP' |
| 120 | . ds ae ae |
| 121 | . ds Ae AE |
| 122 | .\} |
| 123 | .rm #[ #] #H #V #F C |
| 124 | .\" ======================================================================== |
| 125 | .\" |
| 126 | .IX Title "rand 3" |
| 127 | .TH rand 3 "2013-02-11" "1.0.1e" "OpenSSL" |
| 128 | .\" For nroff, turn off justification. Always turn off hyphenation; it makes |
| 129 | .\" way too many mistakes in technical documents. |
| 130 | .if n .ad l |
| 131 | .nh |
| 132 | .SH "NAME" |
| 133 | rand \- pseudo\-random number generator |
| 134 | .SH "SYNOPSIS" |
| 135 | .IX Header "SYNOPSIS" |
| 136 | .Vb 1 |
| 137 | \& #include <openssl/rand.h> |
| 138 | \& |
| 139 | \& int RAND_set_rand_engine(ENGINE *engine); |
| 140 | \& |
| 141 | \& int RAND_bytes(unsigned char *buf, int num); |
| 142 | \& int RAND_pseudo_bytes(unsigned char *buf, int num); |
| 143 | \& |
| 144 | \& void RAND_seed(const void *buf, int num); |
| 145 | \& void RAND_add(const void *buf, int num, int entropy); |
| 146 | \& int RAND_status(void); |
| 147 | \& |
| 148 | \& int RAND_load_file(const char *file, long max_bytes); |
| 149 | \& int RAND_write_file(const char *file); |
| 150 | \& const char *RAND_file_name(char *file, size_t num); |
| 151 | \& |
| 152 | \& int RAND_egd(const char *path); |
| 153 | \& |
| 154 | \& void RAND_set_rand_method(const RAND_METHOD *meth); |
| 155 | \& const RAND_METHOD *RAND_get_rand_method(void); |
| 156 | \& RAND_METHOD *RAND_SSLeay(void); |
| 157 | \& |
| 158 | \& void RAND_cleanup(void); |
| 159 | \& |
| 160 | \& /* For Win32 only */ |
| 161 | \& void RAND_screen(void); |
| 162 | \& int RAND_event(UINT, WPARAM, LPARAM); |
| 163 | .Ve |
| 164 | .SH "DESCRIPTION" |
| 165 | .IX Header "DESCRIPTION" |
| 166 | Since the introduction of the \s-1ENGINE\s0 \s-1API\s0, the recommended way of controlling |
| 167 | default implementations is by using the \s-1ENGINE\s0 \s-1API\s0 functions. The default |
| 168 | \&\fB\s-1RAND_METHOD\s0\fR, as set by \fIRAND_set_rand_method()\fR and returned by |
| 169 | \&\fIRAND_get_rand_method()\fR, is only used if no \s-1ENGINE\s0 has been set as the default |
| 170 | \&\*(L"rand\*(R" implementation. Hence, these two functions are no longer the recommened |
| 171 | way to control defaults. |
| 172 | .PP |
| 173 | If an alternative \fB\s-1RAND_METHOD\s0\fR implementation is being used (either set |
| 174 | directly or as provided by an \s-1ENGINE\s0 module), then it is entirely responsible |
| 175 | for the generation and management of a cryptographically secure \s-1PRNG\s0 stream. The |
| 176 | mechanisms described below relate solely to the software \s-1PRNG\s0 implementation |
| 177 | built in to OpenSSL and used by default. |
| 178 | .PP |
| 179 | These functions implement a cryptographically secure pseudo-random |
| 180 | number generator (\s-1PRNG\s0). It is used by other library functions for |
| 181 | example to generate random keys, and applications can use it when they |
| 182 | need randomness. |
| 183 | .PP |
| 184 | A cryptographic \s-1PRNG\s0 must be seeded with unpredictable data such as |
| 185 | mouse movements or keys pressed at random by the user. This is |
| 186 | described in \fIRAND_add\fR\|(3). Its state can be saved in a seed file |
| 187 | (see \fIRAND_load_file\fR\|(3)) to avoid having to go through the |
| 188 | seeding process whenever the application is started. |
| 189 | .PP |
| 190 | \&\fIRAND_bytes\fR\|(3) describes how to obtain random data from the |
| 191 | \&\s-1PRNG\s0. |
| 192 | .SH "INTERNALS" |
| 193 | .IX Header "INTERNALS" |
| 194 | The \fIRAND_SSLeay()\fR method implements a \s-1PRNG\s0 based on a cryptographic |
| 195 | hash function. |
| 196 | .PP |
| 197 | The following description of its design is based on the SSLeay |
| 198 | documentation: |
| 199 | .PP |
| 200 | First up I will state the things I believe I need for a good \s-1RNG\s0. |
| 201 | .IP "1." 4 |
| 202 | A good hashing algorithm to mix things up and to convert the \s-1RNG\s0 'state' |
| 203 | to random numbers. |
| 204 | .IP "2." 4 |
| 205 | An initial source of random 'state'. |
| 206 | .IP "3." 4 |
| 207 | The state should be very large. If the \s-1RNG\s0 is being used to generate |
| 208 | 4096 bit \s-1RSA\s0 keys, 2 2048 bit random strings are required (at a minimum). |
| 209 | If your \s-1RNG\s0 state only has 128 bits, you are obviously limiting the |
| 210 | search space to 128 bits, not 2048. I'm probably getting a little |
| 211 | carried away on this last point but it does indicate that it may not be |
| 212 | a bad idea to keep quite a lot of \s-1RNG\s0 state. It should be easier to |
| 213 | break a cipher than guess the \s-1RNG\s0 seed data. |
| 214 | .IP "4." 4 |
| 215 | Any \s-1RNG\s0 seed data should influence all subsequent random numbers |
| 216 | generated. This implies that any random seed data entered will have |
| 217 | an influence on all subsequent random numbers generated. |
| 218 | .IP "5." 4 |
| 219 | When using data to seed the \s-1RNG\s0 state, the data used should not be |
| 220 | extractable from the \s-1RNG\s0 state. I believe this should be a |
| 221 | requirement because one possible source of 'secret' semi random |
| 222 | data would be a private key or a password. This data must |
| 223 | not be disclosed by either subsequent random numbers or a |
| 224 | \&'core' dump left by a program crash. |
| 225 | .IP "6." 4 |
| 226 | Given the same initial 'state', 2 systems should deviate in their \s-1RNG\s0 state |
| 227 | (and hence the random numbers generated) over time if at all possible. |
| 228 | .IP "7." 4 |
| 229 | Given the random number output stream, it should not be possible to determine |
| 230 | the \s-1RNG\s0 state or the next random number. |
| 231 | .PP |
| 232 | The algorithm is as follows. |
| 233 | .PP |
| 234 | There is global state made up of a 1023 byte buffer (the 'state'), a |
| 235 | working hash value ('md'), and a counter ('count'). |
| 236 | .PP |
| 237 | Whenever seed data is added, it is inserted into the 'state' as |
| 238 | follows. |
| 239 | .PP |
| 240 | The input is chopped up into units of 20 bytes (or less for |
| 241 | the last block). Each of these blocks is run through the hash |
| 242 | function as follows: The data passed to the hash function |
| 243 | is the current 'md', the same number of bytes from the 'state' |
| 244 | (the location determined by in incremented looping index) as |
| 245 | the current 'block', the new key data 'block', and 'count' |
| 246 | (which is incremented after each use). |
| 247 | The result of this is kept in 'md' and also xored into the |
| 248 | \&'state' at the same locations that were used as input into the |
| 249 | hash function. I |
| 250 | believe this system addresses points 1 (hash function; currently |
| 251 | \&\s-1SHA\-1\s0), 3 (the 'state'), 4 (via the 'md'), 5 (by the use of a hash |
| 252 | function and xor). |
| 253 | .PP |
| 254 | When bytes are extracted from the \s-1RNG\s0, the following process is used. |
| 255 | For each group of 10 bytes (or less), we do the following: |
| 256 | .PP |
| 257 | Input into the hash function the local 'md' (which is initialized from |
| 258 | the global 'md' before any bytes are generated), the bytes that are to |
| 259 | be overwritten by the random bytes, and bytes from the 'state' |
| 260 | (incrementing looping index). From this digest output (which is kept |
| 261 | in 'md'), the top (up to) 10 bytes are returned to the caller and the |
| 262 | bottom 10 bytes are xored into the 'state'. |
| 263 | .PP |
| 264 | Finally, after we have finished 'num' random bytes for the caller, |
| 265 | \&'count' (which is incremented) and the local and global 'md' are fed |
| 266 | into the hash function and the results are kept in the global 'md'. |
| 267 | .PP |
| 268 | I believe the above addressed points 1 (use of \s-1SHA\-1\s0), 6 (by hashing |
| 269 | into the 'state' the 'old' data from the caller that is about to be |
| 270 | overwritten) and 7 (by not using the 10 bytes given to the caller to |
| 271 | update the 'state', but they are used to update 'md'). |
| 272 | .PP |
| 273 | So of the points raised, only 2 is not addressed (but see |
| 274 | \&\fIRAND_add\fR\|(3)). |
| 275 | .SH "SEE ALSO" |
| 276 | .IX Header "SEE ALSO" |
| 277 | \&\fIBN_rand\fR\|(3), \fIRAND_add\fR\|(3), |
| 278 | \&\fIRAND_load_file\fR\|(3), \fIRAND_egd\fR\|(3), |
| 279 | \&\fIRAND_bytes\fR\|(3), |
| 280 | \&\fIRAND_set_rand_method\fR\|(3), |
| 281 | \&\fIRAND_cleanup\fR\|(3) |