On Mon, Jan 08, 2001 at 08:42:35PM +0100, Richard Levitte - VMS Whacker wrote:
>> I don't like this hard-coded waiting time. [...] A usleep
>> for 5 ms should be just as good on average (but with a fairer
>> distribution of randomness to multiple processes), and of
>> course then you can just as well not sleep/select at all.
[...]
> Uhmm, I'm not sure I understand. 5ms is not the same as not waiting
> at all.
For processes that use RAND_poll just once, which is the case with the
implicit calls that happen when using RAND_status or RAND_bytes,
it is equivalent in that the read() just happens a little later,
without any significant correlation to the availability of "real"
randomness. (Other than the expectation that the longer the system's
uptime, the better the chances are that sufficient entropy
has been accumulated.
>> Why use /dev/[s]random anyway? /dev/urandom should be
>> enough, the OpenSSL PRNG does not try to provide more than
>> cryptographically strong random numbers.
> I really, /dev/urandom is enough? Even on system that don't have one?
Obiously not, but what such systems do exist? OK, I guess there is
this one Solaris daemon. So I'd recommend trying /dev/urandom
first, and resorting to /dev/urandom (and others) only if this fails;
i.e., re-order the entries of the current list.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
