Some well known applications use SSLeay with an uninitialized random
number generator. SSLeay interally adds data such as the time and pid
to the PRNG. Unless the machine in question happens to have /dev/random,
that results in a ridiculously insecure system -- as everybody should
know since Netscape's disaster four years ago.
In my opinion, the proper thing for a crypto library in such a situation
is to abort.
The randfile.c functions could also have a better interface. There
should be a function RAND_init() which would take a filename or NULL
(so as to use the default file .rand), place a lock on that file, read
the data, add them to the PRNG and imediately write the current state
back and then release the lock.
An application would have to call that function on startup and on
exit. If the .rand (or other) file does not exist, RAND_init() would
have to read data from system ressources to initialize the PRNG.
Comments?
[BTW, there is a bug in SSLeay and the released version of OpenSSL
(which has been corrected at www.openssl.org), which causes
RAND_load_file() to fail on some systems but nevertheless return a
number larger than zero. So it is important that applications check
the exact quantity of the return value, it is not sufficient to verify
it is >0.]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
