Re: [gnutls-dev] Re: ongoing entropy problems

[Werner Koch]

On Wed, 1 Feb 2006 13:14:06 +0100, Nikos Mavrogiannopoulos said:

> Indirectly it is used during key generation. I believe libgcrypt
> uses GCRY_VERY_STRONG_RANDOM to generate an RSA key. This
> is the reason exim was blocking. It was creating an RSA key per
> connection (which is not really needed).

Well, we could add an extra flag to use reduced quality random. But if
you say it is not needed, we will postpone this.

> no, it uses a direct implementation.

>> >  2. Does gnutls save the random seed file?
>> >         gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE, filename);
>> >       atexit:
>> >         gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE);
>> No.  Should it?  What should we use as the filename?

> I also don't think we should use it. gnutls doesn't need to know about that.
> It could be used by exim though because of the way it works.

Saving the random state is really needed if you want to avoid reading
/dev/random.  There is a minor bug to to a race condition in writing,
reading the file which will trigger a read from /dev/random.  That is
however easy to fix - we have to do this for GnuPG anyway.

> As far as I was told, there is no other way to do that. However a fork
> happens really often in exim, thus is causes that problem.

Actually I assumed that.  So the easiest way to fix it is by having
Exim initialize libgcrypt and initializing, saving a random seed
file. 

I'll add an internal flock call to protect against the above race
conditions.  But even without that it should really help to use a
random seed. 

Another way to help forking servers is a function to declare the
internal random pool initialized; that would be called right after the
fork and avoids the extrs seeding libgcrypt requires when no random
seed file has been loaded; thus it would be a kind of temporary seed
file.


Shalom-Salam,

   Werner