From bernhard at intevation.de Fri Aug 1 10:16:50 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 1 Aug 2014 10:16:50 +0200 Subject: add gnupg-for-java fork to git.gnupg.org In-Reply-To: <53DA9380.20902@guardianproject.info> References: <53D91354.8020105@guardianproject.info> <201407311751.29537.bernhard@intevation.de> <53DA9380.20902@guardianproject.info> Message-ID: <201408011017.00877.bernhard@intevation.de> On Thursday 31 July 2014 at 21:05:36, Hans-Christoph Steiner wrote: > Good idea, I added some things to that page: > https://wiki.gnupg.org/APIs Thanks, I've further massaged the page to clearly recommend GPGME first! > And now I change my original request: > > Please remove the link to https://github.com/smartrevolution/gnupg-for-java > on http://git.gnupg.org/ and instead point to this wiki page: > https://wiki.gnupg.org/APIs :) Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Fri Aug 1 10:23:40 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 1 Aug 2014 10:23:40 +0200 Subject: gpgsm issueing two concurrent passphrase requests fails In-Reply-To: <20140710192841.GA18740@server.agci.com> References: <20140710192841.GA18740@server.agci.com> Message-ID: <201408011023.42126.bernhard@intevation.de> On Thursday 10 July 2014 at 21:28:41, Alfred Ganz wrote: > ? gpgsm --import ssh-key.p12 > and it is after this command there exists a hanging pinentry. Which pinentries did you try? Did you try with pinentries that open an X11 window in particular? My hypothesis is that the curses backend triggers the problem. But, I maybe wrong about this. Having a reproducable testcase in an reported issue on bugs.gnupg.org would be nice. We should work up to this point. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From hans at guardianproject.info Fri Aug 1 19:51:17 2014 From: hans at guardianproject.info (Hans of Guardian) Date: Fri, 1 Aug 2014 13:51:17 -0400 Subject: add gnupg-for-java fork to git.gnupg.org In-Reply-To: <201408011017.00877.bernhard@intevation.de> References: <53D91354.8020105@guardianproject.info> <201407311751.29537.bernhard@intevation.de> <53DA9380.20902@guardianproject.info> <201408011017.00877.bernhard@intevation.de> Message-ID: On Aug 1, 2014, at 4:16 AM, Bernhard Reiter wrote: > On Thursday 31 July 2014 at 21:05:36, Hans-Christoph Steiner wrote: >> Good idea, I added some things to that page: >> https://wiki.gnupg.org/APIs > > Thanks, I've further massaged the page to clearly recommend GPGME first! > >> And now I change my original request: >> >> Please remove the link to https://github.com/smartrevolution/gnupg-for-java >> on http://git.gnupg.org/ and instead point to this wiki page: >> https://wiki.gnupg.org/APIs > > :) Oops, but it should actually be http not https since the certificate is not signed by a proper CA. .hc From rjh at sixdemonbag.org Sun Aug 3 03:47:40 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 02 Aug 2014 21:47:40 -0400 Subject: FAQ: Re: key length In-Reply-To: <201407311021.13108.bernhard@intevation.de> References: <53D06E85.7080903@sixdemonbag.org> <53D0D9C6.1080807@sixdemonbag.org> <201407311021.13108.bernhard@intevation.de> Message-ID: <53DD94BC.8010305@sixdemonbag.org> > This makes me curious: Is there an example for an OpenPGP > implementation that only support <= 2048-bit RSA keys? Still in > usage? Yes. My smartcard, for instance, only supports 2048-bit RSA. Larger keys can't be migrated to them. > I haven't read the ENISA recommendation in full length. If they > allow 2048 bit for old applications or up to a specific point, it > would be an improvement to say so. It may make sense to directly link > to their recommendation paper. I'll see about digging up a specific reference. > You may consider using a different word here. As someone who speaks > English as a foreign language, I had to look "imminently" up to be > sure about its meaning. Easy enough to accommodate. :) > Wasn't there something about the current OpenPGP smartcards only > being able to deal with 3072-bit keys? Some can support 3072-bit RSA. Many can only do RSA-2048. > I recommend to leave out the next question and answer, it does not > add much significant information. Eh. I think it has a point, but I can definitely work on making that point more clear. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From achim at pietig.com Sun Aug 3 09:51:22 2014 From: achim at pietig.com (Achim Pietig) Date: Sun, 03 Aug 2014 09:51:22 +0200 Subject: FAQ: Re: key length In-Reply-To: <53DD94BC.8010305@sixdemonbag.org> References: <53D06E85.7080903@sixdemonbag.org> <53D0D9C6.1080807@sixdemonbag.org> <201407311021.13108.bernhard@intevation.de> <53DD94BC.8010305@sixdemonbag.org> Message-ID: <53DDE9FA.20902@pietig.com> Hi, there ist still some confusion on the supported key length in the card. All cards that are sold by Kernelconcepts and have a manufacturer ID from Zeitcontrol (V2.0 and above) are developed by me and tested by Werner Koch. They support RSA up to 4096 bit - 2048 is the default (still enough for many years). Older versions of gnupg support only 3072 bit RSA, this was solved in a version last year (2.x branch). To use other key lenght in the card you have to change the length indicator in the Extended capabilities of the card with the command PUT DATA. Each key (sign, dec, auth) has its own length and can be set individual, read the specification . After setting the length indicator, gey generation will use the new value or keys with that value can be imported. Other cards from different vendors may not support this feature... Regards, Achim Am 03.08.2014 um 03:47 schrieb Robert J. Hansen: >> This makes me curious: Is there an example for an OpenPGP >> implementation that only support <= 2048-bit RSA keys? Still in >> usage? > > Yes. My smartcard, for instance, only supports 2048-bit RSA. Larger > keys can't be migrated to them. > >> I haven't read the ENISA recommendation in full length. If they >> allow 2048 bit for old applications or up to a specific point, it >> would be an improvement to say so. It may make sense to directly link >> to their recommendation paper. > > I'll see about digging up a specific reference. > >> You may consider using a different word here. As someone who speaks >> English as a foreign language, I had to look "imminently" up to be >> sure about its meaning. > > Easy enough to accommodate. :) > >> Wasn't there something about the current OpenPGP smartcards only >> being able to deal with 3072-bit keys? > > Some can support 3072-bit RSA. Many can only do RSA-2048. > >> I recommend to leave out the next question and answer, it does not >> add much significant information. > > Eh. I think it has a point, but I can definitely work on making that > point more clear. > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From alfred-ganz+gpg at agci.com Sun Aug 3 23:43:43 2014 From: alfred-ganz+gpg at agci.com (Alfred Ganz) Date: Sun, 3 Aug 2014 17:43:43 -0400 Subject: gpgsm issueing two concurrent passphrase requests fails Message-ID: <20140803214343.GA9675@server.agci.com> Bernhard, On Thursday 10 July 2014 at 21:28:41, Alfred Ganz wrote: > ? gpgsm --import ssh-key.p12 > and it is after this command there exists a hanging pinentry. I am sorry to make this complicated, here is the sequence of commands that I did in various windows: openssl req -new -x509 -key -out ssh-cert.pem openssl pkcs12 -export -in ssh-cert.pem -inkey -out ssh-key.p12 separate window: gpg-agent --csh --no-detach --debug-level basic --daemon > ~/.gpg-agent-info source ~/.gpg-agent-info yet another window: source ~/.gpg-agent-info gpgsm --import ssh-key.p12 This last command will need both a passphrase to unprotect the PKCS#12 object, and later one to open my secret key to import the new key. I did it both with just plain /usr/bin/pinentry-curses as well as /usr/bin/pinentry-gtk-2, the effect was the same in both cases. Also, I have done what failed with gpgsm (GnuPG) 2.0.14 and gpg-agent (GnuPG) 2.0.14 successfully under gnupg-1.4.5-14.el5_5.1 and gnupg2-2.0.10-3.el5_5.1. Note that in the earlier system the passphrases were entered via interactive keyboard prompt. I think your hypothesis is correct, but only for one of the two pinentries, which puzzles me because one of pintries works just fine. Looking at the gpg-agent debug output in the attachment to my first message (Jul 9 01:16:25 2014), what seems to happen is that one pinentry invocation is nicely set up (it will be used later and works!), but then the second pinentry invocation, which isn't set up like the first one, tries to get the passphrase for the PKCS#12 object and fails. Note that after getting rid of the hung pinentry, we actually proceed to get the passphrase of the secret key, but of course the PKCS#12 hasn't been unprotected, and so everything fails. Since I don't really understand what is going on, can you tell me where each of the pinentry request originates? Can you please tell me with what debug options you would like me to run the above commands, and where to send the results, I will be glad to try to get it done. Thanks for your help, AG -- ---------------------------------------------------------------------- Alfred Ganz alfred-ganz:at:agci.com AG Consulting (203) 624-9667 440 Prospect Street # 11 New Haven, CT 06511 ---------------------------------------------------------------------- From bernhard at intevation.de Mon Aug 4 10:00:23 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 4 Aug 2014 10:00:23 +0200 Subject: gpgsm issueing two concurrent passphrase requests fails In-Reply-To: <20140803214343.GA9675@server.agci.com> References: <20140803214343.GA9675@server.agci.com> Message-ID: <201408041000.35415.bernhard@intevation.de> On Sunday 03 August 2014 at 23:43:43, Alfred Ganz wrote: > Can you please tell me with what debug options you would like me to run > the above commands, and where to send the results, I will be glad to > try to get it done. As it looks like a defect and a regression, you should search for an entry in bugs.gnupg.org and create one, if there is none. Put in all revelvant details there, so that Werner (or somebody else) can try to reproduce it as easy as you manage. If you think this did work before and broke at some point, try finding this point. E.g. by trying several revisions in a "bisect". Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Aug 4 11:41:24 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Aug 2014 11:41:24 +0200 Subject: FAQ: Re: key length In-Reply-To: <53DDE9FA.20902@pietig.com> (Achim Pietig's message of "Sun, 03 Aug 2014 09:51:22 +0200") References: <53D06E85.7080903@sixdemonbag.org> <53D0D9C6.1080807@sixdemonbag.org> <201407311021.13108.bernhard@intevation.de> <53DD94BC.8010305@sixdemonbag.org> <53DDE9FA.20902@pietig.com> Message-ID: <87vbq8h9rv.fsf@vigenere.g10code.de> On Sun, 3 Aug 2014 09:51, achim at pietig.com said: > To use other key lenght in the card you have to change the length > indicator in the Extended capabilities of the card with the command > PUT DATA. Actually GnuPG does this for you. There will be a confirmation prompt, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Aug 4 11:47:17 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Aug 2014 11:47:17 +0200 Subject: Keyserver rejection filter and signing subkeys In-Reply-To: <53DA6CD1.5090802@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 31 Jul 2014 12:20:33 -0400") References: <53D7E3E8.10803@sumptuouscapital.com> <87wqavjlx1.fsf@vigenere.g10code.de> <53D8B418.40608@sumptuouscapital.com> <87egx3j9ud.fsf@vigenere.g10code.de> <53DA6CD1.5090802@fifthhorseman.net> Message-ID: <87r40wh9i2.fsf@vigenere.g10code.de> On Thu, 31 Jul 2014 18:20, dkg at fifthhorseman.net said: > hm, maybe i'm not understanding the scenario here, but if i request key > 0xdeadbeef, and that is only available as a subkey, and that subkey is > bound to multiple primary keys on the keyservers, won't gpg import them all? As long as the key binding signatures are valid they are all imported (modulo duplicate long keyid bugs). Which is expected and correct. The threat the filter shall stop is that a rogue keyserver returns a different key than requested. A wrong subkey is a different thing. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Tue Aug 5 09:18:04 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 5 Aug 2014 09:18:04 +0200 Subject: FAQ: Re: key length In-Reply-To: <53DDE9FA.20902@pietig.com> References: <53DD94BC.8010305@sixdemonbag.org> <53DDE9FA.20902@pietig.com> Message-ID: <201408050918.05443.bernhard@intevation.de> On Sunday 03 August 2014 at 09:51:22, Achim Pietig wrote: > there ist still some confusion on the supported key length in the card. > All cards that are sold by Kernelconcepts and have a manufacturer ID from > Zeitcontrol (V2.0 and above) are developed by me and tested by Werner Koch. > They support RSA up to 4096 bit - 2048 is the default (still enough for > many years). > > Older versions of gnupg support only 3072 bit RSA, this was solved in a > version last year (2.x branch). Thanks for the clarification on the OpenPGP cards! For the question, though, I wonder if there is a limit on the part of the communication partner. My choice of key length depends on what my installation can handle for my signatures and decryption. If my card and gnupg version can do 4096 bit, this end is okay. The question is: Are there communication partners who's OpenPGP implementation would not be able to a) check my signature or b) encrypt to my certificate? Because this would be the more important reason for making my choice as I cannot control my communication partners implementation. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Aug 5 10:17:31 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Aug 2014 10:17:31 +0200 Subject: FAQ: Re: key length In-Reply-To: <201408050918.05443.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 5 Aug 2014 09:18:04 +0200") References: <53DD94BC.8010305@sixdemonbag.org> <53DDE9FA.20902@pietig.com> <201408050918.05443.bernhard@intevation.de> Message-ID: <87silbe4f8.fsf@vigenere.g10code.de> On Tue, 5 Aug 2014 09:18, bernhard at intevation.de said: > The question is: Are there communication partners who's OpenPGP implementation > would not be able to a) check my signature or b) encrypt to my certificate? re a) You can't know unless you use MUST algorithms of OpenPGP (DSA and SHA-1) with suitable key sizes. re b) OpenPGP specifies 3DES and Elgamal as MUST algorithm. The card supports only RSA and thus there is no guarantee. In theory. In practice all implementations support RSA. OpenPGP does not specify supported key lengths. There is only a lower bound on the key size but none for an upper limit. In reality all _current_ implementations support 4096 bit RSA. The PPC version of the OpenPGP smartcard does only support 1024 bit but I would not call that a current implementation. Using rsa2048 and SHA-256 should be a safe choice for signatures. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Aug 5 10:20:49 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Aug 2014 10:20:49 +0200 Subject: Problems with gpgsm/dirmngr in gnupg-2.1.0-beta751 In-Reply-To: <201407311026.47586.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 31 Jul 2014 10:26:46 +0200") References: <87zjgjpx3e.fsf@pcwi7557.uni-muenster.de> <201407311026.47586.bernhard@intevation.de> Message-ID: <87oavze49q.fsf@vigenere.g10code.de> On Thu, 31 Jul 2014 10:26, bernhard at intevation.de said: > In our setups we prefer to run dirmnger as a system service, > you could try this variant and see if you get further. This changed with 2.1. Dirmngr has been changed to be a proper part of GnuPG and it is started on demand by gpg or gpgsm. The LDAP code of the new dirmngr has not been well tested, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Aug 5 10:28:37 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Aug 2014 10:28:37 +0200 Subject: gpgsm issueing two concurrent passphrase requests fails In-Reply-To: <20140708231625.GA30473@server.agci.com> (Alfred Ganz's message of "Tue, 8 Jul 2014 19:16:25 -0400") References: <20140708231625.GA30473@server.agci.com> Message-ID: <87k36ne3wq.fsf@vigenere.g10code.de> On Wed, 9 Jul 2014 01:16, alfred-ganz+gpg at agci.com said: > gpgsm: gpgsm (GnuPG) 2.0.14 2.0.14 is a 5 years old version. A quick check of the NEWS file shows that 2.0.15 fixes a passphrase related regression in 2.0.14. There are other important fixes in later versions. I strongly suggested to update to a decent version or contact a commercial support company to help you with an old version. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Tue Aug 5 15:34:54 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 5 Aug 2014 09:34:54 -0400 Subject: [PATCH] Fix struct alignment on hppa-linux Message-ID: <1407245694-22243-1-git-send-email-dkg@fifthhorseman.net> As reported by John David Anglin : libgpg-error fails to build on hppa because the t-lock test fails. The test fails because the _gpgrt_lock_t and gpgrt_lock_t objects have different sizes. This happens becuase the pthread_mutex_t type on hppa-linux has 16-byte alignement, but the code in gen-posix-lock-obj.c assumes that a long or pointer to long will provide sufficient alignment. (see https://bugs.debian.org/757060) --- src/gen-posix-lock-obj.c | 3 +++ src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h | 1 + 2 files changed, 4 insertions(+) diff --git a/src/gen-posix-lock-obj.c b/src/gen-posix-lock-obj.c index df732c3..faba83e 100644 --- a/src/gen-posix-lock-obj.c +++ b/src/gen-posix-lock-obj.c @@ -76,6 +76,9 @@ main (void) " long _vers;\n" " union {\n" " volatile char _priv[%d];\n" +#if defined(__hppa__) && defined(__linux__) + " int __lock __attribute__ ((aligned(16)));\n" +#endif " long _x_align;\n" " long *_xp_align;\n" " } u;\n" diff --git a/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h index fd47664..7758604 100644 --- a/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h +++ b/src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h @@ -7,6 +7,7 @@ typedef struct long _vers; union { volatile char _priv[48]; + int __lock __attribute__ ((aligned(16))); long _x_align; long *_xp_align; } u; -- 2.0.1 From wk at gnupg.org Tue Aug 5 18:42:52 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Aug 2014 18:42:52 +0200 Subject: [PATCH] Fix struct alignment on hppa-linux In-Reply-To: <1407245694-22243-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 5 Aug 2014 09:34:54 -0400") References: <1407245694-22243-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87mwbi6g6r.fsf@vigenere.g10code.de> On Tue, 5 Aug 2014 15:34, dkg at fifthhorseman.net said: > different sizes. This happens becuase the pthread_mutex_t type on > hppa-linux has 16-byte alignement, but the code in > gen-posix-lock-obj.c assumes that a long or pointer to long will > provide sufficient alignment. I see. Given that there is probably no suitable 16 byte object, we need to resort to the proposes solution. However, the code is not portable thus I need to check how to fix it in a portable way. Enforcing a 16 byte alignment might for all platfrom won't harm anyway. Thanks for forwarding, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Aug 5 19:35:20 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Aug 2014 19:35:20 +0200 Subject: [PATCH] Fix struct alignment on hppa-linux In-Reply-To: <87mwbi6g6r.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 05 Aug 2014 18:42:52 +0200") References: <1407245694-22243-1-git-send-email-dkg@fifthhorseman.net> <87mwbi6g6r.fsf@vigenere.g10code.de> Message-ID: <87ha1q6drb.fsf@vigenere.g10code.de> On Tue, 5 Aug 2014 18:42, wk at gnupg.org said: > thus I need to check how to fix it in a portable way. Enforcing a 16 > byte alignment might for all platfrom won't harm anyway. but that would be an ABI break. Thus I basically use the proposed patch: >From 3325403c0dd2949bf52efa1b9a5b5cf3191110f9 Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Tue, 5 Aug 2014 19:32:51 +0200 Subject: [PATCH] Use 16 byte alignment for hppa-unknown-linux-gnu. * configure.ac (HAVE_GCC_ATTRIBUTE_ALIGNED): New. * src/gen-posix-lock-obj.c (USE_16BYTE_ALIGNMENT): Set for HPPA-Linux. (main): Enforce alignment if needed. * src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h: Use 16 byte alignment. -- Debian-bug-id: 757060 --- configure.ac | 23 ++++++++++++++++++++++- src/gen-posix-lock-obj.c | 19 +++++++++++++++++++ src/syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h | 1 + 3 files changed, 42 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 653d7ed..e1f167f 100644 --- a/configure.ac +++ b/configure.ac @@ -167,6 +167,20 @@ AC_CHECK_FUNCS([flockfile]) # Checks for typedefs, structures, and compiler characteristics. AC_C_CONST +# +# Check whether the compiler supports the GCC style aligned attribute +# +AC_CACHE_CHECK([whether the GCC style aligned attribute is supported], + [gcry_cv_gcc_attribute_aligned], + [gcry_cv_gcc_attribute_aligned=no + AC_COMPILE_IFELSE([AC_LANG_SOURCE( + [[struct { int a; } foo __attribute__ ((aligned (16)));]])], + [gcry_cv_gcc_attribute_aligned=yes])]) +if test "$gcry_cv_gcc_attribute_aligned" = "yes" ; then + AC_DEFINE(HAVE_GCC_ATTRIBUTE_ALIGNED,1, + [Defined if a GCC style "__attribute__ ((aligned (n))" is supported]) +fi + # Check for thread library. # @@ -278,5 +292,12 @@ echo " Revision: mym4_revision (mym4_revision_dec) Platform: $host - " +if test "$gcry_cv_gcc_attribute_aligned" != "yes" ; then +cat < References: <1404459368.3374.4.camel@latx1.gniibe.org> Message-ID: <1407317257.2152.1.camel@latx1.gniibe.org> On 2014-07-04 at 16:36 +0900, NIIBE Yutaka wrote: > I have updated it. Since I don't think it's maintained by > translation-team-ja at lists.sourceforge.net, I modified: > > "Language-Team: none\n". > > I'll maintain this translation. Committed and pushed. -- From gniibe at fsij.org Wed Aug 6 11:45:15 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 06 Aug 2014 18:45:15 +0900 Subject: FAQ: Re: key length In-Reply-To: <201407311021.13108.bernhard@intevation.de> References: <53D06E85.7080903@sixdemonbag.org> <53D0D9C6.1080807@sixdemonbag.org> <201407311021.13108.bernhard@intevation.de> Message-ID: <1407318315.2152.2.camel@latx1.gniibe.org> On 2014-07-31 at 10:21 +0200, Bernhard Reiter wrote: > This makes me curious: Is there an example for an OpenPGP implementation > that only support <= 2048-bit RSA keys? Still in usage? Although it's OpenPGP card protocol implementation (not OpenPGP implementation), Gnuk only supports 2048-bit RSA keys. Key length is an important factor, indeed. But, I'd say, I prefer putting my 2048-bit RSA private keys on FST-01 with Gnuk, rather than holding longer keys on PC. And it's my practice for this three years. YMMV. -- From steve at gpgtools.org Wed Aug 6 13:43:53 2014 From: steve at gpgtools.org (steve) Date: Wed, 6 Aug 2014 13:43:53 +0200 Subject: import filter Message-ID: <5564A372-2306-4E6E-9B80-6B88C80AE982@gpgtools.org> Hi team, when auto-key retrieve is active, in very few cases but in those cases 100% reproducible the public key is not fetched correctly despite it being on the key server. This happened in a hand full of cases. We were so far not able to determine why the import filter rejects those public keys. Here?s our ticket for this issue: https://gpgtools.lighthouseapp.com/projects/66001/tickets/134-import-filter-rejects-key-on-auto-key-retrieve Can you please have a look. Maybe you have an idea, what is happening here and how we can improve the situation. Kind regards, steve GPGTools -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 831 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Aug 6 14:19:03 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 06 Aug 2014 14:19:03 +0200 Subject: import filter In-Reply-To: <5564A372-2306-4E6E-9B80-6B88C80AE982@gpgtools.org> References: <5564A372-2306-4E6E-9B80-6B88C80AE982@gpgtools.org> Message-ID: <53E21D37.7080408@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 08/06/2014 01:43 PM, steve wrote: > Hi team, > > when auto-key retrieve is active, in very few cases but in those > cases 100% reproducible the public key is not fetched correctly > despite it being on the key server. ... > Can you please have a look. Maybe you have an idea, what is > happening here and how we can improve the situation. See the thread starting at [0] References: [0] http://lists.gnupg.org/pipermail/gnupg-devel/2014-July/028583.html - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "History doesn't repeat itself, but it does rhyme." (Mark Twain) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT4h0zAAoJEPw7F94F4Tag3b8P/3bsImr+5UzM8pwfl1H01fsL j+MiOywSkvMjGtSUkDJHf4uQ6D+/6Y6Kaf60ccMG19EJW2ifCytsrdeGonI+lo5R PMMtjsPMPuSoQwJGnbc6uQgjMHatwENLV7WmuoUdVdGjhQmjTD0gArJ93YtrmXBP idzQacweg5ymb/lgDb60gisFiSY2GZcZUC1O9l43e6UGllDBUq/HBmxqxC7NOj56 oZMUAq1wR1sO7Q8wQuUURTvOwh++9Yn5tAMeR2tJ8EBQNplgTkxZQ9zD8dmXKrSd Jm4ZyODY836Tg+aPvzH1ZR1Jd4puQYp+v+EcFrm3LPEuZ6V4mq22UrVCU8IGcKYE OhK6aA+FsMpCywacEtGQtBzNHrG+g/om90jdr7jMrv2yJRGhvn2AOqN1v/PtjphN Rf8Pwg2kbYqKttzXghs8+eOF7nckra4oiboKY7jeAuy2bbyasgVqtQalcoA9Dyd2 hGLMjZwVX+3FoCq4wRu098WyOqo1mu/3SVycEFCx3nRPh8XZpmAcdZsvXUpAYp2C 4EqUkQpMQB97uQDfgaiussp5vJzgwQOY81OipH0zzlioFU96LFO4BBuNE7jmIjGj dzIA8VHKmpX8iJvKeAvlGSXsFldi3hHzD8f/B5Xf/rJ5QPFhc9jHHaVmLMCXcVkm FVR/DSjNWAe1rvRU34ZZ =iwND -----END PGP SIGNATURE----- From wk at gnupg.org Wed Aug 6 15:37:46 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Aug 2014 15:37:46 +0200 Subject: import filter In-Reply-To: <53E21D37.7080408@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Wed, 06 Aug 2014 14:19:03 +0200") References: <5564A372-2306-4E6E-9B80-6B88C80AE982@gpgtools.org> <53E21D37.7080408@sumptuouscapital.com> Message-ID: <87egwt4u39.fsf@vigenere.g10code.de> On Wed, 6 Aug 2014 14:19, kristian.fiskerstrand at sumptuouscapital.com said: > See the thread starting at [0] and bug 1680. I'll start working on it now. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Aug 6 17:13:07 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Aug 2014 17:13:07 +0200 Subject: import filter In-Reply-To: <87egwt4u39.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 06 Aug 2014 15:37:46 +0200") References: <5564A372-2306-4E6E-9B80-6B88C80AE982@gpgtools.org> <53E21D37.7080408@sumptuouscapital.com> <87egwt4u39.fsf@vigenere.g10code.de> Message-ID: <878un14poc.fsf@vigenere.g10code.de> On Wed, 6 Aug 2014 15:37, wk at gnupg.org said: > and bug 1680. I'll start working on it now. STABLE-BRANCH-2-0 has the fix. I'd appreciate if someone can test that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Wed Aug 6 17:33:35 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 06 Aug 2014 17:33:35 +0200 Subject: import filter In-Reply-To: <878un14poc.fsf@vigenere.g10code.de> References: <5564A372-2306-4E6E-9B80-6B88C80AE982@gpgtools.org> <53E21D37.7080408@sumptuouscapital.com> <87egwt4u39.fsf@vigenere.g10code.de> <878un14poc.fsf@vigenere.g10code.de> Message-ID: <53E24ACF.6060700@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 08/06/2014 05:13 PM, Werner Koch wrote: > On Wed, 6 Aug 2014 15:37, wk at gnupg.org said: > >> and bug 1680. I'll start working on it now. > > STABLE-BRANCH-2-0 has the fix. I'd appreciate if someone can test > that. Thanks, now it works for me $ g10/gpg2 --version gpg (GnuPG) 2.0.26-beta6 libgcrypt 1.7.0-beta102 $ g10/gpg2 --recv-key 0xFC3B17DE05E136A0 gpg: requesting key 0xFC3B17DE05E136A0 from hkp server 192.168.0.33 gpg: key 0x0B7F8B60E3EDFAE3: "Kristian Fiskerstrand " not changed gpg: Total number processed: 1 gpg: unchanged: 1 - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Pr?venire melius est quam pr?veniri It is better to precede than to be preceded -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT4kq6AAoJEPw7F94F4Tago/sP/Rz9NsVjAAOn9TQmkb5yUqaP PT1fZYXn7kdqufg0qgzXY1tdLgBIaLO15YnzvfQSL29p5Ss0Y3Qb515doArwyYk/ qaHocD9xE9RLoh4isvD8G2AwvbTgrq9OTXc01GtoThwmEO0l6ECypsc8zlelfF// WgD2J6qx/XbgZMS96Mh4HRktMRwMHqJ34wuixkunP6GhkOfYdY11ktGY5vK4deok e2Q9WWOguWz8mtGKQl4bYJtFw3xLuBxdYhc87yYMQ0GhrMo/5X3XwZT68KnZ6tLt /bqCVsRbXNijRS2pOt+gTRwCNaM4Br4XOwGxHPMnh49i9iyXHVNe+qCEdYs3whBg ukYckt7Y+NdQ3D/Hh5MDOpY5uk26OZP+mEk4VxoNbYybH1ce4bmUFi2eDyOYTdOC DgocNAd/CBRtZyVpAzJTKZfCll6hUjPhtc/8h0riBieAqK+8DWix+4hfmVxj4Lp4 ggodk+v3gFO/mzFaNS05neBcqMQZUQOCIOym9veOeS08Onre9PgNYkBF2SmKOqP1 xBykQ2NRdz3N4Iv2Vfv9kDn2kck9Tepyjw5KV7P0iuIyP25/STOl0E6xWuMdLCpr rp0j3qbguZhIPshgW549CU8Kd7hZ2gIA15NDpOPA4g/ak+iSx1X8aMgXxUiEmvrj OODiGKaOZymdTG0asrul =U2QG -----END PGP SIGNATURE----- From wk at gnupg.org Wed Aug 6 18:28:11 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Aug 2014 18:28:11 +0200 Subject: import filter In-Reply-To: <53E24ACF.6060700@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Wed, 06 Aug 2014 17:33:35 +0200") References: <5564A372-2306-4E6E-9B80-6B88C80AE982@gpgtools.org> <53E21D37.7080408@sumptuouscapital.com> <87egwt4u39.fsf@vigenere.g10code.de> <878un14poc.fsf@vigenere.g10code.de> <53E24ACF.6060700@sumptuouscapital.com> Message-ID: <87r40t37ms.fsf@vigenere.g10code.de> On Wed, 6 Aug 2014 17:33, kristian.fiskerstrand at sumptuouscapital.com said: > Thanks, now it works for me Thanks for testsing. Let me quickly backport it to 1.4. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lukele at gpgtools.org Wed Aug 6 19:14:36 2014 From: lukele at gpgtools.org (Lukas Pitschl) Date: Wed, 6 Aug 2014 19:14:36 +0200 Subject: --passphrase-fd only works when combined with --batch In-Reply-To: <87zjfh37ot.fsf@vigenere.g10code.de> References: <7C9F33C2-8846-4826-9C82-7444AB89B5DE@gpgtools.org> <87zjfh37ot.fsf@vigenere.g10code.de> Message-ID: Hi Werner, et al, Am 06.08.2014 um 18:26 schrieb Werner Koch : > You don't need to care about the passphrase-id - leave that to gpg-agent > and pinentry. It does a much better job than what one can implement in > a MUA etc. With 2.1 this even more important. 2.0 and the gpg-agent > are more than a decade old. Stop using such hacks. > We?re very aware that 2.0 and gpg-agent are very old and can?t wait for 2.1 to be released. > If you need another integration into the GUI, you may want to look at > what the guardianproject did for Android (pinentry daemon). > We?ll definitely have a look at their implementation. Our request is based on the use case described in the previous email. Since we want to create a key pair and the revocation certificate in one step, pinentry would popup at least 3 times. Once for the passphrase for the key being generated, once for the confirmation of the passphrase and once for the revocation certificate to be created. Unfortunately that?s a pretty terrible user experience. > >> Before applying this patch to our MacGPG2 version of gnupg we wanted >> to know if there?s a specific reason or anything we?re overseeing, why >> this requirement makes sense. > > I am a bit surprised that you do not use gnupg-devel@ for development > questions. It would help to understand that the MacGPG stuff is > quite different from standard GnuPG. There are some patches which I > consider problematic enough not to suggest gpgtools anymore. > Not posting to gnupg-devel was a mistake, I didn?t think twice and had your email address popping up once I typed ?gnupg?, I apologize for that. It would be great if you could let us know which patches you find problematic. We?ve cleaned up our set of patches quite some time ago, since many were no longer necessary. Those that still exists are pretty Mac centric, but if any of them could be integrated into the upstream version, that would be great. Off topic, but an interesting question, since quite a few of our users are running into that problem. Would it very complicated to replace the locking algorithm currently using ?link" with a different one? ?link? doesn?t seem to properly work on network shares. > Let us please continue a discussion on gnupg-devel at gnupg.org so that the > public is involved. Feel free to forward this. > > > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > Best, Lukas GPGTools -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gniibe at fsij.org Thu Aug 7 01:12:51 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 07 Aug 2014 08:12:51 +0900 Subject: FAQ: Re: key length In-Reply-To: <20140806214045.00001972.ecki@lina.inka.de> References: <53D06E85.7080903@sixdemonbag.org> <53D0D9C6.1080807@sixdemonbag.org> <201407311021.13108.bernhard@intevation.de> <1407318315.2152.2.camel@latx1.gniibe.org> <20140806214045.00001972.ecki@lina.inka.de> Message-ID: <1407366771.1549.1.camel@cfw2.gniibe.org> On 2014-08-06 at 21:40 +0200, Bernd Eckenfels wrote: > does the Card interface (and therefore the private key) in any way > influence what signing/encryption keys are accepted or checked? In the OpenPGP card protocol specification, there are "key attributes". When we execute the command line: 'gpg --card-status', we see the information which is something like: Key attributes ...: 2048R 2048R 2048R (It's the case for Gnuk Token.) It means that it supports RSA 2048-bit for signing, decryption, and authentication. Card implementation can support multiple key lengths. There is a bit defined in the extended card capabilities, and when it's set, host can write the key attributes to change its key length (if such a key length is supported by card). > If I have a large key I dont care if others can only produce smaller > keys, as long as they can communicate with me, right? How/Where to put private keys is up to users, and majority of users don't use OpenPGP cards (yet), but there are no problem for OpenPGP communication itself. Besides, OpenPGP card only handles private keys; it helps use of OpenPGP, but it doesn't cover all of OpenPGP operations. It just means: You can't put your private keys to (some) OpenPGP card implementation if its key size or algorithm is not supported by the card/token. When we consider a use-case of OpenPGP encryption to send a message to multiple users, easiest target (to be attacked) could be weakest link. So, it matters, smallest key size, weakest algorithm, or where private keys are. -- From hans at guardianproject.info Thu Aug 7 02:02:11 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 06 Aug 2014 20:02:11 -0400 Subject: --passphrase-fd only works when combined with --batch In-Reply-To: References: <7C9F33C2-8846-4826-9C82-7444AB89B5DE@gpgtools.org> <87zjfh37ot.fsf@vigenere.g10code.de> Message-ID: <53E2C203.6030309@guardianproject.info> Lukas Pitschl wrote: > Hi Werner, et al, > > Am 06.08.2014 um 18:26 schrieb Werner Koch : > >> You don't need to care about the passphrase-id - leave that to gpg-agent >> and pinentry. It does a much better job than what one can implement in >> a MUA etc. With 2.1 this even more important. 2.0 and the gpg-agent >> are more than a decade old. Stop using such hacks. >> > > We?re very aware that 2.0 and gpg-agent are very old and can?t wait for 2.1 to be released. > >> If you need another integration into the GUI, you may want to look at >> what the guardianproject did for Android (pinentry daemon). >> > > We?ll definitely have a look at their implementation. Our request is based on the use case described in the previous email. > Since we want to create a key pair and the revocation certificate in one step, pinentry would popup at least 3 times. > Once for the passphrase for the key being generated, once for the confirmation of the passphrase and once for the revocation certificate to be created. Unfortunately that?s a pretty terrible user experience. Even though it was much more painful implementing pinentry for Android than it will be for Mac OS X, I definitely recommend that for the approach. I don't know if this came up yet in this discussion, but if gpgtools uses pinentry, then gpg-agent handles all the password prompting and caching. .hc >> >>> Before applying this patch to our MacGPG2 version of gnupg we wanted >>> to know if there?s a specific reason or anything we?re overseeing, why >>> this requirement makes sense. >> >> I am a bit surprised that you do not use gnupg-devel@ for development >> questions. It would help to understand that the MacGPG stuff is >> quite different from standard GnuPG. There are some patches which I >> consider problematic enough not to suggest gpgtools anymore. >> > > Not posting to gnupg-devel was a mistake, I didn?t think twice and had your email address popping up once I typed ?gnupg?, I apologize for that. > It would be great if you could let us know which patches you find problematic. We?ve cleaned up our set of patches quite some time ago, since many were no longer necessary. Those that still exists are pretty Mac centric, but if any of them could be integrated into the upstream version, that would be great. > > Off topic, but an interesting question, since quite a few of our users are running into that problem. > Would it very complicated to replace the locking algorithm currently using ?link" with a different one? > ?link? doesn?t seem to properly work on network shares. > > >> Let us please continue a discussion on gnupg-devel at gnupg.org so that the >> public is involved. Feel free to forward this. >> >> >> Shalom-Salam, >> >> Werner >> >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> > > Best, > > Lukas > GPGTools > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From gniibe at fsij.org Thu Aug 7 03:18:00 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 07 Aug 2014 10:18:00 +0900 Subject: po: Update Japanese (ja) Translation Message-ID: <1407374280.1549.3.camel@cfw2.gniibe.org> Hello, I'm going to update gnupg/po/ja.po of master (and 2.0.x). Please let me know about commit message and ChangeLog Entry, if it's better to be ChangeLog Entry or not. Yesterday, when I committed for libgpg-error, I followed the last update of other translation, where commit msg was: Update pl.po (to be ChangeLog Entry). Today, I looked for gnupg, and the practice of such doc changes seems not in ChangeLog Entry (commit msg with the marker line). -- From bernhard at intevation.de Thu Aug 7 09:08:22 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 7 Aug 2014 09:08:22 +0200 Subject: FAQ: Re: key length In-Reply-To: <53D0D9C6.1080807@sixdemonbag.org> References: <53D06E85.7080903@sixdemonbag.org> <53D0D9C6.1080807@sixdemonbag.org> Message-ID: <201408070908.29628.bernhard@intevation.de> On Thursday 24 July 2014 at 12:02:46, Robert J. Hansen wrote: > Q: Is there a general recommendation that 3072-bit keys be used for > ? ?new applications? > A: No, although some respected people and groups within the > ? ?cryptographic community have made such recommendations. Another datapoint: in iX 5/2014 (page 83) they rate RSA 2048 only as "medium" secure and recommend at least 4096 to be save. Citing them: "bei RSA. Wer sichergehen will, sollte auch hier mindestens 4096 Bit einsetzen." Authors are Dominique Petersen and Nobert Pohlmann. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Aug 7 14:02:10 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Aug 2014 14:02:10 +0200 Subject: FOSDEM devroom Message-ID: <87iom4zewt.fsf@vigenere.g10code.de> Hi, the next FOSDEM will be on January 31/February 1 weekend in Brussels. Last year we had a BoF slot at an not easy to find room. What do you think of asking for a devroom. I would suggest OpenPGP as the main topic and like to collect ideas for the schedule. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Thu Aug 7 14:40:17 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 07 Aug 2014 14:40:17 +0200 Subject: FOSDEM devroom In-Reply-To: <87iom4zewt.fsf@vigenere.g10code.de> References: <87iom4zewt.fsf@vigenere.g10code.de> Message-ID: <53E373B1.3080702@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 08/07/2014 02:02 PM, Werner Koch wrote: > Hi, > > the next FOSDEM will be on January 31/February 1 weekend in > Brussels. Last year we had a BoF slot at an not easy to find room. > What do you think of asking for a devroom. I would suggest OpenPGP > as the main topic and like to collect ideas for the schedule. Sounds like a good idea with an OpenPGP devroom to me. If there is interest for it in the schedule I'm available to participate and talk about keyservers and keyserver pools[0]. [0] If there is anyone in the Oslo, Norway area I will also be talking about this on the Norwegian Unix User Group's monthly meeting on 9 September, this will also be streamed live. Although the talk is in Norwegian I've made the presentation in English so this will be available afterwards. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "If you don't drive your business, you will be driven out of business" (B. C. Forbes) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT43OqAAoJEPw7F94F4Tag53AP/0K1TcgG7nbsO2D32rwVp9r3 yiZfViAGzfXy32xFFodBU17rKczuyuKaKRMcBCxCLtd9CgC+QxloS3y/Z0WreSqv Or2sm3ZKbcQQffDwX7tHYLdJLjXtRcXn3MwJHBjD/oOurctI+h2k8n9Id/l4Bjuk HDSUbkgeTtxViYg3xsGIcmEvuUC/4ODMdqTKH2VSmxmPTMTITc5+rm4zbglJP+1d 0rgQJXbF14kQHEDz6vAgW/cLqzIJuEfKHq/KZRPiFZzkCTT73NpNcw1guYUsF5kg 5Qm7tepsS1I2S8BhkyhsoR7J3UY1e7ooiJfdvRcG+MFt9/2T2UgwtV6iPbKPmFZZ 94rPYSGSKpftxLJHtCRn4YLf1jYE7SelMWX5a5rBzYLQOeEbxyEY5Fd4UtogxESv iOibwRsGdSfXas6P1r25sj0kbq6vao+KFZxjCxm0rc+3xGz/+hR0Ep2aeoOLR3S4 9v5AsqimBwjMCsBzPlt2bBOnHgB5Bsxlko1srQcQeSA1BU0hrKabiRhrBWhZIitY 52KS86dRNw7HfYPYlmAPqQSm2tO3NPH++znU9AtnErLAFTfmF2dLBxXpE9fl2g9b QmoV8sXMzcoDHA9+t+Zdkxqt4qBvZmxVqdNQL3+Tmxi7GGe/Lrhu0hkriNwaZ049 s4ysy9a9QlDeAV+RKwPd =rqDH -----END PGP SIGNATURE----- From wk at gnupg.org Thu Aug 7 14:44:51 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Aug 2014 14:44:51 +0200 Subject: [Announce] GnuPG is NOT vulnerable to -Get Your Hands Off My Laptop- Message-ID: <87bnrwzcxo.fsf@vigenere.g10code.de> Hello! This is a note about an improved side-channel attack on old versions of GnuPG. Daniel Genkin, Itamar Pipman, and Eran Tromer latest research on side channel attacks is described in the paper Get Your Hands Off My Laptop: Physical Side-Channel Key-Extraction Attacks On PCs They target an older version of GnuPG and come up with awesome results: We demonstrate physical side-channel attacks on a popular software implementation of RSA and ElGamal, running on laptop computers. Our attacks use novel side channels, based on the observation that the "ground" electric potential, in many computers, fluctuates in a computation-dependent way. An attacker can measure this signal by touching exposed metal on the computer's chassis with a plain wire, or even with a bare hand. The signal can also be measured at the remote end of Ethernet, VGA or USB cables. Through suitable cryptanalysis and signal processing, we have extracted 4096-bit RSA keys and 3072-bit ElGamal keys from laptops, via each of these channels, as well as via power analysis and electromagnetic probing. Despite the GHz-scale clock rate of the laptops and numerous noise sources, the full attacks require a few seconds of measurements using Medium Frequency signals (around 2 MHz), or one hour using Low Frequency signals (up to 40 kHz). See http://www.cs.tau.ac.il/~tromer/handsoff for more. If your GnuPG version is up-to-date there is nothing you need to do! As noted in the paper GnuPG 1.4.16 and later are not vulnerable to the attack. GnuPG 2.x and Gpg4win 2.x are not vulnerable, either. However, if you are still using a GnuPG version older than 1.4.16 you should update to at least 1.4.16 but better to 1.4.18. Note that those version numbers are for the generic GnuPG versions from gnupg.org. Some Linux distributions may have an older version but all major distributions have applied respective security fixes back in December or January. Watching out for possible security problems and working with researches to fix them takes a lot of time. g10 Code GmbH, a German company owned and headed by me, is bearing these costs. To help us carry on this work, we need your support; please see https://gnupg.org/donate/ . Shalom-Salam, 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: 180 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 Thu Aug 7 15:43:07 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Aug 2014 15:43:07 +0200 Subject: po: Update Japanese (ja) Translation In-Reply-To: <1407374280.1549.3.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 07 Aug 2014 10:18:00 +0900") References: <1407374280.1549.3.camel@cfw2.gniibe.org> Message-ID: <8738d8za8k.fsf@vigenere.g10code.de> On Thu, 7 Aug 2014 03:18, gniibe at fsij.org said: > Hello, > > I'm going to update gnupg/po/ja.po of master (and 2.0.x). > > Please let me know about commit message and ChangeLog Entry, if it's > better to be ChangeLog Entry or not. > > Yesterday, when I committed for libgpg-error, I followed the last > update of other translation, where commit msg was: Update pl.po > (to be ChangeLog Entry). Unless it is a small typo fix I would use just the subject line like in po: Update the German (de) translation without a "* po/de.po: Update". If you fix a format string error or similar a regular ChangeLog entry would be goodm though. After all the ChangeLog shall help to quickly see what changed and whether this is relevant for other parts of the code or if it fixes a bug. ChangeLog entries shall all be brief, longer explanations after the "--". BTW, use GnuPG-bug-id: NNNN or/and Debian-bug-id: NNNN after a "--" line to connect it to the BTS. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Aug 7 15:51:56 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Aug 2014 15:51:56 +0200 Subject: FAQ: Re: key length In-Reply-To: <1407366771.1549.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 07 Aug 2014 08:12:51 +0900") References: <53D06E85.7080903@sixdemonbag.org> <53D0D9C6.1080807@sixdemonbag.org> <201407311021.13108.bernhard@intevation.de> <1407318315.2152.2.camel@latx1.gniibe.org> <20140806214045.00001972.ecki@lina.inka.de> <1407366771.1549.1.camel@cfw2.gniibe.org> Message-ID: <87y4v0xv9f.fsf@vigenere.g10code.de> On Thu, 7 Aug 2014 01:12, gniibe at fsij.org said: > Card implementation can support multiple key lengths. There is a bit > defined in the extended card capabilities, and when it's set, host can > write the key attributes to change its key length (if such a key Let me remark that there is no way to know what key length are supported by the card. Unless we want to checkout the vendor and ranges of card numbers. This is the reason why you see a warning prompt if you try to use a different key length. > It just means: You can't put your private keys to (some) OpenPGP card > implementation if its key size or algorithm is not supported by the > card/token. Hopefully we will eventually settle for Ed25519 and Curve25519 as standard algorithms. It is definitely something I like to see in a new card or a "mass" production gnuk token. The recent USB firmware hacks may actually help to favor a non-secure chip with open firmware (gnuk) over an unknown-firmware card-reader+card solution. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Aug 7 15:54:34 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Aug 2014 15:54:34 +0200 Subject: FAQ: Re: key length In-Reply-To: <201408070908.29628.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 7 Aug 2014 09:08:22 +0200") References: <53D06E85.7080903@sixdemonbag.org> <53D0D9C6.1080807@sixdemonbag.org> <201408070908.29628.bernhard@intevation.de> Message-ID: <87tx5oxv51.fsf@vigenere.g10code.de> On Thu, 7 Aug 2014 09:08, bernhard at intevation.de said: > Another datapoint: > in iX 5/2014 (page 83) they rate RSA 2048 only as "medium" secure > and recommend at least 4096 to be save. Well, if you have put your laptop in Faraday cage, run it on battery power, and connect it via fiber, that is something to consider. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Thu Aug 7 16:29:58 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 7 Aug 2014 16:29:58 +0200 Subject: FAQ: Re: key length In-Reply-To: <87tx5oxv51.fsf@vigenere.g10code.de> References: <201408070908.29628.bernhard@intevation.de> <87tx5oxv51.fsf@vigenere.g10code.de> Message-ID: <201408071630.05250.bernhard@intevation.de> On Thursday 07 August 2014 at 15:54:34, Werner Koch wrote: > On Thu, ?7 Aug 2014 09:08, bernhard at intevation.de said: > > Another datapoint: > > in iX 5/2014 (page 83) they rate RSA 2048 only as "medium" secure > > and recommend at least 4096 to be save. > > Well, if you have put your laptop in Faraday cage, run it on battery > power, and connect it via fiber, that is something to consider. You realize that your response is not an argument. I have given the datapoint to show that there are credible people recommending 4096 bits. So it seem natuarl that less savy users ask us about it. Our argumentation must be better then this, if we want to explain it to users and to convince them. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Aug 7 17:16:26 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Aug 2014 17:16:26 +0200 Subject: FAQ: Re: key length In-Reply-To: <201408071630.05250.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 7 Aug 2014 16:29:58 +0200") References: <201408070908.29628.bernhard@intevation.de> <87tx5oxv51.fsf@vigenere.g10code.de> <201408071630.05250.bernhard@intevation.de> Message-ID: <8761i4xrcl.fsf@vigenere.g10code.de> On Thu, 7 Aug 2014 16:29, bernhard at intevation.de said: > You realize that your response is not an argument. Long time readers of this list understand what I am saying: To evaluate security risks it is useless to pick one component of a large system and believe you are done. and I also expected that you read today's security note. > I have given the datapoint to show that there are credible people > recommending 4096 bits. So it seem natuarl that less savy users and they are not talking about a system but an isolated algorithm. > ask us about it. Our argumentation must be better then this, > if we want to explain it to users and to convince them. Right, let's leave the bike shedding to others. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Aug 7 17:08:49 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Aug 2014 17:08:49 +0200 Subject: [Announce] [security] GPGME 1.5.1 and 1.4.4 released Message-ID: <87bnrwxrpa.fsf@vigenere.g10code.de> Hello! I am pleased to announce version 1.5.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. This is a security fix release and it is suggested to update to this version. Given that the 1.5 versions are quite new and implement features which may raise problems with some software, I also released version 1.4.4 with backported fixes. * Noteworthy changes in version 1.5.1 (2014-07-30) - Fixed possible overflow in gpgsm and uiserver engines. [CVE-2014-3564] - Added support for GnuPG 2.1's --with-secret option. - Interface changes relative to the 1.5.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GPGME_KEYLIST_MODE_WITH_SECRET NEW. * Noteworthy changes in version 1.4.4 (2014-07-30) - Fixed possible overflow in gpgsm and uiserver engines. [CVE-2014-3564] - Fixed possibled segv in gpgme_op_card_edit. - Fixed minor memleaks and possible zombie processes. - Fixed prototype inconsistencies and void pointer arithmetic. * Download You may download version 1.5.1 from: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.1.tar.bz2 (943k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.1.tar.bz2.sig You may download version 1.4.4 from: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.4.tar.bz2 (936k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.4.tar.bz2.sig SHA-1 checksums are: a91c258e79acf30ec86a667e07f835e5e79342d8 gpgme-1.5.1.tar.bz2 1f9f668886c25467987a11c0d37c45e1ffe66b8e gpgme-1.4.4.tar.bz2 * Support Please send questions regarding the use of GPGME to the gnupg-devel mailing list: https://lists.gnupg.org/mailman/listinfo/gnupg-devel/ If you need commercial support, you may want to consult this listing: https://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: https://gnupg.org/donate/ Shalom-Salam, 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: 180 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 coruus at gmail.com Thu Aug 7 17:52:29 2014 From: coruus at gmail.com (David Leon Gil) Date: Thu, 7 Aug 2014 11:52:29 -0400 Subject: Key length for integer- and finite-field cryptography Message-ID: So, NIST SP800-57, Table 3, security strength equivalents for finite- and integer- field cryptography: 80-bit equivalent: 1024 bits 112-bit equivalent: 2048 bits 128-bit equivalent: 3072 bits 192-bit equivalent: 7680 bits 256-bit equivalent: 15360 bits Take-home: If you are using AES-256, you should max out your key size in GnuPG. (It is regrettable that only some versions seem to support strong key-sizes.) -- Re requirements: NIST SP800-57 Table 4 requires that applications not use 1024-bit keys. 112-bit security strength is required; thus 2048-bit keys are the *minimum* length in any FIPS-compliant environment. -- Here's a Stack Overflow question which explains, essentially, how these security-strength numbers are derived: http://crypto.stackexchange.com/questions/17798/how-to-calculate-bit-strength-of-integer-factorization-cryptography-ifc-such-a - dlg From rjh at sixdemonbag.org Thu Aug 7 19:32:27 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 07 Aug 2014 13:32:27 -0400 Subject: Key length for integer- and finite-field cryptography In-Reply-To: References: Message-ID: <53E3B82B.8000007@sixdemonbag.org> > Take-home: If you are using AES-256, you should max out your key size > in GnuPG. (It is regrettable that only some versions seem to support > strong key-sizes.) Good grief, *no*, *no*, *no*. This keeps on getting dusted off, and the answer never changes. Please forgive me if I'm a little irate here, but I'm getting really tired of people who bring this up without checking the mailing list history. *If you require 256 bits of entropy throughout, you need to use something other than GnuPG.* PGP stands for "Pretty Good Privacy." Not perfect privacy, just pretty good, and not 256 bits of entropy through-and-through. In fact, OpenPGP can only really be relied upon to provide 112 bits of entropy[*]. The take-home is the same as it's always been. "If you need X bits of entropy, check to make sure each step in the link provides at least X bits. If some provide more, that's fine." The average user will be well-served by 112 bits of entropy. That means RSA-2048 works just fine for the average case. If a user who's well-served by 112 bits of entropy wants to use AES-256, there's nothing wrong with that, and the suggestion that they should revoke their certificate and patch GnuPG to produce 16kbit keys is *just* *flamingly* *wrong*. Using AES-256 is *not* a good reason to start using RSA-16k. [*] if you want to know why this is the case, check the mailing list. Short version: you have no control over what algorithms your correspondents use, and they can always choose 3DES. From coruus at gmail.com Thu Aug 7 20:30:57 2014 From: coruus at gmail.com (David Leon Gil) Date: Thu, 7 Aug 2014 14:30:57 -0400 Subject: Key length for integer- and finite-field cryptography In-Reply-To: <53E3B82B.8000007@sixdemonbag.org> References: <53E3B82B.8000007@sixdemonbag.org> Message-ID: On Thursday, August 7, 2014, Robert J. Hansen wrote: > Good grief, *no*, *no*, *no*. > > *If you require 256 bits of entropy throughout, you need to use something > other than GnuPG.* Generally agreed. (I'm assuming you mean 'security strength' when you write 'entropy'; hopefully GnuPG can use arbitrary amounts of entropy if the system RNG can provide it.) > The take-home is the same as it's always been. "If you need X bits of > entropy, check to make sure each step in the link provides at least X bits. > If some provide more, that's fine." Completely in agreement; do you disagree with the RSA bit-lengths I mentioned? Using AES-256 is *not* a good reason to start using RSA-16k. But wanting a 256-bit security strength is, right? - dlg -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Aug 7 20:48:49 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Aug 2014 20:48:49 +0200 Subject: [Announce] Libgcrypt 1.5.4 released Message-ID: <87mwbgw2y6.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce an update of the Libgcrypt 1.5 series: version 1.5.4. This is a maintenance release with backports of fixes from the current stable 1.6 series. In general it is preferable to use the latest stable version. However, the 1.6 series introduced an ABI break and thus some older software may not build or work correctly with 1.6. Libgcrypt is a general purpose library of cryptographic building blocks. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required for proper use Libgcrypt. Noteworthy changes in version 1.5.4 (2014-08-07) ================================================ * Declare 2016-12-31 as end-of-life for 1.5. Backported from 1.6: * Improved performance of RSA, DSA, and Elgamal by using a new exponentiation algorithm. * Fixed a subtle bug in mpi_set_bit which could set spurious bits. * Fixed a bug in an internal division function. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.4.tar.bz2 (1478k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.4.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.4.tar.gz (1763k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.4.tar.gz.sig Alternativley you may upgrade using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.3-1.5.4.diff.bz2 (17k) In order to check that the version of Libgcrypt you are going to build is an original and unmodified one, you can do it in one of the following ways: * Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.5.4.tar.bz2 you would use this command: gpg --verify libgcrypt-1.5.4.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 the release signing key 4F25E3B6 which is certified by my well known key 1E42B367. To retrieve the keys you may use the command "gpg --fetch-key finger:wk at g10code.com". * If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.5.4.tar.bz2 and check that the output matches the first line from the following list: bdf4b04a0d2aabc04ab3564fbe38fd094135aa7a libgcrypt-1.5.4.tar.bz2 71e432e0ae8792076a40c6059667997250abbb9d libgcrypt-1.5.4.tar.gz 8876ae002751e6ec26c76e510d17fc3e0eccb3ed libgcrypt-1.5.3-1.5.4.diff.bz2 Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt 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://gnupg.org/donate/ Thanks ====== Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] https://gnupg.org/service.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: 180 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 rjh at sixdemonbag.org Thu Aug 7 21:21:27 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 07 Aug 2014 15:21:27 -0400 Subject: Key length for integer- and finite-field cryptography In-Reply-To: References: <53E3B82B.8000007@sixdemonbag.org> Message-ID: <53E3D1B7.70706@sixdemonbag.org> > Generally agreed. (I'm assuming you mean 'security strength' when > you write 'entropy'; hopefully GnuPG can use arbitrary amounts of > entropy if the system RNG can provide it.) No, I meant entropy. Entropy is a measurement, not a thing. (Well, not at the macro level. On a quantum scale it gets very thing-like.) For that reason it's not correct to say "GnuPG can use arbitrary amounts of entropy," because entropy isn't a thing to be used. Yes, you'll see people -- including me, from time to time -- talk about entropy as if it were a thing, but really, that's sloppy language and we (myself definitely included!) should strive for accuracy. Entropy measures the amount of uncertainty present in a system, and is normally calibrated in either nats, shannons or harts. "Bit" is used more or less synonymously with shannon, although really, we should be talking about shannons. One nat is 1.44 Sh or .434 harts. So, yes, I stand by what I said, except that if you're giving me the chance at a do-over I'll change one word. :) "If you need 256 shannons of entropy throughout, you need to use something other than GnuPG." > Completely in agreement; do you disagree with the RSA bit-lengths I > mentioned? NIST is a very reputable outfit with some very sharp people. No one should listen to my opinion over theirs. For that reason it doesn't matter if I agree or disagree with them. However, I will point out that there have been other very reputable outfits with other very sharp people who have reached different conclusions. ENISA's key equivalencies are different from NIST's, for instance... > Using AES-256 is *not* a good reason to start using RSA-16k. > > But wanting a 256-bit security strength is, right? Not really. Decisions ought be driven by needs, not by wants. If you can get more uncertainty than you need without heartburn, go for it, but telling people that they should patch GnuPG and use an unsupported RSA-16k key just because they want 256 shannons of entropy is ... a bit much. Attend to your needs, and take what opportunities present themselves for extra margins of safety where possible. But don't go overboard chasing those extra margins. From coruus at gmail.com Thu Aug 7 21:56:37 2014 From: coruus at gmail.com (David Leon Gil) Date: Thu, 7 Aug 2014 15:56:37 -0400 Subject: Key length for integer- and finite-field cryptography In-Reply-To: <53E3D1B7.70706@sixdemonbag.org> References: <53E3B82B.8000007@sixdemonbag.org> <53E3D1B7.70706@sixdemonbag.org> Message-ID: > ENISA's key equivalencies are different from NIST's Enisa surveys bit-length recommendations comprehensively; the NIST recommendation is always the *shortest* bit-length. 112-bit security: 2048 bits to 3154 bits 128-bit security 3072 bits to 5888 bits 256-bit security: 15360 bits to 46752(!) bits They recommend, for new cryptosystems, RSA keys of length at least 3072 bits if "near term" security is desired and 15360 bits if "long term" security is required. Enisa report, table 3.1 (p. 22), table 3.6 (p. 35): http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport The Enisa report is much better reading than the NIST recommendation, by the way. :) From dkg at fifthhorseman.net Fri Aug 8 00:19:46 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 7 Aug 2014 18:19:46 -0400 Subject: [PATCH] update libgpg-error Danish translation (from https://bugs.debian.org/754128) Message-ID: <1407449986-6173-1-git-send-email-dkg@fifthhorseman.net> From: Joe Hansen --- po/da.po | 50 +++++++++++++++----------------------------------- 1 file changed, 15 insertions(+), 35 deletions(-) diff --git a/po/da.po b/po/da.po index e5b4dce..24f8a2f 100644 --- a/po/da.po +++ b/po/da.po @@ -1,7 +1,7 @@ # Danish translation libgpg-error. -# Copyright (C) 2012 g10 Code GmbH og nedenst?ende overs?ttere. +# Copyright (C) 2014 g10 Code GmbH og nedenst?ende overs?ttere. # This file is distributed under the same license as the libgpg-error package. -# Joe Hansen , 2012. +# Joe Hansen , 2012, 2014. # # invalid -> ugyldig # bad -> ?delagt @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: libgpg-error 1.10\n" "Report-Msgid-Bugs-To: translations at gnupg.org\n" -"PO-Revision-Date: 2013-02-23 20:08+0100\n" +"PO-Revision-Date: 2014-07-07 20:08+0100\n" "Last-Translator: Joe Hansen \n" "Language-Team: Danish \n" "Language: da\n" @@ -320,10 +320,8 @@ msgstr "Ugyldigt svar" msgid "No agent running" msgstr "Ingen agent k?rer" -#, fuzzy -#| msgid "agent error" msgid "Agent error" -msgstr "agentfejl" +msgstr "Agentfejl" msgid "Invalid data" msgstr "Ugyldige data" @@ -655,48 +653,32 @@ msgstr "Ugyldig elliptisk kurve" msgid "Unknown elliptic curve" msgstr "Ukendt elliptisk kurve" -#, fuzzy -#| msgid "Duplicated value" msgid "Duplicated key" -msgstr "Duplikeret v?rdi" +msgstr "Duplikeret n?gle" -#, fuzzy -#| msgid "Ambiguous name" msgid "Ambiguous result" -msgstr "Tvetydigt navn" +msgstr "Tvetydigt resultat" -#, fuzzy -#| msgid "No crypto engine" msgid "No crypto context" -msgstr "Ingen cryptomotor" +msgstr "Ingen cryptokontekst" -#, fuzzy -#| msgid "No crypto engine" msgid "Wrong crypto context" -msgstr "Ingen cryptomotor" +msgstr "Forkert cryptokontekst" -#, fuzzy -#| msgid "Invalid crypto engine" msgid "Bad crypto context" -msgstr "Ugyldig cryptomotor" +msgstr "Ugyldig cryptokontekst" msgid "Conflict in the crypto context" -msgstr "" +msgstr "Konflikt i cryptokonteksten" -#, fuzzy -#| msgid "No public key" msgid "Broken public key" -msgstr "Ingen offentlig n?gle" +msgstr "?delagt offentlig n?gle" -#, fuzzy -#| msgid "No secret key" msgid "Broken secret key" -msgstr "Ingen hemmelig n?gle" +msgstr "?delagt hemmelig n?gle" -#, fuzzy -#| msgid "Invalid digest algorithm" msgid "Invalid MAC algorithm" -msgstr "Ugyldig sammendragsalgoritme" +msgstr "Ugyldig MAC-algoritme" msgid "Operation fully cancelled" msgstr "Handling fuldt afbrudt" @@ -747,12 +729,10 @@ msgid "Bad octal character in S-expression" msgstr "?delagt oktalt tegn i S-udtryk" msgid "Not possible with a card based key" -msgstr "" +msgstr "Ikke muligt med en kortbaseret n?gle" -#, fuzzy -#| msgid "Invalid object" msgid "Invalid lock object" -msgstr "Ugyldigt objekt" +msgstr "Ugyldigt l?seobjekt" msgid "General IPC error" msgstr "Generel IPC-fejl" -- 2.0.1 From gniibe at fsij.org Fri Aug 8 03:11:12 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 08 Aug 2014 10:11:12 +0900 Subject: po: Update Japanese (ja) Translation In-Reply-To: <8738d8za8k.fsf@vigenere.g10code.de> References: <1407374280.1549.3.camel@cfw2.gniibe.org> <8738d8za8k.fsf@vigenere.g10code.de> Message-ID: <1407460272.1568.1.camel@cfw2.gniibe.org> Thank you for your explanation. I updated GnuPG's po/ja.po for master and 2.0 branch. -- From bernhard at intevation.de Fri Aug 8 09:45:03 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 8 Aug 2014 09:45:03 +0200 Subject: FAQ: Re: key length In-Reply-To: <8761i4xrcl.fsf@vigenere.g10code.de> References: <201408071630.05250.bernhard@intevation.de> <8761i4xrcl.fsf@vigenere.g10code.de> Message-ID: <201408080945.09352.bernhard@intevation.de> On Thursday 07 August 2014 at 17:16:26, Werner Koch wrote: > On Thu, 7 Aug 2014 16:29, bernhard at intevation.de said: > > You realize that your response is not an argument. > > Long time readers of this list understand what I am saying: > > To evaluate security risks it is useless to pick one component of a > large system and believe you are done. > > and I also expected that you read today's security note. I know and I did. Still your comment was close to cynism in the eye of an unexperienced reader. ;) > > I have given the datapoint to show that there are credible people > > recommending 4096 bits. So it seem natuarl that less savy users > > and they are not talking about a system but an isolated algorithm. So your argument is "Because the asymmetric crypto algorithm at RSA at 2048bit is usually not the weakest link in your system, we usually do not recommend more bits."? So what is the common weakest link then? The symmetric cipher, the entropy source, the implementation issues in software and hardware (like side channel attacks)? My expectation is that we work together to get the default of a default OpenPGP system to be so strong that is provides 10 years security. At least my actions I can control. > > ask us about it. Our argumentation must be better then this, > > if we want to explain it to users and to convince them. > > Right, let's leave the bike shedding to others. I am making an effort writing to this list because I want crypto to succeed, especially GnuPG and Free Software. The question about default key length comes up so often, that a better explanation is helpful. So here I am exploring the arguments. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Aug 8 10:44:01 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Aug 2014 10:44:01 +0200 Subject: FAQ: Re: key length In-Reply-To: <201408080945.09352.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 8 Aug 2014 09:45:03 +0200") References: <201408071630.05250.bernhard@intevation.de> <8761i4xrcl.fsf@vigenere.g10code.de> <201408080945.09352.bernhard@intevation.de> Message-ID: <877g2jweum.fsf@vigenere.g10code.de> On Fri, 8 Aug 2014 09:45, bernhard at intevation.de said: > So what is the common weakest link then? > The symmetric cipher, the entropy source, the implementation issues in > software and hardware (like side channel attacks)? The ubiquitous exploitable bugs in all software, the OS, the MUAs, the "apps", the browser running foreign code on your box, social engineering, etc. > OpenPGP system to be so strong that is provides 10 years security. > At least my actions I can control. Never connect to the Net and you have a chance to control things. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Aug 8 10:54:27 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Aug 2014 10:54:27 +0200 Subject: Key length for integer- and finite-field cryptography In-Reply-To: (David Leon Gil's message of "Thu, 7 Aug 2014 15:56:37 -0400") References: <53E3B82B.8000007@sixdemonbag.org> <53E3D1B7.70706@sixdemonbag.org> Message-ID: <8738d7wed8.fsf@vigenere.g10code.de> On Thu, 7 Aug 2014 21:56, coruus at gmail.com said: > The Enisa report is much better reading than the NIST recommendation, > by the way. :) Do not forget that there is a political picture as well. The ENISA is new and they need to get the attention of politicians for raising budgets. What is easier than to favor higher key lengths, out of a quite fuzzy research process, to show then that the ENISA is more trustworthy than the NIST and that they should not trust NIST results. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Aug 8 12:17:06 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Aug 2014 12:17:06 +0200 Subject: [Announce] [security fix] Libgcrypt and GnuPG Message-ID: <87egwruvz1.fsf@vigenere.g10code.de> Hi! While evaluating the "Get Your Hands Off My Laptop" [1] paper I missed to describe [2] a software combination which has not been fixed and is thus vulnerable to the attack described by the paper. If you are using a GnuPG version with a *Libgcrypt version < 1.6.0*, it is possible to mount the described side-channel attack on Elgamal encryption subkeys. To check whether you are using a vulnerable Libgcrypt version, enter gpg2 --version on the command line; the second line of the output gives the Libgcrypt version: gpg (GnuPG) 2.0.25 libgcrypt 1.5.3 In this example Libgcrypt is vulnerable. If you see 1.6.0 or 1.6.1 you are fine. GnuPG versions since 1.4.16 are not affected because they do not use Libgcrypt. The recommendation is to update any Libgcrypt version below 1.6.0 to at least the latest version from the 1.5 series which is 1.5.4. Updating to 1.6.1 is also possible but that requires to rebuild GnuPG. Libgcrypt 1.5.4 has been released yesterday [3]; for convenience I include the download instructions below. A CVE-id has not yet been assigned. Many thanks to Daniel Genkin for pointing out this problem. Shalom-Salam, Werner [1] http://www.cs.tau.ac.il/~tromer/handsoff [2] http://lists.gnupg.org/pipermail/gnupg-announce/2014q3/000349.html [3] http://lists.gnupg.org/pipermail/gnupg-announce/2014q3/000351.html Download ======== Libgcrypt source code is hosted at the GnuPG FTP server and its mirrors as listed at https://www.gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.4.tar.bz2 (1478k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.4.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.4.tar.gz (1763k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.4.tar.gz.sig Alternativley you may upgrade using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.3-1.5.4.diff.bz2 (17k) In order to check that the version of Libgcrypt you are going to build is an original and unmodified one, you can do it in one of the following ways: * Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.5.4.tar.bz2 you would use this command: gpg --verify libgcrypt-1.5.4.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 the release signing key 4F25E3B6 which is certified by my well known key 1E42B367. To retrieve the keys you may use the command "gpg --fetch-key finger:wk at g10code.com". * If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.5.4.tar.bz2 and check that the output matches the first line from the following list: bdf4b04a0d2aabc04ab3564fbe38fd094135aa7a libgcrypt-1.5.4.tar.bz2 71e432e0ae8792076a40c6059667997250abbb9d libgcrypt-1.5.4.tar.gz 8876ae002751e6ec26c76e510d17fc3e0eccb3ed libgcrypt-1.5.3-1.5.4.diff.bz2 Watching out for possible security problems and working with researches to fix them takes a lot of time. g10 Code GmbH, a German company owned and headed by me, is bearing these costs. To help us carry on this work, we need your support; please see https://gnupg.org/donate/ . -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 serge0x76 at gmail.com Fri Aug 8 21:52:27 2014 From: serge0x76 at gmail.com (Serge Voilokov) Date: Fri, 8 Aug 2014 15:52:27 -0400 Subject: [PATCH] New pinentry-tty version for dumb terminals. Message-ID: <1407527547-30686-1-git-send-email-serge0x76@gmail.com> Hi, I added version of pinentry tool for dumb terminals (pinentry-tty). Please consider adding this to pinentry project. Thanks, Serge >8-----------------------------------------------8< * .gitignore(insert): added pinentry-tty related files. * Makefile.am(insert): added pinentry-tty. * NEWS(insert): added news about pinentry-tty. * README(insert): added readme. * configure.ac(insert): added tty/Makefile. * tty/Makefile.am(add): am for pinentry-tty. * tty/pinentry-tty.c(add): dumb console version. --- .gitignore | 2 + Makefile.am | 8 ++- NEWS | 2 + README | 1 + configure.ac | 20 ++++++ tty/Makefile.am | 31 +++++++++ tty/pinentry-tty.c | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 256 insertions(+), 1 deletion(-) create mode 100644 tty/Makefile.am create mode 100644 tty/pinentry-tty.c diff --git a/.gitignore b/.gitignore index 575e011..9395e3c 100644 --- a/.gitignore +++ b/.gitignore @@ -34,6 +34,8 @@ secmem/Makefile.in secmem/Makefile w32/Makefile.in w32/Makefile +tty/Makefile.in +tty/Makefile /qt4/pinentryconfirm.moc /qt4/pinentrydialog.moc diff --git a/Makefile.am b/Makefile.am index f4fa814..a3fa819 100644 --- a/Makefile.am +++ b/Makefile.am @@ -35,6 +35,12 @@ else pinentry_curses = endif +if BUILD_PINENTRY_TTY +pinentry_tty = tty +else +pinentry_tty = +endif + if BUILD_PINENTRY_GTK pinentry_gtk = gtk else @@ -65,7 +71,7 @@ else pinentry_w32 = endif -SUBDIRS = assuan secmem pinentry ${pinentry_curses} \ +SUBDIRS = assuan secmem pinentry ${pinentry_curses} ${pinentry_tty} \ ${pinentry_gtk} ${pinentry_gtk_2} ${pinentry_qt} ${pinentry_qt4} \ ${pinentry_w32} doc diff --git a/NEWS b/NEWS index 5bd874f..28d3c80 100644 --- a/NEWS +++ b/NEWS @@ -1,6 +1,8 @@ Noteworthy changes in version 0.8.4 (unreleased) ------------------------------------------------ + * New pinentry-tty version for dump terminals. + * Qt4: New option to enable pasting the passphrase from clipboard * Qt4: Improved accessiblity diff --git a/README b/README index 087208a..6bb0d85 100644 --- a/README +++ b/README @@ -17,6 +17,7 @@ GTK+ V2.0 --enable-pinentry-gtk2 Gimp Toolkit Library, Version 2.0 eg. libgtk-x11-2.0 and libglib-2.0 Qt --enable-pinentry-qt Qt, eg. libqt or libqt-mt Qt4 --enable-pinentry-qt4 Qt4 +TTY --enable-pinentry-tty Simple TTY version, no dependencies The GTK+ and Qt pinentries can fall back to the curses mode. The option to enable this is --enable-fallback-curses, but this is also diff --git a/configure.ac b/configure.ac index 595c2aa..849f038 100644 --- a/configure.ac +++ b/configure.ac @@ -236,6 +236,20 @@ fi dnl +dnl Check for tty pinentry program. +dnl +AC_ARG_ENABLE(pinentry-tty, + AC_HELP_STRING([--enable-pinentry-tty], [build tty pinentry]), + pinentry_tty=$enableval, pinentry_tty=maybe) +AM_CONDITIONAL(BUILD_PINENTRY_TTY, test "$pinentry_tty" = "yes") + +if test "$pinentry_tty" = "yes"; then + AC_DEFINE(PINENTRY_TTY, 1, + [The TTY version of Pinentry is to be build]) +fi + + +dnl dnl Check for GTK+ pinentry program. dnl AC_ARG_ENABLE(pinentry-gtk, @@ -494,6 +508,9 @@ else if test "$pinentry_curses" = "yes"; then PINENTRY_DEFAULT=pinentry-curses else + if test "$pinentry_tty" = "yes"; then + PINENTRY_DEFAULT=pinentry-tty + else if test "$pinentry_w32" = "yes"; then PINENTRY_DEFAULT=pinentry-w32 else @@ -503,6 +520,7 @@ else fi fi fi + fi fi AC_SUBST(PINENTRY_DEFAULT) @@ -512,6 +530,7 @@ assuan/Makefile secmem/Makefile pinentry/Makefile curses/Makefile +tty/Makefile gtk/Makefile gtk+-2/Makefile qt/Makefile @@ -531,6 +550,7 @@ AC_MSG_NOTICE([ Platform: $host Curses Pinentry ..: $pinentry_curses + TTY Pinentry .....: $pinentry_tty GTK+ Pinentry ....: $pinentry_gtk GTK+-2 Pinentry ..: $pinentry_gtk_2 Qt Pinentry ......: $pinentry_qt diff --git a/tty/Makefile.am b/tty/Makefile.am new file mode 100644 index 0000000..8224deb --- /dev/null +++ b/tty/Makefile.am @@ -0,0 +1,31 @@ +# Makefile.am - PIN entry curses frontend. +# Copyright (C) 2002 g10 Code GmbH +# +# This file is part of PINENTRY. +# +# PINENTRY is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# PINENTRY is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + +## Process this file with automake to produce Makefile.in + +EXTRA_DIST = Manifest + +bin_PROGRAMS = pinentry-tty + +AM_CPPFLAGS = -I$(top_srcdir)/pinentry +LDADD = ../pinentry/libpinentry.a \ + ../assuan/libassuan.a ../secmem/libsecmem.a \ + $(LIBCAP) $(LIBICONV) + +pinentry_tty_SOURCES = pinentry-tty.c diff --git a/tty/pinentry-tty.c b/tty/pinentry-tty.c new file mode 100644 index 0000000..24ff8a5 --- /dev/null +++ b/tty/pinentry-tty.c @@ -0,0 +1,193 @@ +/* pinentry-curses.c - A secure curses dialog for PIN entry, library version + Copyright (C) 2002 g10 Code GmbH + + This file is part of PINENTRY. + + PINENTRY is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + PINENTRY is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA + 02111-1307, USA */ + +#ifdef HAVE_CONFIG_H +#include +#endif +#include +#include +#include +#include +#include +#include +#include +#include +#ifdef HAVE_UTIME_H +#include +#endif /*HAVE_UTIME_H*/ + +#include + +#include "pinentry.h" + +#ifndef HAVE_DOSISH_SYSTEM +static int timed_out; +#endif + +static struct termios n_term; +static struct termios o_term; + +static int +cbreak(int fd) +{ + if ((tcgetattr(fd, &o_term)) == -1) + return -1; + n_term = o_term; + n_term.c_lflag = n_term.c_lflag & ~(ECHO|ICANON); + n_term.c_cc[VMIN] = 1; + n_term.c_cc[VTIME]= 0; + if ((tcsetattr(fd, TCSAFLUSH, &n_term)) == -1) + return -1; + return 1; +} + +static int +read_password(pinentry_t pinentry, const char *tty_name, const char *tty_type) +{ + FILE *ttyfi = stdin; + FILE *ttyfo = stdout; + + if (tty_name) + { + ttyfi = fopen(tty_name, "r"); + if (!ttyfi) + return -1; + + ttyfo = fopen(tty_name, "w"); + if (!ttyfo) + { + int err = errno; + fclose(ttyfi); + errno = err; + return -1; + } + } + + if (cbreak(fileno(ttyfi)) == -1) + { + int err = errno; + fclose(ttyfi); + fclose(ttyfo); + fprintf(stderr, "cbreak failure, exiting\n"); + errno = err; + return -1; + } + + fprintf(ttyfo, "%s\n%s:\n", pinentry->description, pinentry->prompt); + fflush(ttyfo); + + memset(pinentry->pin, 0, pinentry->pin_len); + + int count = 0; + while (1) + { + char c = fgetc(ttyfi); + if (c == '\n') + break; + + fflush(ttyfo); + pinentry->pin[count++] = c; + if (count >= pinentry->pin_len) + break; + } + + tcsetattr(fileno(ttyfi), TCSANOW, &o_term); + fclose(ttyfi); + fclose(ttyfo); + return strlen(pinentry->pin); +} + + +/* If a touch has been registered, touch that file. */ +static void +do_touch_file(pinentry_t pinentry) +{ +#ifdef HAVE_UTIME_H + struct stat st; + time_t tim; + + if (!pinentry->touch_file || !*pinentry->touch_file) + return; + + if (stat(pinentry->touch_file, &st)) + return; /* Oops. */ + + /* Make sure that we actually update the mtime. */ + while ((tim = time(NULL)) == st.st_mtime) + sleep(1); + + /* Update but ignore errors as we can't do anything in that case. + Printing error messages may even clubber the display further. */ + utime(pinentry->touch_file, NULL); +#endif /*HAVE_UTIME_H*/ +} + +#ifndef HAVE_DOSISH_SYSTEM +static void +catchsig(int sig) +{ + if (sig == SIGALRM) + timed_out = 1; +} +#endif + +int +tty_cmd_handler(pinentry_t pinentry) +{ + int rc; + +#ifndef HAVE_DOSISH_SYSTEM + timed_out = 0; + + if (pinentry->timeout) + { + struct sigaction sa; + + memset(&sa, 0, sizeof(sa)); + sa.sa_handler = catchsig; + sigaction(SIGALRM, &sa, NULL); + alarm(pinentry->timeout); + } +#endif + + rc = read_password(pinentry, pinentry->ttyname, pinentry->ttytype); + do_touch_file(pinentry); + return rc; +} + +pinentry_cmd_handler_t pinentry_cmd_handler = tty_cmd_handler; + +int +main(int argc, char *argv[]) +{ + pinentry_init("pinentry-tty"); + + /* Consumes all arguments. */ + if (pinentry_parse_opts(argc, argv)) + { + printf("pinentry-tty (pinentry) " VERSION "\n"); + exit(EXIT_SUCCESS); + } + + if (pinentry_loop()) + return 1; + + return 0; +} -- 1.9.0 From wk at gnupg.org Tue Aug 12 10:40:08 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Aug 2014 10:40:08 +0200 Subject: [PATCH] New pinentry-tty version for dumb terminals. In-Reply-To: <1407527547-30686-1-git-send-email-serge0x76@gmail.com> (Serge Voilokov's message of "Fri, 8 Aug 2014 15:52:27 -0400") References: <1407527547-30686-1-git-send-email-serge0x76@gmail.com> Message-ID: <87bnrqp0d3.fsf@vigenere.g10code.de> On Fri, 8 Aug 2014 21:52, serge0x76 at gmail.com said: > I added version of pinentry tool for dumb terminals (pinentry-tty). > Please consider adding this to pinentry project. Done with some minor changes. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Aug 12 11:53:29 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Aug 2014 11:53:29 +0200 Subject: [PATCH] update libgpg-error Danish translation (from https://bugs.debian.org/754128) In-Reply-To: <1407449986-6173-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 7 Aug 2014 18:19:46 -0400") References: <1407449986-6173-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87wqaeniee.fsf@vigenere.g10code.de> On Fri, 8 Aug 2014 00:19, dkg at fifthhorseman.net said: > From: Joe Hansen Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From pgut001 at cs.auckland.ac.nz Tue Aug 12 13:41:40 2014 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 12 Aug 2014 11:41:40 +0000 Subject: Key length for integer- and finite-field cryptography Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B99D9FE@uxcn10-tdc05.UoA.auckland.ac.nz> [Apologies if you've seen this before, it looks like up to a week's worth of mail from here has been lost, this is a resend of the backlog] David Leon Gil writes: >Take-home: If you are using AES-256, you should max out your key size in >GnuPG. Not quite. The proper version is: Take-home: If you believe in NIST's crypto numerology, you should should use ridiculous key sizes. For everyone else: Nothing to see here, move along. Peter. From wk at gnupg.org Tue Aug 12 20:51:03 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Aug 2014 20:51:03 +0200 Subject: [Announce] GnuPG 2.0.26 released Message-ID: <87iolxo82w.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.26. This is a maintenance release to fix a regression introduced with the 2.0.24 release. The GNU Privacy Guard (GnuPG) is the most commonly used tool for OpenPGP mail and data encryption. 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.18) 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 keep maintaining GnuPG-1 versions because they are useful on very old platforms 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, VMS, and Mac OS X. What's New in 2.0.26 ==================== * gpg: Fix a regression in 2.0.24 if a subkey id is given to --recv-keys et al. * gpg: Cap attribute packets at 16MB. * gpgsm: Auto-create the ".gnupg" home directory in the same way gpg does. * scdaemon: Allow for certificates > 1024 when using PC/SC. Getting the Software ==================== Please follow the instructions found at https://www.gnupg.org/download/ or read on: GnuPG 2.0.26 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 https://www.gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org and on its mirrors you should find the following new files in the gnupg/ directory: - The GnuPG-2 source code compressed using BZIP2 and its OpenPGP signature: gnupg-2.0.26.tar.bz2 (4203k) gnupg-2.0.26.tar.bz2.sig - A patch file to upgrade a 2.0.25 GnuPG source tree. This patch does not include updates of the language files. gnupg-2.0.25-2.0.26.diff.bz2 (10k) Note, that we don't distribute gzip compressed tarballs for GnuPG-2. A Windows version will soon be released at https://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-2.0.26.tar.bz2 you would use this command: gpg --verify gnupg-2.0.26.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.26.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.26.tar.bz2 and check that the output matches the first line from the following list: 3ff5b38152c919724fd09cf2f17df704272ba192 gnupg-2.0.26.tar.bz2 9e5727384b163722b05a8bb5f0e4c7987a5cbbb6 gnupg-2.0.25-2.0.26.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 https://www.gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://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. 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: https://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 to continue this work he kindly asks to either purchase a support contract, engage g10 Code for custom enhancements, or to donate money: https://gnupg.org/donate/ 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, and answering questions on the mailing lists. Shalom-Salam, 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: 180 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 bernhard at intevation.de Wed Aug 13 12:00:42 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 13 Aug 2014 12:00:42 +0200 Subject: FAQ: Re: key length In-Reply-To: <877g2jweum.fsf@vigenere.g10code.de> References: <201408080945.09352.bernhard@intevation.de> <877g2jweum.fsf@vigenere.g10code.de> Message-ID: <201408131200.52363.bernhard@intevation.de> On Friday 08 August 2014 at 10:44:01, Werner Koch wrote: > On Fri, 8 Aug 2014 09:45, bernhard at intevation.de said: > > So what is the common weakest link then? > > The symmetric cipher, the entropy source, the implementation issues in > > software and hardware (like side channel attacks)? > > The ubiquitous exploitable bugs in all software, the OS, the MUAs, the > "apps", the browser running foreign code on your box, social > engineering, etc. I know that there are several deep branches in a general attack tree, but this is beside the point. Even if there are weaker spots, it seems sane to try to keep the crypto part that GnuPG is responsible for strong. > > OpenPGP system to be so strong that is provides 10 years security. > > At least my actions I can control. > > Never connect to the Net and you have a chance to control things. Again, this is not an argument I can easily understand. But this is what I am trying to do: Find a good chain of arguments, so that I and others can understand and validate themselfs that the current choice of GnuPG's default key length is a good one. Or come back with a better chain of arguments. And then: Write them down, for more people to question and research them. Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Aug 13 16:16:50 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 13 Aug 2014 16:16:50 +0200 Subject: [PATCH] gpg: Need to init the trustdb for import. Message-ID: <53EB7352.8050603@sumptuouscapital.com> * g10/trustdb.c (clear_ownertrusts): Init trustdb. - -- This was fixed in 1.4 branch in commit 23191d7851eae2217ecdac6484349849a24fd94a but was not applied to the 2.0 branch that exhibits the same problem. This is actually a hack to fix a bug introduced with commit 2528178. GnuPG-bug-id: 1622 - -- This can e.g. be imported using a test case such as A=$(mktemp -d); export A; echo ${A} && gpg2 --export 0x0B7F8B60E3EDFAE3 | gpg2 --trust-model=always --homedir ${A} --import which caused issues with caff for some users. Although it fixes this case I notice that something is still wrong when trying to generate a new key in this scenario $ A=$(mktemp -d); export A; gpg2 --trust-model=always --homedir ${A} --batch --gen-key < Key-Type: RSA > Key-Length: 1024 > Name-Real: Joe Tester > Name-Email: joe at foo.bar > %commit > EOF gpg: keyring `/tmp/tmp.9WKDtaTkg5/secring.gpg' created gpg: keyring `/tmp/tmp.9WKDtaTkg5/pubring.gpg' created gpg: Fatal: can't open `/tmp/tmp.9WKDtaTkg5/trustdb.gpg': No such file or directory I havent tested if this is also an issue for the 1.4 branch for these purposes, but will see if I can around to that later this week. -- ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Aut dosce, aut disce, aut discede Either teach, or study, or leave -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.0.26-Need-to-init-the-trustdb-for-import.patch Type: text/x-patch Size: 895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From laurent at elanor.org Thu Aug 14 10:14:57 2014 From: laurent at elanor.org (Laurent Blume) Date: Thu, 14 Aug 2014 10:14:57 +0200 Subject: Regression: tests failing on Solaris 10 for >= 2.0.23 Message-ID: <53EC7001.8020101@elanor.org> Hello, I'm packaging GnuPG on Solaris 10 for OpenCSW. The build recipe I use worked smoothly until 2.0.22. Now, with 2.0.26, the same recipe fails on those tests: FAIL: genkey1024.test FAIL: conventional.test > IDEA FAIL: conventional-mdc.test I can pinpoint that the problem was introduced between 2.0.22 and 2.0.23. The dependencies are the same for all versions: libgcrypt 1.6.1 and libassuan 2.1.1. The issue occurs with GCC 4.9.0 and Solaris Studio 12u3, on both sparc and x86 architectures, 32 or 64 bit. The same compilers work with 2.0.22, so a compiler issue is unlikely. The content of the tests logs: Test: genkey1024.test GNUPGHOME=/export/espace/apps/OpenCSW/mgar/gnupg2/trunk/work/build-isa-pentium_pro/gnupg-2.0.23/tests/openpgp GPG_AGENT_INFO=/tmp/gpg-ispCws/S.gpg-agent:794:1 gpg: problem with the agent: Broken pipe gpg: key 04C9BD76 marked as ultimately trusted Test: conventional.test GNUPGHOME=/export/espace/apps/OpenCSW/mgar/gnupg2/trunk/work/build-isa-pentium_pro/gnupg-2.0.23/tests/openpgp GPG_AGENT_INFO=/tmp/gpg-kfmtYP/S.gpg-agent:805:1 gpg: problem with the agent: Broken pipe Test: conventional-mdc.test GNUPGHOME=/export/espace/apps/OpenCSW/mgar/gnupg2/trunk/work/build-isa-pentium_pro/gnupg-2.0.23/tests/openpgp GPG_AGENT_INFO=/tmp/gpg-SHqcnB/S.gpg-agent:818:1 gpg: WARNING: unsafe permissions on homedir `.' gpg: problem with the agent: Broken pipe Anything else I can do to help fix this? Laurent From folkert at vanheusden.com Thu Aug 14 11:14:45 2014 From: folkert at vanheusden.com (folkert) Date: Thu, 14 Aug 2014 11:14:45 +0200 Subject: 2 questions regarding gpgme and keyrings Message-ID: <20140814091445.GZ13548@belle.intranet.vanheusden.com> - how can I set the filesystem location of the keyring from WITHIN my application so that gpgme looks in the right location? - when encrypting data from some-one, how can I set the public key using the regular ascii encoding of a key using a function call? e.g. so that it does not retrieve it from a key ring but as an ascii-string Folkert van Heusden -- MultiTail ? uno flexible tool per seguire di logfiles e effettuazione di commissioni. Feltrare, provedere da colore, merge, 'diff-view', etc. http://www.vanheusden.com/multitail/ ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From wk at gnupg.org Thu Aug 14 14:23:24 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Aug 2014 14:23:24 +0200 Subject: 2 questions regarding gpgme and keyrings In-Reply-To: <20140814091445.GZ13548@belle.intranet.vanheusden.com> (folkert@vanheusden.com's message of "Thu, 14 Aug 2014 11:14:45 +0200") References: <20140814091445.GZ13548@belle.intranet.vanheusden.com> Message-ID: <87d2c3dzur.fsf@vigenere.g10code.de> On Thu, 14 Aug 2014 11:14, folkert at vanheusden.com said: > - how can I set the filesystem location of the keyring from WITHIN my > application so that gpgme looks in the right location? err = gpgme_set_engine_info (GPGME_PROTOCOL_OpenPGP, NULL, "/my/other/gnupg/homedir"); That is you can't give the location of a keyring but you need top provide another homedir. The keyring is a detail of the gpg and paying with it should in general be avoided. Note that 2.1 uses by default the faster keybox and shares that with gpgsm. > - when encrypting data from some-one, how can I set the public key > using the regular ascii encoding of a key using a function call? e.g. > so that it does not retrieve it from a key ring but as an ascii-string First import that key and the use it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Aug 14 14:37:20 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Aug 2014 14:37:20 +0200 Subject: Regression: tests failing on Solaris 10 for >= 2.0.23 In-Reply-To: <53EC7001.8020101@elanor.org> (Laurent Blume's message of "Thu, 14 Aug 2014 10:14:57 +0200") References: <53EC7001.8020101@elanor.org> Message-ID: <878umrdz7j.fsf@vigenere.g10code.de> On Thu, 14 Aug 2014 10:14, laurent at elanor.org said: > I can pinpoint that the problem was introduced between 2.0.22 and 2.0.23. There is 571bcd46 * common: Fix build problem with Sun Studio compiler. thus I wonder how it was possible to build before. > gpg: problem with the agent: Broken pipe > gpg: key 04C9BD76 marked as ultimately trusted The agent died, right? The best way to debug this is to put --8<---------------cut here---------------start------------->8--- log-file socket:///home/foo/.gnupg/S.log debug 1024 verbose --8<---------------cut here---------------end--------------->8--- into gpg-agent.conf and watch the output using watchgnupg. You may of course also use a plain file. If you notice that the gpg-agent died, you should start it again and attach a debugger to gpg-agent. And of course run the test case by hand ant via the test script. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From folkert at vanheusden.com Thu Aug 14 15:04:13 2014 From: folkert at vanheusden.com (folkert) Date: Thu, 14 Aug 2014 15:04:13 +0200 Subject: 2 questions regarding gpgme and keyrings In-Reply-To: <87d2c3dzur.fsf@vigenere.g10code.de> References: <20140814091445.GZ13548@belle.intranet.vanheusden.com> <87d2c3dzur.fsf@vigenere.g10code.de> Message-ID: <20140814130413.GA13548@belle.intranet.vanheusden.com> > > - how can I set the filesystem location of the keyring from WITHIN my > > application so that gpgme looks in the right location? > > err = gpgme_set_engine_info (GPGME_PROTOCOL_OpenPGP, > NULL, "/my/other/gnupg/homedir"); > > That is you can't give the location of a keyring but you need top > provide another homedir. The keyring is a detail of the gpg and paying > with it should in general be avoided. Note that 2.1 uses by default the > faster keybox and shares that with gpgsm. Ok thanks > > - when encrypting data from some-one, how can I set the public key > > using the regular ascii encoding of a key using a function call? e.g. > > so that it does not retrieve it from a key ring but as an ascii-string > > First import that key and the use it. But that'll try to write to the key ring files right? Folkert van Heusden -- To MultiTail einai ena polymorfiko ergaleio gia ta logfiles kai tin eksodo twn entolwn. Prosferei: filtrarisma, xrwmatismo, sygxwneysi, diaforetikes provoles. http://www.vanheusden.com/multitail/ ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From laurent at elanor.org Thu Aug 14 15:31:54 2014 From: laurent at elanor.org (Laurent Blume) Date: Thu, 14 Aug 2014 15:31:54 +0200 Subject: Regression: tests failing on Solaris 10 for >= 2.0.23 In-Reply-To: <878umrdz7j.fsf@vigenere.g10code.de> References: <53EC7001.8020101@elanor.org> <878umrdz7j.fsf@vigenere.g10code.de> Message-ID: <53ECBA4A.3040809@elanor.org> Le 2014/08/14 14:37 +0200, Werner Koch a ?crit: > There is > > 571bcd46 * common: Fix build problem with Sun Studio compiler. > > thus I wonder how it was possible to build before. I've been using only GCC4 for a while. I only gave a try to Studio this time as it was suggested it could be a compiler optimization issue. > The agent died, right? The best way to debug this is to put > > --8<---------------cut here---------------start------------->8--- > log-file socket:///home/foo/.gnupg/S.log > debug 1024 > verbose > --8<---------------cut here---------------end--------------->8--- > > into gpg-agent.conf and watch the output using watchgnupg. You may of > course also use a plain file. If you notice that the gpg-agent died, > you should start it again and attach a debugger to gpg-agent. Here is what I get in the log: gpg-agent[10736]: chan_6 -> OK Pleased to meet you, process 10734 gpg-agent[10736]: chan_6 <- RESET gpg-agent[10736]: chan_6 -> OK gpg-agent[10736]: chan_6 <- OPTION ttytype=ansi gpg-agent[10736]: chan_6 -> OK gpg-agent[10736]: chan_6 <- OPTION allow-pinentry-notify gpg-agent[10736]: chan_6 -> OK gpg-agent[10736]: chan_6 <- AGENT_ID And of course, it's only now that I notice there is a core file generated each time in /var/core. Sorry about that, there was no hint of it in the output so far: # pstack core.gpg-agent.10736 core 'core.gpg-agent.10736' of 10736: gpg-agent --server fffffd7fff2679f0 strlen () + 30 fffffd7fff2c7fd3 vsprintf () + 33 fffffd7ffef60273 int_vasprintf () + 2c3 fffffd7ffef58a8d _assuan_debug () + bd fffffd7ffef57e41 assuan_set_error () + 51 fffffd7ffef5bfcf process_request () + 8f fffffd7ffef5c048 assuan_process () + 28 0000000000417db5 start_command_handler () + 145 000000000043dadf main () + c5f 00000000004125fc _start () + 6c Does it help? An strlen() error, that sounds rather trivial? Laurent From wk at gnupg.org Thu Aug 14 18:04:00 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Aug 2014 18:04:00 +0200 Subject: 2 questions regarding gpgme and keyrings In-Reply-To: <20140814130413.GA13548@belle.intranet.vanheusden.com> (folkert@vanheusden.com's message of "Thu, 14 Aug 2014 15:04:13 +0200") References: <20140814091445.GZ13548@belle.intranet.vanheusden.com> <87d2c3dzur.fsf@vigenere.g10code.de> <20140814130413.GA13548@belle.intranet.vanheusden.com> Message-ID: <87wqabcb2n.fsf@vigenere.g10code.de> On Thu, 14 Aug 2014 15:04, folkert at vanheusden.com said: >> First import that key and the use it. > > But that'll try to write to the key ring files right? Sure. Eventually there will be a feature to import ephemeral keys but we definitely need to import the key first. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Aug 14 17:57:06 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Aug 2014 17:57:06 +0200 Subject: [Announce] The sixth Beta for GnuPG 2.1 is now available for testing Message-ID: <871tsjdpyl.fsf@vigenere.g10code.de> Hello! I just released the sixth *beta* version of GnuPG *2.1*. It has been released to give you the opportunity to check out new features and to help fixing bugs. If you need a stable and fully maintained version of GnuPG, you should use version 2.0.26 or 1.4.18. This versions is marked as BETA and as such it should in general not be used for real work. However, the core functionality is solid enough for a long time and I am using this code base for a couple of years now. What's new in 2.1.0-beta783 since beta751 ========================================= * gpg: Add command --quick-gen-key. * gpg: Make --quick-sign-key promote local key signatures. * gpg: Added "show-usage" sub-option to --list-options. * gpg: Screen keyserver responses to avoid importing unwanted keys from rogue servers. * gpg: Removed the option --pgp2 and --rfc1991 and the ability to create PGP-2 compatible messages. * gpg: Removed options --compress-keys and --compress-sigs. * gpg: Cap attribute packets at 16MB. * gpg: Improved output of --list-packets. * gpg: Make with-colons output of --search-keys work again. * gpgsm: Auto-create the ".gnupg" directory like gpg does. * agent: Fold new passphrase warning prompts into one. * scdaemon: Add support for the Smartcard-HSM card. * scdaemon: Remove the use of the pcsc-wrapper. Getting the Software ==================== GnuPG 2.1.0-beta783 is available at ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta783.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta783.tar.bz2.sig and soon on all mirrors . Please read the README file ! 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.1.0-beta783.tar.bz2 you would use this command: gpg --verify gnupg-2.1.0-beta783.tar.bz2.sig Depending on your installation you may use "gpg2" instead of "gpg". 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! 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 https://www.gnupg.org/documentation/manuals/gnupg-devel/ 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: https://www.gnupg.org/service.html Maintaining and improving GnuPG is costly. For more than a decade, g10 Code GmbH, a German company owned and headed by GnuPG's principal author Werner Koch, is bearing the majority of these costs. To help them carry on this work, they need your support. See https://gnupg.org/donate/ For reasons why donating to free software projects is beneficial for everyone, please read Poul-Henning Kamp's "Quality Software Costs Money - Heartbleed Was Free" at https://queue.acm.org/detail.cfm?id=2636165 . 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, and answering questions on the mailing lists. Salam-Shalom, 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: 180 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 Thu Aug 14 18:07:42 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Aug 2014 18:07:42 +0200 Subject: Regression: tests failing on Solaris 10 for >= 2.0.23 In-Reply-To: <53ECBA4A.3040809@elanor.org> (Laurent Blume's message of "Thu, 14 Aug 2014 15:31:54 +0200") References: <53EC7001.8020101@elanor.org> <878umrdz7j.fsf@vigenere.g10code.de> <53ECBA4A.3040809@elanor.org> Message-ID: <87sikzcawh.fsf@vigenere.g10code.de> On Thu, 14 Aug 2014 15:31, laurent at elanor.org said: > fffffd7fff2679f0 strlen () + 30 > fffffd7fff2c7fd3 vsprintf () + 33 > fffffd7ffef60273 int_vasprintf () + 2c3 > fffffd7ffef58a8d _assuan_debug () + bd > fffffd7ffef57e41 assuan_set_error () + 51 > fffffd7ffef5bfcf process_request () + 8f > fffffd7ffef5c048 assuan_process () + 28 > 0000000000417db5 start_command_handler () + 145 > 000000000043dadf main () + c5f > 00000000004125fc _start () + 6c > > Does it help? An strlen() error, that sounds rather trivial? That looks similar to bug 1659 on AIX. The problem is the vasprintf emulation from libassuan. I'll take a look at it later the day. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Aug 14 20:01:00 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Aug 2014 20:01:00 +0200 Subject: Regression: tests failing on Solaris 10 for >= 2.0.23 In-Reply-To: <53ECBA4A.3040809@elanor.org> (Laurent Blume's message of "Thu, 14 Aug 2014 15:31:54 +0200") References: <53EC7001.8020101@elanor.org> <878umrdz7j.fsf@vigenere.g10code.de> <53ECBA4A.3040809@elanor.org> Message-ID: <87k36bc5nn.fsf@vigenere.g10code.de> Hi! It might be that you are running an older version of gpg-agent which does not implement AGENT_ID and in this case the debug code might be triggered with a NULL for the text value. Can you please try the patch for libassuan below. However, I doubt that this is the reason for Solaris because I assume that printf ("%s", NULL) does not bail out on there but I am not sure. The AIX man page explictly remarks that it is undefined (as stated by Posix). Time to move our own printf code from GnuPG to libgpg-error and have libassuan et al use that code too. And we have the guarantee that "%zu" and such work. Salam-Shalom, Werner --- >From d081ab69a6d726528d0ea1ba88736a76fce99950 Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Thu, 14 Aug 2014 17:15:04 +0200 Subject: [PATCH] Fix possible segv in a call to _assuan_debug. * src/context.c (assuan_set_error): Do not pass NULL for %s in the trace function. --- src/context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/context.c b/src/context.c index b4d4d49..62b7f57 100644 --- a/src/context.c +++ b/src/context.c @@ -190,7 +190,7 @@ assuan_set_error (assuan_context_t ctx, gpg_error_t err, const char *text) { TRACE4 (ctx, ASSUAN_LOG_CTX, "assuan_set_error", ctx, "err=%i (%s,%s),text=%s", err, gpg_strsource (err), - gpg_strerror (err), text); + gpg_strerror (err), text?text:"(none)"); ctx->err_no = err; ctx->err_str = text; -- 1.8.4.3 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From laurent at elanor.org Sat Aug 16 00:25:44 2014 From: laurent at elanor.org (Laurent Blume) Date: Sat, 16 Aug 2014 00:25:44 +0200 Subject: Regression: tests failing on Solaris 10 for >= 2.0.23 In-Reply-To: <87k36bc5nn.fsf@vigenere.g10code.de> References: <53EC7001.8020101@elanor.org> <878umrdz7j.fsf@vigenere.g10code.de> <53ECBA4A.3040809@elanor.org> <87k36bc5nn.fsf@vigenere.g10code.de> Message-ID: <53EE88E8.9060803@elanor.org> Le 2014/08/14 20:01 +0200, Werner Koch a ?crit: > Hi! > > It might be that you are running an older version of gpg-agent which > does not implement AGENT_ID and in this case the debug code might be > triggered with a NULL for the text value. I don't quite understand that part: there is no gpg-agent running when I start the tests, and I expect them to test the newly built one, not the currently installed one? > Can you please try the patch for libassuan below. I tried and it fixes the issue, all tests now succeed. > However, I doubt that this is the reason for Solaris because I assume > that printf ("%s", NULL) does not bail out on there but I am not sure. > The AIX man page explictly remarks that it is undefined (as stated by > Posix). Time to move our own printf code from GnuPG to libgpg-error and > have libassuan et al use that code too. And we have the guarantee that > "%zu" and such work. Solaris tends to be picky about such things by default. It can be overruled to provide a Linux-like behaviour, but it's considered to be for debugging-only: ?The user compatibility library /usr/lib/0 at 0.so.1 provides a mechanism that establishes a value of 0 at location 0. Some applications exist that erroneously assume a null character pointer should be treated the same as a pointer to a null string. A segmentation violation occurs in these applications when a null character pointer is accessed.? http://docs.oracle.com/cd/E19253-01/816-5165/ld.so.1-1/index.html Thanks for your help! I'll push a patched libassuan for now. Laurent From wk at gnupg.org Sat Aug 16 10:53:55 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 16 Aug 2014 10:53:55 +0200 Subject: Regression: tests failing on Solaris 10 for >= 2.0.23 In-Reply-To: <53EE88E8.9060803@elanor.org> (Laurent Blume's message of "Sat, 16 Aug 2014 00:25:44 +0200") References: <53EC7001.8020101@elanor.org> <878umrdz7j.fsf@vigenere.g10code.de> <53ECBA4A.3040809@elanor.org> <87k36bc5nn.fsf@vigenere.g10code.de> <53EE88E8.9060803@elanor.org> Message-ID: <87sikwbysc.fsf@vigenere.g10code.de> On Sat, 16 Aug 2014 00:25, laurent at elanor.org said: > I don't quite understand that part: there is no gpg-agent running when > I start the tests, and I expect them to test the newly built one, not > the currently installed one? Well, the last command I noticed in your logs was AGENT_ID, which is quite new. This would have led to passing NULL for "%s" and this condition was the first thing I noticed by looking at the source. There are other cases too. > I tried and it fixes the issue, all tests now succeed. Great. Thanks. I'll do a new libassuan release soon. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Aug 19 22:04:26 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Aug 2014 22:04:26 +0200 Subject: EdDSA/Ed25519 I-D for OpenPGP Message-ID: <874mx88cvp.fsf@vigenere.g10code.de> Hi, I just submitted an I-D for use of Ed25519 in OpenPGP: http://www.ietf.org/id/draft-koch-eddsa-for-openpgp-00.txt I include a version without page breaks below. Salam-Shalom, Werner ==== Network Working Group W. Koch Internet-Draft g10 Code Intended status: Standards Track August 19, 2014 Expires: February 20, 2015 EdDSA for OpenPGP draft-koch-eddsa-for-openpgp-00 Abstract This specification extends OpenPGP with the EdDSA public key algorithm and describes the use of curve Ed25519. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 20, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Supported Curves 3. Point Format 4. Encoding of Public and Private Keys 5. Message Encoding 6. Curve OID 7. Security Considerations 8. IANA Considerations 9. Acknowledgments 10. Normative References Appendix A. Test vectors A.1. Sample key A.2. Sample signature Author's Address 1. Introduction The OpenPGP specification in [RFC4880] defines the RSA, Elgamal, and DSA public key algorithms. [RFC6637] adds support for Elliptic Curve Cryptography and specifies the ECDSA and ECDH algorithms. Due to patent reasons no point compression was defined. This document specifies how to use the EdDSA public key signature algorithm [ED25519] with the OpenPGP standard. It defines a new signature algorithm named EdDSA and specifies how to use the Ed25519 curve with EdDSA. This algorithm uses a custom point compression method. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Supported Curves This document references the Curve "Ed25519" which is the Edwards form of "Curve25519" and specified in the same paper as the "EdDSA" algorithm ([ED25519]). Other curves may be used by using a specific OID for the curve and its EdDSA parameters. The following public key algorithm IDs are added to expand section 9.1 of [RFC4880], "Public-Key Algorithms": +-------+-----------------------------+ | ID | Description of Algorithm | +-------+-----------------------------+ | TBD1 | EdDSA public key algorithm | +-------+-----------------------------+ Compliant applications MUST support EdDSA with the curve Ed25519. Applications MAY support other curves as long as a dedicated OID for that curve is used. 3. Point Format The EdDSA algorithm defines a specific point compression format. To indicate the use of this compression format and to make sure that the key can be represented in the Multiprecision Internet (MPI) format of [RFC4880] the octet string specifying the point is prefixed with the octet 0x40. This encoding is an extension of the encoding given in [RFC6637] which uses 0x04 to indicate an uncompressed point. For example, the length of a public key for the curve Ed25519 is 263 bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the native value of the public key. 4. Encoding of Public and Private Keys The following algorithm specific packets are added to Section 5.5.2 of [RFC4880], "Public-Key Packet Formats", to support EdDSA. Algorithm-Specific Fields for EdDSA keys: o a variable length field containing a curve OID, formatted as follows: * a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions, * octets representing a curve OID, defined in Section 6. o MPI of an EC point representing a public key Q as described under Point Format above. The following algorithm specific packets are added to Section 5.5.3 of [RFC4880], "Secret-Key Packet Formats", to support EdDSA. Algorithm-Specific Fields for EdDSA keys: o an MPI of an integer representing the secret key, which is a scalar of the public EC point. The version 4 packet format MUST be used. 5. Message Encoding Section 5.2.3 of [RFC4880], "Version 4 Signature Packet Format" specifies formats. To support EdDSA no change is required, the MPIs representing the R and S value are encoded as MPIs in the same way as done for the DSA and ECDSA algorithms; in particular the Algorithm- Specific Fields for an EdDSA signature are: - MPI of EdDSA value r. - MPI of EdDSA value s. Note that the compressed version of R and S as specified for EdDSA ([ED25519]) is used. The version 3 signature format MUST NOT be used with EdDSA. Although that algorithm allows arbitrary data as input, its use with OpenPGP requires that a digest of the message is used as input. See section 5.2.4 of [RFC4880], "Computing Signatures" for details. Truncation of the resulting digest is never applied; the resulting digest value is used verbatim as input to the EdDSA algorithm. 6. Curve OID The EdDSA key parameter curve OID is an array of octets that defines a named curve. The table below specifies the exact sequence of bytes for each named curve referenced in this document: +------------------------+------+------------------------+----------+ | OID | Len | Encoding in hex format | Name | +------------------------+------+------------------------+----------+ | 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 | Ed25519 | | | | 0F 01 | | +------------------------+------+------------------------+----------+ See [RFC6637] for a description of the OID encoding given in the second and third columns. 7. Security Considerations The security considerations of [RFC4880] apply accordingly. The use of EdDSA with the Ed25519 curve is believed to be as strong as other curves of the same size. However, a proper implementation of this algorithm avoids most security problems due to wrong usage. The algorithm does not require a unique random number for each signature created by the same key. 8. IANA Considerations IANA is requested to assign an algorithm number from the OpenPGP Public-Key Algorithms range, or the "namespace" in the terminology of [RFC5226], that was created by [RFC4880]. See section 2. +-------+-----------------------------+------------+ | ID | Algorithm | Reference | +-------+-----------------------------+------------+ | TBD1 | EdDSA public key algorithm | This doc | +-------+-----------------------------+------------+ [Notes to RFC-Editor: Please remove the table above on publication. It is desirable not to reuse old or reserved algorithms because some existing tools might print a wrong description. A higher number is also an indication for a newer algorithm. As of now 22 is the next free number.] 9. Acknowledgments The author would like to acknowledge the help of the individuals who kindly voiced their opinions on the IETF OpenPGP and GnuPG mailing lists, in particular, the help of Andrey Jivsov, Jon Callas, and NIIBE Yutaka. 10. Normative References [ED25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. Yang, "High-speed high-security signatures", Journal of Cryptographic Engineering Volume 2, Issue 2, pp. 77-89, September 2011, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in OpenPGP", RFC 6637, June 2012. Appendix A. Test vectors To help implementing this specification a non-normative example is given. This example assumes that the algorithm id for EdDSA will be 22. A.1. Sample key The secret key used for this example is: D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2 Note that this is the raw secret key as used as input to the EdDSA signing operation. The key was created on 2014-08-19 14:28:27 and thus the fingerprint of the OpenPGP key is: C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A The algorithm specific input parameters without the MPI length headers are: oid: 2b06010401da470f01 q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406 The entire public key packet is thus 98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47 0f 01 01 07 40 3f 09 89 94 bd d9 16 ed 40 53 19 79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e 43 ee 3b 24 06 A.2. Sample signature The signature is created using the sample key over the input data "OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash function is m: 4f70656e504750040016080006050255f95f9504ff0000000c using the SHA-256 hash algorithm yields this digest d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280 which is fed into the EdDSA signature function and yields this signature: r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366 s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404 Note that the MPI encoding rules require that the value of S needs to be prefixed with a 0x00 octet. The entire signature packet is thus 88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a 09 10 8c fd e1 21 97 96 5a 9a f6 22 01 00 56 f9 0c ca 98 e2 10 26 37 bd 98 3f db 16 c1 31 df d2 7e d8 2b f4 dd e5 60 6e 0d 75 6a ed 33 66 01 00 d0 9c 4f a1 15 27 f0 38 e0 f5 7f 22 01 d8 2f 2e a2 c9 03 32 65 fa 6c eb 48 9e 85 4b ae 61 b4 04 Author's Address Werner Koch g10 Code Email: wk at gnupg.org URI: https://g10code.com -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kylebutt at gmail.com Wed Aug 20 00:55:50 2014 From: kylebutt at gmail.com (Kyle Butt) Date: Tue, 19 Aug 2014 15:55:50 -0700 Subject: gpg2 head failing to export ecc secret key. Message-ID: gpg2 built from recent head: e5da80bc1888bf8801e69c9ff99f7f47550f7a09, won't export an ecc secret key. It will export an RSA key. I have a debug log from the attempt, and the console log from creating the key and attempting to export it. The specific error message is: gpg: key 48743C8B/07BFC195: error receiving key from agent: Bad secret key - skipped gpg: WARNING: nothing exported The key is included in the attachment if it could help, along with configs. The line: protect-cipher openpgp-s2k3-sha1-aes256-cbc in gpg-agent.conf is from a change I'm working on, I don't think it's related. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: export_ecc_secret_key_logs.tar.xz Type: application/x-xz Size: 6924 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: export_ecc_secret_key_logs.tar.xz.sig Type: application/octet-stream Size: 543 bytes Desc: not available URL: From serge0x76 at gmail.com Wed Aug 20 16:49:56 2014 From: serge0x76 at gmail.com (Serge Voilokov) Date: Wed, 20 Aug 2014 10:49:56 -0400 Subject: [PATCH] pinentry: Added generating missing file. Message-ID: <1408546196-28359-1-git-send-email-serge0x76@gmail.com> Hi, Fresh cloned pinentry/autogen.sh gives an error "required file './compile' not found". Please consider this patch to fix it. Thanks, Serge >8-----------------------------------------------8< autogen.sh on fresh clone failed with error: required file './compile' not found. * autogen.sh: Added '--add-missing' parameter to automake. --- autogen.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/autogen.sh b/autogen.sh index 885e8fd..40bb3ef 100755 --- a/autogen.sh +++ b/autogen.sh @@ -207,7 +207,7 @@ $ACLOCAL -I m4 $ACLOCAL_FLAGS echo "Running autoheader..." $AUTOHEADER echo "Running automake --gnu ..." -$AUTOMAKE --gnu +$AUTOMAKE --gnu --add-missing echo "Running autoconf${FORCE}..." $AUTOCONF${FORCE} -- 2.0.4 From coruus at gmail.com Thu Aug 21 00:24:18 2014 From: coruus at gmail.com (David Leon Gil) Date: Wed, 20 Aug 2014 18:24:18 -0400 Subject: [openpgp] EdDSA/Ed25519 I-D for OpenPGP In-Reply-To: <874mx88cvp.fsf@vigenere.g10code.de> References: <874mx88cvp.fsf@vigenere.g10code.de> Message-ID: On Tue, Aug 19, 2014 at 4:04 PM, Werner Koch wrote: > I just submitted an I-D for use of Ed25519 in OpenPGP: This is terrific! > 2. Supported Curves > > Other curves may be used by using a specific OID for the curve and > its EdDSA parameters. See infra. You should list EdDSA parameters that need to be encoded into the OID. > 3. Point Format Are MPIs -- and the 0x40 prefix -- necessary? The curve OID already determines the length the octet string. Similarly for encoding the signature; it poses significant interoperability concerns to deviate from the existing encoding used by Ed25519 implementations. > Although that algorithm allows arbitrary data as input, its use with > OpenPGP requires that a digest of the message is used as input. See > section 5.2.4 of [RFC4880], "Computing Signatures" for details. > Truncation of the resulting digest is never applied; the resulting > digest value is used verbatim as input to the EdDSA algorithm. This is confusing. EdDSA is defined to operate on messages of arbitrary length; hashing the message is part of the EdDSA algorithm. To quote: EdDSA has seven parameters: - an integer _b_ ? 10; - a cryptographic hash function _H_ producing **2b-bit output**; - a prime power _q_ congruent to 1 modulo 4; - a (_b_?1)-bit encoding of elements of the finite field _Fq_; - a non-square element _d_ of _Fq_; - a prime _L_ between 2^_b_?4 and 2^_b_?3 satisfying an extra constraint [. . .]; - [and a point _B_] Ed25519-SHA2-512 is widely implemented. No other hash functions currently specified for use with OpenPGP provide long enough output to be used with Curve25519. > 10. Normative References > > [ED25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. > Yang, "High-speed high-security signatures", Journal of > Cryptographic Engineering Volume 2, Issue 2, pp. 77-89, > September 2011, http://ed25519.cr.yp.to/ed25519-20110926.pdf From gniibe at fsij.org Thu Aug 21 02:32:13 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 21 Aug 2014 09:32:13 +0900 Subject: EdDSA/Ed25519 I-D for OpenPGP In-Reply-To: <874mx88cvp.fsf@vigenere.g10code.de> References: <874mx88cvp.fsf@vigenere.g10code.de> Message-ID: <1408581133.1630.1.camel@cfw2.gniibe.org> On 2014-08-19 at 22:04 +0200, Werner Koch wrote: > I just submitted an I-D for use of Ed25519 in OpenPGP: > > http://www.ietf.org/id/draft-koch-eddsa-for-openpgp-00.txt Great. I have a question if you plan to submit another I-D for Curve25519 in OpenPGP. Well, I think that when people say "Curve25519", it refers two different things: the Montgomery curve itself or the ECDH computation with the curve. In the paragraph above, I mean ECDH computation. Specifically,,, > 6. Curve OID > > The EdDSA key parameter curve OID is an array of octets that defines > a named curve. The table below specifies the exact sequence of bytes > for each named curve referenced in this document: > > +------------------------+------+------------------------+----------+ > | OID | Len | Encoding in hex format | Name | > +------------------------+------+------------------------+----------+ > | 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 | Ed25519 | > | | | 0F 01 | | > +------------------------+------+------------------------+----------+ Do you intend to use this OID of Ed25519 for ECDH, too? Or do we use another OID of Curve25519 (the Montgomery curve) for ECDH, to specify Curve25519 (ECDH computation)? -- From wk at gnupg.org Thu Aug 21 08:48:44 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Aug 2014 08:48:44 +0200 Subject: [openpgp] EdDSA/Ed25519 I-D for OpenPGP In-Reply-To: <1408581133.1630.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 21 Aug 2014 09:32:13 +0900") References: <874mx88cvp.fsf@vigenere.g10code.de> <1408581133.1630.1.camel@cfw2.gniibe.org> Message-ID: <87iolm5odv.fsf@vigenere.g10code.de> On Thu, 21 Aug 2014 02:32, gniibe at fsij.org said: > I have a question if you plan to submit another I-D for Curve25519 in > OpenPGP. I would like to do that but the problem I face is that there is no suitable specification for the original Curve25519. Ed25519 is well defined and the printed and online paper should be sufficient as a normative reference. However an I-D for Curve25519 [1] has recently been published. Thus it may soon be possible to describe how to use it in OpenPGP. In particular on how to use only the X coordinate. > Do you intend to use this OID of Ed25519 for ECDH, too? No, that is for Ed25519. > Or do we use another OID of Curve25519 (the Montgomery curve) for > ECDH, to specify Curve25519 (ECDH computation)? For the Montgomery curve Peter Gutman assigned 1.3.6.1.4.1.3029.1.5.1 arlier this year. Shalom-Salam, Werner [1] http://tools.ietf.org/id/draft-turner-thecurve25519function-01.txt -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Aug 21 09:22:52 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Aug 2014 09:22:52 +0200 Subject: [openpgp] EdDSA/Ed25519 I-D for OpenPGP In-Reply-To: (David Leon Gil's message of "Wed, 20 Aug 2014 18:24:18 -0400") References: <874mx88cvp.fsf@vigenere.g10code.de> Message-ID: <87egwa5msz.fsf@vigenere.g10code.de> On Thu, 21 Aug 2014 00:24, coruus at gmail.com said: > See infra. You should list EdDSA parameters that need to be encoded > into the OID. Not required. That is specified in the Ed25519 paper. > This is confusing. EdDSA is defined to operate on messages of > arbitrary length; hashing the message is part of the EdDSA algorithm. Right but that can't be used in OpenPGP. Recall that there is a preference system which goes along with encrypted messages and that we have specific requirements of what needs to be hashed. Messing up the well established OpenPGP layered structure won't do any good. Further, to implement EdDSA on a smartcard it is required that the card does the hashing. Now imagine what happens if you try to sign a 100 MB message: You can go out for lunch and come back to realize that it will take another hour to finish. > Ed25519-SHA2-512 is widely implemented. No other hash functions > currently specified for use with OpenPGP provide long enough output to > be used with Curve25519. We are talking about the EdDSA algorithm which required the Edwards form of Curve25519. The internal use of a 64 byte digest is required by the way EdDSA works. Using a SHA-256 hash as data to be signed matches this nicely but if you don't like it you may sign any other hash. > http://ed25519.cr.yp.to/ed25519-20110926.pdf Web pages are not suitable as a normative reference. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Aug 21 15:39:26 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Aug 2014 15:39:26 +0200 Subject: [Announce] Libgcrypt 1.6.2 released Message-ID: <87oave3qsx.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.6.2. This is a maintenance release to fix problems found in the recently released versions. Libgcrypt is a general purpose library of cryptographic building blocks. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required for proper use Libgcrypt. Noteworthy changes in version 1.6.2 (2014-08-21) ================================================ * Map deprecated RSA algo number to the RSA algo number for better backward compatibility. * Support a 0x40 compression prefix for EdDSA. * Improve ARM hardware feature detection and building. * Fix powerpc-apple-darwin detection * Fix building for the x32 ABI platform. * Support building using the latest mingw-w64 toolchain. * Fix some possible NULL deref bugs. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.2.tar.bz2 (2418k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.2.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.2.tar.gz (2874k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.2.tar.gz.sig Alternativley you may upgrade using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1-1.6.2.diff.bz2 (17k) In order to check that the version of Libgcrypt you are going to build is an original and unmodified one, you can do it in one of the following ways: * Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.6.3.tar.bz2 you would use this command: gpg --verify libgcrypt-1.6.3.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 the release signing key 4F25E3B6 which is certified by my well known key 1E42B367. To retrieve the keys you may use the command "gpg --fetch-key finger:wk at g10code.com". * If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.6.3.tar.bz2 and check that the output matches the first line from the following list: cc31aca87e4a3769cb86884a3f5982b2cc8eb7ec libgcrypt-1.6.2.tar.bz2 cdaf2bdd5f34b20f4f9d926536673c15b857d2e6 libgcrypt-1.6.2.tar.gz 302592ec4183b727ad07bdd47fc4d50d717f42e2 libgcrypt-1.6.1-1.6.2.diff.bz2 Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt 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: https://gnupg.org/donate/ Thanks ====== Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] http://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] https://www.gnupg.org/service.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: 180 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 green at mm.st Fri Aug 22 09:49:46 2014 From: green at mm.st (green at mm.st) Date: Fri, 22 Aug 2014 08:49:46 +0100 Subject: GPG functions failing intermitently with specific key on specific machine Message-ID: <1408693786.3430246.155519657.1F61E2D8@webmail.messagingengine.com> Hi, I recently added a post to the gnupg-users mailing list (http://marc.info/?t=140684231100001&r=1&w=2) concerning an issue I'm having with gnupg on my Arch Linux machine. After a few useful suggestions, a couple of the users there have suggested that I now create a new post on gnupg-devel, in order to see if someone with expertise with the gnupg code can help. In summary: - I have gpg set up on two machines, one running Arch Linux (gnupg 2.0.26, libgcrypt 1.6.1) the other Windows 7 x64 (gpg4win 2.2.1). - I originally had only one private key. - gpg2 functions using that key on the Linux machine fail intermittently (e.g. with a "Bad signature" error, when clearsigning). - gpg2 functions using the same key on the Windows PC succeed consistently. - I have since created a new keypair. - I can encrypt consistently and successfully with the new private key on *both* machines. - I have deleted the problematic private key on the Linux machine, exported it from the Windows machine and re-imported it on the Linux machine, but the intermittent errors still occur with that key. I would be very grateful if anyone could help? Please also let me know if there is any additional information I could provide which might help diagnose the problem. Many thanks, Wolf. From wk at gnupg.org Fri Aug 22 10:49:44 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Aug 2014 10:49:44 +0200 Subject: GPG functions failing intermitently with specific key on specific machine In-Reply-To: <1408693786.3430246.155519657.1F61E2D8@webmail.messagingengine.com> (green@mm.st's message of "Fri, 22 Aug 2014 08:49:46 +0100") References: <1408693786.3430246.155519657.1F61E2D8@webmail.messagingengine.com> Message-ID: <8738co52on.fsf@vigenere.g10code.de> On Fri, 22 Aug 2014 09:49, green at mm.st said: > I would be very grateful if anyone could help? Please also let me know Can you please send me the *public* key (to wk at gnupg.org). I have no idea whether this helps but I would like to look at it. Please try to build the GnuPG version with libgcrypt 1.5.3, test and then use libgcrypt 1.5.4 for a second test? Same problem? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From green at mm.st Fri Aug 22 14:40:07 2014 From: green at mm.st (green at mm.st) Date: Fri, 22 Aug 2014 13:40:07 +0100 Subject: GPG functions failing intermitently with specific key on specific machine In-Reply-To: <8738co52on.fsf@vigenere.g10code.de> References: <1408693786.3430246.155519657.1F61E2D8@webmail.messagingengine.com> <8738co52on.fsf@vigenere.g10code.de> Message-ID: <1408711207.3494613.155596633.6F9E3264@webmail.messagingengine.com> Thanks Werner, I've sent the public key to you. I'm not sure how to build GnuPG from source but I'm always happy to learn so I'll do some research and let you know how I get on :) All the best, Wolf On Fri, 22 Aug 2014, at 09:49 AM, Werner Koch wrote: > On Fri, 22 Aug 2014 09:49, green at mm.st said: > > > I would be very grateful if anyone could help? Please also let me know > > Can you please send me the *public* key (to wk at gnupg.org). I have > no idea whether this helps but I would like to look at it. > > Please try to build the GnuPG version with libgcrypt 1.5.3, test and > then use libgcrypt 1.5.4 for a second test? Same problem? > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From harakiri_23 at yahoo.com Sat Aug 23 02:31:54 2014 From: harakiri_23 at yahoo.com (harakiri_23 at yahoo.com) Date: Sat, 23 Aug 2014 00:31:54 +0000 (UTC) Subject: FWD: Message-ID: <977834.41654.bm@smtp117.mail.ir2.yahoo.com> Hey! http://etemadtrading.com/-redirect?zafygjgy34487029 From sdaoden at yandex.com Mon Aug 25 15:17:36 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Mon, 25 Aug 2014 13:17:36 +0000 (UTC) Subject: pinentry-curses can be forced to loop endlessly Message-ID: This is the fourth try to get through to this list. I even subscribed to get it through, but still some black list hits first and excludes anyone from a large provider. Date: Mon, 18 Aug 2014 12:45:08 +0200 From: Steffen Nurpmeso To: gnupg-devel at gnupg.org Subject: pinentry-curses can be forced to loop endlessly Hello, the bug i report here was not present in v2.0.24 (i think, looking at the ArchLinux package history [1]) but then came into existence with v2.0.25 and is still present in the new package that uses v2.0.26. [1] I am still (see ArchLinux bug report [2]) too lazy to find a different way to reproduce it, so this example assumes the default ArchLinux mailx(1) (v14.7.2 or later) (or CRUX-Linux or Void Linux packages; or download S-nail directly [3]): [2] [3] $ eval `gpg-agent --daemon \ --pinentry-program=/usr/bin/pinentry-curses \ --max-cache-ttl 99999 --default-cache-ttl 99999` $ echo PASS > /tmp/.pass $ gpg -e /tmp/.pass $ cat > /tmp/t.rc <<__EOT set v15-compat set smtp=nobody at localhost set agent-shell-lookup='gpg -d /tmp/.pass.gpg' __EOT $ echo bla|MAILRC=/tmp/t.rc mailx/s-nail -n -dvv -s sub du at auch ..^C to interrupt here.. This should leave an endlessly looping pinentry-curses after interruption around which needs to be kill(1)ed with -QUIT explicitly. The bug only occurs if S-nail is used (and thus pinentry-curses is run) as part of a pipe, just as shown. P.S.: i am not subscribed, but cannot say anything more anyway. --steffen From mail at tgries.de Mon Aug 25 21:30:00 2014 From: mail at tgries.de (Thomas Gries) Date: Mon, 25 Aug 2014 21:30:00 +0200 Subject: cannot build pinentry Message-ID: <53FB8EB8.4060202@tgries.de> I cannot built *pinetry* automake --version ? 1.11.6 autoconf --version ? 2.69 git clone git://git.gnupg.org/pinentry.git cd pinentry ./autogen.sh ? main::scan_file() called too early to check prototype at /usr/local/bin/aclocal line 643. Running aclocal -I m4 ... main::scan_file() called too early to check prototype at /usr/local/bin/aclocal line 643. configure.ac:302: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... m4/iconv.m4:22: AM_ICONV_LINK is expanded from... m4/iconv.m4:77: AM_ICONV is expanded from... configure.ac:302: the top level configure.ac:302: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... m4/iconv.m4:22: AM_ICONV_LINK is expanded from... m4/iconv.m4:77: AM_ICONV is expanded from... configure.ac:302: the top level Running autoheader... ? ./configure --enable-maintainer-mode ? ./configure: line 7718: *syntax error*near unexpected token `iconv' ./configure: line 7718: ` AC_LIB_LINKFLAGS_BODY(iconv)' /Can anyone help to get this compiled?// / -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge0x76 at gmail.com Mon Aug 25 22:18:16 2014 From: serge0x76 at gmail.com (Serge Voilokov) Date: Mon, 25 Aug 2014 16:18:16 -0400 Subject: cannot build pinentry In-Reply-To: <53FB8EB8.4060202@tgries.de> References: <53FB8EB8.4060202@tgries.de> Message-ID: Do you have iconv installed in /usr/bin/ or /usr/local/bin/? Check it with: iconv --version It should respond with "iconv (GNU libiconv 1.14)" or similar. On Mon, Aug 25, 2014 at 3:30 PM, Thomas Gries wrote: > I cannot built pinetry > > automake --version ? 1.11.6 > autoconf --version ? 2.69 > > git clone git://git.gnupg.org/pinentry.git > cd pinentry > > ./autogen.sh > ? > main::scan_file() called too early to check prototype at > /usr/local/bin/aclocal line 643. > Running aclocal -I m4 ... > main::scan_file() called too early to check prototype at > /usr/local/bin/aclocal line 643. > configure.ac:302: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not > m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:302: the top level > configure.ac:302: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:302: the top level > Running autoheader... > ? > > ./configure --enable-maintainer-mode > ? > ./configure: line 7718: syntax error near unexpected token `iconv' > ./configure: line 7718: ` AC_LIB_LINKFLAGS_BODY(iconv)' > > > Can anyone help to get this compiled? > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From wk at gnupg.org Tue Aug 26 18:27:20 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Aug 2014 18:27:20 +0200 Subject: Moving estream to libgpg-error Message-ID: <87ppfnxllj.fsf@vigenere.g10code.de> Hi! Estream is a stdio replacement we use for portability reasons in GnuPG. Because that is incredibly useful (think fopencookie/funopen and Windows lack of positional printf args). I have now extended libgpg-error to provide the estream functions. This will allow us to use it in a number of other related projects (e.g. gpgme, gpa) because they require libgpg-error anyway. Note that the symbol names are all prefixed with "gpgrt_" and not with "gpg_err_". If you like to test it, use git master for libgpg-error and the wk/tests-gpgrt-estream branch of gnupg. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kylebutt at gmail.com Tue Aug 26 23:11:47 2014 From: kylebutt at gmail.com (Kyle Butt) Date: Tue, 26 Aug 2014 14:11:47 -0700 Subject: [PATCH] Fix export of ecc secret keys by adjusting check ordering. Message-ID: <1409087507-30269-1-git-send-email-kylebutt@gmail.com> Move the check against PUBKEY_MAX_NSKEY to after the ECC code adjusts the number of parameters. --- g10/export.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/g10/export.c b/g10/export.c index 6a921c1..b4f1a2e 100644 --- a/g10/export.c +++ b/g10/export.c @@ -462,7 +462,7 @@ transfer_format_to_openpgp (gcry_sexp_t s_pgp, PKT_public_key *pk) xfree (string); string = NULL; if (gcry_pk_algo_info (pk_algo, GCRYCTL_GET_ALGO_NPKEY, NULL, &npkey) || gcry_pk_algo_info (pk_algo, GCRYCTL_GET_ALGO_NSKEY, NULL, &nskey) - || !npkey || npkey >= nskey || nskey > PUBKEY_MAX_NSKEY) + || !npkey || npkey >= nskey) goto bad_seckey; /* Check that the pubkey algo matches the one from the public key. */ @@ -503,6 +503,10 @@ transfer_format_to_openpgp (gcry_sexp_t s_pgp, PKT_public_key *pk) goto leave; } + /* This check has to go after the ecc adjustments. */ + if (nskey > PUBKEY_MAX_NSKEY) + goto bad_seckey; + /* Parse the key parameters. */ gcry_sexp_release (list); list = gcry_sexp_find_token (top_list, "skey", 0); -- 1.8.1.4 From stef at thewalter.net Thu Aug 28 12:46:01 2014 From: stef at thewalter.net (Stef Walter) Date: Thu, 28 Aug 2014 12:46:01 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? Message-ID: <53FF0869.8090201@thewalter.net> Hey guys, I noticed this commit: https://gitorious.org/gnupg/mainline/commit/b896fccaada0caf1987eb95ac99dd6b4ca609c4b It seems that you don't want gpg2 used with GNOME 3.x as is (in its default configuration). Should I go ahead and announce that gpg2 (version 2.0.23+) is incompatible with GNOME and people should USE gnupg 1.4.x with GNOME 3.x for now? I know Werner and I discussed solutions to this issue a more than a year ago, but obviously neither of us has had enough time to make the changes happen. To summarize, either: a. gnupg needs to integrate with GNOME 3 (prompt via gnome-shell, and give the option to save passwords in the keyring) and gnome-keyring can then drop its gpg-agent implementation, as its features would now be found elsewhere. Or: b. gnome-keyring needs to run a proper gpg-agent and proxy all the commands to it, intercepting the commands it needs in order to implement its features. This would still be "hijacking" ... whatever that means :/ I'd far prefer option (a) above. Any takers for implementing either one of the above? Cheers, Stef From wk at gnupg.org Thu Aug 28 15:30:23 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Aug 2014 15:30:23 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <53FF0869.8090201@thewalter.net> (Stef Walter's message of "Thu, 28 Aug 2014 12:46:01 +0200") References: <53FF0869.8090201@thewalter.net> Message-ID: <87bnr4wxlc.fsf@vigenere.g10code.de> On Thu, 28 Aug 2014 12:46, stef at thewalter.net said: > It seems that you don't want gpg2 used with GNOME 3.x as is (in its > default configuration). No, I want you to change the default configuration - I told you that over lunch during last years FOSDEM. This mess is going on for many years now and a lot of people are annoyed. Fortunately most users of GnuPG's S/MIME feature are using KDE and not GNOME and thus are not affected by that hijacking. With 2.1 OpenPGP users will also be affected and thus I escalated this issue using the new warning. > Should I go ahead and announce that gpg2 (version 2.0.23+) is > incompatible with GNOME and people should USE gnupg 1.4.x with GNOME 3.x The warning message says it all: GKR is hijacking the IPC between components of GnuPG - you don't have to mess with that! Shall I start to encrypt and authenticate the IPC just to make it harder for GKR to mess with it - that would be a silly game. > I know Werner and I discussed solutions to this issue a more than a year > ago, but obviously neither of us has had enough time to make the changes I tried to implement what we discussed but came to the conclusion that this won't work. You simply can't have two daemons competing about cached items. The caching is an integral part of GnuPG and any hacks around it would only trigger other bugs. > a. gnupg needs to integrate with GNOME 3 (prompt via gnome-shell, and > give the option to save passwords in the keyring) and gnome-keyring There are no passwords to save. You do not want to do that by default. If users figure out a way to do that anyway, they may do that but we should not make it too easy for them. Recall that we are talking about passphrases to protect a private key and not about passphrases used in any authentication or encryption protocol. > implement its features. This would still be "hijacking" ... > whatever that means :/ hijacking n 1: robbery of a traveller or vehicle in transit or seizing control of a vehicle by the use of force [syn: {highjacking}, {hijacking}] > I'd far prefer option (a) above. Any takers for implementing either one > of the above? There is also a c) Write a Pinentry using the documented interface between gpg-agent and Pinentry and make use of it. If you don't want any caching, well, you may disable caching in gpg-agent.conf. The Guardian Project actually used this custom Pinnetry approach to have a better integration with the rest of the Java based Android GUI. It is easy: You already have a running daemon, you only need to write a Pinentry connecting to that daemon. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Aug 28 16:31:38 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 28 Aug 2014 23:31:38 +0900 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <53FF0869.8090201@thewalter.net> References: <53FF0869.8090201@thewalter.net> Message-ID: <53FF3D4A.9050005@fsij.org> Hello, It's not new. It has been incompatible for years, already. On 08/28/14 19:46, Stef Walter wrote: > Should I go ahead and announce that gpg2 (version 2.0.23+) is > incompatible with GNOME and people should USE gnupg 1.4.x with GNOME 3.x > for now? Please note that gpg-agent is not the "GPG password caching daemon". It's not new issue for smartcard/token users and SSH users for gpg2 (both of 2.0 and 2.1) with GNOME. (1) When users have smartcard/token, it doesn't work well. (2) When users configure the SSH-agent feature of gpg-agent, it doesn't work well. We need to disable the features of gnome-keyring, for years. However, how to disable the features of gpg-agent/ssh-agent for gnome-keyring has been changed in version to version. I had figured out how to do that in GNOME2 and in younger GNOME 3, but now, I don't know how we can disable the features in GNOME 3.12 or later (using proper gpg-agent). -- From stef at thewalter.net Thu Aug 28 17:22:48 2014 From: stef at thewalter.net (Stef Walter) Date: Thu, 28 Aug 2014 17:22:48 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <87bnr4wxlc.fsf@vigenere.g10code.de> References: <53FF0869.8090201@thewalter.net> <87bnr4wxlc.fsf@vigenere.g10code.de> Message-ID: <53FF4948.2020408@thewalter.net> On 28.08.2014 15:30, Werner Koch wrote: > On Thu, 28 Aug 2014 12:46, stef at thewalter.net said: > >> It seems that you don't want gpg2 used with GNOME 3.x as is (in its >> default configuration). > > No, I want you to change the default configuration - I told you that > over lunch during last years FOSDEM. This mess is going on for many > years now and a lot of people are annoyed. Fortunately most users of > GnuPG's S/MIME feature are using KDE and not GNOME and thus are not > affected by that hijacking. With 2.1 OpenPGP users will also be > affected and thus I escalated this issue using the new warning. Sorry I don't have time to work on this myself in the near future. The gnome-keyring GPG agent stuff was written for GPG 1.4.x ... and the GPG 2 came around which changed (and is still changing) things significantly. Fair enough, bit this is hardly as one sided as it might seem. It seems nobody cares enough about using those GPG 2.x features (which depend on the real gpg-agent) to actually contribute a fix for this. I'd be overjoyed at such a contribution and would help review and merge it. >> Should I go ahead and announce that gpg2 (version 2.0.23+) is >> incompatible with GNOME and people should USE gnupg 1.4.x with GNOME 3.x > > The warning message says it all: GKR is hijacking the IPC between > components of GnuPG - you don't have to mess with that! Shall I start > to encrypt and authenticate the IPC just to make it harder for GKR to > mess with it - that would be a silly game. This is not about a power trip or outsmarting each other or anything like that. I'm looking for someone to help contribute a fix. Until someone does have time to work on this ... it's obvious gnome-keyring's gpg agent is only meant for gpg 1.4.x .... and we should probably hard code that in during the build process. >> I know Werner and I discussed solutions to this issue a more than a year >> ago, but obviously neither of us has had enough time to make the changes > > I tried to implement what we discussed but came to the conclusion that > this won't work. You simply can't have two daemons competing about > cached items. The caching is an integral part of GnuPG and any hacks > around it would only trigger other bugs. Fair enough. But why didn't you say something about this conclusion? Did I miss an email or mailing list post about this? If so, could you link to it? >> a. gnupg needs to integrate with GNOME 3 (prompt via gnome-shell, and >> give the option to save passwords in the keyring) and gnome-keyring > > There are no passwords to save. You do not want to do that by default. > If users figure out a way to do that anyway, they may do that but we > should not make it too easy for them. Recall that we are talking about > passphrases to protect a private key and not about passphrases used in > any authentication or encryption protocol. This is not a default setting, but many users want to effectively unlock one or more GPG keys when they unlock their machine. Optionally storing the passphrases to protect the private key in the keyring allows for this. >> I'd far prefer option (a) above. Any takers for implementing either one >> of the above? > > There is also a > > c) Write a Pinentry using the documented interface between gpg-agent > and Pinentry and make use of it. If you don't want any caching, > well, you may disable caching in gpg-agent.conf. The Guardian > Project actually used this custom Pinnetry approach to have a better > integration with the rest of the Java based Android GUI. It is > easy: You already have a running daemon, you only need to write a > Pinentry connecting to that daemon. True ... as long as it can cover all the features. I'm not against this option either. Cheers, Stef From stef at thewalter.net Thu Aug 28 17:24:32 2014 From: stef at thewalter.net (Stef Walter) Date: Thu, 28 Aug 2014 17:24:32 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <53FF3D4A.9050005@fsij.org> References: <53FF0869.8090201@thewalter.net> <53FF3D4A.9050005@fsij.org> Message-ID: <53FF49B0.3010603@thewalter.net> On 28.08.2014 16:31, NIIBE Yutaka wrote: > Hello, > > It's not new. It has been incompatible for years, already. > > On 08/28/14 19:46, Stef Walter wrote: >> Should I go ahead and announce that gpg2 (version 2.0.23+) is >> incompatible with GNOME and people should USE gnupg 1.4.x with GNOME 3.x >> for now? > > Please note that gpg-agent is not the "GPG password caching daemon". > > It's not new issue for smartcard/token users and SSH users for gpg2 > (both of 2.0 and 2.1) with GNOME. > > (1) When users have smartcard/token, it doesn't work well. > > (2) When users configure the SSH-agent feature of gpg-agent, it > doesn't work well. > > We need to disable the features of gnome-keyring, for years. > > However, how to disable the features of gpg-agent/ssh-agent for > gnome-keyring has been changed in version to version. I had figured > out how to do that in GNOME2 and in younger GNOME 3, but now, I don't > know how we can disable the features in GNOME 3.12 or later (using > proper gpg-agent). I'm not against contributions which remove the gpg-agent and ssh-agent from gnome-keyring. The equivalent features and use cases should be provided elsewhere, and it's a done deal. Cheers, Stef From aheinecke at intevation.de Thu Aug 28 16:38:51 2014 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 28 Aug 2014 16:38:51 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <87bnr4wxlc.fsf@vigenere.g10code.de> References: <53FF0869.8090201@thewalter.net> <87bnr4wxlc.fsf@vigenere.g10code.de> Message-ID: <13553563.7H4lS9zpWG@esus> Hi, On Thursday, August 28, 2014 - KW 35 03:30:23 PM Werner Koch wrote: > On Thu, 28 Aug 2014 12:46, stef at thewalter.net said: > > It seems that you don't want gpg2 used with GNOME 3.x as is (in its > > default configuration). > > No, I want you to change the default configuration - I told you that > over lunch during last years FOSDEM. This mess is going on for many > years now and a lot of people are annoyed. Fortunately most users of > GnuPG's S/MIME feature are using KDE and not GNOME and thus are not > affected by that hijacking. With 2.1 OpenPGP users will also be > affected and thus I escalated this issue using the new warning. Still even if your run a mostly KDE desktop your distribution might ship the gnome-keyring pseudo gpg-agent and it might be started before the real gnome- keyring. Kleopatra currently fails in the self test if gnome-keyring is hjacking the socket with an "error while asking gpg-agent for its version". There are already some bugs about this from users that do not know what is wrong. But at least it complains. With older versions of kdepim / kleopatra you just get nasty unexpected errors when you try to use features which are not handled by your "pseudo" gpg-agent. So I'm interested in this discussion as I should probably add a similar warning in the Kleopatra self test in case gnome-keyring has hijacked the socket as this hijacking breaks Kleopatra. > > > Should I go ahead and announce that gpg2 (version 2.0.23+) is > > incompatible with GNOME and people should USE gnupg 1.4.x with GNOME 3.x > > The warning message says it all: GKR is hijacking the IPC between > components of GnuPG - you don't have to mess with that! Shall I start > to encrypt and authenticate the IPC just to make it harder for GKR to > mess with it - that would be a silly game. I agree with Werner here. I feel like you want to trick users into using gnome-keyring when they expect to communicate with gpg-agent (With users I also mean other pieces of software) From a Kleopatra standpoint I would like to see gnome-keyring packaged with a "breaks gnupg2" or at least the gpg-agent hijacking part should be packaged in a seprate package which can conflict/break with users of gnupg2 features. It is not gnupg2 that is incompatible with gnome-keyring, it is gnome-keyring that deliberately breaks a large part of the feature set of gnupg2. I mean what would you say if KWallet would set a GNOME_KEYRING_CONTROL environment variable to point to itself? Would you then go ahead and say gnome software is not compatible with a KDE Desktop or would you complain that KWallet breaks gnome-keyring users and should stop setting the variable? Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Aug 28 18:26:05 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Aug 2014 18:26:05 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <53FF4948.2020408@thewalter.net> (Stef Walter's message of "Thu, 28 Aug 2014 17:22:48 +0200") References: <53FF0869.8090201@thewalter.net> <87bnr4wxlc.fsf@vigenere.g10code.de> <53FF4948.2020408@thewalter.net> Message-ID: <87tx4wvaw2.fsf@vigenere.g10code.de> On Thu, 28 Aug 2014 17:22, stef at thewalter.net said: > Sorry I don't have time to work on this myself in the near future. The > gnome-keyring GPG agent stuff was written for GPG 1.4.x ... and the GPG > 2 came around which changed (and is still changing) things > significantly. Fair enough, bit this is hardly as one sided as it might > seem. Release date 1.9.0: 2003-08-05 the first GnuPG-2 release 1.4.0: 2004-12-16 1.4.2: 2005-07-26 adds support for the GnuPG-2 agent 2.0.0: 2006-11-11 Fast forward to 2010: commit 302db3f520c944176be75cb7f491573038d48b6e Author: Stef Walter [...] Date: Sat May 8 15:49:43 2010 +0000 Start work on gpg-agent, incomplete. [...] > It seems nobody cares enough about using those GPG 2.x features (which > depend on the real gpg-agent) to actually contribute a fix for this. I'd I can count the number of mails I answered regarding this problem or the hours I spend analyzing bug reports which turned out to be a GKR problem. > This is not about a power trip or outsmarting each other or anything > like that. I'm looking for someone to help contribute a fix. The fix is on your site: Remove that gpg-agent thingy. > gnome-keyring's gpg agent is only meant for gpg 1.4.x .... and we should > probably hard code that in during the build process. You shall not mess around with the 1.4 IPC either. As gniibe noted, thre is much more to it than just passphrase caching. > Fair enough. But why didn't you say something about this conclusion? Did > I miss an email or mailing list post about this? If so, could you link > to it? Well there is a solution now: That annoying warning dialog. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Thu Aug 28 17:39:46 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Thu, 28 Aug 2014 16:39:46 +0100 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <53FF0869.8090201@thewalter.net> References: <53FF0869.8090201@thewalter.net> Message-ID: <53FF4D42.2060000@pwned.gg> On 28/08/14 11:46, Stef Walter wrote: > Hey guys, > > I noticed this commit: > > https://gitorious.org/gnupg/mainline/commit/b896fccaada0caf1987eb95ac99dd6b4ca609c4b > > It seems that you don't want gpg2 used with GNOME 3.x as is (in its > default configuration). > > Should I go ahead and announce that gpg2 (version 2.0.23+) is > incompatible with GNOME and people should USE gnupg 1.4.x with GNOME 3.x > for now? > > I know Werner and I discussed solutions to this issue a more than a year > ago, but obviously neither of us has had enough time to make the changes > happen. > > To summarize, either: > > a. gnupg needs to integrate with GNOME 3 (prompt via gnome-shell, and > give the option to save passwords in the keyring) and gnome-keyring > can then drop its gpg-agent implementation, as its features would now > be found elsewhere. > From the view of an outsider: gnupg is a lower-level program, GNOME 3 is a higher-level desktop environment. It sounds ridiculous to suggest that lower-level utilities should have to do anything special for desktop environments to work with it. Is there some more reasonable, generalised, non-GNOME-specific interface (that GNOME 3 happens to implement) that you can suggest gnupg to adhere to instead? X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Aug 28 20:17:11 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Aug 2014 20:17:11 +0200 Subject: OpenSSH, gpg-agent, and gpg Message-ID: <871ts0v5qw.fsf@vigenere.g10code.de> Hi, I just read at LWN about the forthcoming OpenSSH 6.7: Among the new features is support for Unix domain socket forwarding. This feature allows a Unix domain socket on the local machine to be forward to a remote TCP port, or a remote TCP port to be forwarded to a local Unix domain socket?using the same syntax that OpenSSH supports for forwarding to TCP ports. For example, a remote PostgreSQL database instance could be connected over a secure SSH channel to a Unix domain socket on the local machine with ssh -L/tmp/foo.sock:mydatabase.net:5432 someserver. It is also possible to connect two local Unix domain sockets over an SSH connection. Several years ago, this functionality was available in a patch set by William Ahern. The last update to Ahern's code, however, was made in 2012 for OpenSSH 6.1. The new feature is a reimplementation of the same work. https://lwn.net/Articles/609321/ (subscriber only for two weeks) That is a cool thing because it allows us to keep gpg-agent on the desktop and run gpg on the server without fearing a compromise of the secret key. I am waiting for such a feature for quite some time. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Thu Aug 28 21:01:33 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 28 Aug 2014 21:01:33 +0200 Subject: OpenSSH, gpg-agent, and gpg In-Reply-To: <871ts0v5qw.fsf@vigenere.g10code.de> References: <871ts0v5qw.fsf@vigenere.g10code.de> Message-ID: <1632518.rkQmKzp4y9@inno> Am Do 28.08.2014, 20:17:11 schrieb Werner Koch: > That is a cool thing because it allows us to keep gpg-agent on the > desktop and run gpg on the server without fearing a compromise of the > secret key. I am waiting for such a feature for quite some time. Is that true for GnuPG 2.0.x, too, or only for 2.1? It seems to me that 2.0.x uses gpg-agent for passphrase caching only but not for handling the private keys. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- 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 kristian.fiskerstrand at sumptuouscapital.com Thu Aug 28 22:09:59 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 28 Aug 2014 22:09:59 +0200 Subject: OpenSSH, gpg-agent, and gpg In-Reply-To: <1632518.rkQmKzp4y9@inno> References: <871ts0v5qw.fsf@vigenere.g10code.de> <1632518.rkQmKzp4y9@inno> Message-ID: <53FF8C97.2090306@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 08/28/2014 09:01 PM, Hauke Laging wrote: > Am Do 28.08.2014, 20:17:11 schrieb Werner Koch: > >> That is a cool thing because it allows us to keep gpg-agent on >> the desktop and run gpg on the server without fearing a >> compromise of the secret key. I am waiting for such a feature >> for quite some time. > > Is that true for GnuPG 2.0.x, too, or only for 2.1? It seems to me > that 2.0.x uses gpg-agent for passphrase caching only but not for > handling the private keys. For OpenPGP operations, this is indeed specific to 2.1 where all secret-key operations are performed in the agent. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT/4yWAAoJEPw7F94F4Tag+8wP/Ak5SxCaaCyjebrLI47waEuz /McqTl8Gw9zVIq6sXEPVXT37AaLor50qUmRH5+DP6iZf5RvljAV9YB0tPZ2ca1KW 0I4xuUyUSNVeGpNJeDn52dR0sUnuuqXbmgUGkD1Wag14hh+ZI5Mja68Cmi9QSGKW X4rVNcPszxra+5eOE1DuSMQEnX+oUDZK5CbmRCxSPB+gQYBorYYiiMEY0BKoL+mp lQF6iT4XqjPB2XOJT+l701CEGjOKquNbFeUy4MrR9DUz0drKkFBAQoovLS4y+y45 2hZD8dcsGiqMlnppwJnC0atXTnMMHhFV6AEYytTsY4Lz69PGjeUcd39y/CtDfQkf 4BH4QcagshJOWp1LrNeoxscG3F2hElknoBnt26y9QFKIlT+TZbsno8Royq6P2SLx fX4n36yOEx5N1Jo+vK1kr/RSzuN6qsrFQWGq2aNKeuLlK0zxAJ8CpEIchksGnY7k Ul87nyK3ufPcEYwh9lDw/wo+tI6oTn+4foKG5CzvcLrnbteWSI/OT7JVYNr2BeT0 lnmvq22kBLrmhJwqDXZX0CDfydnwOKvgokneMXQW0nKuFYvJuqWoNZgR2EmHVhts Wtwe5nEJNoXFsErYaqoVFjFeuCWWs7OBVJT9sVJYv3p8y55EhUUn3vXI3lvH+NGJ EJwrEpE8RjuOSi+SMckw =HVGH -----END PGP SIGNATURE----- From kylebutt at gmail.com Fri Aug 29 01:23:31 2014 From: kylebutt at gmail.com (Kyle Butt) Date: Thu, 28 Aug 2014 16:23:31 -0700 Subject: ECC Key export incorrectly produces 0-sized output for secret part of key. Message-ID: As far as I can tell, the agent produces s-expressions where the public and private key values are opaque, and then gcry_mpi_aprint prints an empty value inside of apply_protection in agent/cvt-openpgp.c (There's a complete backtrace at the end.) I'd go further, but I'm unsure which is wrong, the opaqueness, or the conversion routine. Thanks, Kyle. #0 _gcry_mpi_print (format=format at entry=GCRYMPI_FMT_USG, buffer=0xb6201748 "@", buflen=32, nwritten=nwritten at entry=0xb60ff04c, a=a at entry=0xb6201730) at mpicoder.c:693 #1 0xb76e170b in _gcry_mpi_aprint (format=format at entry=GCRYMPI_FMT_USG, buffer=buffer at entry=0xb60ff1a0, nwritten=nwritten at entry=0xb60ff150, a=a at entry=0xb6201730) at mpicoder.c:854 #2 0xb7679db3 in gcry_mpi_aprint (format=format at entry=GCRYMPI_FMT_USG, buffer=buffer at entry=0xb60ff1a0, nwritten=nwritten at entry=0xb60ff150, a=0xb6201730) at visibility.c:374 #3 0x0806c077 in apply_protection (protect_algo=7, protect_ivlen=16, s2k_mode=3, s2k_algo=2, s2k_count=190, s2k_salt=0xb60ff100 "\036\323\v\361\324\330\062\301", protect_iv=0xb60ff118, passphrase=0xb76557c8 "Test Key 1", nskey=2, npkey=1, array=0xb60ff128) at cvt-openpgp.c:1067 #4 convert_to_openpgp (ctrl=ctrl at entry=0x833dc68, s_key=0xb76557f0, passphrase=passphrase at entry=0xb76557c8 "Test Key 1", r_transferkey=r_transferkey at entry=0xb60ff238, r_transferkeylen=r_transferkeylen at entry=0xb60ff23c) at cvt-openpgp.c:1261 #5 0x08052fee in cmd_export_key (ctx=0xb62004b0, line=) at command.c:2192 #6 0xb7663608 in dispatch_command (ctx=ctx at entry=0xb62004b0, line=, line at entry=0xb620056c "END", linelen=) at assuan-handler.c:675 #7 0xb7664557 in process_request (ctx=0xb62004b0) at assuan-handler.c:871 #8 assuan_process (ctx=0xb62004b0) at assuan-handler.c:894 #9 0x08055e97 in start_command_handler (ctrl=ctrl at entry=0x833dc68, listen_fd=listen_fd at entry=-1, fd=4) at command.c:3058 #10 0x08050167 in start_connection_thread (arg=0x833dc68) at gpg-agent.c:2073 #11 start_connection_thread (arg=0x833dc68) at gpg-agent.c:2057 #12 0xb7648526 in thread_start () from /lib/libnpth.so.0 #13 0x4b7e3aff in start_thread () from /lib/libpthread.so.0 #14 0x4b7130ee in clone () from /lib/libc.so.6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Aug 29 05:08:57 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 Aug 2014 20:08:57 -0700 Subject: OpenSSH, gpg-agent, and gpg In-Reply-To: <871ts0v5qw.fsf@vigenere.g10code.de> References: <871ts0v5qw.fsf@vigenere.g10code.de> Message-ID: <53FFEEC9.7020009@fifthhorseman.net> On 08/28/2014 11:17 AM, Werner Koch wrote: > That is a cool thing because it allows us to keep gpg-agent on the > desktop and run gpg on the server without fearing a compromise of the > secret key. I am waiting for such a feature for quite some time. with a bit of socat for glue, this has been possible for a long time: https://www.debian-administration.org/users/dkg/weblog/68 i agree that it is an excellent feature, and it will be much nicer to be able to do it without the glue. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From stef at thewalter.net Fri Aug 29 09:11:10 2014 From: stef at thewalter.net (Stef Walter) Date: Fri, 29 Aug 2014 09:11:10 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <53FF4D42.2060000@pwned.gg> References: <53FF0869.8090201@thewalter.net> <53FF4D42.2060000@pwned.gg> Message-ID: <5400278E.9090204@thewalter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28.08.2014 17:39, Ximin Luo wrote: > On 28/08/14 11:46, Stef Walter wrote: >> Hey guys, >> >> I noticed this commit: >> >> https://gitorious.org/gnupg/mainline/commit/b896fccaada0caf1987eb95ac99dd6b4ca609c4b >> >> >> >> It seems that you don't want gpg2 used with GNOME 3.x as is (in its >> default configuration). >> >> Should I go ahead and announce that gpg2 (version 2.0.23+) is >> incompatible with GNOME and people should USE gnupg 1.4.x with >> GNOME 3.x for now? >> >> I know Werner and I discussed solutions to this issue a more than >> a year ago, but obviously neither of us has had enough time to >> make the changes happen. >> >> To summarize, either: >> >> a. gnupg needs to integrate with GNOME 3 (prompt via >> gnome-shell, and give the option to save passwords in the >> keyring) and gnome-keyring can then drop its gpg-agent >> implementation, as its features would now be found elsewhere. >> > > From the view of an outsider: gnupg is a lower-level program, GNOME > 3 is a higher-level desktop environment. It sounds ridiculous to > suggest that lower-level utilities should have to do anything > special for desktop environments to work with it. Nah, this happens all the time. Low level stuff, like the kernel, libraries, and gnupg are there to enable higher level features. Developers and system administrators often access these low level APIs and tools ourselves, but that is an exception, at the end of the day they are combined into higher level features for the user to actually use. It's never a surprise that the high level features have a bearing on the capabilities and APIs of the underlying tools. > Is there some more reasonable, generalised, non-GNOME-specific > interface (that GNOME 3 happens to implement) that you can suggest > gnupg to adhere to instead? Well, as Werner suggested, gnupg has such a semi-standard "pinentry" interface. Someone needs to write a gnome-shell prompter using it (one could use this Gcr API if desired [1]). In addition that pinentry prompter needs to be able to optionally save the private key password in gnome-keyring (libsecret API [2]) so that the user can optionally have the private keys automatically unlocked whenever they are logged into their GNOME session. These are the two features that the gnome-keyring GPG agent enables, and the two features that replacement would need to provide. Cheers, Stef -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQAJ40ACgkQe/sRCNknZa+nIwCeIWturjhF8+bXUmZXqa7dUDSW 4X4AoMfLfeDNEMcTVqMkzRRgse0iU8dn =X3s7 -----END PGP SIGNATURE----- From stef at thewalter.net Fri Aug 29 09:40:05 2014 From: stef at thewalter.net (Stef Walter) Date: Fri, 29 Aug 2014 09:40:05 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <87tx4wvaw2.fsf@vigenere.g10code.de> References: <53FF0869.8090201@thewalter.net> <87bnr4wxlc.fsf@vigenere.g10code.de> <53FF4948.2020408@thewalter.net> <87tx4wvaw2.fsf@vigenere.g10code.de> Message-ID: <54002E55.1020802@thewalter.net> On 28.08.2014 18:26, Werner Koch wrote: > On Thu, 28 Aug 2014 17:22, stef at thewalter.net said: > >> Sorry I don't have time to work on this myself in the near future. The >> gnome-keyring GPG agent stuff was written for GPG 1.4.x ... and the GPG >> 2 came around which changed (and is still changing) things >> significantly. Fair enough, bit this is hardly as one sided as it might >> seem. > > Release date 1.9.0: 2003-08-05 the first GnuPG-2 release > 1.4.0: 2004-12-16 > 1.4.2: 2005-07-26 adds support for the GnuPG-2 agent > 2.0.0: 2006-11-11 > > Fast forward to 2010: > > commit 302db3f520c944176be75cb7f491573038d48b6e > Author: Stef Walter [...] > Date: Sat May 8 15:49:43 2010 +0000 > > Start work on gpg-agent, incomplete. > > [...] Nope. This code was moved from the seahorse repo and implemented here: commit b7ec4a856758bb74a72161b62e25dce1dc1f8d85 Author: Stefan Walter Date: Thu Oct 14 22:37:12 2004 +0000 Added seahorse agent (bug# 154201) >> It seems nobody cares enough about using those GPG 2.x features (which >> depend on the real gpg-agent) to actually contribute a fix for this. I'd > > I can count the number of mails I answered regarding this problem or > the hours I spend analyzing bug reports which turned out to be a > GKR problem. Yes, perhaps. But when people actually care they contribute. I would welcome such a contribution from anyone who wants to fix this, and work with them to get it merged. As I said, the gnome-keyring gpg-agent does two things: * Prompts via gnome-shell prompts. * Optionally saves the private key unlock passphrase in the gnome-keyring login keyring so it can be used whenever the user is logged in. A replacement would need to have at least those two features. Some APIs that may be of use: https://developer.gnome.org/gcr/unstable/GcrSystemPrompt.html https://developer.gnome.org/libsecret/0.18/ I think doing these things via the pinentry interface like you suggested, is a decent approach. The pinentry interface may need a slight modification to tell the pinentry program how many times its been called for a given password ... so that the first time it could return a password from the gnome-keyring login keyring, if present, and then on later invocations actually do the prompting. In addition when prompting for a passphrase for a private key, the pinentry program needs to be told a keyid that can be used as a way to store/look up the passphrase in the gnome-keyring login keyring. Does the pinentry interface already accomodate the above? From my basic understanding of the "Developer" section of 'info pinentry', it seeems that the interface doesn't yet have these capabilities. But I guess these could be added. >> This is not about a power trip or outsmarting each other or anything >> like that. I'm looking for someone to help contribute a fix. > > The fix is on your site: Remove that gpg-agent thingy. > >> gnome-keyring's gpg agent is only meant for gpg 1.4.x .... and we should >> probably hard code that in during the build process. > > You shall not mess around with the 1.4 IPC either. As gniibe > noted, thre is much more to it than just passphrase caching. > >> Fair enough. But why didn't you say something about this conclusion? Did >> I miss an email or mailing list post about this? If so, could you link >> to it? > > Well there is a solution now: That annoying warning dialog. I understand if that course of action we discussed in Brussels didn't work out. Fair enough. But instead of writing a simple email to me or a mailing list ... you've chosen to spam everyone's screens and log files. If everyone did that as a first order means of communication we'd have a mess. :/ Cheers, Stef From wk at gnupg.org Fri Aug 29 11:08:25 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Aug 2014 11:08:25 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <54002E55.1020802@thewalter.net> (Stef Walter's message of "Fri, 29 Aug 2014 09:40:05 +0200") References: <53FF0869.8090201@thewalter.net> <87bnr4wxlc.fsf@vigenere.g10code.de> <53FF4948.2020408@thewalter.net> <87tx4wvaw2.fsf@vigenere.g10code.de> <54002E55.1020802@thewalter.net> Message-ID: <87k35ru0hi.fsf@vigenere.g10code.de> On Fri, 29 Aug 2014 09:40, stef at thewalter.net said: > But instead of writing a simple email to me or a mailing list ... you've > chosen to spam everyone's screens and log files. If everyone did that as Self-defending against misbehaving software is not any more appropriate? The problem has been told often enough to no result and it is still going on with no solution from the GNOME site. GNOME broke GnuPG not vice-versa. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From stef at thewalter.net Fri Aug 29 11:17:19 2014 From: stef at thewalter.net (Stef Walter) Date: Fri, 29 Aug 2014 11:17:19 +0200 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <13553563.7H4lS9zpWG@esus> References: <53FF0869.8090201@thewalter.net> <87bnr4wxlc.fsf@vigenere.g10code.de> <13553563.7H4lS9zpWG@esus> Message-ID: <5400451F.5000504@thewalter.net> On 28.08.2014 16:38, Andre Heinecke wrote: > Hi, > > On Thursday, August 28, 2014 - KW 35 03:30:23 PM Werner Koch wrote: >> On Thu, 28 Aug 2014 12:46, stef at thewalter.net said: >>> It seems that you don't want gpg2 used with GNOME 3.x as is (in its >>> default configuration). >> >> No, I want you to change the default configuration - I told you that >> over lunch during last years FOSDEM. This mess is going on for many >> years now and a lot of people are annoyed. Fortunately most users of >> GnuPG's S/MIME feature are using KDE and not GNOME and thus are not >> affected by that hijacking. With 2.1 OpenPGP users will also be >> affected and thus I escalated this issue using the new warning. > > Still even if your run a mostly KDE desktop your distribution might ship the > gnome-keyring pseudo gpg-agent and it might be started before the real gnome- > keyring. > > Kleopatra currently fails in the self test if gnome-keyring is hjacking the > socket with an "error while asking gpg-agent for its version". There are > already some bugs about this from users that do not know what is wrong. > But at least it complains. With older versions of kdepim / kleopatra you just > get nasty unexpected errors when you try to use features which are not handled > by your "pseudo" gpg-agent. > > So I'm interested in this discussion as I should probably add a similar > warning in the Kleopatra self test in case gnome-keyring has hijacked the > socket as this hijacking breaks Kleopatra. > >> >>> Should I go ahead and announce that gpg2 (version 2.0.23+) is >>> incompatible with GNOME and people should USE gnupg 1.4.x with GNOME 3.x >> >> The warning message says it all: GKR is hijacking the IPC between >> components of GnuPG - you don't have to mess with that! Shall I start >> to encrypt and authenticate the IPC just to make it harder for GKR to >> mess with it - that would be a silly game. > > I agree with Werner here. I feel like you want to trick users into using > gnome-keyring when they expect to communicate with gpg-agent (With users I > also mean other pieces of software) > > From a Kleopatra standpoint I would like to see gnome-keyring packaged with a > "breaks gnupg2" or at least the gpg-agent hijacking part should be packaged in > a seprate package which can conflict/break with users of gnupg2 features. > > It is not gnupg2 that is incompatible with gnome-keyring, it is gnome-keyring > that deliberately breaks a large part of the feature set of gnupg2. That's just semantics. As I've said, I'm not against changing this. And else in this thread I've outlined several approaches that could be taken to contribute such a fix. > I mean what would you say if KWallet would set a GNOME_KEYRING_CONTROL > environment variable to point to itself? Would you then go ahead and say gnome > software is not compatible with a KDE Desktop or would you complain that > KWallet breaks gnome-keyring users and should stop setting the variable? It would be awesome to finally have that done ... :) In fact we worked on a standard API with the KWallet developers so this would be possible: http://standards.freedesktop.org/secret-service/ Once again, communication, working together, even a simple email, and contributing is *way* more effective that spamming everyone with warnings. Cheers, Stef From infinity0 at pwned.gg Fri Aug 29 11:48:40 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Fri, 29 Aug 2014 10:48:40 +0100 Subject: Should I mark/announce GNOME as incompatible with gpg2 for now? In-Reply-To: <5400278E.9090204@thewalter.net> References: <53FF0869.8090201@thewalter.net> <53FF4D42.2060000@pwned.gg> <5400278E.9090204@thewalter.net> Message-ID: <54004C78.6030102@pwned.gg> On 29/08/14 08:11, Stef Walter wrote: > On 28.08.2014 17:39, Ximin Luo wrote: >> On 28/08/14 11:46, Stef Walter wrote: >>> Hey guys, >>> >>> I noticed this commit: >>> >>> https://gitorious.org/gnupg/mainline/commit/b896fccaada0caf1987eb95ac99dd6b4ca609c4b >>> >>> >>> >>> > It seems that you don't want gpg2 used with GNOME 3.x as is (in its >>> default configuration). >>> >>> Should I go ahead and announce that gpg2 (version 2.0.23+) is >>> incompatible with GNOME and people should USE gnupg 1.4.x with >>> GNOME 3.x for now? >>> >>> I know Werner and I discussed solutions to this issue a more than >>> a year ago, but obviously neither of us has had enough time to >>> make the changes happen. >>> >>> To summarize, either: >>> >>> a. gnupg needs to integrate with GNOME 3 (prompt via >>> gnome-shell, and give the option to save passwords in the >>> keyring) and gnome-keyring can then drop its gpg-agent >>> implementation, as its features would now be found elsewhere. >>> > >> From the view of an outsider: gnupg is a lower-level program, GNOME >> 3 is a higher-level desktop environment. It sounds ridiculous to >> suggest that lower-level utilities should have to do anything >> special for desktop environments to work with it. > > Nah, this happens all the time. Low level stuff, like the kernel, > libraries, and gnupg are there to enable higher level features. > Developers and system administrators often access these low level APIs > and tools ourselves, but that is an exception, at the end of the day > they are combined into higher level features for the user to actually use. > > It's never a surprise that the high level features have a bearing on > the capabilities and APIs of the underlying tools. > What you just said doesn't have any relevance nor address what I said. "gnupg needs to integrate with GNOME 3" would be like saying "Linux TCP stack needs to integrate with Firefox". Perhaps this is not what you meant; the things mentioned below sound much more reasonable. >> Is there some more reasonable, generalised, non-GNOME-specific >> interface (that GNOME 3 happens to implement) that you can suggest >> gnupg to adhere to instead? > > Well, as Werner suggested, gnupg has such a semi-standard "pinentry" > interface. > > Someone needs to write a gnome-shell prompter using it (one could use > this Gcr API if desired [1]). In addition that pinentry prompter needs > to be able to optionally save the private key password in > gnome-keyring (libsecret API [2]) so that the user can optionally have > the private keys automatically unlocked whenever they are logged into > their GNOME session. > > These are the two features that the gnome-keyring GPG agent enables, > and the two features that replacement would need to provide. > > Cheers, > > Stef > -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Aug 29 15:09:56 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Aug 2014 15:09:56 +0200 Subject: [admin] Quoting Message-ID: <8738cftpaz.fsf@vigenere.g10code.de> Hi, please trim your quotes to an appropriate length. It saves time for your readers if they can easily read _your_ text. The quote is only for the context and a few lines are almost always sufficient. Please also leave an empty line between the quote and your text. I hope I don't need to repeat that top posting is a no-no for mailing lists. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From chdiza at gmail.com Sun Aug 31 01:21:11 2014 From: chdiza at gmail.com (Charles Diza) Date: Sat, 30 Aug 2014 19:21:11 -0400 Subject: Cannot build 2.1 beta 6 on Mac OSX 10.9.4 Message-ID: I tried to build the sixth beta of 2.1 on Mac OSX 10.9.4. All the prereq's build fine, but when building gnupg2 it always fails here: gcc -I/usr/local/Cellar/libgcrypt/1.6.2/include -I/usr/local/Cellar/libgpg-error/1.13/include -I/usr/local/Cellar/libassuan/2.1.2/include -I/usr/local/Cellar/libgpg-error/1.13/include -I/usr/local/Cellar/libksba/1.3.0/include -I/usr/local/Cellar/libgpg-error/1.13/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o t-openpgp-oid t-openpgp-oid.o libcommon.a ../gl/libgnu.a -L/usr/local/Cellar/libgcrypt/1.6.2/lib -lgcrypt -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -L/usr/local/Cellar/libassuan/2.1.2/lib -lassuan -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -liconv Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [t-sexputil] Error 1 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Let me know if you want more information. Cheers, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliverml1 at oli1170.net Sun Aug 31 12:04:39 2014 From: oliverml1 at oli1170.net (Oliver Winker) Date: Sun, 31 Aug 2014 12:04:39 +0200 Subject: Patches gpg-agent + scute for ssl/tls auth using opengpg card with 2048 rsa key Message-ID: <1661443.XlFuGbBlzz@gamix64> And actually better sending to Gnupg-devel ... . --- Hello, The two patches below against gpg-agent (gnupg2-2.0.26) [1] and scute-1.4.0 [2] allow ssl/tls auth using an opengpg card with 2048 rsa key. The patch against gpg-agent basically allow a hash length of 51 bytes for signing. And the patch against scute increases a string buffer to be able to hold 51 bytes hash string. The agent command concerned are basically: --- SETHASH --hash=tls-md5sha1 [102 chars =^ 51 bytes here] PKSIGN --- The patches are functional for me, but I can imagine not 100% perfect for a maintainer (string buffer to big, hash-length check not optimally placed). But I prefer to leave the tuning of the details to the specialists ;). Best Regards, Oliver [1]: Patch against gpg-agent (gnupg2-2.0.26) --- Author: Oliver Winker Date: Sat Aug 30 21:09:29 2014 +0200 agent/command: Allow hash length 51 for SSL auth with OpenGPG card and 2048 bit key diff --git a/agent/command.c b/agent/command.c index 2405c54..3849e2c 100644 --- a/agent/command.c +++ b/agent/command.c @@ -652,7 +652,7 @@ cmd_sethash (assuan_context_t ctx, char *line) if (algo == MD_USER_TLS_MD5SHA1 && n == 36) ; else if (n != 16 && n != 20 && n != 24 - && n != 28 && n != 32 && n != 48 && n != 64) + && n != 28 && n != 32 && n != 48 && n != 64 && n != 51) return set_error (GPG_ERR_ASS_PARAMETER, "unsupported length of hash"); if (n > MAX_DIGEST_LEN) --- [2] Patch against scute-1.4.0: --- Author: Oliver Winker Date: Sat Aug 30 21:30:11 2014 +0200 agent: Increase MAX_DATA_LEN buffer length to hold hash for SSL auth using OpenGPG card and 2048 bit key diff --git a/src/agent.c b/src/agent.c index 9265ca2..a1f1d99 100644 --- a/src/agent.c +++ b/src/agent.c @@ -996,7 +996,7 @@ scute_agent_sign (char *grip, unsigned char *data, int len, { char cmd[150]; gpg_error_t err; -#define MAX_DATA_LEN 36 +#define MAX_DATA_LEN 128 unsigned char pretty_data[2 * MAX_DATA_LEN + 1]; int i; struct signature sig; --- From edfinnerty at gmx.com Sun Aug 31 13:16:45 2014 From: edfinnerty at gmx.com (Ed Finnerty) Date: Sun, 31 Aug 2014 14:16:45 +0300 Subject: NSS 3.16 incompatibility In-Reply-To: <53389593.80602@gmx.com> References: <53389593.80602@gmx.com> Message-ID: <5403041D.60908@gmx.com> I see that there's been no reply to this issue at all, either here or on the NSS bug tracker site: https://bugzilla.mozilla.org/show_bug.cgi?id=990958 Should I assume that compatibility with NSS is not a goal at all for gpgsm? On 03/31/14 01:07, Ed Finnerty wrote: > Hello, > > Running this script: > > #!/bin/sh > > # Create an input file with random content > dd if=/dev/urandom of=input.bin bs=1K count=1 > > # Loop forever > while : ; do > > # Cleanup previous output > rm -f out.bin > > # Encrypt input, write to out.bin > gpgsm -e -r email at address input.bin 2>/dev/null > out.bin > > # Decrypt with cmsutil > cmsutil -D -d ~/.thunderbird/yourprofile.default -i out.bin -v -n > > # If cmsutil, break out of the loop > if [[ $? != 0 ]] ; then > echo "GOTCHA" > break > fi > > done # While loop done > > Will eventually produce this output: > > NSS has been initialized. > Got default certdb > cmsutil: failed to decode message. > cmsutil: problem decoding: SEC_ERROR_BAD_DATABASE: security library: bad > database. > GOTCHA > > Here's more info: > > $ gpgsm --version > gpgsm (GnuPG) 2.0.22 > libgcrypt 1.5.3 > libksba 1.3.0 > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: ~/.gnupg > Supported algorithms: > Cipher: 3DES, AES, AES192, AES256, SERPENT128, SERPENT192, SERPENT256, > SEED, CAMELLIA128, CAMELLIA192, CAMELLIA256 > Pubkey: RSA, ECDSA > Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224, WHIRLPOOL > > I'm using NSS 3.16. > > Obviously, you need to have the proper certificates imported with gpgsm, > certutil, etc. > > What's happening? > > Thanks.