From wk at gnupg.org Wed May 1 12:18:43 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 May 2013 12:18:43 +0200 Subject: [Announce] GPA 0.9.4 released Message-ID: <87wqrjq9z0.fsf@vigenere.g10code.de> Hello! We are pleased to announce GPA version 0.9.4. GPA is a graphical frontend for the GNU Privacy Guard (GnuPG, http://www.gnupg.org). GPA can be used to encrypt, decrypt, and sign files, to verify signatures and to manage the private and public keys. You can find the release here: ftp://ftp.gnupg.org/gcrypt/gpa/gpa-0.9.4.tar.bz2 (713k) ftp://ftp.gnupg.org/gcrypt/gpa/gpa-0.9.4.tar.bz2.sig and soon on all ftp.gnupg.org mirrors. A binary version for Windows will soon be released as part of Gpg4win 2.1.1; see http://gpg4win.org. The SHA1 checksum for this release is: d4b22b6d1f0ce25244c5a001e3bcbc36aff13ecf gpa-0.9.4.tar.bz2 Noteworthy changes in version 0.9.4 (2013-05-01) ------------------------------------------------ * Added scrollbars to the verification result window. * Improved searching in the key listing. * Now uses the native theme under Windows. * The usual collecton of minor bug fixes. If you want to contribute to the development of GPA, please subscribe to the gnupg-devel mailing list [1] and read the file doc/HACKING. The driving force behind the development of GPA is my company g10 Code. Maintenance and improvement of GnuPG and related software, such as GPA, takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Shalom-Salam, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 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 Wed May 1 14:37:31 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 May 2013 14:37:31 +0200 Subject: [Announce] GPGME 1.4.1 released Message-ID: <87sj26ri44.fsf@vigenere.g10code.de> Hello! I am pleased to announce version 1.4.1 of GPGME. GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines as included in GnuPG easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification and key management. Noteworthy changes in version 1.4.1 (2013-05-01) * Fixed reading of gpg.conf files with excessive use of the group option. This fixes problems using the settings dialog of GPA, Kleopatra and possible other GnuPG frontends. * Fixed building with the i686-w64-mingw32 toolchain. * Disabled FD passing by default for Apple. You may download this library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.1.tar.bz2 (936k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.1.tar.bz2.sig GZIP compressed tarballs are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.1.tar.gz (1185k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.1.tar.gz.sig As an alternative you may use a patch file to upgrade the previous version of the library: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.0-1.4.1.diff.bz2 (7k) SHA-1 checksums are: d6110763e7459214fd72705e87ebc682e3b5815e gpgme-1.4.1.tar.bz2 db5b2df70319d92711cb733ef3ee5258c14e7694 gpgme-1.4.1.tar.gz 4120127f68cfbab64f3447ec0dfa1f3484d3f693 gpgme-1.4.0-1.4.1.diff.bz2 Please send questions regarding the use of GPGME to the gnupg-devel mailing list: http://lists.gnupg.org/mailman/listinfo/gnupg-devel If you need commercial support, you may want to consult this listing: http://www.gnupg.org/service.html The driving force behind the development of the GnuPG system is my company g10 Code. Maintenance and improvement of GnuPG and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Happy hacking, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 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 hans at guardianproject.info Thu May 2 22:34:27 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 02 May 2013 16:34:27 -0400 Subject: how to debug --gen-key on Android Message-ID: <5182CDD3.2010308@guardianproject.info> Hey all, We are just finishing up a CLI-version of GnuPG for Android to put into the Play Store for an alpha release. We have all the key parts working except --gen-key. The setup process works fine, but once it starts generating, it never seems to get any entropy. I left one overnight and it never printed a single dot even. Abel and I checked /dev/random and there are bytes coming in. We also checked /proc/sys/kernel/random/entropy_avail and there are bytes available. Any ideas on where to start here? We have importing of secret keys working fine. .hc From wk at gnupg.org Fri May 3 01:33:47 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 May 2013 01:33:47 +0200 Subject: how to debug --gen-key on Android In-Reply-To: <5182CDD3.2010308@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 02 May 2013 16:34:27 -0400") References: <5182CDD3.2010308@guardianproject.info> Message-ID: <87mwsdot2c.fsf@vigenere.g10code.de> On Thu, 2 May 2013 22:34, hans at guardianproject.info said: > --gen-key. The setup process works fine, but once it starts generating, it > never seems to get any entropy. I left one overnight and it never printed a > single dot even. Is there another process draining entropy; i.e. are there any other processes reading from /dev/random or /dev/urandom? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Fri May 3 12:36:02 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 3 May 2013 12:36:02 +0200 Subject: Fwd: [Gpg4win-devel] Wiki for GnuPG/Gpg4win Message-ID: <201305031236.08402.bernhard@intevation.de> Message below was probably stuck in moderation. -------------- next part -------------- An embedded message was scrubbed... From: Emanuel =?iso-8859-1?q?Sch=FCtze?= Subject: [Gpg4win-devel] Wiki for GnuPG/Gpg4win Date: Wed, 10 Apr 2013 12:38:42 +0200 Size: 4983 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From x-alina at gmx.net Fri May 3 16:23:55 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Fri, 03 May 2013 16:23:55 +0200 Subject: REINER SCT Message-ID: <1367591035.3929.26.camel@e525.x-alina.name> This patch here: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blobdiff;f=scd/ccid-driver.c;h=42a219f273500deac3731454e0779b712dde733e;hp=c3a66fafecfc8e4be23d158f6654c5bfe6e4e18c;hb=145d672fbf6d528f57cc3987238e380a9acbbd20;hpb=40ca0022a7035ce5c3d715f36e0c70f310ea4c61 REINER SCT sell many card readers that are not CCID-compliant. The cyberJack go is the big exception. So better test for the device id, too. Regards Alina From x-alina at gmx.net Sat May 4 00:37:27 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Sat, 04 May 2013 00:37:27 +0200 Subject: REINER SCT In-Reply-To: <1367591035.3929.26.camel@e525.x-alina.name> References: <1367591035.3929.26.camel@e525.x-alina.name> Message-ID: <1367620647.3932.23.camel@e525.x-alina.name> NIIBE Yutaka, do you write a patch or should I do? Am Freitag, den 03.05.2013, 16:23 +0200 schrieb Alina Friedrichsen: > This patch here: > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blobdiff;f=scd/ccid-driver.c;h=42a219f273500deac3731454e0779b712dde733e;hp=c3a66fafecfc8e4be23d158f6654c5bfe6e4e18c;hb=145d672fbf6d528f57cc3987238e380a9acbbd20;hpb=40ca0022a7035ce5c3d715f36e0c70f310ea4c61 > > REINER SCT sell many card readers that are not CCID-compliant. > The cyberJack go is the big exception. > > So better test for the device id, too. > > Regards > Alina > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From gniibe at fsij.org Sat May 4 06:24:22 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 04 May 2013 13:24:22 +0900 Subject: REINER SCT In-Reply-To: <1367620647.3932.23.camel@e525.x-alina.name> References: <1367591035.3929.26.camel@e525.x-alina.name> <1367620647.3932.23.camel@e525.x-alina.name> Message-ID: <1367641462.3316.3.camel@cfw2.gniibe.org> On 2013-05-04 at 00:37 +0200, Alina Friedrichsen wrote: > NIIBE Yutaka, do you write a patch or should I do? If it's really needed please write for master. If something is needed I will write for 2.0. > REINER SCT sell many card readers that are not CCID-compliant. > The cyberJack go is the big exception. > > So better test for the device id, too. I understand that it would be better testing device id, ideally (or documentation purpose). But, is it really needed for this _specific_ case? Do you have a some specific scenario, where current code would cause some trouble? The portion of the code will be only executed when it's CCID-compliant. I think that there is no need to distinguish non-CCID device here. -- From x-alina at gmx.net Sat May 4 07:12:54 2013 From: x-alina at gmx.net (Alina Friedrichsen) Date: Sat, 04 May 2013 07:12:54 +0200 Subject: REINER SCT In-Reply-To: <1367641462.3316.3.camel@cfw2.gniibe.org> References: <1367591035.3929.26.camel@e525.x-alina.name> <1367620647.3932.23.camel@e525.x-alina.name> <1367641462.3316.3.camel@cfw2.gniibe.org> Message-ID: <1367644374.3932.47.camel@e525.x-alina.name> It's really needed. The following RFID card reader from REINER SCT is CCID-compliant, but has no pinpad. http://www.reiner-sct.com/produkte/chipkartenleser/cyberjack_RFID_basis.html From syn.shainer at gmail.com Sun May 5 17:11:29 2013 From: syn.shainer at gmail.com (Lisa Vitolo) Date: Sun, 5 May 2013 17:11:29 +0200 Subject: looking for keys on a keyserver with gpgme Message-ID: Hello, I have an issue looking for keys on a keyserver. Specifically the listing returned is always empty. This is my code, written with the help of Werner Koch, useless parts removed: gpgme_keylist_mode_t mode = gpgme_get_keylist_mode(ctx); mode &= ~GPGME_KEYLIST_MODE_LOCAL; mode |= GPGME_KEYLIST_MODE_EXTERN; err = gpgme_set_keylist_mode(ctx, mode); err = gpgme_op_keylist_start(ctx, id, 0); /* id is a string */ while (!err) { err = gpgme_op_keylist_next(ctx, &key); if (err) { break; } /* if the KEY has the same ID as the one I'm looking for, proceed... */ } I believe the error is in the second argument of gpgme_op_keylist_start, where I'm asked to provide a search pattern. I'm not sure how patterns work, so I first tried an empty one (which works when I'm listing keys from the local keyring with the same procedure), and then the ID with or without a leading "0x". In both cases the listing stop at the first call to keylist_next with "EOF". The keyserver should be correctly configured: it's in both the global gpg.conf of my user, and in another gpg.conf in the keyring used within this application. What am I doing wrong? :) Thanks everybody, Lisa Vitolo -- 'Listen, Peaches, trickery is what humans are all about,' said the voice of Maurice. 'They're so keen on tricking one another all the time that they elect governments to do it for them.' -- Terry Pratchett From tobias at radolfstrasse.de Sun May 5 18:17:05 2013 From: tobias at radolfstrasse.de (Tobias) Date: Sun, 5 May 2013 18:17:05 +0200 Subject: [PATCH] UTF8 Filenames under Windows Message-ID: <000601ce49ab$fbec84a0$f3c58de0$@radolfstrasse.de> As GnuPG?s command line does not support UTF 16 filenames, all filenames must be encoded in UTF8. With Linux this just works fine, but the Windows Ascii API (CreateFileA) does not support accessing files using UTF8 paths. It just results in a File not found Error. Attached is a patch for the GnuPG 1.4 branch, that converts all paths from UTF8 to UTF16 and pass them to Windows Wide API. It should resolve the issue 1409. Would be great if it would make into one of the next stable versions. Thanks Tobias diff --git a/util/iobuf.c b/util/iobuf.c index 384b966..aedff90 100644 --- a/util/iobuf.c +++ b/util/iobuf.c @@ -242,6 +242,7 @@ direct_open (const char *fname, const char *mode) #ifdef HAVE_DOSISH_SYSTEM unsigned long da, cd, sm; HANDLE hfile; + unsigned short wPath[_MAX_PATH]; /* Note, that we do not handle all mode combinations */ @@ -266,8 +267,9 @@ direct_open (const char *fname, const char *mode) cd = OPEN_EXISTING; sm = FILE_SHARE_READ; } + MultiByteToWideChar(CP_UTF8, 0, fname, -1, wPath, _MAX_PATH); - hfile = CreateFile (fname, da, sm, NULL, cd, FILE_ATTRIBUTE_NORMAL, NULL); + hfile = CreateFileW (wPath, da, sm, NULL, cd, FILE_ATTRIBUTE_NORMAL, NULL); return hfile; #else int oflag; From jeanjacquesbrucker at gmail.com Sun May 5 19:42:48 2013 From: jeanjacquesbrucker at gmail.com (jbar) Date: Sun, 5 May 2013 19:42:48 +0200 Subject: looking for keys on a keyserver with gpgme In-Reply-To: References: Message-ID: <20130505194248.78ce86a1@gmail.com> Also please try to know if hkp request is really send to the keyserver (using wireshark and filtering only request sended to port 11371 for example). I did met a similar issue months ago, and there was not sended hkp request at all. Then I have un-prioritized the features I wanted to code using gpgme like this (i.e. to make my gpgme-hkp keyserver[1] synchronise new or updated keys with peers and some others sks keyservers). [1]: https://github.com/Open-UDC/thttpgpd On Sun, 5 May 2013 17:11:29 +0200 Lisa Vitolo wrote: > Hello, > > I have an issue looking for keys on a keyserver. Specifically the > listing returned is always empty. This is my code, written with the > help of Werner Koch, useless parts removed: > > gpgme_keylist_mode_t mode = gpgme_get_keylist_mode(ctx); > mode &= ~GPGME_KEYLIST_MODE_LOCAL; > mode |= GPGME_KEYLIST_MODE_EXTERN; > err = gpgme_set_keylist_mode(ctx, mode); > > err = gpgme_op_keylist_start(ctx, id, 0); /* id is a string */ > > while (!err) { > err = gpgme_op_keylist_next(ctx, &key); > > if (err) { > break; > } > > /* if the KEY has the same ID as the one I'm looking for, > proceed... */ > } > > I believe the error is in the second argument of > gpgme_op_keylist_start, where I'm asked to provide a search pattern. > I'm not sure how patterns work, so I first tried an empty one (which > works when I'm listing keys from the local keyring with the same > procedure), and then the ID with or without a leading "0x". In both > cases the listing stop at the first call to keylist_next with "EOF". > The keyserver should be correctly configured: it's in both the global > gpg.conf of my user, and in another gpg.conf in the keyring used > within this application. What am I doing wrong? :) > > Thanks everybody, > Lisa Vitolo > > -- > 'Listen, Peaches, trickery is what humans are all about,' said the > voice of Maurice. 'They're so keen on tricking one another all the > time that they elect governments to do it for them.' -- Terry > Pratchett > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From wk at gnupg.org Mon May 6 21:09:10 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 May 2013 21:09:10 +0200 Subject: looking for keys on a keyserver with gpgme In-Reply-To: (Lisa Vitolo's message of "Sun, 5 May 2013 17:11:29 +0200") References: Message-ID: <8738u0ncx5.fsf@vigenere.g10code.de> On Sun, 5 May 2013 17:11, syn.shainer at gmail.com said: > gpgme_op_keylist_start, where I'm asked to provide a search pattern. > I'm not sure how patterns work, so I first tried an empty one (which This is the same syntax you use with gpg. For example: gpg --search-key "Heinrich Heine" Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue May 7 03:23:23 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 07 May 2013 10:23:23 +0900 Subject: REINER SCT In-Reply-To: <1367644374.3932.47.camel@e525.x-alina.name> References: <1367591035.3929.26.camel@e525.x-alina.name> <1367620647.3932.23.camel@e525.x-alina.name> <1367641462.3316.3.camel@cfw2.gniibe.org> <1367644374.3932.47.camel@e525.x-alina.name> Message-ID: <1367889803.3330.3.camel@cfw2.gniibe.org> On 2013-05-04 at 07:12 +0200, Alina Friedrichsen wrote: > It's really needed. The following RFID card reader from REINER SCT is > CCID-compliant, but has no pinpad. > > http://www.reiner-sct.com/produkte/chipkartenleser/cyberjack_RFID_basis.html Thanks for the pointer. You're talking your theory, while I'm explaining the code. Still, there is no need to distinguish them by product ID. That's because the code checks the availability of pinpad, at first. Well, here is the case we would need to distinguish: (1) It is CCID reader and (2) which claims having pinpad (by bPINSupport of dwFeatures) and (3) Different handling is needed I think that it's not good to write many code than needed, because it would bite us in future. -- From abel at guardianproject.info Tue May 7 18:19:02 2013 From: abel at guardianproject.info (Abel Luck) Date: Tue, 07 May 2013 16:19:02 +0000 Subject: using alternate sources of entropy Message-ID: <51892976.4070903@guardianproject.info> Hi, For various reasons we're exploring alternatives to /dev/random on Android. Primarily because it doesn't fill fast enough, and we do not have root access so we cannot write to it. We've one good source of entropy, the accelerometer, that we would like gpg-agent to use. Looking through the docs it appears gnupg supports EGD. EGD would work well, but it is written in perl, which would be a royal PITA to get working on Android. The options I've come up with are: 1) Write an EGD in C or Java 2) Hack gnupg source and add our own thing Neither are particularly attractive. Is there another way to supply gnupg with entropy? ~abel From cswiger at mac.com Tue May 7 20:00:00 2013 From: cswiger at mac.com (Charles Swiger) Date: Tue, 07 May 2013 11:00:00 -0700 Subject: using alternate sources of entropy In-Reply-To: <51892976.4070903@guardianproject.info> References: <51892976.4070903@guardianproject.info> Message-ID: Hi-- On May 7, 2013, at 9:19 AM, Abel Luck wrote: > For various reasons we're exploring alternatives to /dev/random on > Android. Primarily because it doesn't fill fast enough, and we do not > have root access so we cannot write to it. > > We've one good source of entropy, the accelerometer, that we would like > gpg-agent to use. Looking through the docs it appears gnupg supports EGD. > > EGD would work well, but it is written in perl, which would be a royal > PITA to get working on Android. > > The options I've come up with are: > > 1) Write an EGD in C or Java > 2) Hack gnupg source and add our own thing > > Neither are particularly attractive. Is there another way to supply > gnupg with entropy? There's an EGD-compatible, non-blocking C implementation here: http://sourceforge.net/projects/prngd However, I suspect that you'd obtain better results if you looked into replacing the Android aka Linux-derived /dev/random implementation which blocks with a Yarrow-based /dev/random which will not block. Regards, -- -Chuck From pete at petertodd.org Tue May 7 21:24:11 2013 From: pete at petertodd.org (Peter Todd) Date: Tue, 7 May 2013 15:24:11 -0400 Subject: using alternate sources of entropy In-Reply-To: <51892976.4070903@guardianproject.info> References: <51892976.4070903@guardianproject.info> Message-ID: <20130507192411.GA32018@petertodd.org> On Tue, May 07, 2013 at 04:19:02PM +0000, Abel Luck wrote: > Hi, > > For various reasons we're exploring alternatives to /dev/random on > Android. Primarily because it doesn't fill fast enough, and we do not > have root access so we cannot write to it. Actually any user can write to /dev/random and add data to the random pool. What they can't do is update the pool's counters to tell the pool that the bits you added were actually random. > We've one good source of entropy, the accelerometer, that we would like > gpg-agent to use. Looking through the docs it appears gnupg supports EGD. > > EGD would work well, but it is written in perl, which would be a royal > PITA to get working on Android. > > The options I've come up with are: > > 1) Write an EGD in C or Java > 2) Hack gnupg source and add our own thing > > Neither are particularly attractive. Is there another way to supply > gnupg with entropy? If you add the accelerometer data to /dev/random yourself and keep track of how many bits of randomness you've added the hack could be to just point gnupg to /dev/urandom Hard to say if that's better than a different hack though, and assumes Linux doesn't break /dev/urandom or the adding data to the pool mechanism. -- 'peter'[:-1]@petertodd.org 00000000000000505fb168f1b6ff2a07bae5c7539564dbfea5cede4490e78627 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From wk at gnupg.org Tue May 7 22:00:39 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 May 2013 22:00:39 +0200 Subject: [PATCH 0/5] doc: fix some Texinfo warnings In-Reply-To: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> (Ian Abbott's message of "Thu, 25 Apr 2013 12:00:11 +0100") References: <1366887616-18318-1-git-send-email-abbotti@mev.co.uk> Message-ID: <87d2t2mufs.fsf@vigenere.g10code.de> On Thu, 25 Apr 2013 13:00, abbotti at mev.co.uk said: > These five patches fix some warnings from Texinfo 5 by adding some > missing nodes and changing some sections to subsections, and moving an > '@end ifset' to the start of a line. I also noticed the 'Deprecated > options' subsection didn't appear in the GPG options menu, so I added > it. (Texinfo never warned about it because it was after the last node > in the menu.) Thanks. I squashed them into one patch, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From openpgp at brainhub.org Thu May 9 02:33:40 2013 From: openpgp at brainhub.org (Andrey Jivsov) Date: Wed, 08 May 2013 17:33:40 -0700 Subject: How to test my build of gpg2? Message-ID: <518AEEE4.6090607@brainhub.org> I wonder what's the process of running my own build of gpg2? I am getting the error: > gpg: agent_genkey failed: Unsupported certificate > Key generation failed: Unsupported certificate when I generate a default RSA key, as bellow. I think this is where the password dialog would come up. I think I followed all the steps that I did in the past that were needed, but I am getting an error. There used to be a pinentry, but I don't see it being built now, so I didn't do any replacement for the pinentry. The code is the latest from git+ssh://playfair.gnupg.org/git/gnupg Thank you. > /usr/local/gpg2ecc/bin/gpg2 --gen-key > gpg (GnuPG) 2.1.0-beta210; Copyright (C) 2012 Free Software > Foundation, Inc. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > gpg: NOTE: THIS IS A DEVELOPMENT VERSION! > gpg: It is only intended for test purposes and should NOT be > gpg: used in a production environment or with production keys! > Please select what kind of key you want: > (1) RSA and RSA (default) > (2) DSA and Elgamal > (3) DSA (sign only) > (4) RSA (sign only) > Your selection? 1 > RSA keys may be between 1024 and 4096 bits long. > What keysize do you want? (2048) > Requested keysize is 2048 bits > Please specify how long the key should be valid. > 0 = key does not expire > = key expires in n days > w = key expires in n weeks > m = key expires in n months > y = key expires in n years > Key is valid for? (0) > Key does not expire at all > Is this correct? (y/N) y > > GnuPG needs to construct a user ID to identify your key. > > Real name: testrsa > Email address: > Comment: > You selected this USER-ID: > "testrsa" > > Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O > 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: agent_genkey failed: Unsupported certificate > Key generation failed: Unsupported certificate I launched my own version of the agent: > andrey at sandy gnupg $ ./agent/gpg-agent --daemon --write-env-file > ./gpg-agent-info --enable-ssh-support --debug-all > --allow-preset-passphrase --verbose --log-file ./gpg-agent-verbose.log > gpg-agent[14011]: NOTE: no default option file > '/home/andrey/.gnupg/gpg-agent.conf' > gpg-agent[14011]: enabled debug flags: command mpi crypto memory cache > memstat hashing assuan > GPG_AGENT_INFO=/home/andrey/.gnupg/S.gpg-agent:14012:1; export > GPG_AGENT_INFO; > SSH_AUTH_SOCK=/home/andrey/.gnupg/S.gpg-agent.ssh; export SSH_AUTH_SOCK; I made sure that the libraries that I built are used: > andrey at sandy gnupg $ ldd /usr/local/gpg2ecc/bin/gpg2 > linux-vdso.so.1 => (0x00007fff74c7f000) > libz.so.1 => /lib64/libz.so.1 (0x00007f0c294e4000) > libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f0c292d3000) > libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f0c290ba000) > libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f0c28e75000) > libgcrypt.so.20 => /usr/local/gpg2ecc/lib/libgcrypt.so.20 > (0x00007f0c28bb3000) > libgpg-error.so.0 => /usr/local/gpg2ecc/lib/libgpg-error.so.0 > (0x00007f0c289af000) > libksba.so.8 => /usr/local/gpg2ecc/lib/libksba.so.8 > (0x00007f0c2877a000) > libassuan.so.0 => /usr/local/gpg2ecc/lib/libassuan.so.0 > (0x00007f0c28566000) > libc.so.6 => /lib64/libc.so.6 (0x00007f0c281af000) > libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f0c27f86000) > /lib64/ld-linux-x86-64.so.2 (0x00007f0c29723000) gpg-agent-verbose.log contains entries like: > 2013-05-08 16:26:59 gpg-agent[20517] handler 0x7fe91fa08700 for fd 7 > terminated > 2013-05-08 16:27:59 gpg-agent[20517] handler 0x7fe920209700 for fd 7 > started > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_7 -> OK Pleased to meet > you, process 20517 > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_6 <- OK Pleased to meet > you, process 20517 > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_6 -> GETINFO pid > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_7 <- GETINFO pid > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_7 -> D 20517 > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_7 -> OK > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_6 <- D 20517 > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_6 <- OK > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_6 -> BYE > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_7 <- BYE > 2013-05-08 16:27:59 gpg-agent[20517] DBG: chan_7 -> OK closing connection From gniibe at fsij.org Thu May 9 03:55:45 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 09 May 2013 10:55:45 +0900 Subject: How to disable gnome-keyring (was: How to test my build of gpg2?) In-Reply-To: <518AEEE4.6090607@brainhub.org> References: <518AEEE4.6090607@brainhub.org> Message-ID: <1368064545.5004.0.camel@cfw2.gniibe.org> On 2013-05-08 at 17:33 -0700, Andrey Jivsov wrote: > I am getting the error: > > gpg: agent_genkey failed: Unsupported certificate > > Key generation failed: Unsupported certificate If I guess correctly from the error messages, I think that it is GNOME keyring which runs as gpg-agent on your system. Please check your GPG_AGENT_INFO to see which process runs as gpg-agent. It should be real gpg-agent. In my environment with GNOME 3, I disable GNOME keyring's feature of gpg-agent by invoking: $ gnome-session-properties and uncheck "GPG Password Agent" and "SSH Key Agent" buttons. That's because gpg-agent is more than "GPG Password Agent" now. In the days with GNOME 2, we could just kill GNOME keyring, but newer version is now integrated to desktop (such as wifi secrets, etc.), thus, we can't simply kill it. -- From hans at guardianproject.info Thu May 9 16:27:48 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 09 May 2013 10:27:48 -0400 Subject: GnuPG Command line: now in the Play Store! Message-ID: <518BB264.1050305@guardianproject.info> https://play.google.com/store/apps/details?id=info.guardianproject.gpg This alpha release of our command-line developer tool brings GnuPG to Android for the first time! GNU Privacy Guard Command-Line (gpgcli) gives you command line access to the entire GnuPG suite of encryption software. GPG is GNU?s tool for end-to-end secure communication and encrypted data storage. This trusted protocol is the free software alternative to PGP. GnuPG 2.1 is the new modularized version of GnuPG that now supports OpenPGP and S/MIME. ***Setup*** Before using gpgcli, be sure to launch the app and let it finish its installation process. Once it has completed, then you're ready to use it. The easiest way to get started with gpgcli is to install Android Terminal Emulator. gpgcli will automatically configure Android Terminal Emulator as long as you have the "Allow PATH extensions" settings enabled. Get the Android Terminal Emulator at https://play.google.com/store/apps/details?id=jackpal.androidterm ***Please Report Bugs*** This is an early release of a big project, so there will inevitable be bugs. Help us improve this software by filing bug reports about any problem that you encounter. Feature requests are also welcome! https://dev.guardianproject.info/projects/gpgandroid/issues ***Coming Soon*** ? SECURITY FOR APPS: We have an API in the works so that developers can easily embed this into any app to give it state of the art security features. ? GUI: We?re building a graphical user interface for easy key management. ? STAY UP TO DATE: Sign up for our low-traffic Guardian-Dev mailing list to be notified when the API and GUI are released: https://lists.mayfirst.org/mailman/listinfo/guardian-dev. ? Find us in IRC, we want feedback! irc://irc.freenode.net/guardianproject irc://irc.oftc.net/guardianproject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 939 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Thu May 9 16:24:46 2013 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 09 May 2013 16:24:46 +0200 Subject: How to test my build of gpg2? In-Reply-To: <518AEEE4.6090607@brainhub.org> References: <518AEEE4.6090607@brainhub.org> Message-ID: <518BB1AE.1080408@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/09/2013 02:33 AM, Andrey Jivsov wrote: > I wonder what's the process of running my own build of gpg2? > Hi Andrey, .. >> gpg-agent[14011]: enabled debug flags: command mpi crypto memory >> cache memstat hashing assuan >> GPG_AGENT_INFO=/home/andrey/.gnupg/S.gpg-agent:14012:1; export >> GPG_AGENT_INFO; >> SSH_AUTH_SOCK=/home/andrey/.gnupg/S.gpg-agent.ssh; export >> SSH_AUTH_SOCK; > Did you make sure to include these env variables in your environment, e.g. using eval $(cat .gpg-agent-info ) ? - -- - ---------------------------- Kristian Fiskerstrand Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Carpe noctem Seize the night -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta210 (GNU/Linux) iQIcBAEBCAAGBQJRi7GuAAoJEAt/i2Dj7frjE3cP/jr90NuhNIYZeuVljJ71VFV6 nB3UBI1D6RQ94uZKE6Mg5/03XPNOxjU/NsD8J+DLmXmWdI1w7pLWH3eUZ8X6PNAp f+cZ+iiQ7porrnIDe0zurhr8lqSs8jqGEPZIOT0egCnC7TelmeWKi5ml0Wk1yXk9 L/j7ykOcueW+5tn7KuTSIGmmIds4t+JFJMRTElZHk+3qIEaEIzZ62YdW4KPODHn3 56QErnsVmDQO9hAFw0cS4BDJ4GfAly56IkbwvMNuhsyBDZgofgw3Be3Je69X7uWF wUbOg2cclK0ZTpN02xQ5KyDayfUwoPrordFBjDiLVDxom1tEqFJxC414SZ0V61NV eY185LxGwPwOJ7n0QCkZbDUWKK3r7U0hrpqYVWiVHMZwi0TZOtNv/p6BNQpciAaB PO4M8EUUHjIUe1Cfx0JAmA7FboSzRzkEm00xeVe+bUDK3Ra7h+0F0DmabQXAIKrt wt1pRziIeDStFi6HOeQXO0n3BlCHlTtOVOKxj+rB1Nb+HWAxVe9IJj/91PxkFW4X Y81wHJMFGr0qAoMHQbbFG2/BjsghYTipIjq7mLjw7NupS3GQu37dc65XXQu61ITu KljMZdjY/8JJWi8ckpBVqZGggXX/276H+9ufT35WTNT6qkZpnE1nbj0LYAbhmzI6 N2YOmHYx1ZYXHXhCfwBv =WmtG -----END PGP SIGNATURE----- From hans at guardianproject.info Thu May 9 19:43:23 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 09 May 2013 13:43:23 -0400 Subject: how to debug --gen-key on Android In-Reply-To: <87mwsdot2c.fsf@vigenere.g10code.de> References: <5182CDD3.2010308@guardianproject.info> <87mwsdot2c.fsf@vigenere.g10code.de> Message-ID: <518BE03B.9090106@guardianproject.info> Turns out it was an issue in our pinentry-android implementation that just made it look like the generation process was taking forever. .hc On 05/02/2013 07:33 PM, Werner Koch wrote: > On Thu, 2 May 2013 22:34, hans at guardianproject.info said: > >> --gen-key. The setup process works fine, but once it starts generating, it >> never seems to get any entropy. I left one overnight and it never printed a >> single dot even. > > Is there another process draining entropy; i.e. are there any other > processes reading from /dev/random or /dev/urandom? > > > Shalom-Salam, > > Werner > > From abel at guardianproject.info Thu May 9 21:11:18 2013 From: abel at guardianproject.info (Abel Luck) Date: Thu, 09 May 2013 19:11:18 +0000 Subject: how to debug --gen-key on Android In-Reply-To: <87mwsdot2c.fsf@vigenere.g10code.de> References: <5182CDD3.2010308@guardianproject.info> <87mwsdot2c.fsf@vigenere.g10code.de> Message-ID: <518BF4D6.4000501@guardianproject.info> I can't seem to get log_[info,error] output from libgrcrypt when debugging the genkey code in agent. Is there a way to make gpg-agent setup libgcrypt to use the same --log-file as itself? ~abel Werner Koch: > On Thu, 2 May 2013 22:34, hans at guardianproject.info said: > >> --gen-key. The setup process works fine, but once it starts generating, it >> never seems to get any entropy. I left one overnight and it never printed a >> single dot even. > > Is there another process draining entropy; i.e. are there any other > processes reading from /dev/random or /dev/urandom? > > > Shalom-Salam, > > Werner > > From openpgp at brainhub.org Thu May 9 22:30:54 2013 From: openpgp at brainhub.org (Andrey Jivsov) Date: Thu, 09 May 2013 13:30:54 -0700 Subject: How to test my build of gpg2? In-Reply-To: <518BB1AE.1080408@sumptuouscapital.com> References: <518AEEE4.6090607@brainhub.org> <518BB1AE.1080408@sumptuouscapital.com> Message-ID: <518C077E.2060000@brainhub.org> On 05/09/2013 07:24 AM, Kristian Fiskerstrand wrote: > Did you make sure to include these env variables in your environment, > e.g. using > eval $(cat .gpg-agent-info ) > ? That was it. Thank you, Kristian. From openpgp at brainhub.org Fri May 10 00:00:01 2013 From: openpgp at brainhub.org (Andrey Jivsov) Date: Thu, 09 May 2013 15:00:01 -0700 Subject: Change to generate compliant keys for compact representation. Message-ID: <518C1C61.2050607@brainhub.org> Greetings. I updated cipher/ecc.c in libgcrypt so that GnuPG generates only compliant keys that would allow the easiest compact representation, according to http://tools.ietf.org/html/draft-jivsov-ecc-compact. AKAIK, there is no reason to not to take this change. It doesn't affect anything else right now, doesn't change anything about compact representation. It only enables the easiest and the most efficient ECC point representation that can be implemented in the future. I am planning to write a spec on how to do compact point representation in OpenPGP. It's mostly needed for encrypted messages (sent to a large number of recipients), but is also valuable for anybody who cares about ultra-compact key size. OpenPGP offers very lean encoding format and so that if one's goal is to have the smallest public key, OpenPGP encoding is probably the best choice. Thank you. From wk at gnupg.org Fri May 10 08:21:27 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 May 2013 08:21:27 +0200 Subject: how to debug --gen-key on Android In-Reply-To: <518BF4D6.4000501@guardianproject.info> (Abel Luck's message of "Thu, 09 May 2013 19:11:18 +0000") References: <5182CDD3.2010308@guardianproject.info> <87mwsdot2c.fsf@vigenere.g10code.de> <518BF4D6.4000501@guardianproject.info> Message-ID: <877gj7l5i0.fsf@vigenere.g10code.de> On Thu, 9 May 2013 21:11, abel at guardianproject.info said: > I can't seem to get log_[info,error] output from libgrcrypt when > debugging the genkey code in agent. > > Is there a way to make gpg-agent setup libgcrypt to use the same > --log-file as itself? It does by calling setup_libgcrypt_logging quite early. If you are looking for progress output, it is indeed not enabled. gpg has provisions to handle PROGRESS status messages, but none are coming for libgcrypt. Thus we need to call gcry_set_progress_handler also in gpg-agent with a handler to emit PROGRESS status lines. I'll look into this later the day. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri May 10 09:28:55 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 May 2013 09:28:55 +0200 Subject: using alternate sources of entropy In-Reply-To: <20130507192411.GA32018@petertodd.org> (Peter Todd's message of "Tue, 7 May 2013 15:24:11 -0400") References: <51892976.4070903@guardianproject.info> <20130507192411.GA32018@petertodd.org> Message-ID: <8738tvl2dk.fsf@vigenere.g10code.de> On Tue, 7 May 2013 21:24, pete at petertodd.org said: > If you add the accelerometer data to /dev/random yourself and keep track > of how many bits of randomness you've added the hack could be to just You are not able to track this because you can't have an estimation on many bytes other processes are reading from /dev/{u,}random. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri May 10 09:38:00 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 May 2013 09:38:00 +0200 Subject: using alternate sources of entropy In-Reply-To: <51892976.4070903@guardianproject.info> (Abel Luck's message of "Tue, 07 May 2013 16:19:02 +0000") References: <51892976.4070903@guardianproject.info> Message-ID: <87y5bnjndz.fsf@vigenere.g10code.de> On Tue, 7 May 2013 18:19, abel at guardianproject.info said: > For various reasons we're exploring alternatives to /dev/random on > Android. Primarily because it doesn't fill fast enough, and we do not > have root access so we cannot write to it. If there is not enough entropy in the system you can't do anything about it. Adding an EGD doesn't help because it only mimics what the kernel does. EGD was designed as a replacement for /dev/random which did not exists on all Unix platforms back then. > We've one good source of entropy, the accelerometer, that we would like If that is a good source and does not require much power, why isn't that already used by the kernel? > 1) Write an EGD in C or Java Not a good idea. You may want to look at a HAVEGE implementation but that is very system dependent. > 2) Hack gnupg source and add our own thing The latest libgcrypt master has a feature to switch to use /dev/random directly instead of using this as an entropy source for Libgrypt's own RNG (which way more conservative). You would need to add some minor changes to GnuPG, so that it is really used. That will save a lot of entropy but is of course a security trade-off. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri May 10 14:50:35 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 May 2013 14:50:35 +0200 Subject: [PATCH] UTF8 Filenames under Windows In-Reply-To: <000601ce49ab$fbec84a0$f3c58de0$@radolfstrasse.de> (tobias@radolfstrasse.de's message of "Sun, 5 May 2013 18:17:05 +0200") References: <000601ce49ab$fbec84a0$f3c58de0$@radolfstrasse.de> Message-ID: <87txmbj8x0.fsf@vigenere.g10code.de> On Sun, 5 May 2013 18:17, tobias at radolfstrasse.de said: > As GnuPG?s command line does not support UTF 16 filenames, all filenames must be encoded in UTF8. As with all Unix tools, gpg does not interpret the filename but assumes that it is a plain C string. The only character which a special meaning is the '/'. Under Windows the drive letter and the backslash are treated similar to the slash. > Attached is a patch for the GnuPG 1.4 branch, that converts all paths > from UTF8 to UTF16 and pass them to Windows Wide API. If we want to do that we would need to change a lot more places. The patch is also not correct, because it has no error checking and assumes UTF-8 encoded filenames. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri May 10 18:37:08 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 May 2013 18:37:08 +0200 Subject: [Announce] GnuPg 2.0.20 released Message-ID: <87ip2qkczv.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.20. 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.13) 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 (GPLv3+). GnuPG-2 works best on GNU/Linux and *BSD systems but is also available for other Unices, Microsoft Windows and Mac OS X. What's New in 2.0.20 ==================== * Decryption using smartcards keys > 3072 bit does now work. * New meta option ignore-invalid-option to allow using the same option file by other GnuPG versions. * gpg: The hash algorithm is now printed for sig records in key listings. * gpg: Skip invalid keyblock packets during import to avoid a DoS. * gpg: Correctly handle ports from DNS SRV records. * keyserver: Improve use of SRV records * gpg-agent: Avoid tty corruption when killing pinentry. * scdaemon: Improve detection of card insertion and removal. * scdaemon: Rename option --disable-keypad to --disable-pinpad. * scdaemon: Better support for CCID readers. Now, the internal CCID driver supports readers without the auto configuration feature. * scdaemon: Add pinpad input for PC/SC, if your reader has pinpad and it supports variable length PIN input, and you specify --enable-pinpad-varlen option. * scdaemon: New option --enable-pinpad-varlen. * scdaemon: Install into libexecdir to avoid accidental execution from the command line. * Support building using w64-mingw32. * Assorted bug fixes. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.20 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.20.tar.bz2 (4186k) gnupg-2.0.20.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.19-2.0.20.diff.bz2 (249k) A patch file to upgrade a 2.0.19 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. A binary version for Windows will be released next week as part of the Gpg4win project. 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.20.tar.bz2 you would use this command: gpg --verify gnupg-2.0.20.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 --keyserver keys.gnupg.net --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 1E42B367. 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.20.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.20.tar.bz2 and check that the output matches the first line from the following list: 7ddfefa37ee9da89a8aaa8f9059d251b4cd02562 gnupg-2.0.20.tar.bz2 4afefda1f42c7b8065e97c6df051fab2db552642 gnupg-2.0.19-2.0.20.diff.bz2 Documentation ============= The file gnupg.info has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want 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. Almost all mail clients support GnuPG-2. Mutt users may want to use the configure option "--enable-gpgme" during build time and put a "set use_crypt_gpgme" in ~/.muttrc to enable S/MIME support along with the reworked OpenPGP support. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: http://www.gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software takes up most of their resources. To allow him them continue his work he asks to either purchase a support contract, engage them for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.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. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 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 pete at petertodd.org Fri May 10 23:49:14 2013 From: pete at petertodd.org (Peter Todd) Date: Fri, 10 May 2013 17:49:14 -0400 Subject: using alternate sources of entropy In-Reply-To: <8738tvl2dk.fsf@vigenere.g10code.de> References: <51892976.4070903@guardianproject.info> <20130507192411.GA32018@petertodd.org> <8738tvl2dk.fsf@vigenere.g10code.de> Message-ID: <20130510214914.GB28251@petertodd.org> On Fri, May 10, 2013 at 09:28:55AM +0200, Werner Koch wrote: > On Tue, 7 May 2013 21:24, pete at petertodd.org said: > > > If you add the accelerometer data to /dev/random yourself and keep track > > of how many bits of randomness you've added the hack could be to just > > You are not able to track this because you can't have an estimation on > many bytes other processes are reading from /dev/{u,}random. I'm assuming that provided a sufficient number of bits whose values are unknown to any adversary are added to the pool all subsequent /dev/urandom output is suitable for use as key material. -- 'peter'[:-1]@petertodd.org 000000000000013908ef667dbb075ed27da28870ecb3d6bee5c538ec0ff88e67 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From wk at gnupg.org Sat May 11 10:58:54 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 11 May 2013 10:58:54 +0200 Subject: using alternate sources of entropy In-Reply-To: <20130510214914.GB28251@petertodd.org> (Peter Todd's message of "Fri, 10 May 2013 17:49:14 -0400") References: <51892976.4070903@guardianproject.info> <20130507192411.GA32018@petertodd.org> <8738tvl2dk.fsf@vigenere.g10code.de> <20130510214914.GB28251@petertodd.org> Message-ID: <874ne9ki41.fsf@vigenere.g10code.de> On Fri, 10 May 2013 23:49, pete at petertodd.org said: > I'm assuming that provided a sufficient number of bits whose values are > unknown to any adversary are added to the pool all subsequent The question is whether this data is indeed unknown. Random number generators are are common problem for severe crypto failures. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bjk at luxsci.net Mon May 13 01:08:15 2013 From: bjk at luxsci.net (Ben Kibbey) Date: Sun, 12 May 2013 19:08:15 -0400 Subject: using alternate sources of entropy In-Reply-To: <51892976.4070903@guardianproject.info> (Abel Luck's message of "Tue, 07 May 2013 16:19:02 +0000") References: <51892976.4070903@guardianproject.info> Message-ID: <1368400141-5486804.62579257.fr4CN8GmU008315@rs146.luxsci.com> On Tue, 07 May 2013 16:19:02 +0000, Abel Luck writes: > Hi, > > For various reasons we're exploring alternatives to /dev/random on > Android. Primarily because it doesn't fill fast enough, and we do not > have root access so we cannot write to it. > > We've one good source of entropy, the accelerometer, that we would like > gpg-agent to use. Looking through the docs it appears gnupg supports EGD. > > EGD would work well, but it is written in perl, which would be a royal > PITA to get working on Android. > > The options I've come up with are: > > 1) Write an EGD in C or Java > 2) Hack gnupg source and add our own thing I have done key generation on Android and http://www.issihosts.com/haveged/ seems to work well. Running 'ent' from http://www.fourmilab.ch/random/ gives good results, too. -- Ben Kibbey From gniibe at fsij.org Mon May 13 03:17:21 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 13 May 2013 10:17:21 +0900 Subject: using alternate sources of entropy In-Reply-To: <1368400141-5486804.62579257.fr4CN8GmU008315@rs146.luxsci.com> References: <51892976.4070903@guardianproject.info> <1368400141-5486804.62579257.fr4CN8GmU008315@rs146.luxsci.com> Message-ID: <1368407841.3338.2.camel@cfw2.gniibe.org> On 2013-05-12 at 19:08 -0400, Ben Kibbey wrote: > I have done key generation on Android and > http://www.issihosts.com/haveged/ seems to work well. IMHO, haveged is not well supported on ARM (yet). Yes, we can build and run haveged with --enable-clock_gettime option. But I think that this should be improved to use high resolution timer, if people really want to use haveged on ARM. That's because high resolution timer is crucial part of haveged. It seems for me that support of (userspace) high resolution timer on ARM is not that good situation, though. I found following two pages about userspace high resolution timer on ARM. http://stackoverflow.com/questions/14975349/how-to-get-high-resolution-timer-in-android-native-code http://blog.regehr.org/archives/794 -- From tobias at radolfstrasse.de Wed May 15 20:55:14 2013 From: tobias at radolfstrasse.de (Tobias) Date: Wed, 15 May 2013 20:55:14 +0200 Subject: AW: [PATCH] UTF8 Filenames under Windows In-Reply-To: <87txmbj8x0.fsf@vigenere.g10code.de> References: <000601ce49ab$fbec84a0$f3c58de0$@radolfstrasse.de> <87txmbj8x0.fsf@vigenere.g10code.de> Message-ID: <000001ce519d$bbe38ad0$33aaa070$@radolfstrasse.de> >> As GnuPG?s command line does not support UTF 16 filenames, all filenames must be encoded in UTF8. >As with all Unix tools, gpg does not interpret the filename but assumes >that it is a plain C string. The only character which a special meaning >is the '/'. Under Windows the drive letter and the backslash are >treated similar to the slash. >> Attached is a patch for the GnuPG 1.4 branch, that converts all paths >> from UTF8 to UTF16 and pass them to Windows Wide API. >If we want to do that we would need to change a lot more places. The >patch is also not correct, because it has no error checking and assumes >UTF-8 encoded filenames. Werner, thanks for your feedback. An error checking could be added easily, but know I understand that using always UTF8 will cause compatibility problems in codepage-aware environments (eg. CP862 - Hebrew). So Windows stays a difficult platform when running GnuPG with Asian characters. Tobias From wk at gnupg.org Thu May 16 10:08:44 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 May 2013 10:08:44 +0200 Subject: AW: [PATCH] UTF8 Filenames under Windows In-Reply-To: <000001ce519d$bbe38ad0$33aaa070$@radolfstrasse.de> (tobias@radolfstrasse.de's message of "Wed, 15 May 2013 20:55:14 +0200") References: <000601ce49ab$fbec84a0$f3c58de0$@radolfstrasse.de> <87txmbj8x0.fsf@vigenere.g10code.de> <000001ce519d$bbe38ad0$33aaa070$@radolfstrasse.de> Message-ID: <8738tne48j.fsf@vigenere.g10code.de> On Wed, 15 May 2013 20:55, tobias at radolfstrasse.de said: > So Windows stays a difficult platform when running GnuPG with Asian characters. I don't think so. We talked about filenames which are treated as a binary blob. Okay, that might me a problem but fixing this is not easy and any fix will introduce other problems. The solution for Windows is easy: Do not use filenames but let the shell handle this (gpg file2). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri May 17 02:42:17 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 17 May 2013 09:42:17 +0900 Subject: Using OpenPGPcard through PC/SC service and with reader of Short APDU level exchange only In-Reply-To: <1364258080.2781.3.camel@cfw2.gniibe.org> References: <1364258080.2781.3.camel@cfw2.gniibe.org> Message-ID: <1368751337.3491.3.camel@cfw2.gniibe.org> On 2013-03-26 at 09:34 +0900, NIIBE Yutaka wrote: > I'm looking the bug report: > > https://bugs.g10code.com/gnupg/issue1405 [...] > I think that this bug could be solved, if we improve app-openpgp.c. Currently, GnuPG determines using extended APDU or not, only by the information of the card. When the card supports extended Lc/Le, GnuPG will use extended APDU level exchange, even if the reader does not support it. To support this case correctly, we will require some rework. It's not that important for the community/users, perhaps. Or it would not be worth for the rework. That's because there is just a few readers in industry which support "Short APDU level exchange only", and it still won't work well with OpenPGP V2 card for RSA >= 2048-bit keys. OpenPGP card V2 doesn't support command chaining, which is required for "short APDU only" communication, when APDU is large. (Singing will work as APDU is not need to be large, but it won't work for writing keys to card and for decryption.) Anyhow, this is very important lessen (at least, for me), to consider smartcard related technology. The CCID specification is not that good, for this specific case, and we need to care about both of the reader and the card in the application layer. Perhaps, the recognition of the word, APDU, as an "application" layer, would be wrong for correct programming. Since APDU construction should be adjusted by the constraints of the reader and the card, it is better to consider APDU as a lower layer packet to be hidden from the application. In better API, application would only specify CLS-INS-P1-P2, and DATA, not composing APDU by itself. It would be lower layer which composes APDU. -- From wk at gnupg.org Fri May 17 09:44:54 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 May 2013 09:44:54 +0200 Subject: Using OpenPGPcard through PC/SC service and with reader of Short APDU level exchange only In-Reply-To: <1368751337.3491.3.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 17 May 2013 09:42:17 +0900") References: <1364258080.2781.3.camel@cfw2.gniibe.org> <1368751337.3491.3.camel@cfw2.gniibe.org> Message-ID: <87fvxmaw3t.fsf@vigenere.g10code.de> On Fri, 17 May 2013 02:42, gniibe at fsij.org said: > not be worth for the rework. That's because there is just a few > readers in industry which support "Short APDU level exchange only", Actually all Omnicard based readers support only Short APDU level exchange via CCID. I have a small stack of them and they are pretty useless with the V2 card on Unix. In Windows they work well, though. Maybe newer models have been fixes - I don't know. In any case I don't think it is justified to spend time adding workarounds for these readers. In particular because Omnicard refused to document their internal TPDU interface which is used by their Windows driver. Granted, I once did a workaround for my Omnicard based PC-Card reader but meanwhile my laptop has no such slot anymore so I have no personal need for it, either. Detecting this case and printing a useful error message is of course a good idea. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From branko at majic.rs Fri May 17 10:14:00 2013 From: branko at majic.rs (Branko Majic) Date: Fri, 17 May 2013 10:14:00 +0200 Subject: Using OpenPGPcard through PC/SC service and with reader of Short APDU level exchange only In-Reply-To: <87fvxmaw3t.fsf@vigenere.g10code.de> References: <1364258080.2781.3.camel@cfw2.gniibe.org> <1368751337.3491.3.camel@cfw2.gniibe.org> <87fvxmaw3t.fsf@vigenere.g10code.de> Message-ID: <20130517101400.7e2734d2@zetkin.primekey.se> On Fri, 17 May 2013 09:44:54 +0200 Werner Koch wrote: > On Fri, 17 May 2013 02:42, gniibe at fsij.org said: > > > not be worth for the rework. That's because there is just a few > > readers in industry which support "Short APDU level exchange > > only", > > Actually all Omnicard based readers support only Short APDU level > exchange via CCID. I have a small stack of them and they are pretty > useless with the V2 card on Unix. In Windows they work well, though. > Maybe newer models have been fixes - I don't know. I've had a bit of (mis)experience with this myself. I have been able to use the extended APDU with OmniKey on GNU/Linux, but only using their proprietary module (that's with pcscd). As a side-note, one more thing is that very often (99% of the time) the contactless interfaces on lots of readers won't work with CCID, and require proprietary drivers (OmniKey included). Best regards -- Branko Majic Jabber: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? ?????: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From kylebutt at gmail.com Tue May 21 19:34:00 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Tue, 21 May 2013 10:34:00 -0700 Subject: [PATCH] Allow the user to specify AES256 as well as AES128. Message-ID: <1369157640-13136-1-git-send-email-kylebutt@gmail.com> --- agent/agent.h | 4 +++ agent/gpg-agent.c | 6 +++- agent/protect.c | 104 +++++++++++++++++++++++++++++++++++++----------------- 3 files changed, 81 insertions(+), 33 deletions(-) diff --git a/agent/agent.h b/agent/agent.h index 2fd0b8b..a4f83f8 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -133,6 +133,10 @@ struct /* This global option enables the ssh-agent subsystem. */ int ssh_support; + + /* This global option sets the protect mode for keys in the private key + store */ + const char* protect_cipher; } opt; diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 4690114..2c2d915 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -112,7 +112,8 @@ enum cmd_and_opt_values oKeepDISPLAY, oSSHSupport, oDisableScdaemon, - oWriteEnvFile + oWriteEnvFile, + oProtectCipher, }; @@ -187,6 +188,7 @@ static ARGPARSE_OPTS opts[] = { { oSSHSupport, "enable-ssh-support", 0, N_("enable ssh-agent emulation") }, { oWriteEnvFile, "write-env-file", 2|8, N_("|FILE|write environment settings also to FILE")}, + { oProtectCipher, "protect-cipher", 2, N_("|CIPHER|protect private keys using CIPHER")}, {0} }; @@ -814,6 +816,8 @@ main (int argc, char **argv ) else env_file_name = make_filename ("~/.gpg-agent-info", NULL); break; + case oProtectCipher: + opt.protect_cipher = xstrdup(pargs.r.ret_str); break; default : pargs.err = configfp? 1:2; break; } diff --git a/agent/protect.c b/agent/protect.c index 3e2cbb9..d0985b2 100644 --- a/agent/protect.c +++ b/agent/protect.c @@ -44,6 +44,21 @@ /* Decode an rfc4880 encoded S2K count. */ #define S2K_DECODE_COUNT(_val) ((16ul + ((_val) & 15)) << (((_val) >> 4) + 6)) +/* A table containing the information needed to encrypt a protected + private key */ +static struct { + const char *algo; + int cipher; + int mode; + int keylen; +} cipher_info[] = { + {"openpgp-s2k3-sha1-aes-cbc", GCRY_CIPHER_AES, + GCRY_CIPHER_MODE_CBC, (128/8)}, + {"openpgp-s2k3-sha1-aes256-cbc", GCRY_CIPHER_AES256, + GCRY_CIPHER_MODE_CBC, (256/8)}, + { NULL } +}; +#define FALLBACK_CIPHER_INDEX 0 /* A table containing the information needed to create a protected private key. */ @@ -75,6 +90,19 @@ struct calibrate_time_s static int +get_default_cipher(int *result) { + int cipher_idx; + for (cipher_idx=0; cipher_info[cipher_idx].algo + && strcmp (opt.protect_cipher, cipher_info[cipher_idx].algo); + cipher_idx++) + ; + if (!cipher_info[cipher_idx].algo) + return gpg_error (GPG_ERR_UNSUPPORTED_PROTECTION); + *result = cipher_idx; + return 0; +} + +static int hash_passphrase (const char *passphrase, int hashalgo, int s2kmode, const unsigned char *s2ksalt, unsigned long s2kcount, @@ -133,10 +161,10 @@ calibrate_elapsed_time (struct calibrate_time_s *starttime) /* Run a test hashing for COUNT and return the time required in milliseconds. */ static unsigned long -calibrate_s2k_count_one (unsigned long count) +calibrate_s2k_count_one (int cipher_idx, unsigned long count) { int rc; - char keybuf[PROT_CIPHER_KEYLEN]; + char keybuf[cipher_info[cipher_idx].keylen]; struct calibrate_time_s starttime; calibrate_get_time (&starttime); @@ -155,10 +183,13 @@ calibrate_s2k_count (void) { unsigned long count; unsigned long ms; + int cipher_idx; + if (get_default_cipher(&cipher_idx)) + cipher_idx = FALLBACK_CIPHER_INDEX; for (count = 65536; count; count *= 2) { - ms = calibrate_s2k_count_one (count); + ms = calibrate_s2k_count_one (cipher_idx, count); if (opt.verbose > 1) log_info ("S2K calibration: %lu -> %lums\n", count, ms); if (ms > 100) @@ -173,7 +204,7 @@ calibrate_s2k_count (void) if (opt.verbose) { - ms = calibrate_s2k_count_one (count); + ms = calibrate_s2k_count_one (cipher_idx, count); log_info ("S2K calibration: %lu -> %lums\n", count, ms); } @@ -309,12 +340,12 @@ calculate_mic (const unsigned char *plainkey, unsigned char *sha1hash) */ static int do_encryption (const unsigned char *protbegin, size_t protlen, - const char *passphrase, const unsigned char *sha1hash, - unsigned char **result, size_t *resultlen, - unsigned long s2k_count) + int cipher_idx, const char *passphrase, + const unsigned char *sha1hash, unsigned char **result, + size_t *resultlen, unsigned long s2k_count) { gcry_cipher_hd_t hd; - const char *modestr = "openpgp-s2k3-sha1-" PROT_CIPHER_STRING "-cbc"; + char *modestr = cipher_info[cipher_idx].algo; int blklen, enclen, outlen; unsigned char *iv = NULL; int rc; @@ -325,8 +356,8 @@ do_encryption (const unsigned char *protbegin, size_t protlen, *resultlen = 0; *result = NULL; - rc = gcry_cipher_open (&hd, PROT_CIPHER, GCRY_CIPHER_MODE_CBC, - GCRY_CIPHER_SECURE); + rc = gcry_cipher_open (&hd, cipher_info[cipher_idx].cipher, + cipher_info[cipher_idx].mode, GCRY_CIPHER_SECURE); if (rc) return rc; @@ -340,7 +371,7 @@ do_encryption (const unsigned char *protbegin, size_t protlen, We always append a full block of random bytes as padding but encrypt only what is needed for a full blocksize. */ - blklen = gcry_cipher_get_algo_blklen (PROT_CIPHER); + blklen = gcry_cipher_get_algo_blklen (cipher_info[cipher_idx].cipher); outlen = 2 + protlen + 2 + 6 + 6 + 23 + 2 + blklen; enclen = outlen/blklen * blklen; outbuf = gcry_malloc_secure (outlen); @@ -361,7 +392,7 @@ do_encryption (const unsigned char *protbegin, size_t protlen, if (!rc) { unsigned char *key; - size_t keylen = PROT_CIPHER_KEYLEN; + size_t keylen = cipher_info[cipher_idx].keylen; key = gcry_malloc_secure (keylen); if (!key) @@ -457,7 +488,8 @@ agent_protect (const unsigned char *plainkey, const char *passphrase, const unsigned char *hash_begin, *hash_end; const unsigned char *prot_begin, *prot_end, *real_end; size_t n; - int c, infidx, i; + int c, i; + int inf_idx, cipher_idx; unsigned char hashvalue[20]; char timestamp_exp[35]; unsigned char *protected; @@ -491,15 +523,19 @@ agent_protect (const unsigned char *plainkey, const char *passphrase, if (!n) return gpg_error (GPG_ERR_INV_SEXP); - for (infidx=0; protect_info[infidx].algo - && !smatch (&s, n, protect_info[infidx].algo); infidx++) + for (inf_idx=0; protect_info[inf_idx].algo + && !smatch (&s, n, protect_info[inf_idx].algo); inf_idx++) ; - if (!protect_info[infidx].algo) + if (!protect_info[inf_idx].algo) return gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); - parmlist = protect_info[infidx].parmlist; - prot_from_idx = protect_info[infidx].prot_from; - prot_to_idx = protect_info[infidx].prot_to; + /* Get protection cipher */ + if (get_default_cipher(&cipher_idx)) + cipher_idx = FALLBACK_CIPHER_INDEX; + + parmlist = protect_info[inf_idx].parmlist; + prot_from_idx = protect_info[inf_idx].prot_from; + prot_to_idx = protect_info[inf_idx].prot_to; prot_begin = prot_end = NULL; for (i=0; (c=parmlist[i]); i++) { @@ -515,7 +551,7 @@ agent_protect (const unsigned char *plainkey, const char *passphrase, if (n != 1 || c != *s) { if (n == 5 && !memcmp (s, "curve", 5) - && !i && protect_info[infidx].ecc_hack) + && !i && protect_info[inf_idx].ecc_hack) { /* This is a private ECC key but the first parameter is the name of the curve. We change the parameter list @@ -565,7 +601,7 @@ agent_protect (const unsigned char *plainkey, const char *passphrase, gcry_md_close (md); rc = do_encryption (prot_begin, prot_end - prot_begin + 1, - passphrase, hashvalue, + cipher_idx, passphrase, hashvalue, &protected, &protectedlen, s2k_count); if (rc) return rc; @@ -608,7 +644,7 @@ agent_protect (const unsigned char *plainkey, const char *passphrase, /* Do the actual decryption and check the return list for consistency. */ static int do_decryption (const unsigned char *protected, size_t protectedlen, - const char *passphrase, + int cipher_idx, const char *passphrase, const unsigned char *s2ksalt, unsigned long s2kcount, const unsigned char *iv, size_t ivlen, unsigned char **result) @@ -619,12 +655,12 @@ do_decryption (const unsigned char *protected, size_t protectedlen, unsigned char *outbuf; size_t reallen; - blklen = gcry_cipher_get_algo_blklen (PROT_CIPHER); + blklen = gcry_cipher_get_algo_blklen (cipher_info[cipher_idx].cipher); if (protectedlen < 4 || (protectedlen%blklen)) return gpg_error (GPG_ERR_CORRUPTED_PROTECTION); - rc = gcry_cipher_open (&hd, PROT_CIPHER, GCRY_CIPHER_MODE_CBC, - GCRY_CIPHER_SECURE); + rc = gcry_cipher_open (&hd, cipher_info[cipher_idx].cipher, + cipher_info[cipher_idx].mode, GCRY_CIPHER_SECURE); if (rc) return rc; @@ -636,7 +672,7 @@ do_decryption (const unsigned char *protected, size_t protectedlen, if (!rc) { unsigned char *key; - size_t keylen = PROT_CIPHER_KEYLEN; + size_t keylen = cipher_info[cipher_idx].keylen; key = gcry_malloc_secure (keylen); if (!key) @@ -842,7 +878,7 @@ agent_unprotect (const unsigned char *protectedkey, const char *passphrase, const unsigned char *s; const unsigned char *protect_list; size_t n; - int infidx, i; + int inf_idx, cipher_idx, i; unsigned char sha1hash[20], sha1hash2[20]; const unsigned char *s2ksalt; unsigned long s2kcount; @@ -872,10 +908,10 @@ agent_unprotect (const unsigned char *protectedkey, const char *passphrase, if (!n) return gpg_error (GPG_ERR_INV_SEXP); - for (infidx=0; protect_info[infidx].algo - && !smatch (&s, n, protect_info[infidx].algo); infidx++) + for (inf_idx=0; protect_info[inf_idx].algo + && !smatch (&s, n, protect_info[inf_idx].algo); inf_idx++) ; - if (!protect_info[infidx].algo) + if (!protect_info[inf_idx].algo) return gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); @@ -937,8 +973,12 @@ agent_unprotect (const unsigned char *protectedkey, const char *passphrase, n = snext (&s); if (!n) return gpg_error (GPG_ERR_INV_SEXP); - if (!smatch (&s, n, "openpgp-s2k3-sha1-" PROT_CIPHER_STRING "-cbc")) + for (cipher_idx=0; cipher_info[cipher_idx].algo + && !smatch (&s, n, cipher_info[cipher_idx].algo); cipher_idx++) + ; + if (!cipher_info[cipher_idx].algo) return gpg_error (GPG_ERR_UNSUPPORTED_PROTECTION); + if (*s != '(' || s[1] != '(') return gpg_error (GPG_ERR_INV_SEXP); s += 2; @@ -993,7 +1033,7 @@ agent_unprotect (const unsigned char *protectedkey, const char *passphrase, return gpg_error (GPG_ERR_INV_SEXP); cleartext = NULL; /* Avoid cc warning. */ - rc = do_decryption (s, n, + rc = do_decryption (s, n, cipher_idx, passphrase, s2ksalt, s2kcount, iv, 16, &cleartext); -- 1.7.11.7 From gniibe at fsij.org Wed May 22 03:08:10 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 22 May 2013 10:08:10 +0900 Subject: [PATCH] Allow the user to specify AES256 as well as AES128. In-Reply-To: <1369157640-13136-1-git-send-email-kylebutt@gmail.com> References: <1369157640-13136-1-git-send-email-kylebutt@gmail.com> Message-ID: <1369184890.3501.0.camel@cfw2.gniibe.org> Hello, I think that the feature for stronger encryption scheme for key store will be nice. Although it is a story in future for me, I could imagine that some people using RSA 4096-bit key now (w/ enough entropy for their pass phrases) would like that, to match its content. Well, I have a suggestion that it will be better to use SHA-2 of relevant size, instead of SHA-1. It will be more coherent, then. I'm not sure if it should be a user option or not. It makes more sense for me, when GnuPG selects appropriate key store scheme automatically. On 2013-05-21 at 10:34 -0700, Kyle Butt wrote: > agent/agent.h | 4 +++ > agent/gpg-agent.c | 6 +++- > agent/protect.c | 104 +++++++++++++++++++++++++++++++++++++---------------- Please have a look at doc/HACKING for commit log requirement. Perhaps, you'd like to submit doc/DCO. -- From wk at gnupg.org Wed May 22 11:19:32 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 May 2013 11:19:32 +0200 Subject: [PATCH] Allow the user to specify AES256 as well as AES128. In-Reply-To: <1369184890.3501.0.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 22 May 2013 10:08:10 +0900") References: <1369157640-13136-1-git-send-email-kylebutt@gmail.com> <1369184890.3501.0.camel@cfw2.gniibe.org> Message-ID: <8761yb9xsr.fsf@vigenere.g10code.de> On Wed, 22 May 2013 03:08, gniibe at fsij.org said: > Although it is a story in future for me, I could imagine that some > people using RSA 4096-bit key now (w/ enough entropy for their pass > phrases) would like that, to match its content. The weakest link we have in the key protection is the passphrase - virtually nobody is able to remember a passphrase with 128 bit entropy and 256 bit is well out of scope. Now I hear a counterargument of a random passphrase which is pasted into the Pinentry. That bears the question where to store that one and whether this additional software, USB gimmicks etc. don't introduce a much higher risk of passphrase compromise. The passphrase tries to mitigate the worst case of a compromised box - now if that is the risk, what are the probabilities that such a compromise is limited to a one-time disk or memory copy attack and not a long lasting active keyboard (or whatever) sniffing attack? Does anyone really consider that this probability is less than breaking 128 bit AES? > Well, I have a suggestion that it will be better to use SHA-2 of > relevant size, instead of SHA-1. It will be more coherent, then. To satisfy todays crypto policy requirements, it would be better to move to a MAC based encryption scheme instead of the ad-hoc OpenPGP encrypted SHA-1 integrity checking. For small devices a different KDF (e.g. scrypt) might be useful, though. > I'm not sure if it should be a user option or not. It makes more > sense for me, when GnuPG selects appropriate key store scheme > automatically. Yep. Algorithm proliferation does not gain us anything. In fact it makes the system more weak. If we want to extend the current key protection, a single alternative algorithm with a well defined use case is what we should do. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed May 22 11:24:09 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 May 2013 11:24:09 +0200 Subject: 2.1 key migration Message-ID: <871u8z9xl2.fsf@vigenere.g10code.de> Hi! I just pushed this change for GnuPG 2.1 (i.e. git master): Implement unattended OpenPGP secret key import. With the gpg-agent taking care of the secret keys, the user needs to migrate existing keys from secring.gpg to the agent. This and also the standard import of secret keys required the user to unprotect the secret keys first, so that gpg-agent was able to re-protected them using its own scheme. With many secret keys this is quite some usability hurdle. In particular if a passphrase is not instantly available. To make this migration smoother, this patch implements an unattended key import/migration which delays the conversion to the gpg-agent format until the key is actually used. For example: gpg2 --batch --import mysecretkey.gpg works without any user interaction due to the use of --batch. Now if a key is used (e.g. "gpg2 -su USERID_FROM_MYSECRETKEY foo"), gpg-agent has to ask for the passphrase anyway, converts the key from the openpgp format to the internal format, signs, re-encrypts the key and tries to store it in the gpg-agent format to the disk. The next time, the internal format of the key is used. This patch has only been tested with the old demo keys, more tests with other protection formats and no protection are needed. Further work will be to compare the time of the last import to the timestamp of secring.gpg and print a note if secring.gpg is newer. A one time pop-up window should also be presented to tell the user how to migrate the keys and offer to start a migration. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kylebutt at gmail.com Wed May 22 19:57:37 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Wed, 22 May 2013 10:57:37 -0700 Subject: [PATCH] Allow the user to specify AES256 as well as AES128. In-Reply-To: <8761yb9xsr.fsf@vigenere.g10code.de> References: <1369157640-13136-1-git-send-email-kylebutt@gmail.com> <1369184890.3501.0.camel@cfw2.gniibe.org> <8761yb9xsr.fsf@vigenere.g10code.de> Message-ID: On Wed, May 22, 2013 at 2:19 AM, Werner Koch wrote: > On Wed, 22 May 2013 03:08, gniibe at fsij.org said: > > > Although it is a story in future for me, I could imagine that some > > people using RSA 4096-bit key now (w/ enough entropy for their pass > > phrases) would like that, to match its content. > > The weakest link we have in the key protection is the passphrase - > virtually nobody is able to remember a passphrase with 128 bit entropy > and 256 bit is well out of scope. Now I hear a counterargument of a > random passphrase which is pasted into the Pinentry. That bears the > question where to store that one and whether this additional software, > USB gimmicks etc. don't introduce a much higher risk of passphrase > compromise. The passphrase tries to mitigate the worst case of a > compromised box - now if that is the risk, what are the probabilities > that such a compromise is limited to a one-time disk or memory copy > attack and not a long lasting active keyboard (or whatever) sniffing > attack? Does anyone really consider that this probability is less than > breaking 128 bit AES? > While passphrases are the weakest link in general, This isn't true of every gnupg user, just most. That's why I left the default as AES-128. Most gnupg users will never see the option or consider changing it. 128 bits of entropy isn't that far out of scope, that's 20 printable ascii characters, and a dedicated user could memorize that. I never tried to argue about storing a random passphrase and pasting it. I don't believe it's relevant to the discussion here. > > > Well, I have a suggestion that it will be better to use SHA-2 of > > relevant size, instead of SHA-1. It will be more coherent, then. > > To satisfy todays crypto policy requirements, it would be better to move > to a MAC based encryption scheme instead of the ad-hoc OpenPGP encrypted > SHA-1 integrity checking. > I would be willing to do this work. > > For small devices a different KDF (e.g. scrypt) might be useful, though. > Or this. > > > I'm not sure if it should be a user option or not. It makes more > > sense for me, when GnuPG selects appropriate key store scheme > > automatically. > > Yep. Algorithm proliferation does not gain us anything. In fact it > makes the system more weak. If we want to extend the current key > protection, a single alternative algorithm with a well defined use case > is what we should do. > > I'm not sure I understand the argument here. Are you saying that you agree, and that rather than have it be a flag, it should be dependent on key size and selected automatically? I'd be happy to send that patch instead. Kyle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbeith at rwu.edu Wed May 22 22:14:17 2013 From: lbeith at rwu.edu (Beith, Linda) Date: Wed, 22 May 2013 16:14:17 -0400 Subject: decryption question In-Reply-To: References: Message-ID: Hi everyone, Just a quick follow-up to my problem with downloading and decrypting files from our hosting vendor. It turns out that their Apache did not have a mime type for gpg. Once the mimeType was added we were able to download the file again via the website. This time it did ask for the password. I was then able to get a valid sql file. It didn't help with the original file but at least solved the mystery for why we weren't being prompted for the passcode. Thanks to all who so generously volunteered solutions/suggestions. Linda From: Gnupg-devel [mailto:gnupg-devel-bounces at gnupg.org] On Behalf Of Beith, Linda Sent: Wednesday, April 17, 2013 5:07 PM To: gnupg-devel at gnupg.org Subject: decryption question Hi folks, Please excuse cross-posting but I wasn't sure which list was the best option for my dilemma. I am new to the list and am hoping someone can provide some suggestions for a situation we have at my University. We have had a rather catastrophic loss of all data from one of our Fall 2012 courses on our Sakai open source learning management server. To compound matters, we have a military student who had an incomplete in that course and is on deadline to finish his work and submit his grades or face being dropped from his academic program. Since our Sakai instance is hosted by a third-party vendor we don't have direct access to the application at the server level, so each month the vendor makes a backup copy of our full database and encrypts/zips it using GNU PG so we can download it. We then decrypt it using the passcode they provide and we can run stats against the resulting SQL file. I had a backup file from early December 2012 that I had downloaded but never opened. I sent the file back to our vendor in hopes of being able to retrieve the course data however when they tried to unzip/decrypt it, they were not prompted for the passcode and just got an error: Gpg: can't open 'rwu.dbdump_Nov2012.sql.gz.gpg' Gpg: decrypt_message filed: file open error We can't have them redo the backup because it is too late - the files are no longer on their server. So the only source of the work is locked in this zipped file. The zipped file is quite large - over 1 GB so we know there is data there - we just can't get to it. The assumption is that something went wrong in the original encryption of the file. Do you have idea if it is possible to extract data in this situation? I appreciate any help or suggestions you can provide, Linda Linda L. Beith, Ph.D. Roger Williams University Director, Instructional Design One Old Ferry Road, Bristol RI 401-254-3134 Website: id.rwu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at guardianproject.info Fri May 24 18:04:52 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 24 May 2013 12:04:52 -0400 Subject: distinguishing public from secret keys with gpgme Message-ID: <519F8FA4.9010106@guardianproject.info> Hey all, Using gpgme 1.4.1, I'm trying to pick out which keys in the keyring have the secret component, and can be used for signing and decryption. I've tried: return key->secret and jboolean hasSecretKey = 0; gpgme_subkey_t subkey; for(subkey = key->subkeys; subkey; subkey = subkey->next) if (subkey->secret) return 1; return 0; Both of these always turn up false for every key in the keyring. `gpg2 --list-secret-keys` shows that I have one secret key. What am I missing? .hc From wk at gnupg.org Fri May 24 19:22:03 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 May 2013 19:22:03 +0200 Subject: distinguishing public from secret keys with gpgme In-Reply-To: <519F8FA4.9010106@guardianproject.info> (Hans-Christoph Steiner's message of "Fri, 24 May 2013 12:04:52 -0400") References: <519F8FA4.9010106@guardianproject.info> Message-ID: <871u8w47k4.fsf@vigenere.g10code.de> On Fri, 24 May 2013 18:04, hans at guardianproject.info said: > Hey all, > > Using gpgme 1.4.1, I'm trying to pick out which keys in the keyring have the > secret component, and can be used for signing and decryption. I've tried: > > return key->secret > > and > > jboolean hasSecretKey = 0; > gpgme_subkey_t subkey; > for(subkey = key->subkeys; subkey; subkey = subkey->next) > if (subkey->secret) > return 1; > return 0; > > Both of these always turn up false for every key in the keyring. `gpg2 > --list-secret-keys` shows that I have one secret key. What am I missing? You need to pass true as the last argument to gpgme_op_keylist_start to list the secret keys. Unfortunately this will only return secret keys thus if you want to have a combined listing you need to match them. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Sat May 25 01:55:49 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 24 May 2013 19:55:49 -0400 Subject: distinguishing public from secret keys with gpgme In-Reply-To: <871u8w47k4.fsf@vigenere.g10code.de> References: <519F8FA4.9010106@guardianproject.info> <871u8w47k4.fsf@vigenere.g10code.de> Message-ID: <519FFE05.6090500@guardianproject.info> On 05/24/2013 01:22 PM, Werner Koch wrote: > On Fri, 24 May 2013 18:04, hans at guardianproject.info said: >> Hey all, >> >> Using gpgme 1.4.1, I'm trying to pick out which keys in the keyring have the >> secret component, and can be used for signing and decryption. I've tried: >> >> return key->secret >> >> and >> >> jboolean hasSecretKey = 0; >> gpgme_subkey_t subkey; >> for(subkey = key->subkeys; subkey; subkey = subkey->next) >> if (subkey->secret) >> return 1; >> return 0; >> >> Both of these always turn up false for every key in the keyring. `gpg2 >> --list-secret-keys` shows that I have one secret key. What am I missing? > > You need to pass true as the last argument to gpgme_op_keylist_start to > list the secret keys. Unfortunately this will only return secret keys > thus if you want to have a combined listing you need to match them. Ah perfect, that was easy. I had assumed that the gnupg-for-java was a lot more complete than it is. But now its getting more complete :) I hope to split it out of gnupg-for-android again, so its usable in any java app. .hc From mailinglisten at hauke-laging.de Wed May 29 21:38:45 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 29 May 2013 21:38:45 +0200 Subject: unnecessary newline with --print-md Message-ID: <3075982.8pD3J95dd1@inno.berlin.laging.de> Hello, I just noticed something which one might consider a bug. gpg --print-md prints the file path and then the requested digest. If the file path is "too long" then a newline is inserted after it. That is nice if you just want to read the output. The strange effect is that this happens if the output is piped, too. Even with --batch and --no-tty. In my experience the usual behaviour of console programs is that they do without the fancy terminal related stuff if they detect that their output is not connected to a terminal. I know that --with-colons can be used with --print-md, too, and that this problem can be solved with redirecting the file to stdin but I thought this behaviour might be unintended. Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-courses.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From kylebutt at gmail.com Wed May 29 20:58:30 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Wed, 29 May 2013 11:58:30 -0700 Subject: DCO Submission. Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Kyle Butt -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta204 (GNU/Linux) iQIcBAEBAgAGBQJRpk4AAAoJEFkcxunJusej9hoP/iLxhlXtdQv2q8+G1nXoIhZH gjx5EWJ3MDvk2RHgqIKkrnKoHTp0kF/YW6WmTQ2TWOp9+KhPEDEV4b32JaCrKz9A xV8Oxeisjbcr5Jsk9Kehg25bC/DR3tR2jbWi4VOBN2700jYfsWFB+LsASh5xUDc/ D7FgvPCd0Nev3PvTRaZ7fBJduYJ1zMOWb84TVySnqyBHLVZdMP5VfipF4VaepQgW Yz5R+TKCKY56iOnpNmrPbPQZMswJFurDc1wP896t0T9t3HX/3+QUapgLysNkHY2V /Yzy2WpKEaco2D1WNJ/a+1Wjj0Pm+fxUzg/AmfrYqbZJamrFSHRxn+oJP/cjJiHD fY/PjvIfC7bQBJxICKVkEnXqDzszHXH5K21a7V16KwDBwgLeNn60qPy8C8TUduCK ZnIfRtbD96tTWKp1J81fOtl26WcXuakB22nMPU2HfSf89tDvySsBmQMY4SXbGZT4 PE5eMffsCl9yFt4Xm0/wl9ie/fpBXlpG/s0BH0h4KiESpcVN+EyL6BceG9Ge38zl puESzssmjcpEp0FuFyN7HirWzeRJRzCnWL+8Vip/onNsXoDmadGUVeC313m6AEpU nBIYJMaBGdrONiCwRwT3HjWz8bJ2YscsW6Eh6E0y6F6WbOuCR/Gxua2EbPjGEovk 65xRsklZe2GGUNDx+f+2 =jSA1 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu May 30 10:12:17 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 May 2013 10:12:17 +0200 Subject: unnecessary newline with --print-md In-Reply-To: <3075982.8pD3J95dd1@inno.berlin.laging.de> (Hauke Laging's message of "Wed, 29 May 2013 21:38:45 +0200") References: <3075982.8pD3J95dd1@inno.berlin.laging.de> Message-ID: <8738t4sx7i.fsf@vigenere.g10code.de> On Wed, 29 May 2013 21:38, mailinglisten at hauke-laging.de said: > gpg --print-md prints the file path and then the requested digest. If > the file path is "too long" then a newline is inserted after it. That > is nice if you just want to read the output. That is the case for more than 10 years: 2003-02-11 David Shaw * g10.c (print_hex, print_mds): Print long hash strings a lot neater. This assumes at least an 80-character display, as there are a few other similar assumptions here and there. Users who need unformatted hashes can still use with-colons. Check that SHA384 and 512 are available before using them as they are no longer always available. thus we can't change it. > --batch and --no-tty. In my experience the usual behaviour of console > programs Well, I might be possible to disable the pretty-printing if --batch is in use. I am not sure this is worth the effort. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.