[gnutls-dev] Re: ongoing entropy problems

[Simon Josefsson]

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2006-01-31 Simon Josefsson <jas at extundo.com> wrote:
>> Jason Lunz <lunz at falooley.org> writes:
>> > Are the gnutls developers aware of the ongoing entropy-pool-draining
>> > problems with gnutls in exim4? For example:
>
>> > http://article.gmane.org/gmane.linux.debian.devel.exim4.user/477
>
>> > Is this a known problem? Can something be done about it?
>
>> We are working on it, please see the other current threads on the
>> mailing list.
>
>> I believe we have identified the problem, and proposed a solution, so
>> a exim developer could probably implement it.  Any exim developers
>> following this?
>
> Hello,
> As far as I gather from reading http://bugs.debian.org/343085 and the
> thread "Feature request: not really random session keys" on gnutls-dev
> there are two problems.
>
> #1: Online, blocking generation of RSA-params and DH-params in exim.
> This is already fixed for quite some time in exim (thanks Nikos
> Mavrogiannopoulos), it switched to using a certtool-compatible
> fileformat for these parameters and certtool can be used for
> generating them offline.

Right.

> #2: Florian Weimer wrote in http://bugs.debian.org/343085
> | As a side note: With GNU TLS, every _single_ encrypted mail
> | transmission _totally_ depletes my entropy pool (going from ~3500 to
> | ~150), but after recompiling Exim4 with OpenSSL, only about 200 bits
> | (the number is difficult to measure, but it is way less than with GNU
> | TLS) are used.
>
> For bug #2 /dev/urandom is used, therefore there is no blocking in
> exim, just the fact that anything using /dev/random will block, as
> there is no entropy left.
>
> The issue Jason is refereing to is #2, which is not fixed /yet/ but
> known.

Agreed.  I believe /dev/urandom is poorly designed if reading from it
make /dev/random unusable.  I think this should be raised with the
kernel developers.

I believe we can, and probably should, implement some workaround for
this.  Until GnuTLS supports other crypto libraries than libgcrypt,
solving that problem should likely be done in libgcrypt, or possibly
by improving GnuTLS's use of libgcrypt (like saving the seed).

Thanks.