GnuTLS (libgrypt really) and Postfix

[Simon Josefsson]

Victor Duchovni <Victor.Duchovni at MorganStanley.com> writes:

> The real culprit is libgcrypt, whose log_fatal() macro terminates the
> calling process. This is undesirable in a general purpose library. If
> the authors of GnuTLS have any influence on the design/implementation
> of libgcrypt, I hope they will make an effort to see this issue addressed.

We have made some efforts, but the design of libgcrypt has not
changed.  libgcrypt is problematic for two reasons:

  1) It invoke exit, as you have noticed.  While this only happen
     in extreme and fatal situations, and not during runtime,
     it is not that serious.  Yet, I agree it is poor design to
     do this in a library.

  2) If used in a threaded environment, it wants to have access to
     thread primitives.  The primary reason was for RNG pool locking
     (where it is critical), but I think the primitives are now used
     in other places too.  GnuTLS is thread agnostic, so it can't
     initialize libgcrypt properly.

I have decided that the best approach to solve this is to make GnuTLS
crypto-agnostic.  We now invoke libgcrypt through a simpler wrapper
API.  I have completed this for hashes, symmetric encryption, RNG, but
MPI and PK operations are not yet moved from the libgcrypt to the
general API.  We have started to integrate LibTomMath for the MPI
library, but not yet finished that work.  (In case you are wondering
why we didn't use GMP: it also calls exit, and may have blinding and
timing issues, otherwise I really like GMP.  I know of no other MPI
libraries with a free license and of similar high code quality that
LibTomMath.)

We've made some progress on the RNG issue on the GnuTLS discussion
list.  I think the Linux /dev/urandom implementation is sub-optimal.
When used heavily, it depletes the /dev/random pool, causing
applications that access /dev/random to stall.  I believe /dev/urandom
should be changed, to be a PRNG (re-)seeded with strong randomness
from the /dev/random pool, rather than simply taking entropy from the
/dev/random pool directly.  The source code for the /dev/random
interface in Linux is rather unreadable IMHO.  The code for it should
not be as complicated it is today.

This is an area that is very much alive, and if any prospective
developers here want to help with this effort, that would be greatly
appreciated.  Please join the GnuTLS-developer list if you are
interested:

              http://lists.gnupg.org/mailman/listinfo/gnutls-dev

Thanks,
Simon

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com