Multi-thread

[Antoine Dumont]

Hello,
Thanks for this ironic answer Karl but you don't really answer the question.
I think there was a little misunderstood, make sure that I don't want to
generate a 30,000 bit RSA key , I'm not stupid.
I spoke about a 15,000 DSA key , or a 7,000 bit DSA key  (for "N"
parameter) I think it wasn't really unbelievable. It's just 2^15000
smaller than you think I propose. Moreover, NIST recommendations
indicate that a such level of protection is equivalent of a level of 256
bits of securiy, it's not unbelievable. If I want to create an high
authority which sign other keys for few years (3-5 years), high value is
required . The manual of libgcrypt says that 15360bit key or 7680bit (or
any multiple of 8 between 512 and 15680 if  Q parameter is specified)
for DSA algorithm is possible, and when I try to generate a such key it
was very long and I use only one core, I think it's regrettable.
You confirm me that primary test is a stochastic test, which is classic,
so why don't make guess-and-check operations in different thread : the
first who find the key stop the others ? It's just my question.
I must understand that you prefer to make the generation of key without
multi-thread but I just would like to know why.
An other question, again about the key generation , when I try to
generate a 7680bit DSA key or an DSA key whose length is higher than
6000bits, I have a stranger error :
"Ohhh jeeee : ... this is a bug (pubkey.c:2266:_gcry_pk_genkey)"
and after the program exit.
Are you familiar with this sort of bug ?
Thank again for your job,
Best regards

Le 08/10/2009 15:24, Karl Magdsick a écrit :
> Did you add an extra zero in there, or are you really generating
> 30,000-bit RSA keys?   If you really need 30,000-bit RSA in 2009,
> either you know something about breaking RSA that the public doesn't,
> or you have a lot of other things to worry about besides just
> cryptography.
>
> I'm not sure what questions lead to "30,000-bit keys" being the
> answer, but you should probably take a step back and see if you're
> asking the right high-level questions before going into the details of
> how to generate 30,000-bit keys faster.
>
> Do you really need keys that amazingly large?  If so, you probably
> also want to do something like use RSA to encrypt  a key encrypted
> using an elliptic curve method, read up on cryptosystems that appear
> difficult to crack with quantum computers, and definitely hire a
> professional cryptographer to review your design and implementation.
>  As far as I know, not even governments use 30,000-bit RSA.  (I've
> heard the NSA now uses 511-bit elliptic curve crypto.)
>
> Problems big enough to require keys that big also probably require at
> a minimum a vault and armed guards, probably thermite and anti-tamper
> sensors, and perhaps an armored tank or two,  For the cost of cracking
> 30,000-bit RSA using current publicly known algorithms, an attacker
> could hire a small private army.  Personally, I'd just prefer not to
> deal in secrets whose value may justify the costs of hiring someone to
> kidnap me and coerce my keys out of me, but that's just a personal
> preference.
>
> As to your original question, I believe the APIs are thread-safe, but
> not internally multi-threaded.  If you're only generating one key, the
> latency for generating one key isn't terrible and happens rarely.
>  Making the library internally multi-threaded would reduce its
> efficiency (locking, scheduling, and context switch overhead) in
> generating many keys at once in a server situation or in applications
> that use a lot of keys.
>
> Since prime number generation is a stochastic guess-and-check
> operation, as an ugly hack, you may be able to get a slight speed-up
> by having each core generate one key, and using whichever key gets
> generated first.  I imagine your entropy source may very well be your
> bottle neck, though.  Generating two 15,000-bit cryptographically
> pseudorandom prime numbers is going to burn through a lot of
> cryptographically secure pseudorandom bits.
>
> Now, there's a hornets' nest in my back yard that I've been meaning to
> get rid of and my tank is on the fritz... do any of you have a
> maintenance manual for a WWII Sherman?
>
> On Wed, Oct 7, 2009 at 5:47 AM, Antoine Dumont
> <antoine.dumont86 at gmail.com <mailto:antoine.dumont86 at gmail.com>> wrote:
>
>     Hy,
>     First of all, thanks a lot to the developers of this library and
>     particularly to Werner Koch for his job.
>     My purpose is about the generation of asymetric keys. When I
>     generate a couple of key of DSA or RSA algorithm thanks to the
>     function gcry_pk_genkey it can be very long and I understand that
>     generate primary numbers of 15000 bits is not very simple. But i
>     asked me why the library use only one core. I can compile and run
>     my program in machine whose have many core and I suppose it's
>     possible.
>     After reading the reference manual, I saw that multi-thread is
>     supported, I suppose it's meaning that we can use the library into
>     a multi-thread program, but is the library itself multi-thread ?
>     Thanks a lot for your answers !
>     Best regards,
>     Lao
>
>     _______________________________________________
>     Gcrypt-devel mailing list
>     Gcrypt-devel at gnupg.org <mailto:Gcrypt-devel at gnupg.org>
>     http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20091013/95549703/attachment-0001.htm>