Gratuitous gcry_fast_random_poll

[Werner Koch]

On Wed, 5 May 2004 16:10:09 -0500, Christian Grothoff said:

> All I'm saying is leave that to the application. For example, I may not be 
> using any key generation from libgcrypt, so I definitely don't need any of 

You may want to create a signature and thus you need random.  There
are quite some palces where random numbers are required and so for the
avaerage application the current scheme works.

> the PRNG code.  And as others have remarked before, assertion failures are 
> bad anyway -- return error codes.  If the client doesn't check them, then the 

It is not always pissible to return error codes.  Some functions are
expected to simply work.  If they don;t, something is badly wrong with
their environment.

> originally written for an earlier version of libgcrypt and had not been 
> adapted.  Anyway, it should work just fine (with any version of libgcrypt) if 
> the client guarantees that only one thread enters libgcrypt at a time.  Now, 

Obviously there is another thread using libgcrypt.  

> time for operations that may require global state" -- and the call in 
> question requires global state (and sync) on a path where that's completely 
> counter-intuitive.

You should not make any assumption about the internal working of a
library.  This may work for one version but maybe not for the next.
We have tried to hide all details but your are still looking inside.\
- don't do this.

> Oh, we're using pthreads, I've resolved the problem by putting some extra 
> locks around our libgcrypt calls (since I don't want to rely on a 'recent' 
> libgcrypt version).  Nevertheless I find the random-poll is completely out of 
There is only one stable release yet - all prior releases where
clearly marked as under development.  Please change gnunet to properly
intialize libgcrypt and you are set.

> random (pun not intended) injection of the call.  The code in question 
> initializes the symcipher millions of times but never ever creates a single 

If you make such heavy use of cipher_open, please change your
application to presever the context returned by cipher_open and use
gcry_cipher_reset before setting up a new key and IV.  This will avoid
a lot of other overhead too.

  Werner