[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heuristically picking # of bits for gnutls_dh_params_generate2

From: Nikos Mavrogiannopoulos
Subject: Re: Heuristically picking # of bits for gnutls_dh_params_generate2
Date: Sun, 11 Dec 2011 14:39:33 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111114 Icedove/3.1.16

On 12/10/2011 05:41 PM, Sam Varshavchik wrote:

> 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.

gnutls with libgcrypt used a faster algorithm than the algorithm used 
in gnutls 3.x for DH parameter generation. However the 3.x version
requires stronger properties on the primes.

> 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.

Indeed. However you don't really need to do this at an application's 
run-time. You can use either the included parameters in gnutls
(using certtool --get-dh-params), or if you have requirement for
random ones, then use certtool --generate-dh-params on the background.

> 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.

You can always use weaker options to optimize generation but in that
case it might be wiser to do regeneration often (every week or month).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]