On Mon, Jan 08, 2001 at 11:59:33AM +0100, [EMAIL PROTECTED] wrote:

>   Change RAND_poll for Unix to try a number of devices and only read
>   them for a short period of time (actually, poll them with select(),
>   then read() whatever is there), which is about 10ms (hard-coded value)
>   each.

I don't like this hard-coded waiting time.  Programs should run as
fast as possible and not waste time sleeping if this likely
accomplishes nothing: If there is some entropy available, then it will
be availabe at /dev/urandom too (without delay).  On the other hand if
there is no entropy available, then during 10 ms a number of processes
will pile up longing for randomness, will all be awoken at the same
time, and then there may not be any randomness left for those
scheduled last.  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.

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.

If we had different RAND_poll versions for explicit use by
applications and for implicit use by OpenSSL (currently in
ssleay_rand_bytes and in ssleay_rand_status), then it might be OK to
make RAND_poll slower; internally, we'd use a RAND_fast_poll function
which would just probe /dev/urandom.  Then RAND_poll would only be
called when the application designer thinks that delays are acceptable
(for example, forking servers would make sure to call it *before*
forking; currently, the implicit calls may happen *after* forking,
i.e. n times instead of once).


-- 
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to