diff options
Diffstat (limited to 'secure/lib/libcrypto/man/rand.3')
| -rw-r--r-- | secure/lib/libcrypto/man/rand.3 | 287 |
1 files changed, 287 insertions, 0 deletions
diff --git a/secure/lib/libcrypto/man/rand.3 b/secure/lib/libcrypto/man/rand.3 new file mode 100644 index 0000000..679138f --- /dev/null +++ b/secure/lib/libcrypto/man/rand.3 @@ -0,0 +1,287 @@ +.\" Automatically generated by Pod::Man version 1.15 +.\" Thu May 9 13:19:34 2002 +.\" +.\" Standard preamble: +.\" ====================================================================== +.de Sh \" Subsection heading +.br +.if t .Sp +.ne 5 +.PP +\fB\\$1\fR +.PP +.. +.de Sp \" Vertical space (when we can't use .PP) +.if t .sp .5v +.if n .sp +.. +.de Ip \" List item +.br +.ie \\n(.$>=3 .ne \\$3 +.el .ne 3 +.IP "\\$1" \\$2 +.. +.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. | will give a +.\" real vertical bar. \*(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-|\(bv\*(Tr +.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" '' +'br\} +.\" +.\" If the F register is turned on, we'll generate index entries on stderr +.\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and +.\" index entries marked with X<> in POD. Of course, you'll have to process +.\" the output yourself in some meaningful fashion. +.if \nF \{\ +. de IX +. tm Index:\\$1\t\\n%\t"\\$2" +.. +. nr % 0 +. rr F +.\} +.\" +.\" For nroff, turn off justification. Always turn off hyphenation; it +.\" makes way too many mistakes in technical documents. +.hy 0 +.if n .na +.\" +.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). +.\" Fear. Run. Save yourself. No user-serviceable parts. +.bd B 3 +. \" 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 1" +.TH RAND 1 "perl v5.6.1" "2001-07-19" "User Contributed Perl Documentation" +.UC +.SH "NAME" +rand \- pseudo-random number generator +.SH "SYNOPSIS" +.IX Header "SYNOPSIS" +.Vb 1 +\& #include <openssl/rand.h> +.Ve +.Vb 2 +\& int RAND_bytes(unsigned char *buf, int num); +\& int RAND_pseudo_bytes(unsigned char *buf, int num); +.Ve +.Vb 4 +\& void RAND_seed(const void *buf, int num); +\& void RAND_add(const void *buf, int num, int entropy); +\& int RAND_status(void); +\& void RAND_screen(void); +.Ve +.Vb 3 +\& 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); +.Ve +.Vb 1 +\& int RAND_egd(const char *path); +.Ve +.Vb 3 +\& void RAND_set_rand_method(RAND_METHOD *meth); +\& RAND_METHOD *RAND_get_rand_method(void); +\& RAND_METHOD *RAND_SSLeay(void); +.Ve +.Vb 1 +\& void RAND_cleanup(void); +.Ve +.SH "DESCRIPTION" +.IX Header "DESCRIPTION" +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 RAND_add(3). Its state can be saved in a seed file +(see RAND_load_file(3)) to avoid having to go through the +seeding process whenever the application is started. +.PP +RAND_bytes(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 +.IX Item "1" +A good hashing algorithm to mix things up and to convert the \s-1RNG\s0 'state' +to random numbers. +.Ip "2" 4 +.IX Item "2" +An initial source of random 'state'. +.Ip "3" 4 +.IX Item "3" +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 +.IX Item "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 +.IX Item "5" +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 +.IX Item "6" +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 +.IX Item "7" +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 +RAND_add(3)). +.SH "SEE ALSO" +.IX Header "SEE ALSO" +BN_rand(3), RAND_add(3), +RAND_load_file(3), RAND_egd(3), +RAND_bytes(3), +RAND_set_rand_method(3), +RAND_cleanup(3) |
