[gnutls-dev] Speed of random data generation
wk at gnupg.org
Fri Jun 15 09:28:01 CEST 2007
On Thu, 14 Jun 2007 19:19, home at alexhudson.com said:
> in our situation, we want our software to work on standard GNU/Linux
> distributions, so we can't really ship our own libgcrypt without
> creating worse problems.
I guessed that.
> I hadn't seen this before, thanks. However, in the manual it does say:
> "This command activates the use of a highly-insecure, but fast
> PRNG. It can only be used at initialization time. The only
> useful applications for this are certain regression tests."
> If we used GNUTLS with this turned on, would GNUTLS be working in much
> the same way as OpenSSL does (wrt. cert generation, etc.), or would it
> be a worse position?
Actually it will still read a little bit form /dev/random for initial
seeding but then degrade the quality level to GCRY_STRONG_RANDOM (1).
grep fro "quick_test" in cipher/random.c:
_gcry_quick_random_gen( int onoff )
/* No need to lock it here because we are only initializing. A
prerequisite of the entire code is that it has already been
initialized before any possible concurrent access */
read_random_source(0,0,0); /* init */
last = quick_test;
if( onoff != -1 )
quick_test = onoff;
return faked_rng? 1 : last;
That is just to enable this mode. faked_rng will only be true on
systems without any entropie source and print prominet warnings.
if( !is_initialized )
return (faked_rng || quick_test);
Well this function will return true if quik_test has been enbaled and
that is the reason for the wording in the manual.
static byte *
get_random_bytes ( size_t nbytes, int level, int secure)
byte *buf, *p;
/* First a hack to avoid the strong random using
our regression test suite. */
if (quick_test && level > 1)
level = 1;
Thus you can see that we only degrade the level in the quick random
gcry_randomize (void *buffer, size_t length, enum gcry_random_level level)
/* Make sure we are initialized. */
/* Handle our hack used for regression tests of Libgcrypt. */
if( quick_test && level > 1 )
level = 1;
Same as above.
> is very strong ("highly-insecure"). Is the manual being very paranoid,
> or is there a real risk here?
The whole problem is that we don't have any good estimation of
/dev/random's quality. I still have some doubts. In former times it
was quite stable code whichhas not been touches very often but since
Linux 2.3 (iirc) there have been numerous changes with very differnt
outcvome on the available entropie. A real solid report on /dev/random
is still missing and I doubt that the NSA folks will publish their
But well, that is not spexial to libgcrypt as OpenSSL woull be affected
My conclusion is that the quick random mode is not worse than what
OpenSSL has. I will change the manual to reflect this statement.
I just checked some _old_ GNUTLS code and it seems that it does not use
GCRY_VERY_STRONG_RANDOM for the prime generation. So the quick mode
won't help you at all. Actually I can find only
../libextra/gnutls_openssl.c which uses GCRY_VERY_STRONG_RANDOM in
RAND_bytes - do you use the OpenSSL emulation?
More information about the Gnutls-devel