On Wed, Oct 13, 1999 at 04:40:04PM -0300, Miguel Angel Fraga wrote:
> Bodo Moeller wrote:
[...]
>> The application has to take care of this, not the library. A generic
>> solution is not possible; e.g. for servers, you cannot expect the
>> mouse to move at all. The seeding that OpenSSL does automatically
>> suffices on certain platforms, but one should not rely on such
>> possibilities being available. One part of a solution for application
>> programs is to do what the "openssl" utility does: it expects to find
>> random input in a file (usually $HOME/.rnd) and writes an updated
>> random state back later.
> Why not? A hash of the screen is not enough.
> I mean to enhance (at least) the RAND_seed() function
> when you generate a new request.
RAND_seed is the wrong place to fix because the problem is
applications that don't even call RAND_seed. The current automatic
seeding takes place inside ssleay_rand_bytes (when called for the
first time), which is the standard method for RAND_bytes.
This automatic seeding is no panacea. What it does accomplish is make
sure that you don't get the same pseudorandom number sequence twice
when you use the same seed (presumably stored in a file) multiple
times -- for this the additional seeding need not be unpredictable,
just unique. There's also some seeding from /dev/urandom if available
(or some other file when the library has been configured with
-DDEVRANDOM=\"whatever\"), but that's just for backwards compatibility
with lazy programmers.
There is no way that the library can guarantee strong seeding under
arbitrary circumstances (mouse movement, for one thing, cannot be used
if no mouse is available, and anyway a library providing basic crypto
functionality has no business to access GUI functions). Read the
papers by Peter Gutmann and others on the difficulties of collecting
entropy for PRNG seeding. We've had some discussion on having
RAND_bytes fail if the application has not seeded the PRNG, which
would make sense, but the API does not allow RAND_bytes to fail.
For improved compatibility with lazy programmers I agree that there
are some things we could do, e.g. automatically do another round of
automatic low-entropy seeding when we detect that the PID has changed
(meaning, usually, that the application forked -- we certainly don't
want to have two processes use the same PRN sequence, which currently
can happen in applications written by careless developers, and
obviously could have disastrous consequences; think of ephemeral DSA
random numbers).
Bodo M"oller
<[EMAIL PROTECTED]>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
