From jonas.schnelli at include7.ch Wed Sep 2 11:56:24 2009 From: jonas.schnelli at include7.ch (Jonas Schnelli) Date: Wed, 2 Sep 2009 11:56:24 +0200 Subject: Compile i386 / x86_64 on Mac 10.6 Message-ID: <542C35BC-B995-4989-8A9D-E12811991B3E@include7.ch> Hi i did try to compile gnupg for mac 10.6 as fat binary i386 / x86_64. I've getting a error while compiling multpile archs: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../intl -arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp -Wall -Wno-pointer-sign -MT logger.o -MD -MP -MF .deps/logger.Tpo -c -o logger.o logger.c gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags make[2]: *** [logger.o] Error 1 is there a chance to build a multiple archs? anyone tried this? thanks -- jonas ?????????????????????????????????????????? include7 Jonas Schnelli Staffelstrasse 8 CH-8045 Z?rich Switzerland Office: +41 44 500 16 70 Skype: jonas.schnelli Mail: jonas.schnelli at include7.ch PGP Public Key: www.include7.ch/jspk.txt Web: www.include7.ch ?????????????????????????????????????????? From jonas.schnelli at include7.ch Wed Sep 2 14:07:56 2009 From: jonas.schnelli at include7.ch (Jonas Schnelli) Date: Wed, 2 Sep 2009 14:07:56 +0200 Subject: Compile i386 / x86_64 on Mac 10.6 In-Reply-To: <732076a80909020459x702d4556oc8874137d521e1e5@mail.gmail.com> References: <542C35BC-B995-4989-8A9D-E12811991B3E@include7.ch> <732076a80909020459x702d4556oc8874137d521e1e5@mail.gmail.com> Message-ID: > 2009/9/2 Jonas Schnelli : >> is there a chance to build a multiple archs? >> anyone tried this? > > Which version are you compiling? I can send you full instructions but > you may just be better off downloading a precompiled version from > either http://macgpg.sourceforge.net or http://macgpg2.sourceforge.net > I try to compile the 1.4.9 for Mac OS 10.6 32/64 bit fat. So theres no precompiled version for that. The reason while im doing this is because GPGMail (GPG Extension for Mac builtin Mail App) is running now in 64bit mode. So all dependencies must also run 64bit. Because Mac Mail runs in 32/64 fat mode, i would also like to build gpg in 32/64 mode. if there is any who did manage to build 32/64 bit fat, i could use some help. if not, i will try to release a 32 and a 64 bit version. > Ben ?????????????????????????????????????????? include7 Jonas Schnelli Staffelstrasse 8 CH-8045 Z?rich Switzerland Office: +41 44 500 16 70 Skype: jonas.schnelli Mail: jonas.schnelli at include7.ch PGP Public Key: www.include7.ch/jspk.txt Web: www.include7.ch ?????????????????????????????????????????? From benjamin at py-soft.co.uk Wed Sep 2 13:59:46 2009 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 2 Sep 2009 12:59:46 +0100 Subject: Compile i386 / x86_64 on Mac 10.6 In-Reply-To: <542C35BC-B995-4989-8A9D-E12811991B3E@include7.ch> References: <542C35BC-B995-4989-8A9D-E12811991B3E@include7.ch> Message-ID: <732076a80909020459x702d4556oc8874137d521e1e5@mail.gmail.com> 2009/9/2 Jonas Schnelli : > is there a chance to build a multiple archs? > anyone tried this? Which version are you compiling? I can send you full instructions but you may just be better off downloading a precompiled version from either http://macgpg.sourceforge.net or http://macgpg2.sourceforge.net Ben From dshaw at jabberwocky.com Wed Sep 2 16:49:55 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 2 Sep 2009 10:49:55 -0400 Subject: Compile i386 / x86_64 on Mac 10.6 In-Reply-To: <542C35BC-B995-4989-8A9D-E12811991B3E@include7.ch> References: <542C35BC-B995-4989-8A9D-E12811991B3E@include7.ch> Message-ID: On Sep 2, 2009, at 5:56 AM, Jonas Schnelli wrote: > Hi > > i did try to compile gnupg for mac 10.6 as fat binary i386 / x86_64. > I've getting a error while compiling multpile archs: > > gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../intl -arch > i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp -Wall -Wno-pointer- > sign -MT logger.o -MD -MP -MF .deps/logger.Tpo -c -o logger.o logger.c > gcc-4.2: -E, -S, -save-temps and -M options are not allowed with > multiple -arch flags > make[2]: *** [logger.o] Error 1 > > > is there a chance to build a multiple archs? Try this: ./configure CFLAGS="-arch x86_64 -arch i386" --disable-dependency- tracking --disable-asm (Not tested, as I haven't upgraded to 10.6 yet, but it is correct on 10.5) David From wk at gnupg.org Wed Sep 2 19:21:18 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Sep 2009 19:21:18 +0200 Subject: [Announce] GnuPG 1.4.10 released Message-ID: <87vdk1ntyp.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-1 release: Version 1.4.10. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, samrtcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880 (the update of RFC-2440). Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build and also better portable. In contrast to GnuPG-2 (e.g version 2.0.12) it comes with no support for S/MIME or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.10 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.10.tar.bz2 (3331k) gnupg-1.4.10.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.10.tar.gz (4636k) gnupg-1.4.10.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.9-1.4.10.diff.bz2 (189k) A patch file to upgrade a 1.4.9 GnuPG source. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.10.exe (1531k) gnupg-w32cli-1.4.10.exe.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.10.tar.bz2 you would use this command: gpg --verify gnupg-1.4.10.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.10.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.10.tar.bz2 and check that the output matches the second line from the following list: fd1b6a5f3b2dd836b598a1123ac257b8f105615d gnupg-1.4.10.tar.bz2 0db579b2dc202213424f55243906b71228dd18d1 gnupg-1.4.10.tar.gz 4a6b9f8b15d9849307a90f2b35bde8fd2d111331 gnupg-1.4.9-1.4.10.diff.bz2 c4383992b4815311e523d2f12684d47b7a552fca gnupg-w32cli-1.4.10.exe What's New =========== * 2048 bit RSA keys are now generated by default. The default hash algorithm preferences has changed to prefer SHA-256 over SHA-1. 2048 bit DSA keys are now generated to use a 256 bit hash algorithm * Support v2 OpenPGP cards. * The algorithm to compute the SIG_ID status has been changed to match the one from 2.0.10. * Improved file locking. Implemented it for W32. * Fixed a memory leak which made imports of many keys very slow. * Many smaller bug fixes. * Support for the Camellia cipher (RFC-5581). * Support for HKP keyservers over SSL ("HKPS"). Internationalization ==================== GnuPG comes with support for 28 languages. Due to a lot of new and changed strings some translations are not entirely complete. The Chinese (Simple and Traditional), Czech, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish and Turkish translations are close to be complete. Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by gpg's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. A service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Werner and the other contributors) -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From benjamin at py-soft.co.uk Wed Sep 2 23:15:47 2009 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 2 Sep 2009 22:15:47 +0100 Subject: Compile i386 / x86_64 on Mac 10.6 In-Reply-To: References: <542C35BC-B995-4989-8A9D-E12811991B3E@include7.ch> <732076a80909020459x702d4556oc8874137d521e1e5@mail.gmail.com> Message-ID: <732076a80909021415l6af6192br17a16cdd2a159d84@mail.gmail.com> 2009/9/2 Jonas Schnelli : > The reason while im doing this is because GPGMail (GPG Extension for Mac > builtin Mail App) is running now in 64bit mode. So all dependencies must > also run 64bit. The 32-bit version of gpg2 runs just fine under Snow Leopard with 64-bit mail. In recent tests, there was no speed increase from 64-bits to justify the i386 X86_64 fat binary. Ben (MacGPG2!) From wk at gnupg.org Thu Sep 3 10:14:03 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Sep 2009 10:14:03 +0200 Subject: [Announce] W32 build of GnuPG 1.4.10 is broken In-Reply-To: <87vdk1ntyp.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 02 Sep 2009 19:21:18 +0200") References: <87vdk1ntyp.fsf@vigenere.g10code.de> Message-ID: <87k50gmoms.fsf@vigenere.g10code.de> Hi, GnuPG 1.4.10 has been announced yesterday, including a binary for Microsoft windows: > gnupg-w32cli-1.4.10.exe (1531k) > gnupg-w32cli-1.4.10.exe.sig > > GnuPG compiled for Microsoft Windows and OpenPGP signature. > This is a command line only version; the source files are the > same as given above. Note, that this is a minimal installer and > unless you are just in need for the gpg binary, you are better > off using the full featured installer at http://www.gpg4win.org . > c4383992b4815311e523d2f12684d47b7a552fca gnupg-w32cli-1.4.10.exe It has been reported that this build is proken. Output and input via the console prints weird characters and gpg may crash. We are investigating the problem now. The file has been removed from the main ftp server but it may still be available from mirror sites Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Sep 3 16:37:58 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Sep 2009 16:37:58 +0200 Subject: [Announce] Updated W32 build of GnuPG 1.4.10 In-Reply-To: <87k50gmoms.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 03 Sep 2009 10:14:03 +0200") References: <87vdk1ntyp.fsf@vigenere.g10code.de> <87k50gmoms.fsf@vigenere.g10code.de> Message-ID: <874orkksah.fsf_-_@vigenere.g10code.de> Hi, the broken binary build of GnuPG 1.4.10 for Microsoft Windows has been fixed. The new installer has a new file name and includes a small source patch to document the applied fix. It can be downloaded from ftp://ftp.gnupg.org/gcrypt/binary/ gnupg-w32cli-1.4.10a.exe (1539k) gnupg-w32cli-1.4.10a.exe.sig The SHA-1 checksum is: eecf2ef835b77f2400f05115c5752a11bc37ecfc gnupg-w32cli-1.4.10a.exe Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dt08lk9 at student.lth.se Fri Sep 4 15:57:08 2009 From: dt08lk9 at student.lth.se (Linus Karlsson) Date: Fri, 4 Sep 2009 15:57:08 +0200 Subject: Out of memory error, Mac 10.6, GnuPG 1.4.10 Message-ID: <723D5C28-EC74-492B-9DCD-07B0823D68CA@student.lth.se> Hi! Today I downloaded and compiled GnuPG 1.4.10 to my Mac running Snow Leopard. The compilation went smoothly, with no errors (using ./ configure --disable-asm ). I created a set of new keys, a main key, RSA 4096-bit, and two 2048- bit subkeys, which I moved to my OpenPGP-card. I have tried to encrypt two different files with my encryption subkey, showing no error. But when I try to decrypt them gpg gives me this error: macbook:Desktop linus$ LANGUAGE=en_US gpg -d test.txt.gpg gpg: anonymous recipient; trying secret key 01DB6623 ... gpg(22464) malloc: *** mmap(size=140733193392128) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug gpg: out of memory while allocating 27 bytes (The same error is given without the LANGUAGE var, but with the first line of the output in Swedish). The decryption error remains the same regardless if the OpenPGP card is inserted in the card reader or not. However, if I encrypt the file with: gpg -e -a testfile.txt (with ASCII-armoring), the decryption works without any problems. Has anyone encountered the same error? Thanks, Linus From dshaw at jabberwocky.com Fri Sep 4 19:04:27 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 4 Sep 2009 13:04:27 -0400 Subject: Out of memory error, Mac 10.6, GnuPG 1.4.10 In-Reply-To: <723D5C28-EC74-492B-9DCD-07B0823D68CA@student.lth.se> References: <723D5C28-EC74-492B-9DCD-07B0823D68CA@student.lth.se> Message-ID: <3051E86D-F4F5-46EE-99DE-8BBD2C7953BB@jabberwocky.com> On Sep 4, 2009, at 9:57 AM, Linus Karlsson wrote: > Hi! > > Today I downloaded and compiled GnuPG 1.4.10 to my Mac running Snow > Leopard. The compilation went smoothly, with no errors (using ./ > configure --disable-asm ). Does it pass 'make check' ? > I created a set of new keys, a main key, RSA 4096-bit, and two 2048- > bit subkeys, which I moved to my OpenPGP-card. > > I have tried to encrypt two different files with my encryption > subkey, showing no error. But when I try to decrypt them gpg gives > me this error: > > macbook:Desktop linus$ LANGUAGE=en_US gpg -d test.txt.gpg > gpg: anonymous recipient; trying secret key 01DB6623 ... > gpg(22464) malloc: *** mmap(size=140733193392128) failed (error > code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > gpg: out of memory while allocating 27 bytes > > (The same error is given without the LANGUAGE var, but with the > first line of the output in Swedish). > The decryption error remains the same regardless if the OpenPGP card > is inserted in the card reader or not. Can you run a test without using the card at all? That is, create the main 4096-bit key, and the two 2048-bit subkeys, and encrypt your test file in the same way (using --throw-keyid or --hidden-recipient it seems), but without transferring the key to the card first. Something seems wonky in memory allocation (140733193392128 is 7FFF00001000, which is more than a little suspicious). If you happen to have a Mac that isn't running Snow Leopard handy, it would be great if you could try it there as well. David From wk at gnupg.org Fri Sep 4 19:09:32 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Sep 2009 19:09:32 +0200 Subject: [Announce] GnuPG 2.0.13 released Message-ID: <87tyziiqlv.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.13. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.10) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPL version 3). GnuPG-2 works best on GNU/Linux or *BSD systems. What's New =========== * GPG now generates 2048 bit RSA keys by default. The default hash algorithm preferences has changed to prefer SHA-256 over SHA-1. 2048 bit DSA keys are now generated to use a 256 bit hash algorithm * The envvars XMODIFIERS, GTK_IM_MODULE and QT_IM_MODULE are now passed to the Pinentry to make SCIM work. * The GPGSM command --gen-key features a --batch mode and implements all features of gpgsm-gencert.sh in standard mode. * New option --re-import for GPGSM's IMPORT server command. * Enhanced writing of existing keys to OpenPGP v2 cards. * Add hack to the internal CCID driver to allow the use of some Omnikey based card readers with 2048 bit keys. * GPG now repeatly asks the user to insert the requested OpenPGP card. This can be disabled with --limit-card-insert-tries=1. * Minor bug fixes. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.13 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.13.tar.bz2 (3854k) gnupg-2.0.13.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.12-2.0.13.diff.bz2 (231k) A patch file to upgrade a 2.0.12 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.0.13.tar.bz2 you would use this command: gpg --verify gnupg-2.0.13.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.13.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.13.tar.bz2 and check that the output matches the first line from the following list: 2ff42aff14cdddafc291d44ac1968af5f09a9d4d gnupg-2.0.13.tar.bz2 56c0c0ca1eb5836e773fbf7c920bb46af0965aec gnupg-2.0.12-2.0.13.diff.bz2 Internationalization ==================== GnuPG comes with support for 27 languages. Due to a lot of new and changed strings many translations are not entirely complete. Jedi, Maxim Britov, Jaime Su?rez and Nilg?n Belma Bug?ner have been kind enough to go over their translations and thus the Chinese, German, Russian, Spanish, and Turkish translations are pretty much complete. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. KDE's KMail is the most prominent user of GnuPG-2. In fact it has been developed along with the KMail folks. Mutt users might want to use the configure option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP support. The manual is also available online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ and in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. The GnuPG service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Fri Sep 4 19:34:37 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Sep 2009 19:34:37 +0200 Subject: Out of memory error, Mac 10.6, GnuPG 1.4.10 In-Reply-To: <723D5C28-EC74-492B-9DCD-07B0823D68CA@student.lth.se> (Linus Karlsson's message of "Fri, 4 Sep 2009 15:57:08 +0200") References: <723D5C28-EC74-492B-9DCD-07B0823D68CA@student.lth.se> Message-ID: <87my5aipg2.fsf@vigenere.g10code.de> On Fri, 4 Sep 2009 15:57, dt08lk9 at student.lth.se said: > macbook:Desktop linus$ LANGUAGE=en_US gpg -d test.txt.gpg > gpg: anonymous recipient; trying secret key 01DB6623 ... > gpg(22464) malloc: *** mmap(size=140733193392128) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > gpg: out of memory while allocating 27 bytes Please run: LANGUAGE=en_US gpg --debug 32 -d test.txt.gpg the last lines of the log might give a hint where we allocate the 27 bytes. Given that the error is in libc I dount that it will help, however running it is easy. Also check that the C macro M_GUARD is not defined: You find such #ifdefs in util/memory.c. Add a line #error ooops inside of such a block and compile it again. I tested the release on a 64 bit PPC box, so this won't be the problem. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dt08lk9 at student.lth.se Fri Sep 4 21:53:15 2009 From: dt08lk9 at student.lth.se (Linus Karlsson) Date: Fri, 4 Sep 2009 21:53:15 +0200 Subject: Out of memory error, Mac 10.6, GnuPG 1.4.10 In-Reply-To: <87my5aipg2.fsf@vigenere.g10code.de> References: <723D5C28-EC74-492B-9DCD-07B0823D68CA@student.lth.se> <87my5aipg2.fsf@vigenere.g10code.de> Message-ID: Thanks for your answers (both Werner and David). Results follow: On 4 sep 2009, at 19.34, Werner Koch wrote: > > Please run: > > LANGUAGE=en_US gpg --debug 32 -d test.txt.gpg macbook:Desktop linus$ LANGUAGE=en_US gpg --debug 32 -d testenc.txt.gpg gpg: reading options from `/Users/linus/.gnupg/gpg.conf' gpg: DBG: mpi_alloc(2048) gpg: DBG: mpi_alloc_limb_space(2048) gpg: DBG: mpi_alloc(4096) gpg: DBG: mpi_alloc_limb_space(4096) gpg: DBG: mpi_alloc(64) gpg: DBG: mpi_alloc_limb_space(64) gpg: DBG: mpi_alloc(0) gpg: DBG: free_packet() type=5 gpg: DBG: mpi_free gpg: DBG: dummy m_size called gpg: DBG: mpi_free_limb_space of size 0 gpg: DBG: mpi_free gpg: DBG: dummy m_size called gpg: DBG: mpi_free_limb_space of size 0 gpg: DBG: mpi_free gpg: DBG: mpi_alloc(4096) gpg: DBG: mpi_alloc_limb_space(4096) gpg: DBG: mpi_alloc(64) gpg: DBG: mpi_alloc_limb_space(64) gpg: DBG: mpi_alloc(0) gpg: DBG: mpi_alloc(4096) gpg: DBG: mpi_alloc_limb_space(4096) gpg: DBG: free_packet() type=12 gpg: DBG: mpi_alloc(4096) gpg: DBG: mpi_alloc_limb_space(4096) gpg: DBG: free_packet() type=12 gpg: DBG: mpi_alloc(4096) gpg: DBG: mpi_alloc_limb_space(4096) gpg: DBG: free_packet() type=12 gpg: DBG: mpi_alloc(2048) gpg: DBG: mpi_alloc_limb_space(2048) gpg: DBG: mpi_alloc(64) gpg: DBG: mpi_alloc_limb_space(64) gpg: DBG: mpi_alloc(0) gpg: DBG: mpi_alloc(4096) gpg: DBG: mpi_alloc_limb_space(4096) gpg: DBG: free_packet() type=12 gpg: DBG: mpi_alloc(2048) gpg: DBG: mpi_alloc_limb_space(2048) gpg: DBG: mpi_alloc(64) gpg: DBG: mpi_alloc_limb_space(64) gpg: DBG: mpi_alloc(0) gpg: DBG: mpi_alloc(4096) gpg: DBG: mpi_alloc_limb_space(4096) gpg: DBG: free_packet() type=12 gpg: DBG: mpi_alloc(2048) gpg: DBG: mpi_alloc_limb_space(2048) gpg: DBG: mpi_alloc(64) gpg: DBG: mpi_alloc_limb_space(64) gpg: DBG: mpi_alloc(0) gpg: anonymous recipient; trying secret key 01DB6623 ... gpg(57398) malloc: *** mmap(size=732127585634357248) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug gpg: out of memory while allocating 27 bytes > > Also check that the C macro M_GUARD is not defined: You find such > #ifdefs in util/memory.c. Add a line > > #error ooops > > inside of such a block and compile it again. I added #error ooops on line 102 in the specified file. Compilation passed without any errors. On 4 sep 2009, at 19.04, David Shaw wrote: > > Does it pass 'make check' ? Yes, all 27 tests pass. > Can you run a test without using the card at all? That is, create > the main 4096-bit key, and the two 2048-bit subkeys, and encrypt > your test file in the same way (using --throw-keyid or --hidden- > recipient it seems), but without transferring the key to the card > first. Done, encryption/decryption works fine when I generated new keys without moving them to the card. I tried to create the keys the same way as when I generated them for the card, that is, I also removed the main key's secret key from my keyring. (Following this guide: https://we.riseup.net/debian/using-the-openpgp-card-with-subkeys ). I have "hidden-encrypt-to" specified in my gpg.conf, with the key-id of the encryption subkey. > If you happen to have a Mac that isn't running Snow Leopard handy, > it would be great if you could try it there as well. Unfortunatly I only have one Mac, newly formatted to Snow Leopard, so I'm afraid I can't test it on any other version. /Linus From wittau at lnxnt.org Mon Sep 7 15:53:06 2009 From: wittau at lnxnt.org (wittau at lnxnt.org) Date: Mon, 7 Sep 2009 15:53:06 +0200 (CEST) Subject: strange behavior/maybe a critical bug? Message-ID: <13010.wittau@lnxnt.org.1252331586.squirrel@www.lnxnt.org> Hello everyone, I?m not a developer but I encountered a strange behavior regarding gpg encrypted messages. Maybe I discovered a critical bug, maybe I?m absolutely wrong. I try to be as precise as possible. The situation was an Enigmail installation at a USB-Stick for Windows, with encrypted mails. We tried to find a possibility for decrypting some .pdf files at MacOS 9 from this USB-Stick. So we searched about the right mails in the text-files, and copied the encrypted code to a text file. At BBEdit I added the lines "----- begin pgp message -----" and "------ end pgpg message -----" to the encrypted text. Than I installed PGP 6.0 at my Mac G3 and imported the private key. After importing, I went to PGP-Tools and "decrypt/veryfy" and selected the textfile for decryption. PGP 6 produces an error and tells me: "the file "xy" could not be decrypted/verified because an error occured: ascii armor input incomplete." BUT - PGP produces an file at my desktop! After renaming this file "xy" to "xy.pdf" I can read the pdf without any password! That behavior is reproduceable! It?s possible to read every encrypted attachements from enigmail without the need of an password, ... Any ideas? From John at Mozilla-Enigmail.org Mon Sep 7 17:07:14 2009 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Mon, 07 Sep 2009 10:07:14 -0500 Subject: strange behavior/maybe a critical bug? In-Reply-To: <13010.wittau@lnxnt.org.1252331586.squirrel@www.lnxnt.org> References: <13010.wittau@lnxnt.org.1252331586.squirrel@www.lnxnt.org> Message-ID: <4AA521A2.30800@Mozilla-Enigmail.org> wittau at lnxnt.org wrote: > > That behavior is reproduceable! > It?s possible to read every encrypted attachements from enigmail without > the need of an password, ... > > Any ideas? Yep. I'd bet your "Encrypted attachments" are nothing more than attachments. Check the MIME headers in the original message. Individual files are attached unencrypted. If the sender wants them encrypted, PGP/MIME must be used to encrypt the _entire_ email as one unit. Rather than PGP 6.0 on the Mac, why didn't you install a recent GnuPG version? Checkout the MacGPG project. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 679 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Sep 7 18:51:06 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 07 Sep 2009 09:51:06 -0700 Subject: strange behavior/maybe a critical bug? In-Reply-To: <13010.wittau@lnxnt.org.1252331586.squirrel@www.lnxnt.org> References: <13010.wittau@lnxnt.org.1252331586.squirrel@www.lnxnt.org> Message-ID: <4AA539FA.8030104@sixdemonbag.org> wittau at lnxnt.org wrote: > It?s possible to read every encrypted attachements from enigmail without > the need of an password, ... Let's not jump to conclusions. If what you say is true, then there is a critical bug in Enigmail. That said, I think a little more investigation is necessary before we start a panic. A discussion about this has been started on the Enigmail users list; let's take the discussion there. From bernhard at intevation.de Tue Sep 8 17:49:45 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 8 Sep 2009 17:49:45 +0200 Subject: GnuPG Port for Symbian In-Reply-To: <200808251200.58684.nd@syndicat.com> References: <200808251200.58684.nd@syndicat.com> Message-ID: <200909081749.48452.bernhard@intevation.de> Hi Niels, Am Montag, 25. August 2008 12:00:53 schrieb Niels Dettenbach: > im still wondering if the is no GnuPG port today for Symbian OS wich is > widely spread on mobile phones worldwide - even as GnuPG still seems to be > ported for a lot of difference operating systems. > > The last posting / thread I've found about this issue was in 2000: > http://lists.gnupg.org/pipermail/gnupg-users/2000-March/005097.html > > Since Symbian published their developement kit (for windows and linux > afaik) plus more and more API docs, the phones got more memory and cpu > power - i assume GnuPG porting to it should be a much easier task then a > few years ago. yes, I think you are correct. There is even a POSIX layer, which should really work since S60 rev 3 FP2 or so: http://en.wikipedia.org/wiki/P.I.P.S._Is_POSIX_on_Symbian > Even Perl and Python got a OS port on Symbian. The Python port still has > wide access to all phone and GUI functions of the phones (may be could be > used for GnuPG GUI interoperability) - or see asex. the mobile webserver > project. > > Many users today are using their phones for email communication and the > storage of (may be) sensible files on their phones - and many users (if > they knwo it or not) are using Symbian based phones. With the USB storage > capability the phone could be used as a "secure" smart crypt or signing > device over USB storage with not trusted PCs o.o. hardware too. I agree it would be cool to have a GnuPG port to Symbian, especially now that Symbian is going to released as Free Software over time. (Nokia that owns Symbian started with one crypto component as far as I know.) > The only (commercial) "email crypto" software product i've found > was "CryptoGraf" wich seems not working properly and is no OS product (so > not trustful for me and most other GPG users). > > Is there anyone who is currently working on a GnuPG port for Symbian OS or > knows a working port? I am not aware of anyone currently working on such a port (after asking Werner the same question). So it is matter wit many products that are needed: Do it yourself or find someone to do it for you. ;) Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From philcerf at googlemail.com Thu Sep 10 00:43:19 2009 From: philcerf at googlemail.com (Philippe Cerfon) Date: Thu, 10 Sep 2009 00:43:19 +0200 Subject: does gpg cope with very large key sizes Message-ID: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> Hi list and GnuPG developers! Let me introduce myself,... I'm Philippe Cerfon and I'm currently taking some crypto-lectures... including all that fancy algorithms and so on ;-) Out of curiosity I was starting some test series on how key creation time and encryption/signing time relates to key sizes. I soon found out that gpg puts a limit on keys at 4096 bits which is surely reasonable for real world but somewhat disturbing my test. I was looking into the gnupg mailing list archives and found out that gpg is said to be able to work with larger keys. I've also seen that this topic is well somewhat critical, so to say it in advance,.. this only for trying and playing :) So I grepped the sources (for both version 1.x and 2.x) and found that the limit is enfored here: g10/keygen.c: unsigned nbits, min, def=2048, max=4096; With version 2.x probably in some other places, too: g10/app-openpgp.c: max_length = 4096; scd/app-openpgp.c: max_length = 4096; scd/command.c:#define MAXLEN_KEYDATA 4096 tools/gpgkey2ssh.c: max_length = 4096; tools/gpgconf-comp.c:#define BUF_LEN 4096 but I think they're unrelated to key creation/use. So all I must to is e.g. set max = 65536 or even something higher ;-) Right so far? I've seen many other places where some buffers or other this are set to 4096 (see attachments): So my questions now are: - Is it done with changing the max or would I have to change some other places too in order to make everything work correctly (e.g. these max_length's or so)? - Are the generated keys (or their signatures) actually sane? I mean I could imagine that at some point randomness gets just worse, or some buffers cap the key entropy or whatever. - Or is in everything ok,.. and there's just this max=something in g10/keygen.c where you save users from shooting into their feets by creating to large keys but nothing else? You know, my time measurements might be simply bogus as gpg stops producing valuable key bits after some limit,.. or the measurements might be useless as these keys were no longer secure (even less than normal keys) anyway... Thanks and au revoir, Philippe. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Thu Sep 10 05:09:49 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 9 Sep 2009 23:09:49 -0400 Subject: does gpg cope with very large key sizes In-Reply-To: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> Message-ID: <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> On Sep 9, 2009, at 6:43 PM, Philippe Cerfon wrote: > Hi list and GnuPG developers! > > > Let me introduce myself,... I'm Philippe Cerfon and I'm currently > taking some crypto-lectures... including all that fancy algorithms > and so on ;-) > Out of curiosity I was starting some test series on how key creation > time and encryption/signing time relates to key sizes. > I soon found out that gpg puts a limit on keys at 4096 bits which is > surely reasonable for real world but somewhat disturbing my test. > > I was looking into the gnupg mailing list archives and found out > that gpg is said to be able to work with larger keys. I've also seen > that this topic is well somewhat critical, so to say it in > advance,.. this only for trying and playing :) > > So I grepped the sources (for both version 1.x and 2.x) and found > that the limit is enfored here: > g10/keygen.c: unsigned nbits, min, def=2048, max=4096; Yes. > So all I must to is e.g. set max = 65536 or even something higher ;-) > Right so far? Right, but you may be surprised how long it takes to generate a really massive key. The key generation code is single-threaded, and generally not optimized for really big keys. > So my questions now are: > - Is it done with changing the max or would I have to change some > other places too in order to make everything work correctly (e.g. > these max_length's or so)? You should be okay with changing the ones in keygen.c. > - Or is in everything ok,.. and there's just this max=something in > g10/keygen.c where you save users from shooting into their feets by > creating to large keys but nothing else? Pretty much true if your goal is to just do performance testing with different sizes. I certainly wouldn't actually use such a key in the real world, though. David From philcerf at googlemail.com Thu Sep 10 13:40:40 2009 From: philcerf at googlemail.com (Philippe Cerfon) Date: Thu, 10 Sep 2009 13:40:40 +0200 Subject: does gpg cope with very large key sizes In-Reply-To: <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> Message-ID: <6e7da8720909100440l4c13ed03ve78a3d43bd0dc33d@mail.gmail.com> Hi David. On Thu, Sep 10, 2009 at 5:09 AM, David Shaw wrote: >> So I grepped the sources (for both version 1.x and 2.x) and found that the limit is enfored here: >> g10/keygen.c: ?unsigned nbits, min, def=2048, max=4096; > Yes. Wow,.. I alawys knew I'd be a gpg-code guru *laughs* ;-) >> So all I must to is e.g. set max = 65536 or even something higher ;-) >> Right so far? > Right, but you may be surprised how long it takes to generate a really massive key. ?The key generation code is single-threaded, and generally not optimized for really big keys. That's just what I want to find out,... ok actually,.. I think the times required to sign/encrypt with such a key are more interesting,.. but creation time is somewhat interesting, too. > You should be okay with changing the ones in keygen.c. >> - Or is in everything ok,.. and there's just this max=something in g10/keygen.c where you save users from shooting into their feets by creating to large keys but nothing else? > Pretty much true if your goal is to just do performance testing with different sizes. ?I certainly wouldn't actually use such a key in the real world, though. Pretty much? What do you mean by that? The time/performance issues? Out of curiosity: As far as I know the suggested key sizes will always rather raise, right (expect one moves perhaps away from RSA, but are there any alternatives than DSA?)? So maybe in 20 or 30 years 32k bit keys will be necessary,... would be bad if those keys weren't usable in the real world :-/ Cheers, Philippe. From dshaw at jabberwocky.com Thu Sep 10 18:07:07 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 10 Sep 2009 12:07:07 -0400 Subject: does gpg cope with very large key sizes In-Reply-To: <6e7da8720909100440l4c13ed03ve78a3d43bd0dc33d@mail.gmail.com> References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> <6e7da8720909100440l4c13ed03ve78a3d43bd0dc33d@mail.gmail.com> Message-ID: On Sep 10, 2009, at 7:40 AM, Philippe Cerfon wrote: >>> - Or is in everything ok,.. and there's just this max=something in >>> g10/keygen.c where you save users from shooting into their feets >>> by creating to large keys but nothing else? >> Pretty much true if your goal is to just do performance testing >> with different sizes. I certainly wouldn't actually use such a key >> in the real world, though. > > Pretty much? What do you mean by that? The time/performance issues? Yes, but also that it's a silly keysize in the real world. For most people (doing regular-people things like using computers connected to the internet, presumably in a house or apartment with a front door), the key would be so vastly stronger than the rest of the environment that an attacker wouldn't bother to attack it. Rather they'd go against that front door, or other attacks against you and/or your environment. It's a bit like this: http://failblog.org/2009/05/22/security-fail-5/ > Out of curiosity: As far as I know the suggested key sizes will always > rather raise, right (expect one moves perhaps away from RSA, but are > there any alternatives than DSA?)? So maybe in 20 or 30 years 32k bit > keys will be necessary,... would be bad if those keys weren't usable > in the real world :-/ I don't forsee we'll ever end up with keys that large. They're just too big to conveniently use. Rather, we'll switch over to algorithms like Elliptic Curve that are stronger per-bit than RSA or DSA. David From gnupg.devel at ml.karotte.org Thu Sep 10 18:21:32 2009 From: gnupg.devel at ml.karotte.org (Sebastian Wiesinger) Date: Thu, 10 Sep 2009 18:21:32 +0200 Subject: does gpg cope with very large key sizes In-Reply-To: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> Message-ID: <20090910162132.GC14108@danton.fire-world.de> * Philippe Cerfon [2009-09-10 01:43]: > Hi list and GnuPG developers! > > > Let me introduce myself,... I'm Philippe Cerfon and I'm currently taking > some crypto-lectures... including all that fancy algorithms and so on ;-) > Out of curiosity I was starting some test series on how key creation time > and encryption/signing time relates to key sizes. > I soon found out that gpg puts a limit on keys at 4096 bits which is surely > reasonable for real world but somewhat disturbing my test. Hi, regarding this, the Simtec Entropy Key http://www.entropykey.co.uk/ is available for sale online since a few days ago. This is an USB hardware entropy generator. Perhaps this would be something to consider in your tests regarding quality and speed of entropy generation. Regards, Sebastian -- New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 591 bytes Desc: Digital signature URL: From philcerf at googlemail.com Thu Sep 10 23:29:57 2009 From: philcerf at googlemail.com (Philippe Cerfon) Date: Thu, 10 Sep 2009 23:29:57 +0200 Subject: does gpg cope with very large key sizes In-Reply-To: References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> <6e7da8720909100440l4c13ed03ve78a3d43bd0dc33d@mail.gmail.com> Message-ID: <6e7da8720909101429q22a70a65o18de3bb2d651c9f7@mail.gmail.com> Hi David. On Thu, Sep 10, 2009 at 6:07 PM, David Shaw wrote: >> Pretty much? What do you mean by that? The time/performance issues? > Yes, but also that it's a silly keysize in the real world. ?For most people > (doing regular-people things like using computers connected to the internet, > presumably in a house or apartment with a front door), the key would be so > vastly stronger than the rest of the environment that an attacker wouldn't > bother to attack it. ?Rather they'd go against that front door, or other > attacks against you and/or your environment. Of course,... I was aware on this :) If CIA|NSA|etc. want my secrets (not that my life would be so interesting ^^), they probably woulnd't try to hack my keys at all,.. but simply beat me until I happly give them everything plus confessions to anything they want ;) When I asked you before,.. I just ment if these oversized keys would still be ok and "secure", in a hypothetical scenario, where everything else is also perfectly secure (e.g. having a steel door with Superman guarding it ;-) ) > I don't forsee we'll ever end up with keys that large. ?They're just too big > to conveniently use. ?Rather, we'll switch over to algorithms like Elliptic > Curve *looked it up* Ah,.. interesting... So will this "replace" RSA/DSA? Perhaps also with an OpenPGP without the strict bindings to SHA1 you mentioned before? Is it already working (for gpg)? Or when could one expect this being usable for production? Cheers, Philippe. From dshaw at jabberwocky.com Fri Sep 11 00:27:34 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 10 Sep 2009 18:27:34 -0400 Subject: does gpg cope with very large key sizes In-Reply-To: <6e7da8720909101429q22a70a65o18de3bb2d651c9f7@mail.gmail.com> References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> <6e7da8720909100440l4c13ed03ve78a3d43bd0dc33d@mail.gmail.com> <6e7da8720909101429q22a70a65o18de3bb2d651c9f7@mail.gmail.com> Message-ID: On Sep 10, 2009, at 5:29 PM, Philippe Cerfon wrote: > When I asked you before,.. I just ment if these oversized keys would > still be ok and "secure", in a hypothetical scenario, where everything > else is also perfectly secure (e.g. having a steel door with Superman > guarding it ;-) ) So far as I know, they should be fine and still secure - just very large. Of course, we don't test beyond 4096 bits, but I don't know of any particular gotchas in there for keys beyond 4096. >> I don't forsee we'll ever end up with keys that large. They're >> just too big >> to conveniently use. Rather, we'll switch over to algorithms like >> Elliptic >> Curve > > *looked it up* > Ah,.. interesting... > So will this "replace" RSA/DSA? Perhaps also with an OpenPGP without > the strict bindings to SHA1 you mentioned before? > Is it already working (for gpg)? Or when could one expect this being > usable for production? Not very soon. The first step is to get ECC as an update to the OpenPGP spec. The next step (really concurrent with the first step) would be get more than one implementation (GPG, PGP, OpenPGP:SDK, etc) to support it and prove interoperability. Finally there is the rather slow ramp-up as people slowly adopt the new ability. This is the part that takes the longest as people don't upgrade very quickly or often, there is reluctance to make new keys, etc. There is currently a proposal for OpenPGP ECC. See http://brainhub.googlepages.com/pgp Note that ECC and a no-SHA1 OpenPGP aren't necessarily related. As specified in the draft, ECC ends up being two new algorithm types like RSA or DSA. You could have a (for example) a ECDSA subkey on your RSA primary key and so on. A no-SHA1 OpenPGP is a different sort of problem, and pretty much implies a new key packet type, as I see it. Even in an ideal world, widespread ECC use is years away. (Which doesn't mean we shouldn't start - if we want it used years from now, we have to start on it). If you're interested in ECC, I suggest you check out the ietf-openpgp list. This is where changes to the OpenPGP spec are discussed. See http://www.imc.org/ietf-openpgp/ David From philcerf at googlemail.com Fri Sep 11 01:22:53 2009 From: philcerf at googlemail.com (Philippe Cerfon) Date: Fri, 11 Sep 2009 01:22:53 +0200 Subject: does gpg cope with very large key sizes In-Reply-To: References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> <6e7da8720909100440l4c13ed03ve78a3d43bd0dc33d@mail.gmail.com> <6e7da8720909101429q22a70a65o18de3bb2d651c9f7@mail.gmail.com> Message-ID: <6e7da8720909101622l10c7dee6ka2585733f36a3af1@mail.gmail.com> Thanks for your infos and the pointer to that mailing list :-) Greetings, Philippe From philcerf at googlemail.com Fri Sep 11 15:54:08 2009 From: philcerf at googlemail.com (Philippe Cerfon) Date: Fri, 11 Sep 2009 15:54:08 +0200 Subject: GPG User ID Comments and RFC 5322 Message-ID: <6e7da8720909110654s499a64f7hc9358b16f63c4bfc@mail.gmail.com> Hi again. Some days ago I was reading RFC 5322 which will probably become the new standard for internet mail. In sections 3.4 and 3.4.1 it says: >Also, because some legacy >implementations interpret the comment, comments generally SHOULD >NOT be used in address fields to avoid confusing such >implementations. and >Comments and folding white space >SHOULD NOT be used around the "@" in the addr-spec. As far as I can see this is what gnupg does when users set a Comment when they create their key. It has the same format: "(" phrase ")" Also the RFC means these comments (as far as I understand) more as real comments as you know them from C/C++,.. that are totally ignored by the clients/programs, while gpg does (of course) not ignore them but also interpret them more as and additional note to the name e.g.: Charles de Gaulle (pr?sident) in contrast to Charles de Gaulle (teacher) Just wanted you to know this, that you can react if you think this should be done. Cheers, Philppe From dshaw at jabberwocky.com Sun Sep 13 00:28:25 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 12 Sep 2009 18:28:25 -0400 Subject: GPG User ID Comments and RFC 5322 In-Reply-To: <6e7da8720909110654s499a64f7hc9358b16f63c4bfc@mail.gmail.com> References: <6e7da8720909110654s499a64f7hc9358b16f63c4bfc@mail.gmail.com> Message-ID: <01869ED3-9573-43C5-A194-7EAFD471296D@jabberwocky.com> On Sep 11, 2009, at 9:54 AM, Philippe Cerfon wrote: > Hi again. > > Some days ago I was reading RFC 5322 which will probably become the > new standard for internet mail. > > > In sections 3.4 and 3.4.1 it says: > >> Also, because some legacy >> implementations interpret the comment, comments generally SHOULD >> NOT be used in address fields to avoid confusing such >> implementations. > > and > >> Comments and folding white space >> SHOULD NOT be used around the "@" in the addr-spec. > > > As far as I can see this is what gnupg does when users set a Comment > when they create their key. It has the same format: "(" phrase ")" > > Also the RFC means these comments (as far as I understand) more as > real comments as you know them from C/C++,.. that are totally ignored > by the clients/programs, while gpg does (of course) not ignore them > but also interpret them more as and additional note to the name e.g.: > Charles de Gaulle (pr?sident) > in contrast to > Charles de Gaulle (teacher) GPG generally ignores comments. They're intended as messages from one human to another, and not GPG's responsiblity. You can search on the field, but (with one exception) GPG will not act differently depending on what it finds in there. (The exception is if you put a comment in that says the key is "insecure" or "do not use", GPG will believe you) David From philcerf at googlemail.com Sun Sep 13 19:04:55 2009 From: philcerf at googlemail.com (Philippe Cerfon) Date: Sun, 13 Sep 2009 19:04:55 +0200 Subject: GPG User ID Comments and RFC 5322 In-Reply-To: <01869ED3-9573-43C5-A194-7EAFD471296D@jabberwocky.com> References: <6e7da8720909110654s499a64f7hc9358b16f63c4bfc@mail.gmail.com> <01869ED3-9573-43C5-A194-7EAFD471296D@jabberwocky.com> Message-ID: <6e7da8720909131004w6d0be2fdx837335321676164e@mail.gmail.com> On Sun, Sep 13, 2009 at 12:28 AM, David Shaw wrote: > GPG generally ignores comments. They're intended as messages from one human > to another, and not GPG's responsiblity. You can search on the field, but > (with one exception) GPG will not act differently depending on what it finds > in there. Isn't this a problem? If gpg handles keys (or even different keys) with user IDs that only differ by their comment,.. but gpg ignores this? > (The exception is if you put a comment in that says the key is "insecure" or > "do not use", GPG will believe you) What if use insecure in another language? Or "non-insecure"? :P Apart from all that, I've read some pages of the RFC where it says User IDs are basically just strings without any special format. So shouldn't gpg ignore this comment-speciality from emails and just take it as strings? Cheers, Philippe. From philcerf at googlemail.com Sun Sep 13 19:07:26 2009 From: philcerf at googlemail.com (Philippe Cerfon) Date: Sun, 13 Sep 2009 19:07:26 +0200 Subject: does gpg cope with very large key sizes In-Reply-To: References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> <6e7da8720909100440l4c13ed03ve78a3d43bd0dc33d@mail.gmail.com> <6e7da8720909101429q22a70a65o18de3bb2d651c9f7@mail.gmail.com> Message-ID: <6e7da8720909131007w65f7ed1dr3c92a5d0eaadbae5@mail.gmail.com> Hi. For those wo are interested,... ;) I've aborted trying to create a 65536 bit RSA key. Took just too long and I don't know enough on key generation to make an estimation ;) Anyway,.. when trying to create 32768 bit RSA key I've got the following error: We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. .......................+++++ .........................................................................+++++ gpg: out of secure memory while allocating 4096 bytes gpg: (this may be caused by too many secret keys used simultaneously or due to excessive large key sizes) Is this a bug? Or is there anything I can do to get more "secure memory"? Thanks, Philippe From dshaw at jabberwocky.com Sun Sep 13 20:03:49 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 13 Sep 2009 14:03:49 -0400 Subject: GPG User ID Comments and RFC 5322 In-Reply-To: <6e7da8720909131004w6d0be2fdx837335321676164e@mail.gmail.com> References: <6e7da8720909110654s499a64f7hc9358b16f63c4bfc@mail.gmail.com> <01869ED3-9573-43C5-A194-7EAFD471296D@jabberwocky.com> <6e7da8720909131004w6d0be2fdx837335321676164e@mail.gmail.com> Message-ID: On Sep 13, 2009, at 1:04 PM, Philippe Cerfon wrote: > On Sun, Sep 13, 2009 at 12:28 AM, David Shaw > wrote: >> GPG generally ignores comments. They're intended as messages from >> one human >> to another, and not GPG's responsiblity. You can search on the >> field, but >> (with one exception) GPG will not act differently depending on what >> it finds >> in there. > Isn't this a problem? If gpg handles keys (or even different keys) > with user IDs that only differ by their comment,.. but gpg ignores > this? GPG does really not do anything with the user ID beyond allowing you to search with it. The key ID is how GPG manipulates keys. The user ID is for human beings. David From dshaw at jabberwocky.com Sun Sep 13 20:13:03 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 13 Sep 2009 14:13:03 -0400 Subject: does gpg cope with very large key sizes In-Reply-To: <6e7da8720909131007w65f7ed1dr3c92a5d0eaadbae5@mail.gmail.com> References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> <6e7da8720909100440l4c13ed03ve78a3d43bd0dc33d@mail.gmail.com> <6e7da8720909101429q22a70a65o18de3bb2d651c9f7@mail.gmail.com> <6e7da8720909131007w65f7ed1dr3c92a5d0eaadbae5@mail.gmail.com> Message-ID: <74CA2C13-A15F-4637-8C89-86BB7930CABA@jabberwocky.com> On Sep 13, 2009, at 1:07 PM, Philippe Cerfon wrote: > Hi. > > For those wo are interested,... ;) > > I've aborted trying to create a 65536 bit RSA key. Took just too long > and I don't know enough on key generation to make an estimation ;) > > > Anyway,.. when trying to create 32768 bit RSA key I've got the > following error: > We need to generate a lot of random bytes. It is a good idea to > perform > some other action (type on the keyboard, move the mouse, utilize the > disks) during the prime generation; this gives the random number > generator a better chance to gain enough entropy. > .......................+++++ > .........................................................................+ > ++++ > gpg: out of secure memory while allocating 4096 bytes > gpg: (this may be caused by too many secret keys used simultaneously > or due to excessive large key sizes) > > Is this a bug? Or is there anything I can do to get more "secure > memory"? No, it's not a bug. You're hacking the code to get it to do something the developers explicitly don't permit doing. You can't file a bug against a car for not driving straight after you removed a wheel. The rules of this game are: if you break it, you get to keep the pieces. You can get more secure memory by changing the call to secmem_init in gpg.c. David From rdieter at math.unl.edu Sun Sep 13 22:02:06 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 13 Sep 2009 15:02:06 -0500 Subject: can't get pinentry-qt4 to work Message-ID: Anyone having luck getting pinentry-qt4 to work? Both -qt and -gtk-2 seems to work ok for me, but as soon as I try -qt4, gpg-agent fails, my debug-level advanced output includes: 2009-09-13 14:24:55 gpg-agent[27662] starting a new PIN Entry gpg-agent[27662]: can't connect server: ec=4.16383 2009-09-13 14:24:56 gpg-agent[27662] can't connect to the PIN entry module: End of file 2009-09-13 14:24:56 gpg-agent[27662] command get_passphrase failed: No pinentry gpg-agent[27662.7] DBG: -> ERR 67108949 No pinentry gpg-agent[27662.7] DBG: <- [EOF] ?? any clues or advice? -- Rex From philcerf at googlemail.com Sun Sep 13 22:22:57 2009 From: philcerf at googlemail.com (Philippe Cerfon) Date: Sun, 13 Sep 2009 22:22:57 +0200 Subject: does gpg cope with very large key sizes In-Reply-To: <74CA2C13-A15F-4637-8C89-86BB7930CABA@jabberwocky.com> References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> <6e7da8720909100440l4c13ed03ve78a3d43bd0dc33d@mail.gmail.com> <6e7da8720909101429q22a70a65o18de3bb2d651c9f7@mail.gmail.com> <6e7da8720909131007w65f7ed1dr3c92a5d0eaadbae5@mail.gmail.com> <74CA2C13-A15F-4637-8C89-86BB7930CABA@jabberwocky.com> Message-ID: <6e7da8720909131322v250f44a6qef51f9d382dcfc5a@mail.gmail.com> On Sun, Sep 13, 2009 at 8:13 PM, David Shaw wrote: > You can get more secure memory by changing the call to secmem_init in gpg.c. btw: For my tests, ... would it also work to just set --no-require-secmem ? Cheers, Philippe. From dshaw at jabberwocky.com Sun Sep 13 22:54:01 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 13 Sep 2009 16:54:01 -0400 Subject: does gpg cope with very large key sizes In-Reply-To: <6e7da8720909131322v250f44a6qef51f9d382dcfc5a@mail.gmail.com> References: <6e7da8720909091543l6a67e9b6h736de412adb8200@mail.gmail.com> <3AC34D66-8907-4846-BF40-F4CEB7E61E58@jabberwocky.com> <6e7da8720909100440l4c13ed03ve78a3d43bd0dc33d@mail.gmail.com> <6e7da8720909101429q22a70a65o18de3bb2d651c9f7@mail.gmail.com> <6e7da8720909131007w65f7ed1dr3c92a5d0eaadbae5@mail.gmail.com> <74CA2C13-A15F-4637-8C89-86BB7930CABA@jabberwocky.com> <6e7da8720909131322v250f44a6qef51f9d382dcfc5a@mail.gmail.com> Message-ID: On Sep 13, 2009, at 4:22 PM, Philippe Cerfon wrote: > On Sun, Sep 13, 2009 at 8:13 PM, David Shaw > wrote: >> You can get more secure memory by changing the call to secmem_init >> in gpg.c. > > btw: For my tests, ... would it also work to just set --no-require- > secmem ? No, that has nothing to do with the amount of secure memory. David From stefan.lorenz at stud.uni-saarland.de Mon Sep 14 15:34:33 2009 From: stefan.lorenz at stud.uni-saarland.de (Stefan Lorenz) Date: Mon, 14 Sep 2009 15:34:33 +0200 Subject: Experimental Algorithms Message-ID: <4AAE4669.7030003@stud.uni-saarland.de> Hi all, we are working on experimental algorithms and tried to incorporate different signing algorithms into gpg. We created a public key package, set the algorithm field to 100 and put our data into the packet. This worked fine, however, when we tried to import this key into our own keyring, gpg says: gpg: key 13D59A3E: no valid user IDs gpg: this may be caused by a missing self-signature gpg: Total number processed: 1 gpg: w/o user IDs: 1 We can force gpg to import it using the "allow-non-selfsigned-uid" option, but then we can never export or sign this self-created public key. So, as a next step we attached a UID packet to the public key packet, and then attached a signature packet with signature type 0x10, algorithm 100 for hash and pk, and an issuer signature sub packet with the corresponding public keys keyID. Again, gpg -v --list-packets on our packet doesn't complain and recognizes all the fields set correctly. An import this time complains about the key algorithm 100 thats not supported, thus skips the userID and then complains about a missing ID. Our question is, is there a way to import "own" key-material (data) into gpg thus that we can sign it using our standard gpg dsa key and export it? Or is there a possibility to attach own key-material (data) to an existing public or secret key? Best, Stefan From bernhard at intevation.de Wed Sep 16 11:50:58 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 16 Sep 2009 11:50:58 +0200 Subject: GnuPG 2 does not import older keys with RSA-E and RSA-S anymore Message-ID: <200909161150.58875.bernhard@intevation.de> It seems that some GnuPG2 2.0.12 packages do not import old keys with the deprecated following algorithms anymore: 2 - RSA Encrypt-Only [HAC] 3 - RSA Sign-Only [HAC] rfc4880 notes: Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be generated, but may be interpreted. For a test case see: http://lists.wald.intevation.org/pipermail/gpg4win-devel/2009-September/000881.html http://lists.wald.intevation.org/pipermail/gpg4win-devel/2009-September/000882.html Gpg1 still does it. Certainly a defect is that the algorithm is reported as unknown. I wonder though, why this was changes as rf4880 allows for interpretation of such keys. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Sep 16 13:58:51 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 16 Sep 2009 13:58:51 +0200 Subject: pinentry-qt4 Message-ID: <200909161358.54782.bernhard@intevation.de> > Anyone having luck getting pinentry-qt4 to work? Yes, works in gpg4win 2.0.1rc1 and I could just complie it and run it for pinentry-0.7.6 on lenny. > Both -qt and -gtk-2 seems > to work ok for me, but as soon as I try -qt4, gpg-agent fails, my > debug-level advanced > output includes: > > 2009-09-13 14:24:55 gpg-agent[27662] starting a new PIN Entry > gpg-agent[27662]: can't connect server: ec=4.16383 > 2009-09-13 14:24:56 gpg-agent[27662] can't connect to the PIN entry module: > End of file > 2009-09-13 14:24:56 gpg-agent[27662] command get_passphrase failed: No > pinentry > gpg-agent[27662.7] DBG: -> ERR 67108949 No pinentry > gpg-agent[27662.7] DBG: <- [EOF] > > ?? any clues or advice? Does the pinentry-qt4 binary work on the command line, aka ./pinentry-qt4 GETPIN BYE -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From rdieter at math.unl.edu Wed Sep 16 14:34:29 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 16 Sep 2009 07:34:29 -0500 Subject: pinentry-qt4 In-Reply-To: <200909161358.54782.bernhard@intevation.de> References: <200909161358.54782.bernhard@intevation.de> Message-ID: <4AB0DB55.5010905@math.unl.edu> Bernhard Reiter wrote: >> Anyone having luck getting pinentry-qt4 to work? ... >> 2009-09-13 14:24:55 gpg-agent[27662] starting a new PIN Entry >> gpg-agent[27662]: can't connect server: ec=4.16383 >> 2009-09-13 14:24:56 gpg-agent[27662] can't connect to the PIN entry module: >> End of file >> 2009-09-13 14:24:56 gpg-agent[27662] command get_passphrase failed: No >> pinentry >> gpg-agent[27662.7] DBG: -> ERR 67108949 No pinentry >> gpg-agent[27662.7] DBG: <- [EOF] >> >> ?? any clues or advice? > > Does the pinentry-qt4 binary work on the command line, aka > ./pinentry-qt4 > GETPIN > BYE This part works. the gpg-agent "can't connect server", "can't connect to the PIN entry module" errors are the odd ones here it seems. Any other advice on finding where the gpg-agent+pinentry-qt4 combo goes wrong? -- Rex From bernhard at intevation.de Thu Sep 17 11:05:29 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 17 Sep 2009 11:05:29 +0200 Subject: pinentry-qt4 In-Reply-To: <4AB0DB55.5010905@math.unl.edu> References: <200909161358.54782.bernhard@intevation.de> <4AB0DB55.5010905@math.unl.edu> Message-ID: <200909171105.29629.bernhard@intevation.de> Am Mittwoch, 16. September 2009 14:34:29 schrieb Rex Dieter: > > Does the pinentry-qt4 binary work on the command line, aka > > ./pinentry-qt4 > > GETPIN > > BYE > > This part works. Oh, good. > the gpg-agent "can't connect server", "can't connect to the PIN entry > module" errors are the odd ones here it seems. > > Any other advice on finding where the gpg-agent+pinentry-qt4 combo goes > wrong? You can try setting GPGMEDEBUG. Make sure the gpg-agent.conf has the right debugging options and pinentry configuration. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From stefan.lorenz at stud.uni-saarland.de Thu Sep 17 14:54:23 2009 From: stefan.lorenz at stud.uni-saarland.de (Stefan Lorenz) Date: Thu, 17 Sep 2009 14:54:23 +0200 Subject: Experimental Algorithms again Message-ID: <4AB2317F.3010003@stud.uni-saarland.de> Hello, I am sorry for posting again, but we didn't find a solution to the problem yet and didn't get any responses so far. The main question is, whether it is possible, maybe using the Algorithm type 100 (experimental), to attach own (key)data for an additional algorithm, to an existing gpg key, or to import it into the keyring as a standalone key. So far we achieved importing a key with experimental algorithm type into the keyring, however we could not construct a valid self-signed UID packet. We appreciate any hints on whether this is possible at all and if so, how. Best, Stefan From wk at gnupg.org Mon Sep 21 10:03:40 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Sep 2009 10:03:40 +0200 Subject: GPG User ID Comments and RFC 5322 In-Reply-To: <6e7da8720909131004w6d0be2fdx837335321676164e@mail.gmail.com> (Philippe Cerfon's message of "Sun, 13 Sep 2009 19:04:55 +0200") References: <6e7da8720909110654s499a64f7hc9358b16f63c4bfc@mail.gmail.com> <01869ED3-9573-43C5-A194-7EAFD471296D@jabberwocky.com> <6e7da8720909131004w6d0be2fdx837335321676164e@mail.gmail.com> Message-ID: <87iqfc912b.fsf@vigenere.g10code.de> On Sun, 13 Sep 2009 19:04, philcerf at googlemail.com said: >> (The exception is if you put a comment in that says the key is "insecure" or >> "do not use", GPG will believe you) > What if use insecure in another language? Or "non-insecure"? :P > > Apart from all that, I've read some pages of the RFC where it says > User IDs are basically just strings without any special format. So > shouldn't gpg ignore this comment-speciality from emails and just take > it as strings? That is what gpg does. The thing with "(insecure!)", "not secure" or "do not use" in a user id is a hack to detect test keys likely created in a special testing mode using a faked random number generator. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Sep 21 10:11:56 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Sep 2009 10:11:56 +0200 Subject: Experimental Algorithms again In-Reply-To: <4AB2317F.3010003@stud.uni-saarland.de> (Stefan Lorenz's message of "Thu, 17 Sep 2009 14:54:23 +0200") References: <4AB2317F.3010003@stud.uni-saarland.de> Message-ID: <87ab0o90oj.fsf@vigenere.g10code.de> On Thu, 17 Sep 2009 14:54, stefan.lorenz at stud.uni-saarland.de said: > The main question is, whether it is possible, maybe using the > Algorithm type 100 (experimental), to attach own (key)data for an > additional algorithm, to an existing gpg key, or to import it into the > keyring as a standalone key. So far we achieved importing a key with > experimental algorithm type into the keyring, however we could not > construct a valid self-signed UID packet. We appreciate any hints on You need to fully implement the new algorithm. Obviously you missed something. The description you posted is not sufficient to help you. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Sep 21 10:15:05 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Sep 2009 10:15:05 +0200 Subject: GnuPG 2 does not import older keys with RSA-E and RSA-S anymore In-Reply-To: <200909161150.58875.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 16 Sep 2009 11:50:58 +0200") References: <200909161150.58875.bernhard@intevation.de> Message-ID: <8763bc90ja.fsf@vigenere.g10code.de> On Wed, 16 Sep 2009 11:50, bernhard at intevation.de said: > following algorithms anymore: > 2 - RSA Encrypt-Only [HAC] > 3 - RSA Sign-Only [HAC] > rfc4880 notes: > Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be > generated, but may be interpreted. I have not seen such keys for years. Software used to create such keys most likely also used MD5 as a hash algorithm and thus these keys should be considered broken. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Tue Sep 22 14:36:00 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 22 Sep 2009 14:36:00 +0200 Subject: GnuPG 2 does not import older keys with RSA-E and RSA-S anymore In-Reply-To: <8763bc90ja.fsf@vigenere.g10code.de> References: <200909161150.58875.bernhard@intevation.de> <8763bc90ja.fsf@vigenere.g10code.de> Message-ID: <200909221436.01321.bernhard@intevation.de> Am Montag, 21. September 2009 10:15:05 schrieb Werner Koch: > On Wed, 16 Sep 2009 11:50, bernhard at intevation.de said: > > following algorithms anymore: ? ? > > ? ? ? 2 ? ? ? ? ?- RSA Encrypt-Only [HAC] > > ? ? ? 3 ? ? ? ? ?- RSA Sign-Only [HAC] > > rfc4880 notes: > > ? ?Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be > > ? ?generated, but may be interpreted. > > I have not seen such keys for years. ?Software used to create such keys > most likely also used MD5 as a hash algorithm and thus these keys should > be considered broken. Wouldn't it better to say so then instead of "unknown"? I've created the following issue about it: https://bugs.g10code.com/gnupg/issue1139 -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kevhilton at gmail.com Sat Sep 26 14:54:44 2009 From: kevhilton at gmail.com (Kevin Hilton) Date: Sat, 26 Sep 2009 07:54:44 -0500 Subject: libassuan Message-ID: <96c450350909260554i3570b9c9wf0bbd9fa607b6b0@mail.gmail.com> Attempted compiling gnupg2 svn 5163 this am on ubuntu -- getting this error: configure: *** *** You need libassuan with Pth support to build this program. *** This library is for example available at *** ftp://ftp.gnupg.org/gcrypt/libassuan/ *** (at least version 1.1.0 (API 2) is required). *** configure: error: *** *** Required libraries not found. Please consult the above messages *** and install them before running configure again. *** I currently have only libassuan 1.0.5 installed and the program is asking for 1.1.0. When visiting the ftp site as referenced above, the latest version is only 1.0.5. Where do I get 1.1.0 or is this an error? -- Kevin Hilton From wk at gnupg.org Sat Sep 26 20:09:57 2009 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Sep 2009 20:09:57 +0200 Subject: libassuan In-Reply-To: <96c450350909260554i3570b9c9wf0bbd9fa607b6b0@mail.gmail.com> (Kevin Hilton's message of "Sat, 26 Sep 2009 07:54:44 -0500") References: <96c450350909260554i3570b9c9wf0bbd9fa607b6b0@mail.gmail.com> Message-ID: <87vdj5r30q.fsf@vigenere.g10code.de> On Sat, 26 Sep 2009 14:54, kevhilton at gmail.com said: > I currently have only libassuan 1.0.5 installed and the program is > asking for 1.1.0. When visiting the ftp site as referenced above, the > latest version is only 1.0.5. Where do I get 1.1.0 or is this an > error? I should have announced it. GnuPG 2.0 is now on branches/STABLE-BRANCH-2-0 . Trunk is used for GnuPG 2.1 development which is in an very early stage. Use svn switch to change to the 2.0 branch. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Sat Sep 26 20:15:50 2009 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Sep 2009 20:15:50 +0200 Subject: GnuPG 2.0 SVN moved to a new branch Message-ID: <87r5ttr2qx.fsf@vigenere.g10code.de> Hi, I recently created a new branch for GnuPG 2.0. svn://cvs.gnupg.org/gnupg/branches/STABLE-BRANCH-2-0 is what you want. Use svn switch to update a current working copy. Development continues on the trunk but as of now it is to early to follow that; for example you need the latest version of libassuan which has not yet been released and its API changed in the course of changing it to a DSO. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From klaus at flittner.org Sun Sep 27 00:50:18 2009 From: klaus at flittner.org (Klaus Flittner) Date: Sun, 27 Sep 2009 00:50:18 +0200 Subject: Length of public exponent in OpenPGP card specification Message-ID: <20090927005018.652067b9@moon> Hello, in the specification[1] the algorithm attributes contain a field for the length of the public exponent. The available implementation of the card[2] has a fixed value of 32 bits, but key import accepts a value of 65537 (17 bits) and key generation also produces only keys with e of 65537. What is the use of this field then? Regards Klaus Flittner [1] http://www.g10code.com/docs/openpgp-card-2.0.pdf [2] http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=42 From kevhilton at gmail.com Sun Sep 27 07:25:41 2009 From: kevhilton at gmail.com (Kevin Hilton) Date: Sun, 27 Sep 2009 00:25:41 -0500 Subject: libassuan In-Reply-To: <87vdj5r30q.fsf@vigenere.g10code.de> References: <96c450350909260554i3570b9c9wf0bbd9fa607b6b0@mail.gmail.com> <87vdj5r30q.fsf@vigenere.g10code.de> Message-ID: <96c450350909262225q626c9dccm6e0c7cafb959c73e@mail.gmail.com> Its obvious I dont know a lot about svn, however I used the svn switch command to switch repositories, but I'm still getting the libassuan error about wanting 1.1.0 version. Maybe I should just check out the archive from scratch since doing the switch command for me was a complete bust! From wk at gnupg.org Sun Sep 27 13:04:35 2009 From: wk at gnupg.org (Werner Koch) Date: Sun, 27 Sep 2009 13:04:35 +0200 Subject: libassuan In-Reply-To: <96c450350909262225q626c9dccm6e0c7cafb959c73e@mail.gmail.com> (Kevin Hilton's message of "Sun, 27 Sep 2009 00:25:41 -0500") References: <96c450350909260554i3570b9c9wf0bbd9fa607b6b0@mail.gmail.com> <87vdj5r30q.fsf@vigenere.g10code.de> <96c450350909262225q626c9dccm6e0c7cafb959c73e@mail.gmail.com> Message-ID: <87my4gr6m4.fsf@vigenere.g10code.de> On Sun, 27 Sep 2009 07:25, kevhilton at gmail.com said: > Its obvious I dont know a lot about svn, however I used the svn switch > command to switch repositories, but I'm still getting the libassuan > error about wanting 1.1.0 version. Maybe I should just check out the Run ./autogen.sh --force before you run configure. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Sun Sep 27 13:06:37 2009 From: wk at gnupg.org (Werner Koch) Date: Sun, 27 Sep 2009 13:06:37 +0200 Subject: Length of public exponent in OpenPGP card specification In-Reply-To: <20090927005018.652067b9@moon> (Klaus Flittner's message of "Sun, 27 Sep 2009 00:50:18 +0200") References: <20090927005018.652067b9@moon> Message-ID: <87iqf4r6iq.fsf@vigenere.g10code.de> On Sun, 27 Sep 2009 00:50, klaus at flittner.org said: > in the specification[1] the algorithm attributes contain a field for > the length of the public exponent. The available implementation of the > card[2] has a fixed value of 32 bits, but key import accepts a value of > 65537 (17 bits) and key generation also produces only keys with e of > 65537. What is the use of this field then? It is the size of the variable describing the length of the exponent. For example you need 17 bits to express 65537, thus it first easily into 32 bits. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Tue Sep 29 09:46:16 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 29 Sep 2009 09:46:16 +0200 Subject: SHA2 in OpenPGP cards? Message-ID: <87y6nykxbr.fsf@mocca.josefsson.org> Hi! Before I spend time testing it, can the OpenPGP card support RSA-SHA2 signatures? /Simon From wk at gnupg.org Tue Sep 29 13:38:00 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Sep 2009 13:38:00 +0200 Subject: SHA2 in OpenPGP cards? In-Reply-To: <87y6nykxbr.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 29 Sep 2009 09:46:16 +0200") References: <87y6nykxbr.fsf@mocca.josefsson.org> Message-ID: <87my4e56cn.fsf@vigenere.g10code.de> On Tue, 29 Sep 2009 09:46, simon at josefsson.org said: > Hi! Before I spend time testing it, can the OpenPGP card support > RSA-SHA2 signatures? The v2 cards support any hash agorithm as long as they fit into pkcs#1. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Wed Sep 30 14:19:43 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 30 Sep 2009 14:19:43 +0200 Subject: SHA2 in OpenPGP cards? In-Reply-To: <87my4e56cn.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 29 Sep 2009 13:38:00 +0200") References: <87y6nykxbr.fsf@mocca.josefsson.org> <87my4e56cn.fsf@vigenere.g10code.de> Message-ID: <87k4zg4obk.fsf@mocca.josefsson.org> Werner Koch writes: > On Tue, 29 Sep 2009 09:46, simon at josefsson.org said: >> Hi! Before I spend time testing it, can the OpenPGP card support >> RSA-SHA2 signatures? > > The v2 cards support any hash agorithm as long as they fit into pkcs#1. Ok thanks. Is there any problem sending the future SHA-3 hashes in the PKCS#1 struct too? Does the smartcard validate the PKCS#1 data in any way before signing it? I'm thinking also of the ad-hoc MD5/SHA1 data used by TLS, it doesn't follow PKCS#1 format. /Simon From wk at gnupg.org Wed Sep 30 16:00:46 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Sep 2009 16:00:46 +0200 Subject: SHA2 in OpenPGP cards? In-Reply-To: <87k4zg4obk.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 30 Sep 2009 14:19:43 +0200") References: <87y6nykxbr.fsf@mocca.josefsson.org> <87my4e56cn.fsf@vigenere.g10code.de> <87k4zg4obk.fsf@mocca.josefsson.org> Message-ID: <878wfw5y7l.fsf@vigenere.g10code.de> On Wed, 30 Sep 2009 14:19, simon at josefsson.org said: > PKCS#1 struct too? Does the smartcard validate the PKCS#1 data in any > way before signing it? I'm thinking also of the ad-hoc MD5/SHA1 data > used by TLS, it doesn't follow PKCS#1 format. With the old cards the use of MD5/SHA1 was only possible with the authentication key but not with the signature key. The v2 new cards uses the relaxed check also for the signature key: In compliance with PKSC #1, the card checks that the DigestInfo in the command data field is not longer than 40% of the length of the modulus of the signature key, otherwise the command is rejected. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.