Upgrade to OpenSSL 0.9.8h.
[dragonfly.git] / secure / lib / libcrypto / man / rand.3
index 302887b..3fb3cfa 100644 (file)
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.12 (Pod::Simple 3.05)
+.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.32
 .\"
 .\" Standard preamble:
 .\" ========================================================================
 ..
 .\" 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-
+.\" 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-
 .    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.
 .    \" fudge factors for nroff and troff
 .\" ========================================================================
 .\"
 .IX Title "rand 3"
-.TH rand 3 "2007-10-24" "0.9.8g" "OpenSSL"
-.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
+.TH rand 3 "2008-09-06" "0.9.8h" "OpenSSL"
 .SH "NAME"
 rand \- pseudo\-random number generator
 .SH "SYNOPSIS"
 .IX Header "SYNOPSIS"
 .Vb 1
 \& #include <openssl/rand.h>
-\&
+.Ve
+.PP
+.Vb 1
 \& int  RAND_set_rand_engine(ENGINE *engine);
-\&
+.Ve
+.PP
+.Vb 2
 \& int  RAND_bytes(unsigned char *buf, int num);
 \& int  RAND_pseudo_bytes(unsigned char *buf, int num);
-\&
+.Ve
+.PP
+.Vb 3
 \& void RAND_seed(const void *buf, int num);
 \& void RAND_add(const void *buf, int num, int entropy);
 \& int  RAND_status(void);
-\&
+.Ve
+.PP
+.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
+.PP
+.Vb 1
 \& int  RAND_egd(const char *path);
-\&
+.Ve
+.PP
+.Vb 3
 \& void RAND_set_rand_method(const RAND_METHOD *meth);
 \& const RAND_METHOD *RAND_get_rand_method(void);
 \& RAND_METHOD *RAND_SSLeay(void);
-\&
+.Ve
+.PP
+.Vb 1
 \& void RAND_cleanup(void);
-\&
+.Ve
+.PP
+.Vb 3
 \& /* For Win32 only */
 \& void RAND_screen(void);
 \& int RAND_event(UINT, WPARAM, LPARAM);
@@ -188,7 +205,7 @@ described in \fIRAND_add\fR\|(3). Its state can be saved in a seed file
 seeding process whenever the application is started.
 .PP
 \&\fIRAND_bytes\fR\|(3) describes how to obtain random data from the
-\&\s-1PRNG\s0.
+\&\s-1PRNG\s0. 
 .SH "INTERNALS"
 .IX Header "INTERNALS"
 The \fIRAND_SSLeay()\fR method implements a \s-1PRNG\s0 based on a cryptographic
@@ -198,12 +215,15 @@ 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
+.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
+.IP "2" 4
+.IX Item "2"
 An initial source of random 'state'.
-.IP "3." 4
+.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
@@ -211,21 +231,25 @@ 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
+.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
+.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
+.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
+.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
@@ -278,4 +302,4 @@ So of the points raised, only 2 is not addressed (but see
 \&\fIRAND_load_file\fR\|(3), \fIRAND_egd\fR\|(3),
 \&\fIRAND_bytes\fR\|(3),
 \&\fIRAND_set_rand_method\fR\|(3),
-\&\fIRAND_cleanup\fR\|(3)
+\&\fIRAND_cleanup\fR\|(3)