On Fri, Oct 5, 2012 at 6:42 AM, Jakob Bohm <jb-open...@wisemo.com> wrote:
> On 10/5/2012 9:54 AM, int0...@safe-mail.net wrote:
>>
>> > On computers that don't have a good /dev/*random, the randomness used
>> > by OpenSSL comes only from things happening on the computer during the
>> > few moments when the openssl tool is running. To gather up more
>> > randomness, the openssl tool tries to accumulate randomness over
>> > multiple runs as follows:
>> >
>> > 1. At the end of each run that used the random number generator,
>> > write a file of random bits (computed so they have a lot of entropy but
>> > do not reveal any of the random numbers already generated).
>> >
>> > 2. At the start of each such run, read in that file and use it as an
>> > initial pool of random bits to be mixed with any random system activity
>> > observed during the run.
>> Thanks for the explanation, that clarified things!
>> How does the OpenSSL tools know if /dev/{random,urandom} is "good"?
>>
> Basically it is a compile time decision. The code assumes that there is a
> usable /dev/*random with a specific name (such as /dev/random) when compiled
> for certain operating systems and that there is not on others.
>
>> > So the seed written to ${HOME}/.rnd is supposed to stay around until the
>> > next time you run the openssl tool, and reveals very little about keys
>> > you alredy created. But it may reveal something about the next key you
>> > create, which is why the file is/should be written with permissions so
>> > only you can read it.
>> I saw some people getting their randomness from /dev/random via
>> dd if=/dev/random of=/root/.rnd... and using the -rand parameter to give
>> the seed to openssl. If I got you right, that is a redundant step, since
>> OpenSSL
>> takes its randomness from /dev/random as well. Using -rand would only be
>> necessary
>> if one has a hardware random number generator (for example). Is that
>> right?
>
> If the OpenSSL version they used assumed that /dev/random was not working
> on that platform,then this step is an elegant workaround.
>
>> So my to go would be:
>> Set $RANDFILE to /root/.rnd and leave it up to openssl to use the file,
>> without filling it myself. I only need to make sure the permissions are
>> set
>> correctly. Is that right?
>
> Setting it to ${HOME}/.rnd would be better as it would work for non-root
> users.
>
>> > Now why OpenSSL keeps doing this on platforms with a good OS random
>> > source (such as non-historic Linux versions, some BSDs, recent Solaris
>> > versions, non-historic Windows versions) is a mystery to me.
>> Can somone else bring some light into this?
Also be careful of virtual environments, especially if the platform
does not have drivers to push seeds to the VM through a mechanism such
are virtio_rng. I seem to recall Debian or Ubuntu did not have a
driver out of the box (or had a misconfigured driver).
I think the short of it is an application should take a defensive
position and try and acquire seed material from the following (for
seeding an approved, in-app generator):
* random
* urandom
* virtio_rng
* hw_random
I'm only aware of two papers on the subject (perhaps there is more
now). The proposed solution was using the network to acquire
additional entropy though a remote host's public key and SSL/TLS
algorithm parameters (IIRC).
Jeff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
