[gnutls-dev] Re: ongoing entropy problems
wk at gnupg.org
Wed Feb 1 15:48:59 CET 2006
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
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
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
More information about the Gnutls-dev