[gnutls-dev] Re: Feature request: not really random session keys

[Simon Josefsson]

Florian Weimer <fw at deneb.enyo.de> writes:

> Okay, the subject line might be a bit misleading.  On server machines,
> random bits are a very scarce ressource, and you cannot really afford
> to throw them a way at a rate of a few kbps.  Yet if you run certain
> network servers (or clients) with GNUTLS, this is what happens -- and
> these servers stall from time to time, waiting for more randomness.
>
> I would like to see an additional API which allows code to degrade
> session key randomness to a mere PRNG (i.e. /dev/urandom instead of
> /dev/random).  In a theoretical sense, this sacrifices Perfect Forward
> Secrecy, but for some applications (MTAs, for example) this is not
> such a relevant issue anyway.

We are working on this issue, but we don't really know how to solve it
currently.  See Werner's last post on the 'living without global
variables' thread for some problems.  I have added the following to
doc/TODO to make sure we don't forget it.

* RNG improvements, to avoid /dev/random blocking on busy servers.

You can specify --without-libgcrypt and then specify
--enable-random-devices=/dev/urandom, but the non-libgcrypt mode is
not well tested yet.

The goal is probably to provide some new APIs for applications that
want to modify this themselves, and some environment variable so users
can override this per-application.  The environment variable could
contain a path to a device/socket that contain the random data.

I'm beginning to think we should read from /dev/urandom by default.
People with stronger RNG needs could change the path through the
environment variable, and start some RNG daemon that collect entropy
and serve it through that device or socket.

I'd also like to support a strong PRNG seeded from a file, but I find
it very complicated to do this.  The problem is how to avoid having
multiple GnuTLS instances read the same PRNG seed and thus generate
the same random data.  Doing that in a portable fashion is a
challenge.

Thanks.