Multi-thread

[Karl Magdsick]

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>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
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20091008/828a044f/attachment.htm>