From wk at gnupg.org Wed Sep 1 06:51:04 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Sep 2010 06:51:04 +0200 Subject: Mutex causing memory leaks In-Reply-To: <4C71FFAE.2030307@fastmail.us> (Steven Hudson's message of "Sun, 22 Aug 2010 21:57:18 -0700") References: <4C71FFAE.2030307@fastmail.us> Message-ID: <87bp8it6br.fsf@gnupg.org> On Mon, 23 Aug 2010 06:57, randomproof at fastmail.us said: > I've setup the mutex functions for thread saftey using > gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); but it > seams the mutex_destroy function is never called. It there a function I > need to call when the program is closing? Mutexes should be destroyed when a process terminates. It is the OSs task. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From randomproof at fastmail.us Wed Sep 1 17:26:17 2010 From: randomproof at fastmail.us (Steven Hudson) Date: Wed, 01 Sep 2010 08:26:17 -0700 Subject: Mutex causing memory leaks In-Reply-To: <87bp8it6br.fsf@gnupg.org> References: <4C71FFAE.2030307@fastmail.us> <87bp8it6br.fsf@gnupg.org> Message-ID: <4C7E7099.6040906@fastmail.us> The main problem I see is that in the macros for GCRY_THREAD_OPTION_PTH_IMPL and GCRY_THREAD_OPTION_PTHREAD_IMPL malloc() is being called in gcry_pthread_mutex_init() but free() is not being called because gcry_pthread_mutex_destroy() is not called. -- Steven Hudson randomproof at fastmail.us On 08/31/2010 09:51 PM, Werner Koch wrote: > On Mon, 23 Aug 2010 06:57, randomproof at fastmail.us said: >> I've setup the mutex functions for thread saftey using >> gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); but it >> seams the mutex_destroy function is never called. It there a function I >> need to call when the program is closing? > > Mutexes should be destroyed when a process terminates. It is the OSs > task. > > > Salam-Shalom, > > Werner > From mabrand at mabrand.nl Wed Sep 1 22:55:36 2010 From: mabrand at mabrand.nl (Mark Brand) Date: Wed, 01 Sep 2010 22:55:36 +0200 Subject: runtime problem with static libgpg-error 1.9 on MinGW Message-ID: <4C7EBDC8.9060507@mabrand.nl> Hi, I have been working on updating from libgpg-error-1.8 to libgpg-error-1.9 in mingw-cross-env. Mingw-cross-env is a cross building environment for MinGW. One of its features is that it builds static versions of all its libraries. With 1.9 I have a runtime problem with applications linked to static libgpg-error-1.9. Compiling and linking go fine, but at runtime in Windows, the program immediately crashes. Under Wine, the program immediately gets stuck, producing this message: err:ntdll:RtlpWaitForCriticalSection section 0x473374 "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec). I'm pretty sure this happens before main(). The problem can be reproduced with tests/basic.c from libgcrypt-1.4.6. As far as I can tell, it does not make it to main(), suggesting an init problem. This thread might be related: http://marc.info/?l=gcrypt-devel&m=127679204515086&w=2 I would be grateful for some insights into this problem or hints about how to do further troubleshooting. (Apologies for cross-posting. I originally asked about this on gnupg-users, but it looks like it belongs on this forum.) regards, Mark From wk at gnupg.org Thu Sep 2 16:21:38 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Sep 2010 16:21:38 +0200 Subject: Mutex causing memory leaks In-Reply-To: <4C7E7099.6040906@fastmail.us> (Steven Hudson's message of "Wed, 01 Sep 2010 08:26:17 -0700") References: <4C71FFAE.2030307@fastmail.us> <87bp8it6br.fsf@gnupg.org> <4C7E7099.6040906@fastmail.us> Message-ID: <87wrr4i5u5.fsf@gnupg.org> On Wed, 1 Sep 2010 17:26, randomproof at fastmail.us said: > The main problem I see is that in the macros for > GCRY_THREAD_OPTION_PTH_IMPL and GCRY_THREAD_OPTION_PTHREAD_IMPL malloc() > is being called in gcry_pthread_mutex_init() but free() is not being > called because gcry_pthread_mutex_destroy() is not called. Well, the heap is part of the process and thus destroyed at the process termination. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Sep 16 20:42:57 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Sep 2010 20:42:57 +0200 Subject: runtime problem with static libgpg-error 1.9 on MinGW In-Reply-To: <4C7EBDC8.9060507@mabrand.nl> (Mark Brand's message of "Wed, 01 Sep 2010 22:55:36 +0200") References: <4C7EBDC8.9060507@mabrand.nl> Message-ID: <87pqwdedhq.fsf@vigenere.g10code.de> On Wed, 1 Sep 2010 22:55, mabrand at mabrand.nl said: > > With 1.9 I have a runtime problem with applications linked to static > libgpg-error-1.9. Compiling and linking go fine, but at runtime in > Windows, the program immediately crashes. Under Wine, the program I just fixed that bug in libgpg-error. The problem was that for a static lib we can't rely on the gcc constructors and thus a CS object was not initialized. SVN revision 250 has the fix. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mabrand at mabrand.nl Thu Sep 16 21:56:48 2010 From: mabrand at mabrand.nl (Mark Brand) Date: Thu, 16 Sep 2010 21:56:48 +0200 Subject: runtime problem with static libgpg-error 1.9 on MinGW In-Reply-To: <87pqwdedhq.fsf@vigenere.g10code.de> References: <4C7EBDC8.9060507@mabrand.nl> <87pqwdedhq.fsf@vigenere.g10code.de> Message-ID: <4C927680.3060008@mabrand.nl> >> With 1.9 I have a runtime problem with applications linked to static >> libgpg-error-1.9. Compiling and linking go fine, but at runtime in >> Windows, the program immediately crashes. Under Wine, the program > I just fixed that bug in libgpg-error. The problem was that for a > static lib we can't rely on the gcc constructors and thus a CS object > was not initialized. SVN revision 250 has the fix. Thanks. That solves the problem. Linked programs start and run normally again under Wine and Windows. Mark From wk at gnupg.org Sun Sep 19 19:06:49 2010 From: wk at gnupg.org (Werner Koch) Date: Sun, 19 Sep 2010 19:06:49 +0200 Subject: GnuPG has now full ECC support (ECDSA, ECDH) In-Reply-To: <4C95BC2C.3090709@brainhub.org> (Andrey Jivsov's message of "Sun, 19 Sep 2010 00:30:52 -0700") References: <4C95BC2C.3090709@brainhub.org> Message-ID: <87zkvdu0gm.fsf@vigenere.g10code.de> On Sun, 19 Sep 2010 09:30, openpgp at brainhub.org said: > I am happy to announce that GnuPG now fully implements ECC encryption > and signing capability. A user can generate an ECC key with gpg2 > --gen-key and use it to encrypt or sign messages or keys. 256, 384, > and 521 bit ECC keys are supported. Cool. I noticed that the documentation is really good. I'll look into the changes the next days. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sacrificial-spam-address at horizon.com Thu Sep 30 09:38:37 2010 From: sacrificial-spam-address at horizon.com (sacrificial-spam-address at horizon.com) Date: 30 Sep 2010 03:38:37 -0400 Subject: Bug#475168: certtool --generate-dh-params is ridiculously wasteful of entropy Message-ID: <20100930073837.12561.qmail@science.horizon.com> I just thought I'd forward mention of Debian bug #475168, available at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475168 Briefly, running strace -eread -s12 certtool --generate-dh-params --bits 384 (certtool (GnuTLS 2.8.6) 2.9.9, using libgcrypt11 1.4.5-2) shows 25 120-bytes reads from /dev/urandom, totalling 3000 bytes (14400 bits) for seed material. This is grotesquely excessive and unnecessarily drains the entropy pool for other users. To quote the Linux /dev/random man page: The amount of seed material required to generate a cryptographic key equals the effective key size of the key. For example, a 3072-bit RSA or Diffie-Hellman private key has an effective key size of 128 bits (it requires about 2^128 operations to break) so a key generator only needs 128 bits (16 bytes) of seed material from /dev/random. While some safety margin above that minimum is reasonable, as a guard against flaws in the CPRNG algorithm, no cryptographic primitive available today can hope to promise more than 256 bits of security, so if any program reads more than 256 bits (32 bytes) from the kernel random pool per invocation, or per reasonable reseed interval (not less than one minute), that should be taken as a sign that its cryptography is not skilfully implemented. That's perhaps an oversimplification (I think the Blum-Blum-Shub generator can do a bit better, assuming factoring is hard), but the point is still true: using stupid amounts of seed material makes the implementation look stupid. Indeed, for D-H *parameter* generation, the seed doesn't have to be secure at all, although I can see the advantage in using a common PRNG. Is it possible to make the implementation less stupid? Thank you!