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 _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
