[Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem
nmav at gnutls.org
Mon Sep 19 12:32:13 CEST 2005
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.
More information about the Gnutls-help