355 lines
10 KiB
Groff
355 lines
10 KiB
Groff
.rn '' }`
|
|
'''
|
|
'''
|
|
.de Sh
|
|
.br
|
|
.if t .Sp
|
|
.ne 5
|
|
.PP
|
|
\fB\\$1\fR
|
|
.PP
|
|
..
|
|
.de Sp
|
|
.if t .sp .5v
|
|
.if n .sp
|
|
..
|
|
.de Ip
|
|
.br
|
|
.ie \\n(.$>=3 .ne \\$3
|
|
.el .ne 3
|
|
.IP "\\$1" \\$2
|
|
..
|
|
.de Vb
|
|
.ft CW
|
|
.nf
|
|
.ne \\$1
|
|
..
|
|
.de Ve
|
|
.ft R
|
|
|
|
.fi
|
|
..
|
|
'''
|
|
'''
|
|
''' Set up \*(-- to give an unbreakable dash;
|
|
''' string Tr holds user defined translation string.
|
|
''' Bell System Logo is used as a dummy character.
|
|
'''
|
|
.tr \(*W-|\(bv\*(Tr
|
|
.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" ""
|
|
''' \*(M", \*(S", \*(N" and \*(T" are the equivalent of
|
|
''' \*(L" and \*(R", except that they are used on ".xx" lines,
|
|
''' such as .IP and .SH, which do another additional levels of
|
|
''' double-quote interpretation
|
|
.ds M" """
|
|
.ds S" """
|
|
.ds N" """""
|
|
.ds T" """""
|
|
.ds L' '
|
|
.ds R' '
|
|
.ds M' '
|
|
.ds S' '
|
|
.ds N' '
|
|
.ds T' '
|
|
'br\}
|
|
.el\{\
|
|
.ds -- \(em\|
|
|
.tr \*(Tr
|
|
.ds L" ``
|
|
.ds R" ''
|
|
.ds M" ``
|
|
.ds S" ''
|
|
.ds N" ``
|
|
.ds T" ''
|
|
.ds L' `
|
|
.ds R' '
|
|
.ds M' `
|
|
.ds S' '
|
|
.ds N' `
|
|
.ds T' '
|
|
.ds PI \(*p
|
|
'br\}
|
|
.\" If the F register is turned on, we'll generate
|
|
.\" index entries out stderr for the following things:
|
|
.\" TH Title
|
|
.\" SH Header
|
|
.\" Sh Subsection
|
|
.\" Ip Item
|
|
.\" X<> Xref (embedded
|
|
.\" Of course, you have to process the output yourself
|
|
.\" in some meaninful fashion.
|
|
.if \nF \{
|
|
.de IX
|
|
.tm Index:\\$1\t\\n%\t"\\$2"
|
|
..
|
|
.nr % 0
|
|
.rr F
|
|
.\}
|
|
.TH rand 3 "0.9.5a" "22/Jul/2000" "OpenSSL"
|
|
.UC
|
|
.if n .hy 0
|
|
.if n .na
|
|
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
|
|
.de CQ \" put $1 in typewriter font
|
|
.ft CW
|
|
'if n "\c
|
|
'if t \\&\\$1\c
|
|
'if n \\&\\$1\c
|
|
'if n \&"
|
|
\\&\\$2 \\$3 \\$4 \\$5 \\$6 \\$7
|
|
'.ft R
|
|
..
|
|
.\" @(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2
|
|
. \" AM - accent mark definitions
|
|
.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 ? ?
|
|
. ds ! !
|
|
. ds /
|
|
. ds q
|
|
.\}
|
|
.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 ? \s-2c\h'-\w'c'u*7/10'\u\h'\*(#H'\zi\d\s+2\h'\w'c'u*8/10'
|
|
. ds ! \s-2\(or\s+2\h'-\w'\(or'u'\v'-.8m'.\v'.8m'
|
|
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
|
|
. ds q o\h'-\w'o'u*8/10'\s-4\v'.4m'\z\(*i\v'-.4m'\s+4\h'\w'o'u*8/10'
|
|
.\}
|
|
. \" 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 v \\k:\h'-(\\n(.wu*9/10-\*(#H)'\v'-\*(#V'\*(#[\s-4v\s0\v'\*(#V'\h'|\\n:u'\*(#]
|
|
.ds _ \\k:\h'-(\\n(.wu*9/10-\*(#H+(\*(#F*2/3))'\v'-.4m'\z\(hy\v'.4m'\h'|\\n:u'
|
|
.ds . \\k:\h'-(\\n(.wu*8/10)'\v'\*(#V*4/10'\z.\v'-\*(#V*4/10'\h'|\\n:u'
|
|
.ds 3 \*(#[\v'.2m'\s-2\&3\s0\v'-.2m'\*(#]
|
|
.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
|
|
.ds oe o\h'-(\w'o'u*4/10)'e
|
|
.ds Oe O\h'-(\w'O'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 v \h'-1'\o'\(aa\(ga'
|
|
. ds _ \h'-1'^
|
|
. ds . \h'-1'.
|
|
. ds 3 3
|
|
. 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
|
|
. ds oe oe
|
|
. ds Oe OE
|
|
.\}
|
|
.rm #[ #] #H #V #F C
|
|
.SH "NAME"
|
|
rand \- pseudo-random number generator
|
|
.SH "LIBRARY"
|
|
libcrypto, -lcrypto
|
|
.SH "SYNOPSIS"
|
|
.PP
|
|
.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,int 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"
|
|
These functions implement a cryptographically secure pseudo-random
|
|
number generator (PRNG). 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 PRNG must be seeded with unpredictable data such as
|
|
mouse movements or keys pressed at random by the user. This is
|
|
described in the \fIRAND_add(3)|RAND_add(3)\fR manpage. Its state can be saved in a seed file
|
|
(see the \fIRAND_load_file(3)|RAND_load_file(3)\fR manpage) to avoid having to go through the
|
|
seeding process whenever the application is started.
|
|
.PP
|
|
the \fIRAND_bytes(3)|RAND_bytes(3)\fR manpage describes how to obtain random data from the
|
|
PRNG.
|
|
.SH "INTERNALS"
|
|
The \fIRAND_SSLeay()\fR method implements a PRNG 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 RNG.
|
|
.Ip "1" 4
|
|
A good hashing algorithm to mix things up and to convert the \s-1RNG\s0 \*(L'state\*(R'
|
|
to random numbers.
|
|
.Ip "2" 4
|
|
An initial source of random \*(L'state\*(R'.
|
|
.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 \*(L'secret\*(R' 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\*(R' dump left by a program crash.
|
|
.Ip "6" 4
|
|
Given the same initial \*(L'state\*(R', 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 \*(L'state'), a
|
|
working hash value ('md'), and a counter ('count').
|
|
.PP
|
|
Whenever seed data is added, it is inserted into the \*(L'state\*(R' 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 \*(L'md\*(R', the same number of bytes from the \*(L'state\*(R'
|
|
(the location determined by in incremented looping index) as
|
|
the current \*(L'block\*(R', the new key data \*(L'block\*(R', and \*(L'count\*(R'
|
|
(which is incremented after each use).
|
|
The result of this is kept in \*(L'md\*(R' and also xored into the
|
|
\&'state\*(R' 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\s0\-1), 3 (the \*(L'state'), 4 (via the \*(L'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 top 10 bytes from the local \*(L'md\*(R'
|
|
(which is initialized from the global \*(L'md\*(R' before any bytes are
|
|
generated), the bytes that are to be overwritten by the random bytes,
|
|
and bytes from the \*(L'state\*(R' (incrementing looping index). From this
|
|
digest output (which is kept in \*(L'md'), the top (up to) 10 bytes are
|
|
returned to the caller and the bottom (up to) 10 bytes are xored into
|
|
the \*(L'state\*(R'.
|
|
.PP
|
|
Finally, after we have finished \*(L'num\*(R' random bytes for the caller,
|
|
\&'count\*(R' (which is incremented) and the local and global \*(L'md\*(R' are fed
|
|
into the hash function and the results are kept in the global \*(L'md\*(R'.
|
|
.PP
|
|
I believe the above addressed points 1 (use of \s-1SHA\s0\-1), 6 (by hashing
|
|
into the \*(L'state\*(R' the \*(L'old\*(R' 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 \*(L'state\*(R', but they are used to update \*(L'md').
|
|
.PP
|
|
So of the points raised, only 2 is not addressed (but see
|
|
the \fIRAND_add(3)|RAND_add(3)\fR manpage).
|
|
.SH "SEE ALSO"
|
|
the \fIBN_rand(3)|BN_rand(3)\fR manpage, the \fIRAND_add(3)|RAND_add(3)\fR manpage,
|
|
the \fIRAND_load_file(3)|RAND_load_file(3)\fR manpage, the \fIRAND_egd(3)|RAND_egd(3)\fR manpage,
|
|
the \fIRAND_bytes(3)|RAND_bytes(3)\fR manpage,
|
|
the \fIRAND_set_rand_method(3)|RAND_set_rand_method(3)\fR manpage,
|
|
the \fIRAND_cleanup(3)|RAND_cleanup(3)\fR manpage
|
|
|
|
.rn }` ''
|
|
.IX Title "rand 3"
|
|
.IX Name "rand - pseudo-random number generator"
|
|
|
|
.IX Header "NAME"
|
|
|
|
.IX Header "SYNOPSIS"
|
|
|
|
.IX Header "DESCRIPTION"
|
|
|
|
.IX Header "INTERNALS"
|
|
|
|
.IX Item "1"
|
|
|
|
.IX Item "2"
|
|
|
|
.IX Item "3"
|
|
|
|
.IX Item "4"
|
|
|
|
.IX Item "5"
|
|
|
|
.IX Item "6"
|
|
|
|
.IX Item "7"
|
|
|
|
.IX Header "SEE ALSO"
|
|
|