[Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem

[Nikos Mavrogiannopoulos]

On Saturday 10 September 2005 18:18, Simon Josefsson wrote:

> > The problem seems to be libgcrypt's random generator. As far as I
> > understand when you fork() the random generator is on the same state for
> > every children. That's why the server produces the same session ID in the
> > second process.
> > I am not really sure about it, and I don't know how to overcome this,
> > that's why I crosspost to gcrypt-devel as well.
> One solution is that we switch to the random number handling that is
> implemented when --enable-nettle is given to a GnuTLS build.  Then
> GnuTLS will read (on GNU/Linux) from /dev/urandom for pseudo-random
> data and nonces, and from /dev/random for random data.

The problem with this is that a gnutls server will depleat /dev/random (we 
need to generate a master secret for each session), thus the server will be 
most of the time blocked waiting for input for /dev/random.

> Alternatively, GnuTLS could use an internal PRNG, and we could add an
> API to seed it.
The problem with internal PRNGs is that they are not thread safe (see 
libgcrypt's PRNG). 

> My personal preference is to rely on /dev/*random for randomness.  If
> that isn't sufficient for someone, she can always point GnuTLS to
> another device (or even file socket) and have full control without
> bogging down the gnutls library.
The file sockets seem like a good idea. We could still keep the libgcrypt 
PRNG, but it could run on a separate process (forked at global_init), and the
communication would be via local sockets. I don't know how good it sounds... 
but it looks thread and fork safe.
It also sound like a lot of work.


-- 
Nikos Mavrogiannopoulos