From funman at videolan.org Thu Nov 2 21:17:00 2006 From: funman at videolan.org (=?UTF-8?B?UmFmYcOrbCBDYXJyw6k=?=) Date: Thu Nov 2 23:14:33 2006 Subject: [PATCH] fix a typo when building libgcrypt and gnupg 1.4 with mingw-runtime 3.10 Message-ID: <20061102211700.0933ba9b@zod> Hello, Since version 3.10, mingw-runtime now includes gettimeofday() defined in as specified by POSIX: http://www.opengroup.org/onlinepubs/009695399/functions/gettimeofday.html People using this version to compile are experiencing problems with a piece of code which is common to gnupg 1.4 and libcrypt 1.2.3 : cipher/random.c http://lists.gnupg.org/pipermail/gnupg-devel/2006-June/022975.html Here is that code: #ifdef HAVE_GETTIMEOFDAY #include #endif What will happen on UNIX systems: they all have gettimeofday(), and they all have sys/times.h so it's ok What will happen on WINDOWS systems: they don't have gettimeofday() , so it's ok too What will happen on WINDOWS systems using mingw compiler and mingw-runtime 3.10 : they have gettimeofday(), but they don't have so the build will fail To my knowledge, there is no system that defines gettimeofday() in , only in Please replace by because this is an annoying typo. Thanks. -- Rafa?l Carr? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061102/3223c3aa/signature.pgp From wk at gnupg.org Fri Nov 3 11:24:42 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Nov 3 11:26:52 2006 Subject: [PATCH] fix a typo when building libgcrypt and gnupg 1.4 with mingw-runtime 3.10 In-Reply-To: <20061102211700.0933ba9b@zod> (=?utf-8?Q?Rafa=C3=ABl_Carr?= =?utf-8?Q?=C3=A9's?= message of "Thu\, 2 Nov 2006 21\:17\:00 +0100") References: <20061102211700.0933ba9b@zod> Message-ID: <87ac38omj9.fsf@wheatstone.g10code.de> On Thu, 2 Nov 2006 21:17, Rafa?l Carr? said: > Please replace by because this is an > annoying typo. Done in my working copy of gnupg 1.4 and libgcrypt trunk. Thanks, Werner From tim.kosse at filezilla-project.org Fri Nov 3 14:35:12 2006 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Fri Nov 3 16:26:33 2006 Subject: libgcrypt painfully slow under Windows Message-ID: <454B4590.6020909@filezilla-project.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm using GnuTLS under Windows and initializing GnuTLS takes over 10 seconds on my system. After some investigation, I found out that calling libgcrypt's gcry_randomize causes the delay. My system is an IBM Thinkpad R52, 2GHz Pentium M, 1 GB RAM running a fully patched Windows XP SP 2. Further investigation revealed that the delay is caused inside _gcry_rndw32_gather_random in cipher/rndw32.c One of the things libgcrypt does, is to query HKEY_PERFORMANCE_DATA. That alone takes 3-4 seconds, returning around 140KB of performance data. Furthermore, libgcrypt walks the local heap. With a minimal program, this already takes over 1 second. In a more complex program, it will take a lot of time. Currently _gcry_rndw32_gather_random takes a little over 10 seconds with my program, which is still far from finished. The amount of time seems to be only bounded by the amount of heap memory which can be allocated. The other methods used to gather entropy are almost instant however. On http://www.securitypunk.com/libgcrypt/ I found a patch from J. Salvatore Testa which enables libgcrypt to use the Crypto API of Windows, in particular the CryptGenRandom function. I've modified the patch to also work if libgcrypt gets linked statically and allowed a fallback to the previous, slow methods if the Crypto API cannot be initialized or CryptGenRandom fails. (patch: http://filezilla-project.org/codesquid/rndw32.c.patch) Using this patch, there is no longer any noticeable delay. Would it be possible to officially apply it to libgcrypt in some way? As in its current state, libgcrypt and the libraries/programs using it are barely usable due to the delays under Windows. Regards, Tim Kosse -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFS0WQ8N9+lcqiUkURArqiAKDD8tgsD2BEpiDGYhgu1J4b/CSITgCfVE4E Bm6BmAZbMWFWnHzcfdQah/w= =uDqh -----END PGP SIGNATURE----- From tim.kosse at filezilla-project.org Fri Nov 3 14:36:22 2006 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Fri Nov 3 16:41:15 2006 Subject: libgcrypt painfully slow under Windows Message-ID: <454B45D6.8090004@filezilla-project.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm using GnuTLS under Windows and initializing GnuTLS takes over 10 seconds on my system. After some investigation, I found out that calling libgcrypt's gcry_randomize causes the delay. My system is an IBM Thinkpad R52, 2GHz Pentium M, 1 GB RAM running a fully patched Windows XP SP 2. Further investigation revealed that the delay is caused inside _gcry_rndw32_gather_random in cipher/rndw32.c One of the things libgcrypt does, is to query HKEY_PERFORMANCE_DATA. That alone takes 3-4 seconds, returning around 140KB of performance data. Furthermore, libgcrypt walks the local heap. With a minimal program, this already takes over 1 second. In a more complex program, it will take a lot of time. Currently _gcry_rndw32_gather_random takes a little over 10 seconds with my program, which is still far from finished. The amount of time seems to be only bounded by the amount of heap memory which can be allocated. The other methods used to gather entropy are almost instant however. On http://www.securitypunk.com/libgcrypt/ I found a patch from J. Salvatore Testa which enables libgcrypt to use the Crypto API of Windows, in particular the CryptGenRandom function. I've modified the patch to also work if libgcrypt gets linked statically and allowed a fallback to the previous, slow methods if the Crypto API cannot be initialized or CryptGenRandom fails. (patch: http://filezilla-project.org/codesquid/rndw32.c.patch) Using this patch, there is no longer any noticeable delay. Would it be possible to officially apply it to libgcrypt in some way? As in its current state, libgcrypt and the libraries/programs using it are barely usable due to the delays under Windows. Regards, Tim Kosse -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFS0WQ8N9+lcqiUkURArqiAKDD8tgsD2BEpiDGYhgu1J4b/CSITgCfVE4E Bm6BmAZbMWFWnHzcfdQah/w= =uDqh -----END PGP SIGNATURE----- From wk at gnupg.org Fri Nov 3 18:36:22 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Nov 3 18:41:57 2006 Subject: libgcrypt painfully slow under Windows In-Reply-To: <454B4590.6020909@filezilla-project.org> (Tim Kosse's message of "Fri\, 03 Nov 2006 14\:35\:12 +0100") References: <454B4590.6020909@filezilla-project.org> Message-ID: <87hcxgiga1.fsf@wheatstone.g10code.de> On Fri, 3 Nov 2006 14:35, Tim Kosse said: > I'm using GnuTLS under Windows and initializing GnuTLS takes over 10 > seconds on my system. After some investigation, I found out that calling > libgcrypt's gcry_randomize causes the delay. See my posting on gnutls-devel Salam-Shalom, Werner From tim.kosse at filezilla-project.org Thu Nov 9 17:12:51 2006 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Thu Nov 9 17:11:43 2006 Subject: Compiling libgcrypt under OS X as universal binary Message-ID: <45535383.3060703@filezilla-project.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In did compile libgcrypt (SVN trunk) under OSX (arch: i386) as univeral binary (both i386 as well as ppc), by configuring it with this command: CFLAGS="-arch i386 -arch ppc" ./configure --disable-shared - --enable-static --disable-dependency-tracking --disable-nls --disable-asm However, compilation failed with error messages similar to this: "ar: somefile.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)" I noticed, that libgcrypt comes a long with very old libtool files. I had to replace the provided ltmain.sh, config.sub and config.guess files with the ones from libtool 1.5.22, which adds support for fat binaries. Would it be possible to update these files in the next libgcrypt version? Furthermore, I had to modify config.h, I had to add these lines: #if defined (__ppc__) || defined(__ppc64__) #define WORDS_BIGENDIAN 1 #endif Basically, if creating fat binaries, all files get compiled twice automatically, once for i386, once for ppc. Last but not least, I had to disable src/gcryptrnd.c, it failed due to missing pth.h. Regards, Tim Kosse -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFU1OC8N9+lcqiUkURAmoyAKDBOqZyJcNqEQmILxodRQuN8fLybQCgtwUR H3e21HMRDdsImolPGOzDcHo= =PHTR -----END PGP SIGNATURE----- From wk at gnupg.org Sun Nov 12 14:22:24 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Nov 12 23:42:02 2006 Subject: Compiling libgcrypt under OS X as universal binary In-Reply-To: <45535383.3060703@filezilla-project.org> (Tim Kosse's message of "Thu\, 09 Nov 2006 17\:12\:51 +0100") References: <45535383.3060703@filezilla-project.org> Message-ID: <87mz6whka7.fsf@wheatstone.g10code.de> On Thu, 9 Nov 2006 17:12, tim.kosse@filezilla-project.org said: > I noticed, that libgcrypt comes a long with very old libtool files. I > Would it be possible to update these files in the next libgcrypt version? We won't do this for libgcrypt 1.2. However libtool will be updated with the release of 1.3. > Furthermore, I had to modify config.h, I had to add these lines: > #if defined (__ppc__) || defined(__ppc64__) > #define WORDS_BIGENDIAN 1 > #endif Updating autoconf should fix this. Will also be done with the next/first release of 1.3. > Last but not least, I had to disable src/gcryptrnd.c, it failed due to > missing pth.h. This is all under development. Thanks, Werner From spizamme at hotmail.com Thu Nov 30 07:33:21 2006 From: spizamme at hotmail.com (jitspoe) Date: Thu Nov 30 10:45:32 2006 Subject: RSA Key Gen: Fast in Test App, Slow in Real App. In-Reply-To: <8764ezf7oo.fsf@wheatstone.g10code.de> References: <6380989.post@talk.nabble.com> <200610021020.54067.bradh@frogmouth.net> <6651937.post@talk.nabble.com> <8764ezf7oo.fsf@wheatstone.g10code.de> Message-ID: <7614339.post@talk.nabble.com> You were correct about it being the RNG. I found that simply calling gcry_randomize() paused for several seconds. The slow_gatherer_windowsNT() function seems to be the culprit. More specifically, the RegQueryValueEx(HKEY_PERFORMANCE_DATA, "Global", NULL, NULL, (LPBYTE) pPerfData, &dwSize); call. I guess the console app didn't use this for whatever reason? Any suggestions on how I would improve this performance? Looking through the code, the only way I see to do it would be to create a seed file. -- View this message in context: http://www.nabble.com/RSA-Key-Gen%3A-Fast-in-Test-App%2C-Slow-in-Real-App.-tf2296684.html#a7614339 Sent from the GnuPG - Libgcrypt - Dev mailing list archive at Nabble.com.