[gnutls-dev] Speed of random data generation

[Alex Hudson]

Werner,

Thanks again for a very informative e-mail.

On Fri, 2007-06-15 at 09:28 +0200, Werner Koch wrote:
> > 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
> results. 

Are you talking about /dev/urandom here, or /dev/random? 

> My conclusion is that the quick random mode is not worse than what
> OpenSSL has.  I will change the manual to reflect this statement.

That's useful to know - I feel more comfortable offering it as an option
on that basis.

> But wait:
> 
> 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?

No. We did try the OpenSSL emulation when we first used GNUTLS, but to
be honest we didn't experience much success. We didn't care too much
about OpenSSL compatibility, so we went GNUTLS-native.

I did some testing with part of our crypto generation. I did this on my
laptop, which has plenty of entropy, but ..ENABLE_QUICK_RANDOM made an
obvious difference.

The code I ran is this:

	gnutls_global_init();

	// data 1

	gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE);

	// data 2

	// DH params
	gnutls_dh_params_init(&dh_params);
	gnutls_dh_params_generate2(dh_params, 1024);
	gnutls_dh_params_export_pkcs3 (dh_params, GNUTLS_X509_FMT_PEM, &dhdata,
&dsize);

	// data 3
	
	// RSA params
	gnutls_rsa_params_init(&rsa_params);
	gnutls_rsa_params_generate2(rsa_params, 512);
	gnutls_dh_params_export_pkcs3 (rsa_params, GNUTLS_X509_FMT_PEM,
&rsadata, &dsize);

	// data 4

At those points I marked 'data', I did:
	
	gcry_control(GCRYCTL_DUMP_RANDOM_STATS, NULL);

And the results were:

(without QUICK_RANDOM):

1	random usage: poolsize=600 mixed=2 polls=5/1 added=11/692
	              outmix=1 getlvl1=1/1 getlvl2=0/0
2	random usage: poolsize=600 mixed=3 polls=5/1 added=11/692
	              outmix=2 getlvl1=1/1 getlvl2=0/0
3	random usage: poolsize=600 mixed=49 polls=5/29 added=179/3268
	              outmix=30 getlvl1=29/755 getlvl2=0/0
4	random usage: poolsize=600 mixed=54 polls=5/31 added=227/3752
	              outmix=32 getlvl1=29/755 getlvl2=2/64

(with QUICK_RANDOM):

1	random usage: poolsize=600 mixed=2 polls=0/1 added=11/720
	              outmix=1 getlvl1=1/1 getlvl2=0/0
2	random usage: poolsize=600 mixed=3 polls=0/1 added=11/720
	              outmix=2 getlvl1=1/1 getlvl2=0/0
3	random usage: poolsize=600 mixed=58 polls=0/29 added=179/3296
	              outmix=30 getlvl1=29/755 getlvl2=0/0
4	random usage: poolsize=600 mixed=62 polls=0/31 added=191/3480
	              outmix=32 getlvl1=31/819 getlvl2=0/0

On the first run, it _noticably_ depleted my entropy. I can't tell
exactly how much it read, but I had "3600" (bytes? bits?) to begin with,
and it quickly dropped to nothing. The process then stalled while it
waited for more entropy.

On the second run, the value in entropy_available didn't drop below 3500
(though I had only a 2 second watch on the value, my entropy doesn't
fill up _that_ fast - I don't think it could have been much lower than
3300 in any event).

This is using gnutls-1.4 as shipped in Fedora Core 6 - it really did
seem to make a big difference. Perhaps there is a bug somewhere which is
resulting in GNUTLS asking for stronger random numbers?

Cheers,

Alex.