X-Git-Url: https://code.wpia.club/?a=blobdiff_plain;f=lib%2Fopenssl%2Fdoc%2Fcrypto%2Frand.pod;fp=lib%2Fopenssl%2Fdoc%2Fcrypto%2Frand.pod;h=1c068c85b34c144ed4981c4ded00e961bc210a2b;hb=9ff1530871deeb0f7eaa35ca0db6630724045e4a;hp=0000000000000000000000000000000000000000;hpb=25b73076b01ae059da1a2e9a1677e00788ada620;p=cassiopeia.git diff --git a/lib/openssl/doc/crypto/rand.pod b/lib/openssl/doc/crypto/rand.pod new file mode 100644 index 0000000..1c068c8 --- /dev/null +++ b/lib/openssl/doc/crypto/rand.pod @@ -0,0 +1,175 @@ +=pod + +=head1 NAME + +rand - pseudo-random number generator + +=head1 SYNOPSIS + + #include + + 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, 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 recommened +way to control defaults. + +If an alternative B 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. Its state can be saved in a seed file +(see L) to avoid having to go through the +seeding process whenever the application is started. + +L 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). + +=head1 SEE ALSO + +L, L, +L, L, +L, +L, +L + +=cut