| =pod |
| |
| =head1 NAME |
| |
| rand - pseudo-random number generator |
| |
| =head1 SYNOPSIS |
| |
| #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, int 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); |
| |
| =head1 DESCRIPTION |
| |
| Since the introduction of the ENGINE API, the recommended way of controlling |
| default implementations is by using the ENGINE API functions. The default |
| B<RAND_METHOD>, as set by RAND_set_rand_method() and returned by |
| RAND_get_rand_method(), is only used if no ENGINE has been set as the default |
| "rand" implementation. Hence, these two functions are no longer the recommended |
| way to control defaults. |
| |
| If an alternative B<RAND_METHOD> implementation is being used (either set |
| directly or as provided by an ENGINE module), then it is entirely responsible |
| for the generation and management of a cryptographically secure PRNG stream. The |
| mechanisms described below relate solely to the software PRNG implementation |
| built in to OpenSSL and used by default. |
| |
| 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)|RAND_add(3)>. Its state can be saved in a seed file |
| (see L<RAND_load_file(3)|RAND_load_file(3)>) to avoid having to go through the |
| seeding process whenever the application is started. |
| |
| L<RAND_bytes(3)|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 value ('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 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 |
| 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 10 bytes (or less), we do the following: |
| |
| 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'. |
| |
| 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'. |
| |
| 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 10 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(3)|RAND_add(3)>). |
| |
| =head1 SEE ALSO |
| |
| L<BN_rand(3)|BN_rand(3)>, L<RAND_add(3)|RAND_add(3)>, |
| L<RAND_load_file(3)|RAND_load_file(3)>, L<RAND_egd(3)|RAND_egd(3)>, |
| L<RAND_bytes(3)|RAND_bytes(3)>, |
| L<RAND_set_rand_method(3)|RAND_set_rand_method(3)>, |
| L<RAND_cleanup(3)|RAND_cleanup(3)> |
| |
| =cut |