libgcrypt 1.1.93 released

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just wanted to throw in another reason why I like Nikos suggestion to add a
handle for the PRNG.  I would like to be able to pass my own PRNG to the
(RSA) key generation.  Now, I don't know if that's currently possible (didn't
have the time to look into this so far), but _if_ the PRNG is the only thing
that keeps gcrypt from being thread-safe, the ability to easily replace the
PRNG with external code gives yet another motivation to do this using some
handle (or more specifically, some callback construct which can be conceived
as a handle).

just my 2 cents

Christian

On Tuesday 09 March 2004 08:35 am, Marcus Brinkmann wrote:
> At Tue, 9 Mar 2004 15:08:19 +0200,
>
> Nikos Mavroyanopoulos wrote:
> > Since the only non-reentrant part is the random generator, an other
> > solution would be to add a thread safe random number generator api
> > (ie return handle of a pool), so the only one bothered with
> > locking is the application.
>
> I don't know gcrypt internals to say if that is the only problematic
> location in the code.  It very well might be (I assume you have
> checked :), but there might be others in the future.  Plus, we also
> have this issue in gpgme, which is I/O intensive and calls
> sub-processes, and we would like a common solution if possible (for
> maintenance reason).  But all of that would not be convincing if the
> solution you propose wouldn't have the exact problem as I wrote above,
> namely that you'd then have to pass on the interface in every
> intermediate library to the application level.
>
> > Another solution would be for libgcrypt to fork a rng proccess,
> > and communicate using IPC with it. This would be certainly thread
> > safe (however this only works in systems with fork() available).
>
> Mmh, it's an interesting idea.  However, it appears to me that any
> such solution would end up to be specifically tailored around one
> particular issue (random pool in gcrypt here).  It's much more
> preferable (for obvious reasons) to have a common solution.
>
> All in all, good suggestions.  Keep it going!  In particular, don't be
> shy to tell me if you think my above counter-arguments are not sound
> or incomplete.  We are very much open for a discussion of this.  We
> only believe to have thought it all through, we have not proven it :)
>
> Thanks,
> Marcus
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFATdp99tNtMeXQLkIRAq9GAJ92RBsqu19r0T3JwV2/2QDiYdeIwgCfWHyv
XPuJnftyw6lvjp2SFSS6hJc=
=SqM6
-----END PGP SIGNATURE-----