wk at gnupg.org
Fri May 7 16:14:09 CEST 2004
[I assume, Nikos sent his mail accidently only to me].
On Fri, 07 May 2004 13:19:16 +0300, Nikos Mavroyanopoulos said:
> Seems fine then. Maybe removing the initialization part of this function
> might speed up things to programs that do not use the rnd (just hash
> or encrypt). So this will only update the pool if initialized. I don't know if
I have done these changes right now in the CVS and you or Christan
might want to look at it. If this works out, I will gop into 1.2.1.
The random number is now only initialzed when random numbers are
actually been requested or the new macro gcry_fast_random_poll() has
been used. The internal _gcry_fast_random_poll is a NOP as long as
the RNG has not been initialized - thus for simple application
/dev/random should not even be opened.
There is of course the drawback that we put less of possible entropy
into the pool but I don't consider this a serious problem because two
calls to the internal fast random poll function in a short time won't
make any difference as the current time and used resources will be
mostly identical (I assume that a cipher_open or md_open will
immediatley be followed by a request for random or vice versa). And
more important, good random for the RNG will either be sucked in from
/dev/random or a seed file at startup anyway.
If you have an application with a main processing loop or other points
in the code which are regulary called (say about every second) you
might already want to start adding this
and as soon as you use compile against a newer libgcrypt version this
will be used. Don't use this in a timer tick handler - it would be
More information about the Gcrypt-devel