diff options
Diffstat (limited to 'secure/lib/libcrypto/man/rand.3')
| -rw-r--r-- | secure/lib/libcrypto/man/rand.3 | 286 |
1 files changed, 286 insertions, 0 deletions
diff --git a/secure/lib/libcrypto/man/rand.3 b/secure/lib/libcrypto/man/rand.3 new file mode 100644 index 000000000000..dabbb601c50e --- /dev/null +++ b/secure/lib/libcrypto/man/rand.3 @@ -0,0 +1,286 @@ +.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35) +.\" +.\" Standard preamble: +.\" ======================================================================== +.de Sp \" Vertical space (when we can't use .PP) +.if t .sp .5v +.if n .sp +.. +.de Vb \" Begin verbatim text +.ft CW +.nf +.ne \\$1 +.. +.de Ve \" End verbatim text +.ft R +.fi +.. +.\" Set up some character translations and predefined strings. \*(-- will +.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left +.\" double quote, and \*(R" will give a right double quote. \*(C+ will +.\" give a nicer C++. Capital omega is used to do unbreakable dashes and +.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, +.\" nothing in troff, for use with C<>. +.tr \(*W- +.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' +.ie n \{\ +. ds -- \(*W- +. ds PI pi +. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch +. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch +. ds L" "" +. ds R" "" +. ds C` "" +. ds C' "" +'br\} +.el\{\ +. ds -- \|\(em\| +. ds PI \(*p +. ds L" `` +. ds R" '' +. ds C` +. ds C' +'br\} +.\" +.\" Escape single quotes in literal strings from groff's Unicode transform. +.ie \n(.g .ds Aq \(aq +.el .ds Aq ' +.\" +.\" If the F register is >0, we'll generate index entries on stderr for +.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index +.\" entries marked with X<> in POD. Of course, you'll have to process the +.\" output yourself in some meaningful fashion. +.\" +.\" Avoid warning from groff about undefined register 'F'. +.de IX +.. +.if !\nF .nr F 0 +.if \nF>0 \{\ +. de IX +. tm Index:\\$1\t\\n%\t"\\$2" +.. +. if !\nF==2 \{\ +. nr % 0 +. nr F 2 +. \} +.\} +.\" +.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). +.\" Fear. Run. Save yourself. No user-serviceable parts. +. \" fudge factors for nroff and troff +.if n \{\ +. ds #H 0 +. ds #V .8m +. ds #F .3m +. ds #[ \f1 +. ds #] \fP +.\} +.if t \{\ +. ds #H ((1u-(\\\\n(.fu%2u))*.13m) +. ds #V .6m +. ds #F 0 +. ds #[ \& +. ds #] \& +.\} +. \" simple accents for nroff and troff +.if n \{\ +. ds ' \& +. ds ` \& +. ds ^ \& +. ds , \& +. ds ~ ~ +. ds / +.\} +.if t \{\ +. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" +. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' +. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' +. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' +. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' +. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' +.\} +. \" troff and (daisy-wheel) nroff accents +.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' +.ds 8 \h'\*(#H'\(*b\h'-\*(#H' +.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] +.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' +.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' +.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] +.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] +.ds ae a\h'-(\w'a'u*4/10)'e +.ds Ae A\h'-(\w'A'u*4/10)'E +. \" corrections for vroff +.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' +.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' +. \" for low resolution devices (crt and lpr) +.if \n(.H>23 .if \n(.V>19 \ +\{\ +. ds : e +. ds 8 ss +. ds o a +. ds d- d\h'-1'\(ga +. ds D- D\h'-1'\(hy +. ds th \o'bp' +. ds Th \o'LP' +. ds ae ae +. ds Ae AE +.\} +.rm #[ #] #H #V #F C +.\" ======================================================================== +.\" +.IX Title "rand 3" +.TH rand 3 "2018-08-14" "1.0.2p" "OpenSSL" +.\" For nroff, turn off justification. Always turn off hyphenation; it makes +.\" way too many mistakes in technical documents. +.if n .ad l +.nh +.SH "NAME" +rand \- pseudo\-random number generator +.SH "SYNOPSIS" +.IX Header "SYNOPSIS" +.Vb 1 +\& #include <openssl/rand.h> +\& +\& int RAND_set_rand_engine(ENGINE *engine); +\& +\& int RAND_bytes(unsigned char *buf, int num); +\& int RAND_pseudo_bytes(unsigned char *buf, int num); +\& +\& void RAND_seed(const void *buf, int num); +\& void RAND_add(const void *buf, int num, double entropy); +\& int RAND_status(void); +\& +\& int RAND_load_file(const char *file, long max_bytes); +\& int RAND_write_file(const char *file); +\& const char *RAND_file_name(char *file, size_t num); +\& +\& int RAND_egd(const char *path); +\& +\& void RAND_set_rand_method(const RAND_METHOD *meth); +\& const RAND_METHOD *RAND_get_rand_method(void); +\& RAND_METHOD *RAND_SSLeay(void); +\& +\& void RAND_cleanup(void); +\& +\& /* For Win32 only */ +\& void RAND_screen(void); +\& int RAND_event(UINT, WPARAM, LPARAM); +.Ve +.SH "DESCRIPTION" +.IX Header "DESCRIPTION" +Since the introduction of the \s-1ENGINE API,\s0 the recommended way of controlling +default implementations is by using the \s-1ENGINE API\s0 functions. The default +\&\fB\s-1RAND_METHOD\s0\fR, as set by \fIRAND_set_rand_method()\fR and returned by +\&\fIRAND_get_rand_method()\fR, is only used if no \s-1ENGINE\s0 has been set as the default +\&\*(L"rand\*(R" implementation. Hence, these two functions are no longer the recommended +way to control defaults. +.PP +If an alternative \fB\s-1RAND_METHOD\s0\fR implementation is being used (either set +directly or as provided by an \s-1ENGINE\s0 module), then it is entirely responsible +for the generation and management of a cryptographically secure \s-1PRNG\s0 stream. The +mechanisms described below relate solely to the software \s-1PRNG\s0 implementation +built in to OpenSSL and used by default. +.PP +These functions implement a cryptographically secure pseudo-random +number generator (\s-1PRNG\s0). It is used by other library functions for +example to generate random keys, and applications can use it when they +need randomness. +.PP +A cryptographic \s-1PRNG\s0 must be seeded with unpredictable data such as +mouse movements or keys pressed at random by the user. This is +described in \fIRAND_add\fR\|(3). Its state can be saved in a seed file +(see \fIRAND_load_file\fR\|(3)) to avoid having to go through the +seeding process whenever the application is started. +.PP +\&\fIRAND_bytes\fR\|(3) describes how to obtain random data from the +\&\s-1PRNG.\s0 +.SH "INTERNALS" +.IX Header "INTERNALS" +The \fIRAND_SSLeay()\fR method implements a \s-1PRNG\s0 based on a cryptographic +hash function. +.PP +The following description of its design is based on the SSLeay +documentation: +.PP +First up I will state the things I believe I need for a good \s-1RNG.\s0 +.IP "1." 4 +A good hashing algorithm to mix things up and to convert the \s-1RNG\s0 'state' +to random numbers. +.IP "2." 4 +An initial source of random 'state'. +.IP "3." 4 +The state should be very large. If the \s-1RNG\s0 is being used to generate +4096 bit \s-1RSA\s0 keys, 2 2048 bit random strings are required (at a minimum). +If your \s-1RNG\s0 state only has 128 bits, you are obviously limiting the +search space to 128 bits, not 2048. I'm probably getting a little +carried away on this last point but it does indicate that it may not be +a bad idea to keep quite a lot of \s-1RNG\s0 state. It should be easier to +break a cipher than guess the \s-1RNG\s0 seed data. +.IP "4." 4 +Any \s-1RNG\s0 seed data should influence all subsequent random numbers +generated. This implies that any random seed data entered will have +an influence on all subsequent random numbers generated. +.IP "5." 4 +When using data to seed the \s-1RNG\s0 state, the data used should not be +extractable from the \s-1RNG\s0 state. I believe this should be a +requirement because one possible source of 'secret' semi random +data would be a private key or a password. This data must +not be disclosed by either subsequent random numbers or a +\&'core' dump left by a program crash. +.IP "6." 4 +Given the same initial 'state', 2 systems should deviate in their \s-1RNG\s0 state +(and hence the random numbers generated) over time if at all possible. +.IP "7." 4 +Given the random number output stream, it should not be possible to determine +the \s-1RNG\s0 state or the next random number. +.PP +The algorithm is as follows. +.PP +There is global state made up of a 1023 byte buffer (the 'state'), a +working hash value ('md'), and a counter ('count'). +.PP +Whenever seed data is added, it is inserted into the 'state' as +follows. +.PP +The input is chopped up into units of 20 bytes (or less for +the last block). Each of these blocks is run through the hash +function as follows: The data passed to the hash function +is the current 'md', the same number of bytes from the 'state' +(the location determined by in incremented looping index) as +the current 'block', the new key data 'block', and 'count' +(which is incremented after each use). +The result of this is kept in 'md' and also xored into the +\&'state' at the same locations that were used as input into the +hash function. I +believe this system addresses points 1 (hash function; currently +\&\s-1SHA\-1\s0), 3 (the 'state'), 4 (via the 'md'), 5 (by the use of a hash +function and xor). +.PP +When bytes are extracted from the \s-1RNG,\s0 the following process is used. +For each group of 10 bytes (or less), we do the following: +.PP +Input into the hash function the local 'md' (which is initialized from +the global 'md' before any bytes are generated), the bytes that are to +be overwritten by the random bytes, and bytes from the 'state' +(incrementing looping index). From this digest output (which is kept +in 'md'), the top (up to) 10 bytes are returned to the caller and the +bottom 10 bytes are xored into the 'state'. +.PP +Finally, after we have finished 'num' random bytes for the caller, +\&'count' (which is incremented) and the local and global 'md' are fed +into the hash function and the results are kept in the global 'md'. +.PP +I believe the above addressed points 1 (use of \s-1SHA\-1\s0), 6 (by hashing +into the 'state' the 'old' data from the caller that is about to be +overwritten) and 7 (by not using the 10 bytes given to the caller to +update the 'state', but they are used to update 'md'). +.PP +So of the points raised, only 2 is not addressed (but see +\&\fIRAND_add\fR\|(3)). +.SH "SEE ALSO" +.IX Header "SEE ALSO" +\&\fIBN_rand\fR\|(3), \fIRAND_add\fR\|(3), +\&\fIRAND_load_file\fR\|(3), \fIRAND_egd\fR\|(3), +\&\fIRAND_bytes\fR\|(3), +\&\fIRAND_set_rand_method\fR\|(3), +\&\fIRAND_cleanup\fR\|(3) |