Mailing List Archive

On Wednesday 07 April 2004 21:52, Werner Koch wrote:

> I have not seen many comments on the last libgcrypt release.  Was it
> so awful that you all gave up sending bug reports ;-?.  Soem questions:
> * Are there any problems building it?
> * Did you try to use it with your application?
> * Comments on the new thread support scheme?

I've tested it with gnutls and a multi-threaded web server and worked fine.
I have noticed, however, a delay in the RSA parameters generation (at least
for the 512 bits that are used by gnutls). Were there any changes on this
part?

--
Nikos Mavroyanopoulos

On Wed, 7 Apr 2004 23:53:59 +0300, Nikos Mavroyanopoulos said:

> I've tested it with gnutls and a multi-threaded web server and worked fine.
> I have noticed, however, a delay in the RSA parameters generation (at least
> for the 512 bits that are used by gnutls). Were there any changes on this
> part?

There is one change in the prime generator where the callback is
called at other places using the new modes:

#define GCRY_PRIME_CHECK_AT_GOT_PRIME 1
#define GCRY_PRIME_CHECK_AT_MAYBE_PRIME 2

if you probably check for mode (which used to be 0 in previous
versions), it should not make any difference.

Werner

On Thursday 08 April 2004 09:30, Werner Koch wrote:

> > I've tested it with gnutls and a multi-threaded web server and worked
> > fine. I have noticed, however, a delay in the RSA parameters generation
> > (at least for the 512 bits that are used by gnutls). Were there any
> > changes on this part?
> There is one change in the prime generator where the callback is
> called at other places using the new modes:
> #define GCRY_PRIME_CHECK_AT_GOT_PRIME 1
> #define GCRY_PRIME_CHECK_AT_MAYBE_PRIME 2
> if you probably check for mode (which used to be 0 in previous
> versions), it should not make any difference.
How can I do that? I currently generate the parameters using
gcry_pk_genkey() with a sexp of "(genkey(rsa(nbits %d)))".

> Werner

--
Nikos Mavroyanopoulos

On Sat, 17 Apr 2004 19:53:30 +0300, Nikos Mavroyanopoulos said:

>> #define GCRY_PRIME_CHECK_AT_GOT_PRIME 1
>> #define GCRY_PRIME_CHECK_AT_MAYBE_PRIME 2
>> if you probably check for mode (which used to be 0 in previous
>> versions), it should not make any difference.
> How can I do that? I currently generate the parameters using
> gcry_pk_genkey() with a sexp of "(genkey(rsa(nbits %d)))".

That is only used for the primegen interface and not for the higher
level public key generation. IIRC, you requested this interface for
DH use?

Anywat, the old code should have looked like this:


static int
cb (void *arg, int mode, gcry_mpi_t candidate)
{
if (!mode)
return 1;
return true_if_this prime_is_of_my_taste (candidate)
}


...

err = gcry_prime_generate (&prime,
prime_specs[i].prime_bits,
prime_specs[i].factor_bits,
cb, cb_arg,
GCRY_STRONG_RANDOM,
prime_specs[i].flags);

and new code making use of the other mode might look like this:

static int
cb (void *arg, int mode, gcry_mpi_t candidate)
{
switch (mode)
{
case GCRY_PRIME_CHECK_AT_FINISH /* This has the value 0 */:
return true_if_this prime_is_of_my_taste (candidate);
case GCRY_PRIME_CHECK_AT_GOT_PRIME:
return true_if_prime_should_be_used_for_composition (candidate);
case GCRY_PRIME_CHECK_AT_MAYBE_PRIME:
return true_if_prime_check_shall_continue_for (candidate);
default:
return 1;
}
}

Applications might want to check at GCRY_PRIME_CHECK_AT_MAYBE_PRIME
time whether the candidate has the required properties (e.g. high bits
sets) and avoid the expensive Rabin-Miller tests. Not, sure whether
this is really useful, though.

However it is important to return 1 for unknown values of MODE so that
we can add new mode values.


Salam-Shalom,

Werner

On Mon, 19 Apr 2004 17:42:02 +0300, Nikos Mavroyanopoulos said:

> in the random gatherer (probably due to blocking in /dev/random). It seems
> that the VERY_STRONG flag, is quite demanding :)

Yep, it requires that the pool is updated with at least 50% of data
from /dev/random - 300 bytes once per session. So a random seed file
is only of smaller help.


Werner

On Monday 19 April 2004 15:47, Werner Koch wrote:

> >> #define GCRY_PRIME_CHECK_AT_GOT_PRIME 1
> >> #define GCRY_PRIME_CHECK_AT_MAYBE_PRIME 2
> >> if you probably check for mode (which used to be 0 in previous
> >> versions), it should not make any difference.
> > How can I do that? I currently generate the parameters using
> > gcry_pk_genkey() with a sexp of "(genkey(rsa(nbits %d)))".
> That is only used for the primegen interface and not for the higher
> level public key generation. IIRC, you requested this interface for
> DH use?
Yes that's true, but I didn't really care about the DH primes generation,
since it was already slow. The difference was in RSA keys generation which was
slowed down considerably (at least for 512 bit keys).

I just debugged it a bit, and it seems like a false alarm. The long delay was
in the random gatherer (probably due to blocking in /dev/random). It seems
that the VERY_STRONG flag, is quite demanding :)


> Salam-Shalom,
> Werner

--
Nikos Mavroyanopoulos