----- Original Message -----
From: Bodo Moeller <[EMAIL PROTECTED]>
> 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).
>
How about using the digitization capabilities of a standard PC sound card?
Plug a white noise generator into the sound card´s Input, such as a TV or
radio receiver tuned between stations, capture until you have an "X" MBy
sound file (you decide how many MBy you need, but use the highest stereo
sampling rate and resolution possible), then calc the MD5 hash of the sound
file.
The resulting hash ought to be a good seed. If you´re not in Win32-land and
don´t have easy access to a sound card, use a PC, then transfer the hash
manually to your environment. In any case you only need to do this once.
Perhaps some kind souls can mount trustable white noise sources on the
Web and make them available programmatically to everyone: Then just
get your white noise, or only the hash, from each of N sources and XOR
them all, adding any additional goodies such as mouse movements, screen
capture hashes, disk FATs, ping response times to distant servers, etc, as
you may wish.
The optimal entropy source is a radioactive one (such as can be found in
a common smoke detector) coupled with a digitized Geiger counter. Then
count the number of particles emitted per time period (for example per
second). Then if the number of particles emitted is greater than the
average
of the last M periods, you have a "1". If it is less than or equal, you
have a
zero. This wold be a "moving average" type scheme. Put this all on a
circuit
board (better yet on a single chip!), add an ISA interface and a driver, and
you have a sellable product any serious PK certificate holder ought to
have!
Remember, security is only as strong as it´s weakest link, so don´t skimp on
priming the RNG with decent entropy!
In any case, OpenSSL ought to have more *explicit* entropy management
functionality at the user level, since we all don´t necessarily have the
resources
or the skills to develop the code ourselves.
So, this was my two cents worth on a subject I am far from being an expert
on, so those of you who are experts, please do comment!
Regards to all in this most useful of lists,
J. Andrew Hall.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
