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