Heuristically picking # of bits for gnutls_dh_params_generate2

[Sam Varshavchik]

Does anyone happen to know of a good heuristic to come up with some  
reasonable number of bits at runtime that I can give to  
gnutls_dh_params_generate2, and have reasonably odds of coming up with a DH  
pair in, maybe, 5-10 seconds.

I was hacking on some code in a 32 bit guest VM, and I thought that I was  
corrupting something, because gnutls_dh_params_generate2 was seemingly  
getting stuck, spinning forever. But it turns out that it was really just  
very, very slow.

I don't think it's the VM itself, it seems to run reasonably well to me.  
Regular compiles get completed at a fairly reasonable pace. I don't know if  
it's just that gmp is slow on i686, if something is not right with the rnd  
generator, or something other reason. I'm just used to my native x86-64 bare  
metal cranking out a key at a good clip. After feeding 2048 bits to  
gnutls_dh_params_generate2 it cranks something out in only a few seconds.

But, for whatever reason may be, flipping over to an i686 guest VM, and  
gnutls_dh_params_generate2 runs slow as molasses. I'm clocking a 1024 bit  
run of gnutls_dh_params_generate2 to take several minutes long, typically.  
Sometimes I get lucky, and come up with a 1024-bit based parameter in 5-10  
seconds. But my last two runs took a minute and a half, and over three  
minutes, each, and that's typical. With GNUTLS_SEC_PARAM_NORMAL telling me  
that I should use 3072 bits, that'll probably take a day.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20111210/b4c2c8ab/attachment.pgp>