Uses too much entropy (Debian Bug #343085)

[Nikos Mavrogiannopoulos]

On Jan 3, 2008 2:32 AM, Marc Haber <mh+gnutls-devel at zugschlus.de> wrote:

> Hi,
>
> Debian Bug #343085, http://bugs.debian.org/343085
> This is an example bug for the entropy issue which seems to be the
> most pressing issue with Exim4 and GnuTLS at the moment. Let me give
> you a little background: Exim4's documentation used to recommend
> deleting the dh-parameter file needed for some crypto operations on a
> regular basis. The cron job used to remove the file, and exim then
> proceeded to re-built the file on the next TLS operation. This
> generation reads from /dev/random, blocks if no entropy is available,
> which leads to entropy starvation and an interrupted e-mail service.
>
> We have reacted to this issue by removing the RSAEXPORT algorithms,
> eliminating the need for the blocking operation. However, this issue
> has left our user base in some kind of sensitiveness when exim4's TLS
> operations goof in the presence of low entropy. Currently, our
> research has shown that using exim4 as a TLS server will not block,
> but keep the system's entropy at a very low level during even only
> moderately busy operation. As a result of this issue, GnuTLS bugs
> http://savannah.gnu.org/support/?106113 and
> http://savannah.gnu.org/support/?106112 were filed.
>
> The entropy issue is also mentioned in http://bugs.debian.org/446036
> and http://bugs.debian.org/448775.

My point of view was:

> This looks more like a bug of the implementation of /dev/random and /dev/urandom rather than a gnutls bug. GnuTLS (libgcrypt) reads >some bytes per process from /dev/urandom in order to be able to initialize it's PRNG. Since exim uses lots of processes the
> /dev/urandom pool could be exhausted. Since /dev/urandom is public the security of the system shouldn't depend on someone reading
>bytes from it. You replied:

> have to disagree with this being a kernel bug. man 4 random on Linux documents how /dev/urandom behaves, and is supposed to behave.
> "Some bytes" looks more like "a few hundred bytes", and Exim does not exhaust /dev/urandom as badly when OpenSSL is used. If
>  GnuTLS wants to be a free (speech) alternative to OpenSSL, it does not need more issues that OpenSSL, it needs to do things actually better.

We don't market gnutls as an openssl replacement. It is an alternative
to it and it has different inner workings. We do provide a complete
documentation of these so anybody can create his software using it. We
(or better I) are not interested into creating a plug and play openssl
replacement. However on the point. I still believe it is a kernel
issue. A process should not be able to deplete randomness in a system.
There are algorithms that can do that, and there were even rejected
kernel patches that implemented them.

A workaround might be to use the libgcrypt's random number process
feature which uses a single server process to feed other processes
with entropy (I've never worked with it so I don't know if it can be
used in that case). This might solve this issue.

regards,
Nikos