From antoine.dumont86 at gmail.com Wed Oct 7 11:47:29 2009 From: antoine.dumont86 at gmail.com (Antoine Dumont) Date: Wed, 07 Oct 2009 11:47:29 +0200 Subject: Multi-thread Message-ID: <4ACC63B1.2070707@gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmagnum at gmail.com Thu Oct 8 15:24:16 2009 From: kmagnum at gmail.com (Karl Magdsick) Date: Thu, 8 Oct 2009 09:24:16 -0400 Subject: Multi-thread In-Reply-To: <4ACC63B1.2070707@gmail.com> References: <4ACC63B1.2070707@gmail.com> Message-ID: 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 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: From antoine.dumont86 at gmail.com Tue Oct 13 15:15:55 2009 From: antoine.dumont86 at gmail.com (Antoine Dumont) Date: Tue, 13 Oct 2009 15:15:55 +0200 Subject: Multi-thread In-Reply-To: References: <4ACC63B1.2070707@gmail.com> Message-ID: <4AD47D8B.8030108@gmail.com> 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 > > 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: From nmav at gnutls.org Tue Oct 13 15:56:42 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 13 Oct 2009 16:56:42 +0300 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Hi, thanks for the investigation. >From the following trace: libgcrypt.so.11`md_enable+0xfc libgcrypt.so.11`md_open+0xfc I suppose that this leak occurs in libgcrypt md_enable() in md.c. I cannot figure out where exactly though. I CC the gcrypt-devel list for more insight. best regards, Nikos 2009/10/12 tangtong : > I have redone my test and go through the memory leak points, I get the > following info: >> ::findleaks > CACHE LEAKED BUFCTL CALLER > 00204e08 1 004ab7e8 libclntsh.so.10.1`sigpnm+0x80 > 0020b188 7816 007f53b0 libgcrypt.so.11`do_malloc+0x54 > 0020ae08 106 0130e960 libgcrypt.so.11`do_malloc+0x54 > 0020dc08 1 00c0cd98 libgcrypt.so.11`do_malloc+0x54 > 0020dc08 63 008a5e78 libgcrypt.so.11`do_malloc+0x54 > 0020ae08 8153 0043f518 libgcrypt.so.11`do_malloc+0x54 > 0020b188 422 01046168 libgcrypt.so.11`do_malloc+0x54 > 0020dc08 8330 00b3d860 libgcrypt.so.11`do_malloc+0x54 > 0020dc08 8230 01206438 libgcrypt.so.11`do_malloc+0x54 > ---------------------------------------------------------------------- > To! tal 33122 buffers, 21130336 bytes > >> 007f53b0$ 0x7f53b0: next addr slab > 0 7f3700 21aa50 > 0x7f53bc: cache timestamp thread > 20b188 738886035200566511 &nb! sp; > 0x7f53cc: lastlog contents stackdepth > 1d8000 0 15 > libumem.so.1`umem_cache_alloc+0x208 > libumem.so.1`umem_alloc+0x44 > libumem.so.1`malloc+0x2c > libgcrypt.so.11`do_malloc+0x54 > &nbs! p; libgcrypt.so.11`_gcry_malloc+0x10 > libgcrypt.so.11`md_enable+0xfc > libgcrypt.so.11`md_open+0xfc > libgcrypt.so.11`_gcry_md_open+0x4c > libgnutls.so.26`wrap_gcry_hash_init+0x60 > libgnutls.so.26`_gnutls_hash_init+0x78 > libgnutls.so.26`gnutls_handshake+0xe8 > libUE.so`_ZN12SSLSETDriver9onRec! eiveEv+0x268 > libUE.so`_ZN12InTaskRunner3runEv+0x118 > libclassutil.so`_ZN7MThread7routineEv+0x28 > libclassutil.so`_ZN7MThread10thrRoutineEPv+0x1c > > All other leaks points also show the same clues: memory leaks happen during > the gnutls_handshake. > > For the report of MDB, total 21130336 bytes memory leaks are observed. I > have launched 167201 session in 3344 seconds. > > Anybody can give me some helps? If I am not using gnutls in the proper > way??? > > Regards > Tony > > ________________________________ > From: tang__tong at hotmail.com > To: help-gnutls at gnu.org > Date: Sat, 10 Oct 2009 08:21:05 +0000 > Subject: Memory leaks are observed for libgcrypt.so.11 in multi-thread mode > > Hi, > My program is a multi-thread server(pthread) working in Solaris enviorment, > For thread-safe consideration, according to the guide, I have defined the > following macro and call the specific function during iniatlization: > GCRY_THREAD_OPTION_PTHREAD_IMPL; > gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); > > Scenario1: > Launch Tls session one after another to guarantee there is no concurrency > existing between tls session, there is no memory leak reported by MDB; > > > Scenario2: > Launch TLS session concurrently, e.g., 50 TPS, memory leaks are reported by > MDB > >> ::findleaks > CACHE LEAKED BUFCTL CALLER > 00204a88 17 0053b860 libUE.so`_ZN12PacketHelper12createPacketEi+0x34 > 0020dc08 27 00aea708 libgcrypt.so.11`do_malloc+0x54 > 0020b188 88 012f0b40 libgcrypt.so.11`do_malloc+0x54 > 0020dc08&n! bsp; 100 013aa000 libgcrypt.so.11`do_malloc+0x54 > 0020ae08 64 00461e00 libgcrypt.so.11`do_malloc+0x54 > 0020b188 39 0073a780 libgcrypt.so.11`do_malloc+0x54 > 0020ae08 65 016cf248 libgcrypt.so.11`do_malloc+0x54 > 0020dc08 129 00aea7f8 libgcrypt.so.11`do_malloc+0x54 > ---------------------------------------------------------------------- > Total 529 buffers, 325752 bytes > > I have disabled the session reusage and deinit tls sessions structure with > gnutls_deinit(). > > Anybody can give me some tips on this issue? > > Regards > Tony > > > > > > > > > > > > ________________________________ > ????? Windows Live Messenger ???????? ????? > ________________________________ > ????? Windows Live Messenger ???????? ????? > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > > From kmagnum at gmail.com Tue Oct 13 20:50:11 2009 From: kmagnum at gmail.com (Karl Magdsick) Date: Tue, 13 Oct 2009 14:50:11 -0400 Subject: Multi-thread In-Reply-To: <4AD47D8B.8030108@gmail.com> References: <4ACC63B1.2070707@gmail.com> <4AD47D8B.8030108@gmail.com> Message-ID: 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 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: From kmagnum at gmail.com Tue Oct 13 21:05:45 2009 From: kmagnum at gmail.com (Karl Magdsick) Date: Tue, 13 Oct 2009 15:05:45 -0400 Subject: Multi-thread In-Reply-To: References: <4ACC63B1.2070707@gmail.com> <4AD47D8B.8030108@gmail.com> Message-ID: 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 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> 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: From cmouse at youzen.ext.b2.fi Wed Oct 14 08:22:45 2009 From: cmouse at youzen.ext.b2.fi (Aki Tuomi) Date: Wed, 14 Oct 2009 09:22:45 +0300 Subject: Multi-thread In-Reply-To: <4ACC63B1.2070707@gmail.com> References: <4ACC63B1.2070707@gmail.com> Message-ID: <20091014062245.GA29079@pi.ip.fi> On Wed, Oct 07, 2009 at 11:47:29AM +0200, Antoine Dumont 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 You do understand that mere fact of having "multiple threads" makes no difference. You'd need tasks to give to each thread. Just like having multiple cores in your CPU, you need *distinct* tasks to divide to these threads. Generating a keypair is not something that can be divided into distributable subtasks readily, thus making it very difficult to benefit from multithreading. Aki Tuomi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From antoine.dumont86 at gmail.com Wed Oct 14 09:39:37 2009 From: antoine.dumont86 at gmail.com (Antoine Dumont) Date: Wed, 14 Oct 2009 09:39:37 +0200 Subject: Multi-thread In-Reply-To: References: <4ACC63B1.2070707@gmail.com> <4AD47D8B.8030108@gmail.com> Message-ID: <4AD58039.7090202@gmail.com> 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 > 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 > > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From linux at paip.net Wed Oct 14 14:33:24 2009 From: linux at paip.net (Ian Goldberg) Date: Wed, 14 Oct 2009 08:33:24 -0400 Subject: Multi-thread In-Reply-To: References: <4ACC63B1.2070707@gmail.com> <4AD47D8B.8030108@gmail.com> Message-ID: <20091014123324.GA14061@thunk.cs.uwaterloo.ca> On Tue, Oct 13, 2009 at 02:50:11PM -0400, Karl Magdsick wrote: > 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. You're both right. N=256 is the value for 128-bit security, due to the sqrt(q) attacks such as Pollard's kangaroo method. That corresponds to 3072-bit p. But the original question was about 256-bit security, which indeed would require a 512-bit q and a p on the order of 10,000-15,000 bits. Note, however, that there's no good reason to want 256-bit security here. You can't be worried about large-scale quantum computing, since that would break DSA completely. If this is a signature key, the security only has to last for the validity time of the signature. (As opposed to an encryption key, whose security has to last for the length of time the data must remain secret.) No one believes 128-bit security is inadequate in the 3-5 year timeframe. (Many people believe 80-bit security is even adequate for that timeframe, but that's perhaps too close to the edge for some.) Also remember that you can technically reuse the public p and q values for a DSA key; the security is in the secrecy of the x value. So once you generate your 15000-bit prime p such that p-1 has a 512-bit prime factor q, you can just use that pair with different 512-bit values of x to create different keys. Note, however, that doing so is in violation of the FIPS, and indeed using p and q that large is itself in violation of the FIPS (as was pointed out by Karl). - Ian From tang__tong at hotmail.com Fri Oct 16 08:35:13 2009 From: tang__tong at hotmail.com (tangtong) Date: Fri, 16 Oct 2009 06:35:13 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Hi,Nikos and Simon To verify the issue, I have configured my server to run as signle thread mode. Under high TPS, the memory leak still happen in gnutls_handshake, which means the root-cause is not caused by multi-thread. By more logs and analysis, I have the following findings: Under high TPS, my server can't serve every session timely, which leads to the closure of the sockets by the clients for timeout reason. The write operation on the server side of the corresponding socket leads to broken pipe error. gnutls_handshake() reports GNUTLS_E_PUSH_ERROR, -53. As a result, the hand-shake stage of tls session is not finished successfully. After repeated testing, It is evident when aborted tls session caused by error -53 are observed, the memory leak happen. I have double check my codes, for these aborted session, I have called the gnutls_bye()/gnutls_deinit() function. My assumption now is for those session which has unfinished hand-shake stage, the resourses are not released properly in gnutls_handshake() for some reason. What's your opinion? Regards Tony > Date: Tue, 13 Oct 2009 16:56:42 +0300 > Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > From: nmav at gnutls.org > To: tang__tong at hotmail.com > CC: help-gnutls at gnu.org; gcrypt-devel at gnupg.org > > Hi, > thanks for the investigation. > From the following trace: > libgcrypt.so.11`md_enable+0xfc > libgcrypt.so.11`md_open+0xfc > > I suppose that this leak occurs in libgcrypt md_enable() in md.c. I > cannot figure out where exactly though. I CC the gcrypt-devel list for > more insight. > > best regards, > Nikos > > 2009/10/12 tangtong : > > I have redone my test and go through the memory leak points, I get the > > following info: > >> ::findleaks > > CACHE LEAKED BUFCTL CALLER > > 00204e08 1 004ab7e8 libclntsh.so.10.1`sigpnm+0x80 > > 0020b188 7816 007f53b0 libgcrypt.so.11`do_malloc+0x54 > > 0020ae08 106 0130e960 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08 1 00c0cd98 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08 63 008a5e78 libgcrypt.so.11`do_malloc+0x54 > > 0020ae08 8153 0043f518 libgcrypt.so.11`do_malloc+0x54 > > 0020b188 422 01046168 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08 8330 00b3d860 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08 8230 01206438 libgcrypt.so.11`do_malloc+0x54 > > ---------------------------------------------------------------------- > > To! tal 33122 buffers, 21130336 bytes > > > >> 007f53b0$ > 0x7f53b0: next addr slab > > 0 7f3700 21aa50 > > 0x7f53bc: cache timestamp thread > > 20b188 738886035200566511 &nb! sp; > > 0x7f53cc: lastlog contents stackdepth > > 1d8000 0 15 > > libumem.so.1`umem_cache_alloc+0x208 > > libumem.so.1`umem_alloc+0x44 > > libumem.so.1`malloc+0x2c > > libgcrypt.so.11`do_malloc+0x54 > > &nbs! p; libgcrypt.so.11`_gcry_malloc+0x10 > > libgcrypt.so.11`md_enable+0xfc > > libgcrypt.so.11`md_open+0xfc > > libgcrypt.so.11`_gcry_md_open+0x4c > > libgnutls.so.26`wrap_gcry_hash_init+0x60 > > libgnutls.so.26`_gnutls_hash_init+0x78 > > libgnutls.so.26`gnutls_handshake+0xe8 > > libUE.so`_ZN12SSLSETDriver9onRec! eiveEv+0x268 > > libUE.so`_ZN12InTaskRunner3runEv+0x118 > > libclassutil.so`_ZN7MThread7routineEv+0x28 > > libclassutil.so`_ZN7MThread10thrRoutineEPv+0x1c > > > > All other leaks points also show the same clues: memory leaks happen during > > the gnutls_handshake. > > > > For the report of MDB, total 21130336 bytes memory leaks are observed. I > > have launched 167201 session in 3344 seconds. > > > > Anybody can give me some helps? If I am not using gnutls in the proper > > way??? > > > > Regards > > Tony > > > > ________________________________ > > From: tang__tong at hotmail.com > > To: help-gnutls at gnu.org > > Date: Sat, 10 Oct 2009 08:21:05 +0000 > > Subject: Memory leaks are observed for libgcrypt.so.11 in multi-thread mode > > > > Hi, > > My program is a multi-thread server(pthread) working in Solaris enviorment, > > For thread-safe consideration, according to the guide, I have defined the > > following macro and call the specific function during iniatlization: > > GCRY_THREAD_OPTION_PTHREAD_IMPL; > > gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); > > > > Scenario1: > > Launch Tls session one after another to guarantee there is no concurrency > > existing between tls session, there is no memory leak reported by MDB; > > > > > > Scenario2: > > Launch TLS session concurrently, e.g., 50 TPS, memory leaks are reported by > > MDB > > > >> ::findleaks > > CACHE LEAKED BUFCTL CALLER > > 00204a88 17 0053b860 libUE.so`_ZN12PacketHelper12createPacketEi+0x34 > > 0020dc08 27 00aea708 libgcrypt.so.11`do_malloc+0x54 > > 0020b188 88 012f0b40 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08&n! bsp; 100 013aa000 libgcrypt.so.11`do_malloc+0x54 > > 0020ae08 64 00461e00 libgcrypt.so.11`do_malloc+0x54 > > 0020b188 39 0073a780 libgcrypt.so.11`do_malloc+0x54 > > 0020ae08 65 016cf248 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08 129 00aea7f8 libgcrypt.so.11`do_malloc+0x54 > > ---------------------------------------------------------------------- > > Total 529 buffers, 325752 bytes > > > > I have disabled the session reusage and deinit tls sessions structure with > > gnutls_deinit(). > > > > Anybody can give me some tips on this issue? > > > > Regards > > Tony > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > ????? Windows Live Messenger ???????? ????? > > ________________________________ > > ????? Windows Live Messenger ???????? ????? > > _______________________________________________ > > Help-gnutls mailing list > > Help-gnutls at gnu.org > > http://lists.gnu.org/mailman/listinfo/help-gnutls > > > > _________________________________________________________________ ?Windows Live ??????????Messenger? http://www.windowslive.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: From ametzler at downhill.at.eu.org Sun Oct 25 09:35:05 2009 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 25 Oct 2009 09:35:05 +0100 Subject: file handle exhaustion with openvpn and pam_ldap Message-ID: Hello, this is : When using openvpn and pam_ldap against an LDAP server with TLS support on every authentication, a file handle to /dev/urandom is created but never released. (libldap-2.4-2 is using gnutls, openvpn isn't.) ------------------------ Lars Ellenberg has debuged the issue, I am forwarding his comments: attached is a simple program to reproduce, and workaround the issue. libgcrypt standard behaviour is, at least on linux, to open /dev/urandom once, save that file descriptor in some static variable, and re-use it wherever appropriate. and never ever close that file descriptor, but on exit or fork. problem is: pam_start() via various indirections may dlopen()s libgcrypt, pam_stop() will dlclose() it again. which means the libgcrypt will be unloaded, and its static urandom fd with it. but there is no destructor to close the FD. on the next iteration, a new instance of libgcrypt will be loaded, with freshly initialized data segment, resulting in an additional open of urandom. that is the leak. Workaround: grab an additional reference on libgcrypt. these workarounds seem to have precedence, see the void nasty_pthread_hack (void) __attribute__ ((constructor)); void nasty_ssl_hack (void) __attribute__ ((constructor)); in libpam_ldap: pam_ldap.c This should only be done as a short term workaround, though. Real fix would be for libgcrypt to properly clean up on unload, i.e. to provide proper destructor functions. try.c is attached. example session: ~/src/try$ gcc -o try try.c -lpam -ldl -pthread ~/src/try$ strace -e open ./try 2>&1 | grep urandom open("/dev/urandom", O_RDONLY) = 4 open("/dev/urandom", O_RDONLY) = 6 open("/dev/urandom", O_RDONLY) = 7 ~/src/try$ gcc -DFIXIT -o try try.c -lpam -ldl -pthread ~/src/try$ strace -e open ./try 2>&1 | grep urandom open("/dev/urandom", O_RDONLY) = 4 ---------------------------------------------- #include #include #include #include #include #include #define USERNAME "dummy1" #define PASSWORD "dummy2" /* * PAM conversation function */ /* copied and shortened from openvpn source */ static int my_conv (int n, const struct pam_message **msg_array, struct pam_response **response_array, void *appdata_ptr) { struct pam_response *aresp; int i; int ret = PAM_SUCCESS; *response_array = NULL; if (n <= 0 || n > PAM_MAX_NUM_MSG) return (PAM_CONV_ERR); if ((aresp = calloc (n, sizeof *aresp)) == NULL) return (PAM_BUF_ERR); /* loop through each PAM-module query */ for (i = 0; i < n; ++i) { const struct pam_message *msg = msg_array[i]; aresp[i].resp_retcode = 0; aresp[i].resp = NULL; /* use PAM_PROMPT_ECHO_x hints */ switch (msg->msg_style) { case PAM_PROMPT_ECHO_OFF: aresp[i].resp = strdup (PASSWORD); if (aresp[i].resp == NULL) ret = PAM_CONV_ERR; break; case PAM_PROMPT_ECHO_ON: aresp[i].resp = strdup (USERNAME); if (aresp[i].resp == NULL) ret = PAM_CONV_ERR; break; case PAM_ERROR_MSG: case PAM_TEXT_INFO: break; default: ret = PAM_CONV_ERR; break; } } if (ret == PAM_SUCCESS) *response_array = aresp; return ret; } int main(int argc, char **argv) { #ifdef FIXIT void *dlh = dlopen("libgcrypt.so", RTLD_LAZY); #endif struct pam_conv conv = { .conv = my_conv, }; pam_handle_t *pamh; int i; for (i = 0; i < 3; i++) { pam_start("openvpn", USERNAME, &conv, &pamh); pam_authenticate(pamh, 0); pam_end(pamh, PAM_SUCCESS); } return 0; } ---------------------------------------------- cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From wk at gnupg.org Mon Oct 26 09:55:54 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Oct 2009 09:55:54 +0100 Subject: file handle exhaustion with openvpn and pam_ldap In-Reply-To: (Andreas Metzler's message of "Sun, 25 Oct 2009 09:35:05 +0100") References: Message-ID: <87y6my1qlh.fsf@vigenere.g10code.de> On Sun, 25 Oct 2009 09:35, ametzler at downhill.at.eu.org said: > When using openvpn and pam_ldap against an LDAP server with TLS > support on every authentication, a file handle to /dev/urandom is > created but never released. (libldap-2.4-2 is using gnutls, openvpn > isn't.) The problem is that you can't load/unload/load libgcrypt using dlopen tricks. This is simply not defined unless dlopen/dlclose implements a complete process initialization/termination. True, there is a function to terminate the secure memory which needs to be called before the process terminates but this is not a complete shutdown of libgcrypt, the OS needs to cleanup some of the resources. The documentation os FIPS required state machine says: [The state transition from] Operational to Shutdown is an artifical state without any direct action in Libgcrypt. When reaching the Shutdown state the library is deinitialized and can't return to any other state again. Thus to change this you would need to implement the required OS parts in your dlopen/dlclose. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From ametzler at downhill.at.eu.org Mon Oct 26 13:17:57 2009 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 26 Oct 2009 13:17:57 +0100 Subject: file handle exhaustion with openvpn and pam_ldap In-Reply-To: <87y6my1qlh.fsf@vigenere.g10code.de> References: <87y6my1qlh.fsf@vigenere.g10code.de> Message-ID: <20091026121757.GE3347@downhill.g.la> On 2009-10-26 Werner Koch wrote: > On Sun, 25 Oct 2009 09:35, ametzler at downhill.at.eu.org said: > > When using openvpn and pam_ldap against an LDAP server with TLS > > support on every authentication, a file handle to /dev/urandom is > > created but never released. (libldap-2.4-2 is using gnutls, openvpn > > isn't.) > The problem is that you can't load/unload/load libgcrypt using dlopen > tricks. This is simply not defined unless dlopen/dlclose implements a > complete process initialization/termination. True, there is a function > to terminate the secure memory which needs to be called before the > process terminates but this is not a complete shutdown of libgcrypt, the > OS needs to cleanup some of the resources. > The documentation os FIPS required state machine says: > [The state transition from] Operational to Shutdown is an artifical > state without any direct action in Libgcrypt. When reaching the > Shutdown state the library is deinitialized and can't return to any > other state again. > Thus to change this you would need to implement the required OS parts in > your dlopen/dlclose. Hello, just to clarify. - You are saying that: * This issue cannot be fixed in gcrypt itself (and therefore will not be fixed). * The way dlopen works on $OS would need to be changed (I guess on Linux this would be glibc.) thanks, cu andreas From wk at gnupg.org Mon Oct 26 19:58:06 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Oct 2009 19:58:06 +0100 Subject: file handle exhaustion with openvpn and pam_ldap In-Reply-To: <20091026121757.GE3347@downhill.g.la> (Andreas Metzler's message of "Mon, 26 Oct 2009 13:17:57 +0100") References: <87y6my1qlh.fsf@vigenere.g10code.de> <20091026121757.GE3347@downhill.g.la> Message-ID: <87eioq0ypt.fsf@vigenere.g10code.de> On Mon, 26 Oct 2009 13:17, ametzler at downhill.at.eu.org said: > * This issue cannot be fixed in gcrypt itself (and therefore will not > be fixed). Well, this is fix not that easy. The open file descriptor is just one sign thatthe process has not really be terminated. Sure, it is possible to do that but it is quite some work for a rare use case. > * The way dlopen works on $OS would need to be changed (I guess on > Linux this would be glibc.) Frankly, I doubt that this will be possible on Unix. A process is a fundamental resource and tweaking it to behave similar to an independant process but not really is a bit weird. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Mon Oct 26 23:14:53 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 26 Oct 2009 18:14:53 -0400 Subject: gcrypt initialization Message-ID: <4AE61F5D.8070802@fifthhorseman.net> hey gcrypt folks-- I'm trying to understand the various phases of gcrypt initialization. I've read the docs, but in some places they appear to be self-contradictory about what calls are specifically allowed when. As i understand it, the required order is: A) gcry_control(GCRYCTL_SET_THREAD_CBS or GCRYCTL_FORCE_FIPS_MODE) B) gcry_check_version() C) gcry_control(,...) D) gcry_control(GCRYCTL_INITIALIZATION_FINISHED) E) When a gcry_control command says that it can "only be used during initialization time" (e.g. GCRYCTL_ENABLE_M_GUARD), i believe that means that it must be invoked during phase C, but other gcry_control invocations can be invoked at any time (including after the library has actually been used). Is this correct? What am i missing? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From ametzler at downhill.at.eu.org Tue Oct 27 20:10:53 2009 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Tue, 27 Oct 2009 20:10:53 +0100 Subject: file handle exhaustion with openvpn and pam_ldap In-Reply-To: <87eioq0ypt.fsf@vigenere.g10code.de> References: <87y6my1qlh.fsf@vigenere.g10code.de> <20091026121757.GE3347@downhill.g.la> <87eioq0ypt.fsf@vigenere.g10code.de> Message-ID: <20091027191053.GA3375@downhill.g.la> On 2009-10-26 Werner Koch wrote: > On Mon, 26 Oct 2009 13:17, ametzler at downhill.at.eu.org said: > > * This issue cannot be fixed in gcrypt itself (and therefore will not > > be fixed). > Well, this is fix not that easy. The open file descriptor is just one > sign thatthe process has not really be terminated. Sure, it is possible > to do that but it is quite some work for a rare use case. > > * The way dlopen works on $OS would need to be changed (I guess on > > Linux this would be glibc.) > Frankly, I doubt that this will be possible on Unix. A process is a > fundamental resource and tweaking it to behave similar to an independant > process but not really is a bit weird. Hello, thanks for the clarification. So it is basically the other way round than I understood it. The issue *might* be fixed in libgcrypt, but is hard. "but it is quite some work for a rare use case" It possibly breaks every pam or nsswitch modules that uses GnuTLS. In Debian this includes some of the popular ones (e.g. samba, ldap postgresql). I do not claim that pam/nss is a brilliant design especially due to dlopen problems like this one but it is not that unpopular. cu andreas From dkg at fifthhorseman.net Tue Oct 27 23:50:33 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Oct 2009 18:50:33 -0400 Subject: segfault in GCRYCTL_SET_THREAD_CBS Message-ID: <4AE77939.3040100@fifthhorseman.net> The attached simple program tries to initialize gcrypt with pthread support. On my debian system (testing/unstable, libgcrypt11 1.4.4-4) this triggers a segfault during the call to gcry_control(GCRYCTL_SET_THREAD_CBS). What am i doing wrong? What have i missed? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: main.c Type: text/x-csrc Size: 621 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Makefile URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Oct 28 14:35:12 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Oct 2009 14:35:12 +0100 Subject: gcrypt initialization In-Reply-To: <4AE61F5D.8070802@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 26 Oct 2009 18:14:53 -0400") References: <4AE61F5D.8070802@fifthhorseman.net> Message-ID: <87ocnrzlnz.fsf@vigenere.g10code.de> On Mon, 26 Oct 2009 23:14, dkg at fifthhorseman.net said: > A) gcry_control(GCRYCTL_SET_THREAD_CBS or GCRYCTL_FORCE_FIPS_MODE) The first is merely a handmade constructor and as such pretty special. The second is: @item GCRYCTL_FORCE_FIPS_MODE; Arguments: none Running this command puts the library into FIPS mode. If the library is already in FIPS mode, a self-test is triggered and thus the library will be put into operational state. This command may be used before a call to gcry_check_version and that is actually the recommended way to let an [...] and states that it may be used before gcry_check_version (between A and B) to force gcrypt into fips mode. > When a gcry_control command says that it can "only be used during > initialization time" (e.g. GCRYCTL_ENABLE_M_GUARD), i believe that Okay, the docs are not clear. I changed it to say "before gcry_check_version". Let me know if you find other unclear documentation. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 28 14:54:03 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Oct 2009 14:54:03 +0100 Subject: segfault in GCRYCTL_SET_THREAD_CBS In-Reply-To: <4AE77939.3040100@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 27 Oct 2009 18:50:33 -0400") References: <4AE77939.3040100@fifthhorseman.net> Message-ID: <87k4yfzksk.fsf@vigenere.g10code.de> On Tue, 27 Oct 2009 23:50, dkg at fifthhorseman.net said: - ret = gcry_control(GCRYCTL_SET_THREAD_CBS, gcry_threads_pthread); + ret = gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); This is the usual problem with general purpose ioctl-alike fucntions: You don't have any type checking. I added examples to the docs. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Oct 28 15:59:35 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Oct 2009 10:59:35 -0400 Subject: gcrypt initialization In-Reply-To: <87ocnrzlnz.fsf@vigenere.g10code.de> References: <4AE61F5D.8070802@fifthhorseman.net> <87ocnrzlnz.fsf@vigenere.g10code.de> Message-ID: <4AE85C57.1050805@fifthhorseman.net> On 10/28/2009 09:35 AM, Werner Koch wrote: > Okay, the docs are not clear. I changed it to say "before > gcry_check_version". Thanks, Werner. > Let me know if you find other unclear documentation. line 523 of gcrypt.texi appears to claim that the full set of functionality allowed before gcry_check_version is GCRYCTL_SET_THREAD_CBS. Maybe it should mention GCRYCTL_FORCE_FIPS_MODE and GCRYCTL_ENABLE_M_GUARD and GCRYCTL_ANY_INITIALIZATION_P (and others?) Alternately, if there really are valid phases of initialization, maybe it'd be useful to define them (with more semantically-meaningful names than my earlier "A,B,C"), and indicate which commands belong to which phase? Another thing that might be useful to document is what the relationship is between the other gcry_control() calls and GCRYCTL_INITIALIZATION_FINISHED -- at the moment, it's unclear what the consequences of GCRYCTL_INITIALIZATION_FINISHED are, other than GCRYCTL_INITIALIZATION_FINISHED_P returning a different value, and the library appears to work without that call. So why should a user bother to issue GCRYCTL_INITIALIZATION_FINISHED? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Oct 28 16:04:51 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Oct 2009 11:04:51 -0400 Subject: segfault in GCRYCTL_SET_THREAD_CBS In-Reply-To: <87k4yfzksk.fsf@vigenere.g10code.de> References: <4AE77939.3040100@fifthhorseman.net> <87k4yfzksk.fsf@vigenere.g10code.de> Message-ID: <4AE85D93.5090805@fifthhorseman.net> On 10/28/2009 09:54 AM, Werner Koch wrote: > On Tue, 27 Oct 2009 23:50, dkg at fifthhorseman.net said: > > - ret = gcry_control(GCRYCTL_SET_THREAD_CBS, gcry_threads_pthread); > + ret = gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); > > This is the usual problem with general purpose ioctl-alike fucntions: > You don't have any type checking. I added examples to the docs. Thanks, Werner. That does fix it for me, and it seems obvious in retrospect ;) I suspect having the examples in the docs will be useful. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Oct 28 22:21:50 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Oct 2009 17:21:50 -0400 Subject: another gcrypt documentation suggestion: gcry_free results of gcry_random_bytes Message-ID: <4AE8B5EE.2070707@fifthhorseman.net> hey folks-- i think section 8.2 of the gcrypt documentation ("Retrieving Random Numbers") should indicate that the buffers returned by gcry_random_bytes and gcry_random_bytes_secure should be released with gcry_free when they are no longer needed. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Oct 28 22:30:18 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Oct 2009 17:30:18 -0400 Subject: testing gcrypt thread-safety Message-ID: <4AE8B7EA.50603@fifthhorseman.net> now that i can properly initialize gcrypt in a threaded fashion (thanks, Werner!), i'm curious what commands might be particularly vulnerable to uninitialized threadsafety features. For example, it appears the registering new ciphers, digests, or asymmetric algorithms use mutex-based locking, as does secmem and fips-mode. Is there other functionality that might be vulnerable? I don't see any code in the tests/ directory which exercises this stuff, but i'd be willing to write a test if anyone has a particular feature that they think would be worth testing against threadsafe initialization. i'm aware that threadsafety issues are difficult to make reliably 100% reproducible test cases for, but i figure if we make simple test case, even a 1% failure rate (assuming folks who build the tool actually run the test suite and report their errors) would be worth having. Suggestions for what to test? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: