mirror of
https://github.com/openssl/openssl.git
synced 2024-12-21 06:09:35 +08:00
146 lines
4.8 KiB
Plaintext
146 lines
4.8 KiB
Plaintext
|
=pod
|
||
|
|
||
|
=head1 NAME
|
||
|
|
||
|
rand - Psdeudo-random number generator
|
||
|
|
||
|
=head1 SYNOPSIS
|
||
|
|
||
|
#include <openssl/rand.h>
|
||
|
|
||
|
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,int entropy);
|
||
|
void RAND_screen(void);
|
||
|
|
||
|
int RAND_load_file(const char *file,long max_bytes);
|
||
|
int RAND_write_file(const char *file);
|
||
|
char *RAND_file_name(char *file,int num);
|
||
|
|
||
|
void RAND_set_rand_method(RAND_METHOD *meth);
|
||
|
RAND_METHOD *RAND_get_rand_method(void);
|
||
|
RAND_METHOD *RAND_SSLeay(void);
|
||
|
|
||
|
void RAND_cleanup(void);
|
||
|
|
||
|
=head1 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.
|
||
|
|
||
|
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 L<RAND_add(3)>. Its state can be saved in a seed file
|
||
|
(see L<RAND_load_file(3)>) to avoid having to go through the seeding
|
||
|
process whenever the application is started.
|
||
|
|
||
|
L<RAND_bytes(3)> describes how to obtain random data from the PRNG.
|
||
|
|
||
|
=head1 INTERNALS
|
||
|
|
||
|
The RAND_SSLeay() method implements a PRNG based on a cryptographic
|
||
|
hash function.
|
||
|
|
||
|
The following description of its design is based on the SSLeay
|
||
|
documentation:
|
||
|
|
||
|
First up I will state the things I believe I need for a good RNG.
|
||
|
|
||
|
=over 4
|
||
|
|
||
|
=item 1
|
||
|
|
||
|
A good hashing algorithm to mix things up and to convert the RNG 'state'
|
||
|
to random numbers.
|
||
|
|
||
|
=item 2
|
||
|
|
||
|
An initial source of random 'state'.
|
||
|
|
||
|
=item 3
|
||
|
|
||
|
The state should be very large. If the RNG is being used to generate
|
||
|
4096 bit RSA keys, 2 2048 bit random strings are required (at a minimum).
|
||
|
If your RNG 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 RNG state. It should be easier to
|
||
|
break a cipher than guess the RNG seed data.
|
||
|
|
||
|
=item 4
|
||
|
|
||
|
Any RNG 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.
|
||
|
|
||
|
=item 5
|
||
|
|
||
|
When using data to seed the RNG state, the data used should not be
|
||
|
extractable from the RNG 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.
|
||
|
|
||
|
=item 6
|
||
|
|
||
|
Given the same initial 'state', 2 systems should deviate in their RNG state
|
||
|
(and hence the random numbers generated) over time if at all possible.
|
||
|
|
||
|
=item 7
|
||
|
|
||
|
Given the random number output stream, it should not be possible to determine
|
||
|
the RNG state or the next random number.
|
||
|
|
||
|
=back
|
||
|
|
||
|
The algorithm is as follows.
|
||
|
|
||
|
There is global state made up of a 1023 byte buffer (the 'state'), a
|
||
|
working hash function ('md') and a counter ('count').
|
||
|
|
||
|
Whenever seed data is added, it is inserted into the 'state' as
|
||
|
follows.
|
||
|
|
||
|
The input is chopped up into units of 16 bytes (or less for the last
|
||
|
block). Each of these blocks is run through the hash function. 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' and the new key data 'block'.
|
||
|
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
|
||
|
SHA-1), 3 (the 'state'), 4 (via the 'md'), 5 (by the use of a hash
|
||
|
function and xor).
|
||
|
|
||
|
When bytes are extracted from the RNG, the following process is used.
|
||
|
For each group of 8 bytes (or less), we do the following,
|
||
|
|
||
|
Input into the hash function, the top 8 bytes from 'md', the byte that
|
||
|
are to be overwritten by the random bytes and bytes from the 'state'
|
||
|
(incrementing looping index). From this hash function output (which
|
||
|
is kept in 'md'), the top (upto) 8 bytes are returned to the caller
|
||
|
and the bottom (upto) 8 bytes are xored into the 'state'.
|
||
|
|
||
|
Finally, after we have finished 'generation' random bytes for the
|
||
|
called, 'count' (which is incremented) and 'md' are fed into the hash
|
||
|
function and the results are kept in 'md'. I believe the above
|
||
|
addressed points 1 (use of SHA-1), 6 (by hashing into the 'state' the
|
||
|
'old' data from the caller that is about to be overwritten) and 7 (by
|
||
|
not using the 8 bytes given to the caller to update the 'state', but
|
||
|
they are used to update 'md').
|
||
|
|
||
|
So of the points raised, only 2 is not addressed (but see
|
||
|
L<RAND_add()>).
|
||
|
|
||
|
=head1 SEE ALSO
|
||
|
|
||
|
BN_rand(3), RAND_add(3), RAND_load_file(3), RAND_bytes(3),
|
||
|
RAND_set_rand_method(3), RAND_cleanup(3)
|
||
|
|
||
|
=cut
|