Gratuitous gcry_fast_random_poll

[Werner Koch]

[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

#ifdef gcry_fast_random_poll
     gcry_fast_random_poll ();
#endif

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
mostly pointless.



Salam-Shalom,

   Werner