Bug#448775: Uses too much entropy (Debian Bug #343085)

[Andreas Metzler]

On 2008-01-04 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
> On Jan 3, 2008 2:32 AM, Marc Haber <mh+gnutls-devel at zugschlus.de> wrote:
[...]
>> 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.

Hello,
The amount of data read from /dev/urandom in Gnutls/Gcrypt is on a
different scale than in openssl:

When acting as a server gnutls pulls that much data from /dev/urandom
that entropy available for /dev/random is down to its minimum
safeguard. ((it is not possible to completely deplete /dev/random by
reading from /dev/urandom in current kernels)

ametzler at argenau:~$ cat /proc/sys/kernel/random/entropy_avail && gnutls-serv --x
509keyfile /tmp/CERT/exim.key --x509certfile /tmp/CERT/exim.crt & sleep 1 &&  ca
t /proc/sys/kernel/random/entropy_avail
[1] 5356
3591
Echo Server ready. Listening to port '5556'.
139


ametzler at argenau:~$ cat /proc/sys/kernel/random/entropy_avail && openssl s_serve
r -cert /tmp/CERT/exim.crt -key /tmp/CERT/exim.key -accept 5556 & sleep 1 &&  cat /proc/sys/kernel/random/entropy_avail
[1] 7139
3596
[...]
3361


The same thing happens when gnutls acts as a client (It does not
matter whether the server is gnutls-serv or openssl s_client since both
do no fork but setup the RNG at startup.)

ametzler at argenau:~$  cat /proc/sys/kernel/random/entropy_avail && echo xx | open
ssl s_client -connect localhost:5556 && cat /proc/sys/kernel/random/entropy_avail
3585
[...]
3329
ametzler at argenau:~$  cat /proc/sys/kernel/random/entropy_avail && echo xx | gnutls-cli -p 5556  localhost > /dev/null 2>&1 && cat /proc/sys/kernel/random/entrop
y_avail
3593
[...]
140

(Tests done with GnuTLS 1.4.4., I don't think there have been
substantial changes in the libraries in that respect. 2.0.4 behaves
the same.)

So with a forking daemon (therefore initialising the RNG for every in-
and outgoing connection) GnuTLS will deplete entropy_avail to its
bare minimum vor every single connection, while openssl only takes
about 7%.

What is the actual cause of this difference in resource usage?
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'