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

[Nikos Mavrogiannopoulos]

On Monday 12 September 2005 02:35, Simon Josefsson wrote:

> >> 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.
> I see.  But isn't it worse to use master secrets based on poor random
> data?  The kernel block the read for a reason, after all.
Using good PRNGs even for master secrets is acceptable, as long as the seed is 
long and random enough. Also blocking a TLS server, for seconds or even 
minutes in order for randomness from the kernel to be obtained is 
unacceptable by most of the sites today.

> I don't see how libgcrypt is in a better position to always give out
> randomness than the kernel is.  Also, I think the current use of
The kernel's random functions have not really been designed for being used
in cryptographic libraries that require several levels of randomness --in a 
non blocking way. Also by using /dev/urandom (say for nonces) you also 
deplete the /dev/random pool. This is unacceptable. Thus the best way is to 
use some good PRNG sinstead of the kernel's.

> libgcrypt's randomness functions by GnuTLS for TLS master secret is
> equivalent to /dev/urandom, not /dev/random.  And /dev/urandom never
> block, as far as I know.
Of course... but the uses of /dev/random are really limited. It has high 
quality (say) of randomness thus you may use it to generate a private key... 
but for session keys that might be thousants per second it is too much.

> I think we should change the GnuTLS default to read from /dev/urandom
> for pseudo-random data like TLS master secrets.  Unless there is a
> simple way to make libgcrypt work after fork.
I saw that Werner made a fix for it. Haven't tested it though.

> Thanks,
> Simon

-- 
Nikos Mavrogiannopoulos