Multi-thread

[Antoine Dumont]

That is a very good and complete answer !
Thanks ! I will read documentation more :)
Sorry to ask some questions again but about the problem of a good random
generation have you find something else than /dev/random (or
/dev/urandom for less quality) ?
Have a nice day !


Le 13/10/2009 21:05, Karl Magdsick a écrit :
> Make that about 5 times as large as allowed for US federal agencies by
> FIPS 183-3.
>
> On Tue, Oct 13, 2009 at 2:50 PM, Karl Magdsick <kmagnum at gmail.com
> <mailto:kmagnum at gmail.com>> wrote:
>
>     You still appear to me to be generating DSA keys approximately 10
>     times as large as the largest size allowed for US government
>     entities by FIPS 183-3.  ("Federal government agencies shall
>     generate digital signatures using one or more of these choices."
>     FIPS 183-3, section 4.2, listing possible values of the DSA
>     parameter L as 1024, 2048, and 3072.)  I doubt any NIST
>     recommendations published after FIPS 183-3 (and before today's
>     date) contradict FIPS 183-3.
>
>     On Tue, Oct 13, 2009 at 9:15 AM, Antoine Dumont
>     <antoine.dumont86 at gmail.com <mailto:antoine.dumont86 at gmail.com>>
>     wrote:
>
>         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.
>
>
>     You spoke of 15,000-bit primes for DSA or RSA.  RSA keys using
>     15,000-bit primes use 30,000-bit moduli, assuming 2-factor RSA.  I
>     believe 3-factor RSA is encumbered with intellectual property issues.
>      
>
>         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 .
>
>
>     FIPS 183-3 (approved and published June, 2009), section 4.2 (page
>     15) lists values for N of 160, 224, and 256.  N is the number of
>     bits in the prime q.  The  largest L listed is 3,072, resulting in
>     a 3,072-bit prime p.  This standard points to SP 800-57 for
>     further guidance on domain parameter size.  SP 800-57, section
>     4.2.4.1 (page 37) mentions the same parameter sizes.  FIPS 183-3,
>     sections A.1.1 and A.1.2 don't mention use of any parameters that
>     would be anywhere near 15,000 bits.
>
>     Where are you getting these NIST recommendations for (L, N) ?  I
>     don't see anything in FIPS 183-3 that would suggest FIPS 183-3
>     compliant values for L are anything but 1,024, 2,048, and 3,072.
>
>     On a side note, when one speaks of the number of bits of security
>     for a signature or hash algorithm, one takes into account the
>     birthday attack, so SHA-256 has at most 128-bit strength.  This
>     convention helps in matching the size of hash functions, signature
>     algorithm parameters, and symmetric encryption keys.
>      
>
>         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.
>
>
>     The libgcrypt manual may say that those sizes are possible (I
>     haven't checked), and if so, it would seem to be correct.  I don't
>     think the manual guarantees that these huge sizes will be speedy
>     or even practical.
>      
>
>         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.
>
>
>     Because this is the simplest way I can think of that may give you
>     a speed increase without modifying libgcrypt.  It may or may not
>     provide a speed increase.  It's certainly less efficient,
>     providing a speed-up that's very much less than linear.
>      
>
>         I must understand that you prefer to make the generation of
>         key without multi-thread but I just would like to know why.
>
>
>     Amdahl's law plus synchronization, coordination, and communication
>     overhead.
>
>
>     Cheers,
>     -Karl
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20091014/2697350d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091014/2697350d/attachment.pgp>