From smenzel at gmx-gmbh.de Thu Mar 1 13:33:39 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Thu, 1 Mar 2007 13:33:39 +0100 Subject: [gpgme] fork() problem In-Reply-To: <871wkjm9ar.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702210850.04561.smenzel@gmx-gmbh.de> <871wkjm9ar.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200703011333.40612.smenzel@gmx-gmbh.de> Am Mittwoch, 21. Februar 2007 23:32:12 schrieb Marcus Brinkmann: > You may want to try to compile your own glibc with NPTL. From what I > have heard, NPTL is more standard conform to pthread than > linuxthreads. Of course, that's just more stabbing in the dark, but > it's worth it because it really is a completely different > implementation. Yeah. We did that, I just forgot to call the right executable. Instead of /lib/libc.so.6 one should call /lib/tls/libc.so.6 which says: GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-13). Compiled on a Linux 2.6.0-test7 system on 2006-09-06. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others NPTL 0.60 by Ulrich Drepper BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. Report bugs using the `glibcbug' script to . so we do have and use NPTL which is confirmed. > > ==5676== 2,088 (96 direct, 1,992 indirect) bytes in 2 blocks are > > definitely lost in loss record 93 of 146 > > ==5676== at 0x40207E3: calloc > > (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) > > ==5676== by 0x4BCA6FC: (within /usr/lib/libgpgme-pthread.so.11.6.2) > > ==5676== by 0x4BCB7C0: (within /usr/lib/libgpgme-pthread.so.11.6.2) > > ==5676== by 0x4BD3B1C: (within /usr/lib/libgpgme-pthread.so.11.6.2) > > ==5676== by 0x4BC5D2D: (within /usr/lib/libgpgme-pthread.so.11.6.2) > > ==5676== by 0x4BC687D: (within /usr/lib/libgpgme-pthread.so.11.6.2) > > ==5676== by 0x4BCAE34: gpgme_op_keylist_next > > (in /usr/lib/libgpgme-pthread.so.11.6.2) > > ==5676== by 0x4BCAF94: gpgme_get_key > > (in /usr/lib/libgpgme-pthread.so.11.6.2) > > ==5676== by 0x4BAFC21: MyClass::getKey(char const*) (MyClass.cc:39) > > > > I'll try to find out if I was causing the leak here. > > Maybe you don't release a key acquired with gpgme_get_key with > gpgme_key_unref? Ooops. I didn't know such a function exists :-( I always thought calling gpgme_release on the context clears all the buffers used within the session. I'll fix this, thanks for the hint. Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070301/a4d9bde2/attachment.pgp From albrecht.dress at arcor.de Sun Mar 4 19:17:42 2007 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sun, 04 Mar 2007 19:17:42 +0100 Subject: GnuPG 2.0 vs. 1.4 locale; gpgme_set_locale In-Reply-To: <87ejrnbbx8.fsf@wheatstone.g10code.de> (from wk@gnupg.org on Tue Nov 28 20:37:07 2006) References: <1164742278l.21919l.0l@antares.localdomain> <87ejrnbbx8.fsf@wheatstone.g10code.de> Message-ID: <1173032279l.26348l.0l@antares.localdomain> Am 28.11.06 20:37 schrieb(en) Werner Koch: > On Tue, 28 Nov 2006 20:30, albrecht.dress at arcor.de said: > > > Any ideas? > > Once we had similar problems with gpgsm. I will check the code. The problem is still in GnuPG 2.0.2. However, if the user gives --lc-ctype or --lc-cmessages options, why don't we simply use them in the application, e.g. as in the attached patch? This seems to solve the problem for me. Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress at arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg2-locale.diff Type: text/x-patch Size: 896 bytes Desc: not available Url : /pipermail/attachments/20070304/f36643c5/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070304/f36643c5/attachment.pgp From wk at gnupg.org Mon Mar 5 19:55:21 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Mar 2007 19:55:21 +0100 Subject: Some bits about SCdaemon Message-ID: <87odn7cyg6.fsf@wheatstone.g10code.de> Hi, For the GUUG [1] spring conference, I wrote an article on the design of the SCdaemon, GnuPG-2's module to access smartcards: For GnuPG 2.0 a new framework to access smart cards has been developed. It is based on a daemon process and designed as a replacement for the PC/SC architecture. The problems of PC/SC as and the new solution are described. The new API as well as an introduction on how supporting code for new smart cards needs to be written is given. Further we briefly describe a PKCS\#11 connector based on this API. Get it from: http://g10code.com/docs/scdaemon-ffg2007.pdf Shalom-Salam, Werner [1] German Unix User Group (http://www.guug.de), organizers of several conferences including the well known www.LinuxKongress.org . From wk at gnupg.org Mon Mar 5 20:04:13 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Mar 2007 20:04:13 +0100 Subject: New versions of GnupG and GPGME Message-ID: <877itvcy1e.fsf@wheatstone.g10code.de> Hi, we have released new version of GnuPG and GPGME due a forthcoming security advisory. That advisory was scheduled for today but I have not yet seen it. Given that the night has already fallen over Europe and that I am about to leave the office, I attach our own advisory for those who are keen to know what is going on. Salam-Shalom, Werner Multiple Messages Problem in GnuPG and GPGME ============================================== 2007-03-05 Summary ======= Gerardo Richarte from Core Security Technologies identified a problem when using GnuPG in streaming mode. The problem is actually a variant of a well known problem in the way signed material is presented in a MUA. It is possible to insert additional text before or after a signed (or signed and encrypted) OpenPGP message and make the user believe that this additional text is also covered by the signature. The Core Security advisory describes several variants of the attack; they all boil down to the fact that it might not be possible to identify which part of a message is actually signed if gpg is not used correctly. [ Please do not send private mail in response to this message. The mailing list gnupg-devel is the best place to discuss this problem (please subscribe first so you don't need moderator approval [1]). ] Impact ====== All applications using GnuPG without properly using the status interface to verify signed or signed and encrypted messages. All GPGME versions up to and including 1.1.3. Starting with version 1.4.7 and 2.0.3, GnuPG implements an additional and sufficient protection against this common usage problem. Detached signatures are in no way affected by this problem. Description =========== When using gpg (or gpg2) in a pipeline or with redirected input and output additional data may be inserted into a message. This allows to forge a signed message by prefixing it with arbitrary material. A way to create such a message is: echo "This is my sneaky plaintext message" > foobar.txt gpg -z0 --output prefix.gpg --store foobar.txt cat prefix.gpg original-signed-message.gpg > forged.gpg Using gpg naively this results in: $ gpg " [...] and thus gives the impression that the sneaky message is part of the signed Groucho quote. The correct way to use gpg with redirection is by taking care of the status interface: $ gpg --status-fd 1 gpg: Good signature from "Alfa Test (demo key) " [...] Here the PLAINTEXT status lines clearly identify the start of a new message. Note, that using gpg on the command line is in almost all cases not done with redirection but by letting gpg save the the signed message. In this case gpg will save the message to different files or in case the file names are identical, prompt the over to overwrite the first one again. Because the problem of identifying the actual signed content when mixing the signed data and the signature is very common, the long standing suggestion for all digital signatures is to use a detached signature. A detached signature allows to clearly identify what is signed and what is the signature. This is also the reason why PGP/MIME signed messages are in general to be preferred over the old style clear signed messages. Solution ======== Given that there are many applications in use which are subject to the described problem, we have decided to change GnuPG so that such forged OpenPGP messages are detected and the signature verification will fail. GnuPG 1.4.7 has been released today and is available from the usual places [2]. If you don't want to update, a minimal patch against GnuPG 1.4.6 is available at ftp://ftp.gnupg.org/gcrypt/gnupg/patches/gnupg-1.4.6-multiple-message.patch Many applications are using the library GPGME which implements an easy way to process OpenPGP messages using gpg. We have updated GPGME to make it immune against this problem even if an old version of gpg is being used. GPGME 1.1.4 is available from the usual places [2]. A patch (against version 1.1.3 or 1.1.2) is available at ftp://ftp.gnupg.org/gcrypt/gpgme/patches/gpgme-1.1.3-multiple-message.patch Please note that - after applying one of these patches - some vulnerable applications (mainly MUAs) may fail to handle certain messages which are composed of several OpenPGP messages. To continue the support of such messages fixing the application is required as there is no way for GnuPG to do it. Support ======= g10 Code GmbH [3], a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. Support contracts or other financial backing will greatly help us to improve the quality of GnuPG. Thanks ====== Gerardo Richarte found this problem. David Shaw greatly helped to analyse and describe the core of the problem. [1] See http://lists.gnupg.org/mailman/listinfo/gnupg-devel [2] See http://www.gnupg.org/download/ [3] See http://www.gnupg.org/service.html From wk at gnupg.org Tue Mar 6 09:02:45 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Mar 2007 09:02:45 +0100 Subject: [Announce] Multiple Messages Problem in GnuPG and GPGME Message-ID: <873b4ibxzu.fsf@wheatstone.g10code.de> Multiple Messages Problem in GnuPG and GPGME ============================================== 2007-03-05 Summary ======= Gerardo Richarte from Core Security Technologies identified a problem when using GnuPG in streaming mode. The problem is actually a variant of a well known problem in the way signed material is presented in a MUA. It is possible to insert additional text before or after a signed (or signed and encrypted) OpenPGP message and make the user believe that this additional text is also covered by the signature. The Core Security advisory describes several variants of the attack; they all boil down to the fact that it might not be possible to identify which part of a message is actually signed if gpg is not used correctly. [ Please do not send private mail in response to this message. The mailing list gnupg-devel is the best place to discuss this problem (please subscribe first so you don't need moderator approval [1]). ] Impact ====== All applications using GnuPG without properly using the status interface to verify signed or signed and encrypted messages. All GPGME versions up to and including 1.1.3. Starting with version 1.4.7 and 2.0.3, GnuPG implements an additional and sufficient protection against this common usage problem. Detached signatures are in no way affected by this problem. Description =========== When using gpg (or gpg2) in a pipeline or with redirected input and output additional data may be inserted into a message. This allows to forge a signed message by prefixing it with arbitrary material. A way to create such a message is: echo "This is my sneaky plaintext message" > foobar.txt gpg -z0 --output prefix.gpg --store foobar.txt cat prefix.gpg original-signed-message.gpg > forged.gpg Using gpg naively this results in: $ gpg " [...] and thus gives the impression that the sneaky message is part of the signed Groucho quote. The correct way to use gpg with redirection is by taking care of the status interface: $ gpg --status-fd 1 gpg: Good signature from "Alfa Test (demo key) " [...] Here the PLAINTEXT status lines clearly identify the start of a new message. Note, that using gpg on the command line is in almost all cases not done with redirection but by letting gpg save the the signed message. In this case gpg will save the message to different files or in case the file names are identical, prompt the over to overwrite the first one again. Because the problem of identifying the actual signed content when mixing the signed data and the signature is very common, the long standing suggestion for all digital signatures is to use a detached signature. A detached signature allows to clearly identify what is signed and what is the signature. This is also the reason why PGP/MIME signed messages are in general to be preferred over the old style clear signed messages. Solution ======== Given that there are many applications in use which are subject to the described problem, we have decided to change GnuPG so that such forged OpenPGP messages are detected and the signature verification will fail. GnuPG 1.4.7 has been released today and is available from the usual places [2]. If you don't want to update, a minimal patch against GnuPG 1.4.6 is available at ftp://ftp.gnupg.org/gcrypt/gnupg/patches/gnupg-1.4.6-multiple-message.patch Many applications are using the library GPGME which implements an easy way to process OpenPGP messages using gpg. We have updated GPGME to make it immune against this problem even if an old version of gpg is being used. GPGME 1.1.4 is available from the usual places [2]. A patch (against version 1.1.3 or 1.1.2) is available at ftp://ftp.gnupg.org/gcrypt/gpgme/patches/gpgme-1.1.3-multiple-message.patch Please note that - after applying one of these patches - some vulnerable applications (mainly MUAs) may fail to handle certain messages which are composed of several OpenPGP messages. To continue the support of such messages fixing the application is required as there is no way for GnuPG to do it. Support ======= g10 Code GmbH [3], a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. Support contracts or other financial backing will greatly help us to improve the quality of GnuPG. Thanks ====== Gerardo Richarte found this problem. David Shaw greatly helped to analyse and describe the core of the problem. [1] See http://lists.gnupg.org/mailman/listinfo/gnupg-devel [2] See http://www.gnupg.org/download/ [3] See http://www.gnupg.org/service.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20070306/ce639d51/attachment-0001.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From alan at batie.org Tue Mar 6 19:11:49 2007 From: alan at batie.org (Alan Batie) Date: Tue, 06 Mar 2007 10:11:49 -0800 Subject: [Announce] Multiple Messages Problem in GnuPG and GPGME In-Reply-To: <873b4ibxzu.fsf@wheatstone.g10code.de> References: <873b4ibxzu.fsf@wheatstone.g10code.de> Message-ID: <45EDAEE5.8080607@batie.org> Werner Koch wrote: > The correct way to use gpg with redirection is > by taking care of the status interface: > > $ gpg --status-fd 1 [GNUPG:] PLAINTEXT 62 1172479053 foobar.txt > [GNUPG:] PLAINTEXT_LENGTH 36 > This is my sneaky plaintext message > [GNUPG:] PLAINTEXT 62 1172480224 original-signed-message > [GNUPG:] PLAINTEXT_LENGTH 86 > Either I'm dead or my watch has stopped. > -- Groucho Marx's last words > gpg: Signature made Mon Feb 26 09:57:04 2007 CET using DSA key ID 68697734 > [GNUPG:] SIG_ID UncMPBJYgbG/uszJVNKoCAz+hvY 2007-02-26 1172480224 > [GNUPG:] GOODSIG 2D727CC768697734 Alfa Test (demo key) > gpg: Good signature from "Alfa Test (demo key) " > [...] > > Here the PLAINTEXT status lines clearly identify the start of a new > message. "clearly"? Only to a gnupg developer would this be "clearly". Granted, for the most part, the only people using pgp probably can interpret this, but if you ever want non-techies to have any hope of using it, this needs major improvement. And I suspect even most technical people would prefer something more readable... How about: $ gpg < forged.gpg [GNUPG SEGMENT 1:] foobar.txt --- This is my sneaky plaintext message --- [GNUPG STATUS 1:] UNTRUSTED (unsigned, possibly forged) === [GNUPG SEGMENT 2:] original-signed-message --- Either I'm dead or my watch has stopped. -- Groucho Marx's last words --- [GNUPG SIG INFO 2:] Signature made Mon Feb 26 09:57:04 2007 CET using DSA key ID 68697734 [GNUPG STATUS 2:] Good signature from "Alfa Test (demo key) " Still parseable (which I assume is the reason for the crypticness), but readable as well. And for the developers who want more machine readable info: $ gpg -v < forged.gpg [GNUPG SEGMENT 1:] foobar.txt [GNUPG DATA 1:] PLAINTEXT 62 1172479053 36 foobar.txt --- This is my sneaky plaintext message --- [GNUPG STATUS 1:] UNTRUSTED (unsigned, possibly forged) === [GNUPG SEGMENT 2:] original-signed-message --- Either I'm dead or my watch has stopped. -- Groucho Marx's last words --- [GNUPG SIG INFO 2:] Signature made Mon Feb 26 09:57:04 2007 CET using DSA key ID 68697734 [GNUPG SIG_ID 2:] UncMPBJYgbG/uszJVNKoCAz+hvY 2007-02-26 1172480224 [GNUPG DATA 2:] GOODSIG 2D727CC768697734 Alfa Test (demo key) [GNUPG STATUS 2:] Good signature from "Alfa Test (demo key) " -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3263 bytes Desc: S/MIME Cryptographic Signature Url : /pipermail/attachments/20070306/c8acab47/attachment.bin From sadam at clemson.edu Tue Mar 6 21:35:56 2007 From: sadam at clemson.edu (Adam Schreiber) Date: Tue, 6 Mar 2007 15:35:56 -0500 Subject: gpg2 support in GPGME Message-ID: <8298be230703061235x46d20e29p52b0ef11e587c931@mail.gmail.com> Are there currently any plans to make gpgme able to use gpg2 as its engine without gpg-1.4.x installed in parallel? The seahorse project has had several bugs reported that hinge on this incompatibility. At the present we have simply recommended they install both. Cheers, Adam From marcus.brinkmann at ruhr-uni-bochum.de Wed Mar 7 01:24:04 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 07 Mar 2007 01:24:04 +0100 Subject: gpg2 support in GPGME In-Reply-To: <8298be230703061235x46d20e29p52b0ef11e587c931@mail.gmail.com> References: <8298be230703061235x46d20e29p52b0ef11e587c931@mail.gmail.com> Message-ID: <878xe9hpej.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 6 Mar 2007 15:35:56 -0500, "Adam Schreiber" wrote: > > Are there currently any plans to make gpgme able to use gpg2 as its > engine without gpg-1.4.x installed in parallel? The seahorse project > has had several bugs reported that hinge on this incompatibility. At > the present we have simply recommended they install both. Can you elaborate on the incompatibilities? I don't know about them. The crypto engine can be set up at configure time or with gpgme_set_engine_info NEW gpgme_ctx_set_engine_info NEW which exist since version 1.1.0. Thanks, Marcus From john at johnrshannon.com Wed Mar 7 00:58:26 2007 From: john at johnrshannon.com (John R. Shannon) Date: Tue, 6 Mar 2007 16:58:26 -0700 Subject: gpg2 support in GPGME In-Reply-To: <8298be230703061235x46d20e29p52b0ef11e587c931@mail.gmail.com> References: <8298be230703061235x46d20e29p52b0ef11e587c931@mail.gmail.com> Message-ID: <200703061658.32243.john@johnrshannon.com> On Tuesday 06 March 2007 01:35:56 pm Adam Schreiber wrote: > Are there currently any plans to make gpgme able to use gpg2 as its > engine without gpg-1.4.x installed in parallel? The seahorse project > has had several bugs reported that hinge on this incompatibility. At > the present we have simply recommended they install both. > > Cheers, > > Adam > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel It works that way now. I'm signing this message via gpgme with gpg2. gpg-1.4.x is not installed on my computer. -- John R. Shannon, CISSP Chief Scientist DSCI, Information Assurance Division jshannon at dsci-usa.com john.r.shannon at us.army.mil shannonjr at NetBSD.org (208)522-4506 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2544 bytes Desc: not available Url : /pipermail/attachments/20070306/b1688b22/attachment.bin From patrick at mozilla-enigmail.org Wed Mar 7 08:51:47 2007 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Wed, 07 Mar 2007 08:51:47 +0100 Subject: [Announce] Multiple Messages Problem in GnuPG and GPGME In-Reply-To: <45EDAEE5.8080607@batie.org> References: <873b4ibxzu.fsf@wheatstone.g10code.de> <45EDAEE5.8080607@batie.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Batie wrote: > Werner Koch wrote: >> The correct way to use gpg with redirection is >> by taking care of the status interface: >> >> $ gpg --status-fd 1 > [GNUPG:] PLAINTEXT 62 1172479053 foobar.txt >> [GNUPG:] PLAINTEXT_LENGTH 36 >> This is my sneaky plaintext message >> [GNUPG:] PLAINTEXT 62 1172480224 original-signed-message >> [GNUPG:] PLAINTEXT_LENGTH 86 >> Either I'm dead or my watch has stopped. >> -- Groucho Marx's last words >> gpg: Signature made Mon Feb 26 09:57:04 2007 CET using DSA key ID 68697734 >> [GNUPG:] SIG_ID UncMPBJYgbG/uszJVNKoCAz+hvY 2007-02-26 1172480224 >> [GNUPG:] GOODSIG 2D727CC768697734 Alfa Test (demo key) >> gpg: Good signature from "Alfa Test (demo key) " >> [...] >> >> Here the PLAINTEXT status lines clearly identify the start of a new >> message. > > "clearly"? Only to a gnupg developer would this be "clearly". Granted, > for the most part, the only people using pgp probably can interpret > this, but if you ever want non-techies to have any hope of using it, > this needs major improvement. And I suspect even most technical people > would prefer something more readable... How about: > > $ gpg < forged.gpg > [GNUPG SEGMENT 1:] foobar.txt > --- > This is my sneaky plaintext message > --- > [GNUPG STATUS 1:] UNTRUSTED (unsigned, possibly forged) > === > [GNUPG SEGMENT 2:] original-signed-message > --- > Either I'm dead or my watch has stopped. > -- Groucho Marx's last words > --- [...] The --status-fd interface is defined and in use for quite a while, you cannot just change the core of it without breaking dozens of applications. I agree that a some improvements here and there would be possible, but it definitely serves the purpose. The problem is more that the usage of multiple PLAINTEXT parts -- especially the fact that there can be multiple parts -- doesn't seem to be documented well enough. I.e. I think that some explicit mentioning in the DETAILS document would help much more than changing the interface in any way (which would still mean that it would need to be documented!). - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRe5vEHcOpHodsOiwAQIiHgf+NgilEP+GUP4k1WBq3nFVMIZW1DB4bczZ /ylfRJCXz9zuEKOLCkLK3kNN1z5+J5/IHcPX+/BQ2dJzpvEpSTjeTRvs7/czEGlH Bhaq+fNQMGJYwgcq9iNpKN81budQBBeUkTdJ7jiA51s9WvAxlbhoSQEZdg9Cr/Fc T9glBtHkcXKQji3NzuA8K4odoXHxGZKzRwhYCUMR0dPnrIL4Pkv4TJvaJ+C0gtvd t21YfSFD8mhSVVqIlo6/TTbXv6ytb4lGyfLr1Uhq/WrdLWWYLRUFp+GtXl0RhVMZ nbUUqq9gr6+wWsTRRj/E9d5hleIsGKuDfD2f5pnSpowU/WAXL0URAw== =uIbF -----END PGP SIGNATURE----- From wk at gnupg.org Wed Mar 7 10:04:28 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Mar 2007 10:04:28 +0100 Subject: [Announce] Multiple Messages Problem in GnuPG and GPGME In-Reply-To: <45EDAEE5.8080607@batie.org> (Alan Batie's message of "Tue\, 06 Mar 2007 10\:11\:49 -0800") References: <873b4ibxzu.fsf@wheatstone.g10code.de> <45EDAEE5.8080607@batie.org> Message-ID: <87abyp4e77.fsf@wheatstone.g10code.de> On Tue, 6 Mar 2007 19:11, alan at batie.org said: > this needs major improvement. And I suspect even most technical people > would prefer something more readable... How about: Granted, using gpg in stream mode is not easy but most people won't do that but save the message to a file in which case they can just check the content of the file. We can't change the status interface. Salam-Shalom, Werner From wk at gnupg.org Wed Mar 7 21:20:21 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Mar 2007 21:20:21 +0100 Subject: Cherry XX44 PIN pads Message-ID: <87lki8ztyy.fsf@wheatstone.g10code.de> Hi, to those of you, using a Cherry XX44 keyboard with card reader: Entering the PIN on the keyboard does now work with the latest SVN of GnuPG-2 (trunk). When using gpg-agent and scdaemon, gpg-1.4 will also take advantage of it. GnuPG 2.0.3 will be released in a few days. Salam-Shalom, Werner From nicholas.cole at gmail.com Thu Mar 8 09:50:04 2007 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 8 Mar 2007 08:50:04 +0000 Subject: Injecting Status-fd output Message-ID: The update got me thinking about using gpg in stream mode. Usually, I read the --status-fd output and the statard output seperately, but obviously this has its own problems. If the two are read together, however, as they seem to be intended to be, what is to stop the plaintext injecting lines that begin: [GPG: ] into its output and upsetting whatever parsing engine is doing the reading? From nicholas.cole at gmail.com Thu Mar 8 09:51:14 2007 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 8 Mar 2007 08:51:14 +0000 Subject: Injecting Status-fd output In-Reply-To: References: Message-ID: > [GPG: ] Obviously, I meant [GNUPG:] - not enough coffee yet this morning. From wk at gnupg.org Thu Mar 8 12:20:59 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Mar 2007 12:20:59 +0100 Subject: Injecting Status-fd output In-Reply-To: (Nicholas Cole's message of "Thu\, 8 Mar 2007 08\:50\:04 +0000") References: Message-ID: <87wt1svv50.fsf@wheatstone.g10code.de> On Thu, 8 Mar 2007 09:50, nicholas.cole at gmail.com said: > Usually, I read the --status-fd output and the statard output > seperately, but obviously this has its own problems. gpg should make sure that this is syncronized. But wait, I just checked the writing of the plaintext and found a problem when writing to stdout. In this case the file pointer will not be closed at the end of the wrinting. If this is now a plaintext packet which is not signed and followed by a signed plaintext, it is possible that some data of the first packet might have not been flushed at the time the the PLAINTEXT status is written. I just fixed this by making sure that stdout gets flushed before and after writing out a plaintext. Fortunately this can't be exploited with gpg 1.4.7 as a plaintext packet will lead to an error. It is however a problem for applications taking care of the plaintext status line. I am not sure whether this is really exploitable but an update to gpg 1.4.7 is highly suggested. > If the two are read together, however, as they seem to be intended to > be, what is to stop the plaintext injecting lines that begin: > > [GPG: ] > > into its output and upsetting whatever parsing engine is doing the reading? This is an old problem and something we can't easily fix. Detecting this marker in the plaintext is of course possible but what shall we do about it? We would need to modify the message and thus break a lot of applications. It might we possible to do this for the case of status-fd and output writing to stdout only. Salam-Shalom, Werner From patrick at mozilla-enigmail.org Thu Mar 8 13:57:55 2007 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Thu, 08 Mar 2007 13:57:55 +0100 Subject: Injecting Status-fd output In-Reply-To: References: Message-ID: Nicholas Cole wrote: > The update got me thinking about using gpg in stream mode. > > Usually, I read the --status-fd output and the statard output > seperately, but obviously this has its own problems. > > If the two are read together, however, as they seem to be intended to > be, what is to stop the plaintext injecting lines that begin: > > [GPG: ] > > into its output and upsetting whatever parsing engine is doing the reading? I'm not sure if it's a good idea to read --status-fd from stdout for exactly the reason you describe. In Enigmail I read it on a separate file descriptor, and check the results at the end of the process, before displaying the data to the user. This way, I can count the number of PLAINTEXT occurrences, and if needed I can split the output according to the PLAINTEXT_LENGTH fields (at least I hope that this is reliable information). -Patrick From nicholas.cole at gmail.com Thu Mar 8 15:48:01 2007 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 8 Mar 2007 14:48:01 +0000 Subject: Injecting Status-fd output In-Reply-To: References: Message-ID: On 3/8/07, Patrick Brunschwig wrote: [snip] > In Enigmail I read it on a separate file descriptor, and check the > results at the end of the process, before displaying the data to the > user. This way, I can count the number of PLAINTEXT occurrences, and if > needed I can split the output according to the PLAINTEXT_LENGTH fields > (at least I hope that this is reliable information). The problem being, though, that many situations do not produce a PLAINTEXT_LENGTH field. How do you cope with that? From patrick at mozilla-enigmail.org Thu Mar 8 16:16:04 2007 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Thu, 08 Mar 2007 16:16:04 +0100 Subject: Injecting Status-fd output In-Reply-To: References: Message-ID: <45F028B4.80203@mozilla-enigmail.org> Nicholas Cole wrote: > On 3/8/07, Patrick Brunschwig wrote: > [snip] >> In Enigmail I read it on a separate file descriptor, and check the >> results at the end of the process, before displaying the data to the >> user. This way, I can count the number of PLAINTEXT occurrences, and if >> needed I can split the output according to the PLAINTEXT_LENGTH fields >> (at least I hope that this is reliable information). > > The problem being, though, that many situations do not produce a > PLAINTEXT_LENGTH field. How do you cope with that? In this case I warn the user about multiple plain texts. There is nothing else I could do. Unfortunately, the architecture of Mozilla doesn't allow me to read bit by bit (i.e. first read status message, then wait for text on stdout, then wait for next status message etc.). From this point of view using stdout for both status-fd and decrypted text would seem to be more advantageous -- but my fear for injected [GNUPG:] lines is too big for this. If you use stdout, you can very easily pretend e.g. valid signature status messages, so I *really* don't consider this desirable, and I would be very careful with this approach. A few simple lines that look like normal gpg status output would be sufficient to trick you ... -Patrick From wk at gnupg.org Thu Mar 8 15:36:30 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Mar 2007 15:36:30 +0100 Subject: [Announce] GnuPG 2.0.3 released Message-ID: <87tzwvvm35.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.3 This is bug fix release. There are also some minor enhancements. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.6) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPL). GnuPG-2 works best on GNU/Linux or *BSD systems. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.3 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and ist mirrors you should find the following files in the *gnupg* directory: gnupg-2.0.3.tar.bz2 (3.8M) gnupg-2.0.3.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.3-2.0.3.diff.bz2 (29k) A patch file to upgrade a 2.0.2 GnuPG source. The patch file does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs. 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.3.tar.bz2 you would use this command: gpg --verify gnupg-2.0.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 that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.3.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.3.tar.bz2 and check that the output matches the first line from the following list: 4680bcb96873191b331252ae40b35e39589c58ca gnupg-2.0.3.tar.bz2 901b8d9fe430e12c14d16365a08d50389c305f9a gnupg-2.0.2-2.0.3.diff.bz2 What's New =========== * By default, do not allow processing multiple plaintexts in a single stream. Many programs that called GnuPG were assuming that GnuPG did not permit this, and were thus not using the plaintext boundary status tags that GnuPG provides. This change makes GnuPG reject such messages by default which makes those programs safe again. --allow-multiple-messages returns to the old behavior. * New --verify-option show-primary-uid-only. * gpgconf may now reads a global configuration file to select which options are changeable by a frontend. The new applygnupgdefaults tool may be used by an admin to set default options for all users. * The PIN pad of the Cherry XX44 keyboard is now supported. The DINSIG and the NKS applications are now also aware of PIN pads. Internationalization ==================== GnuPG comes with support for 27 languages. Due to a lot of new and changed strings most translations are not entirely complete. The Swedish, Turkish, German and Russian translations should be complete. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. KDE's KMail is the most prominent user of GnuPG. In fact it has been developed along with the Kmail folks. Mutt users might want to use the configure option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP support. The manual is also available online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ and as an PDF at http://www.gnupg.org/documentation/manuals/gnupg.pdf . Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or by donating money. Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. A service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Marcus, Werner and all other contributors) -- Werner Koch The GnuPG Experts http://g10code.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20070308/12872c7f/attachment.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From ueno at unixuser.org Thu Mar 8 15:38:25 2007 From: ueno at unixuser.org (Daiki Ueno) Date: Thu, 08 Mar 2007 23:38:25 +0900 Subject: Injecting Status-fd output In-Reply-To: (Patrick Brunschwig's message of "Thu, 08 Mar 2007 13:57:55 +0100") References: Message-ID: >>>>> In >>>>> Patrick Brunschwig wrote: > I'm not sure if it's a good idea to read --status-fd from stdout for > exactly the reason you describe. > In Enigmail I read it on a separate file descriptor, and check the > results at the end of the process, before displaying the data to the > user. This way, I can count the number of PLAINTEXT occurrences, and if > needed I can split the output according to the PLAINTEXT_LENGTH fields > (at least I hope that this is reliable information). I envy such a modern plugin architecture. In Emacs, I can't distinguish FD's. I once tried to utilize PLAINTEXT_LENGTH, but I noticed that there was no way to remove "gpg:" lines. ;; BTW, gpg2 doesn't have --logger-file option? Regards, -- Daiki Ueno From sadam at clemson.edu Thu Mar 8 17:04:11 2007 From: sadam at clemson.edu (Adam Schreiber) Date: Thu, 8 Mar 2007 11:04:11 -0500 Subject: gpg2 support in GPGME In-Reply-To: <878xe9hpej.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <8298be230703061235x46d20e29p52b0ef11e587c931@mail.gmail.com> <878xe9hpej.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <8298be230703080804p5e019a16p951cbc78e6f9ffe5@mail.gmail.com> On 3/6/07, Marcus Brinkmann wrote: > At Tue, 6 Mar 2007 15:35:56 -0500, > "Adam Schreiber" wrote: > > > > Are there currently any plans to make gpgme able to use gpg2 as its > > engine without gpg-1.4.x installed in parallel? The seahorse project > > has had several bugs reported that hinge on this incompatibility. At > > the present we have simply recommended they install both. > > Can you elaborate on the incompatibilities? I don't know about them. AFAIK, the incompatibilities only show up where users have installed gpg2 and not the other. As for elaboration, because I haven't experienced the bugs myself, I can point you at a bug report in GNOME Bugzilla [1]. Cheers, Adam [1] http://bugzilla.gnome.org/show_bug.cgi?id=410324 From nicholas.cole at gmail.com Thu Mar 8 17:12:39 2007 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 8 Mar 2007 16:12:39 +0000 Subject: Injecting Status-fd output In-Reply-To: <87wt1svv50.fsf@wheatstone.g10code.de> References: <87wt1svv50.fsf@wheatstone.g10code.de> Message-ID: On 3/8/07, Werner Koch wrote: > On Thu, 8 Mar 2007 09:50, nicholas.cole at gmail.com said: > > > Usually, I read the --status-fd output and the statard output > > seperately, but obviously this has its own problems. > > gpg should make sure that this is syncronized. [snip] Interesting. I hadn't realised this. I've been using the popen2 module in python, which seems to break this, even if I disable buffering. I can't seem to find a way of calling gpg that would let me take advantage of whatever it is trying to do. [snip] > This is an old problem [injected status lines] and something we can't easily fix. Detecting > this marker in the plaintext is of course possible but what shall we > do about it? We would need to modify the message and thus break a lot > of applications. It might we possible to do this for the case of > status-fd and output writing to stdout only. I guess that the only way to fix it without breaking existing apps would be to add an option like: --prefix-plaintext-lines and put [GNUPG PLAINTEXT] at the front of each. Or am I missing something obvious? Best, N. From wk at gnupg.org Thu Mar 8 19:05:09 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Mar 2007 19:05:09 +0100 Subject: Injecting Status-fd output In-Reply-To: (Daiki Ueno's message of "Thu\, 08 Mar 2007 23\:38\:25 +0900") References: Message-ID: <87ps7jtxuy.fsf@wheatstone.g10code.de> On Thu, 8 Mar 2007 15:38, ueno at unixuser.org said: > I envy such a modern plugin architecture. In Emacs, I can't distinguish > FD's. I once tried to utilize PLAINTEXT_LENGTH, but I noticed that You better use the PLAINTEXT status; PLAINTEXT_LENGTH is not emitted in all cases. > ;; BTW, gpg2 doesn't have --logger-file option? --log-file will only be used in --batch mode. That is to make it more similar to gpgsm which uses it only in --server mode. Eventually --server-mode will be implemented for gpg2. Shalom-Salam, Werner From albrecht.dress at arcor.de Thu Mar 8 21:00:18 2007 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Thu, 08 Mar 2007 21:00:18 +0100 Subject: gpg2 support in GPGME In-Reply-To: <8298be230703080804p5e019a16p951cbc78e6f9ffe5@mail.gmail.com> (from sadam@clemson.edu on Thu Mar 8 17:04:11 2007) Message-ID: <1173384028l.13786l.0l@antares.localdomain> Am 08.03.07 17:04 schrieb(en) Adam Schreiber: > AFAIK, the incompatibilities only show up where users have installed > gpg2 and not the other. As for elaboration, because I haven't > experienced the bugs myself, I can point you at a bug report in GNOME > Bugzilla [1]. I can confirm that gpgme 1.1.3 and gnupg 2.0.2 do not interact properly when using it in the MUA balsa. As an example, try to sign a message, i.e. create a context, select the signer's key, create the input and output data objects, and then call gpgme_op_sign(). Gpg-agent kicks in and calls pinentry to read the passphrase of the secret key. Now click cancel in pinentry - and gpgme_op_sign() will return with exit code 0! The gpgme debug log (balsa-gpgme.log) of this operation is attached. Replacing gpg2 by gpg 1.4.5, everything works flawlessly (see attached log balsa-gpgme-1.4.log). Please note that at the end of this log, apparently more information about the failed operation is available (fd 33: "MISSING_PASSPHRASE", "BAD_PASSPHRASE"). This problem might be related to a different one [1] I reported a few weeks ago, unfortunately without any feedback yet. I'm using a PowerMac running Yellowdog Linux (kernel 2.6.19.1) with glibc 2.3.4 and gcc 3.4.4, if this is important. Cheers, Albrecht. [1] http://lists.gnupg.org/pipermail/gnupg-devel/2007-February/023676.html -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress at arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: balsa-gpgme.log Type: text/x-log Size: 4391 bytes Desc: not available Url : /pipermail/attachments/20070308/0bf460c9/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: balsa-gpgme-1.4.log Type: text/x-log Size: 5220 bytes Desc: not available Url : /pipermail/attachments/20070308/0bf460c9/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070308/0bf460c9/attachment.pgp From wk at gnupg.org Fri Mar 9 09:38:27 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Mar 2007 09:38:27 +0100 Subject: Injecting Status-fd output In-Reply-To: (Nicholas Cole's message of "Thu\, 8 Mar 2007 16\:12\:39 +0000") References: <87wt1svv50.fsf@wheatstone.g10code.de> Message-ID: <87zm6mstfg.fsf@wheatstone.g10code.de> On Thu, 8 Mar 2007 17:12, nicholas.cole at gmail.com said: > Interesting. I hadn't realised this. I've been using the popen2 > module in python, which seems to break this, even if I disable > buffering. I can't seem to find a way of calling gpg that would let > me take advantage of whatever it is trying to do. Hmmm. Marcus, can you look at our gpgme code and explain how we handle it there. > and put [GNUPG PLAINTEXT] at the front of each. For binary messages it will be some work for applications to filter it out again. But yes, I agree that this will work. Modulo that some folks will immediately complain that in-band signalling is Bad Idea ;-) Salam-Shalom, Werner From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 9 14:11:21 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri, 09 Mar 2007 14:11:21 +0100 Subject: Injecting Status-fd output In-Reply-To: <87zm6mstfg.fsf@wheatstone.g10code.de> References: <87wt1svv50.fsf@wheatstone.g10code.de> <87zm6mstfg.fsf@wheatstone.g10code.de> Message-ID: <87slcelfye.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 09 Mar 2007 09:38:27 +0100, 'Werner Koch' wrote: > > On Thu, 8 Mar 2007 17:12, nicholas.cole at gmail.com said: > > > Interesting. I hadn't realised this. I've been using the popen2 > > module in python, which seems to break this, even if I disable > > buffering. I can't seem to find a way of calling gpg that would let > > me take advantage of whatever it is trying to do. > > Hmmm. Marcus, can you look at our gpgme code and explain how we > handle it there. We don't support multiple plaintexts (we return an error since your change on 2007-02-26). Is there any other scenario where ordering of stdout and status-fd matters? Thanks, Marcus From wk at gnupg.org Sun Mar 11 13:04:31 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 11 Mar 2007 13:04:31 +0100 Subject: Injecting Status-fd output In-Reply-To: <87slcelfye.wl%marcus.brinkmann@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "Fri\, 09 Mar 2007 14\:11\:21 +0100") References: <87wt1svv50.fsf@wheatstone.g10code.de> <87zm6mstfg.fsf@wheatstone.g10code.de> <87slcelfye.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <878xe4ouk0.fsf@wheatstone.g10code.de> On Fri, 9 Mar 2007 14:11, marcus.brinkmann at ruhr-uni-bochum.de said: > We don't support multiple plaintexts (we return an error since your > change on 2007-02-26). Is there any other scenario where ordering of > stdout and status-fd matters? Right. AFAICS, there are no other cases given that key listings don't use status lines at all and all other information is directly conveyed by status lines. Shalom-Salam, Werner From fweimer at bfk.de Mon Mar 12 11:38:14 2007 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 12 Mar 2007 11:38:14 +0100 Subject: Injecting Status-fd output In-Reply-To: (Nicholas Cole's message of "Thu, 8 Mar 2007 16:12:39 +0000") References: <87wt1svv50.fsf@wheatstone.g10code.de> Message-ID: <827itmvjah.fsf@mid.bfk.de> * Nicholas Cole: > I guess that the only way to fix it without breaking existing apps > would be to add an option like: > > --prefix-plaintext-lines > > and put [GNUPG PLAINTEXT] at the front of each. In general, it's better to use something like the OpenPGP streamed encoding. It's faster, and less ambiguous (what is a new line?). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nicholas.cole at gmail.com Tue Mar 13 11:52:55 2007 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 13 Mar 2007 10:52:55 +0000 Subject: Injecting Status-fd output In-Reply-To: <827itmvjah.fsf@mid.bfk.de> References: <87wt1svv50.fsf@wheatstone.g10code.de> <827itmvjah.fsf@mid.bfk.de> Message-ID: On 3/12/07, Florian Weimer wrote: > In general, it's better to use something like the OpenPGP streamed > encoding. It's faster, and less ambiguous (what is a new line?). The what? :) From nicholas.cole at gmail.com Tue Mar 13 20:40:06 2007 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 13 Mar 2007 19:40:06 +0000 Subject: Injecting Status-fd output In-Reply-To: <82hcspruxi.fsf@mid.bfk.de> References: <87wt1svv50.fsf@wheatstone.g10code.de> <827itmvjah.fsf@mid.bfk.de> <82hcspruxi.fsf@mid.bfk.de> Message-ID: On 3/13/07, Florian Weimer wrote: > * Nicholas Cole: > > > On 3/12/07, Florian Weimer wrote: > > > >> In general, it's better to use something like the OpenPGP streamed > >> encoding. It's faster, and less ambiguous (what is a new line?). > > > > The what? :) I just don't know how to use "OpenPGP streamed encoding": can gpg spit it out? N From wk at gnupg.org Wed Mar 14 10:30:46 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Mar 2007 10:30:46 +0100 Subject: Injecting Status-fd output In-Reply-To: (Nicholas Cole's message of "Tue\, 13 Mar 2007 19\:40\:06 +0000") References: <87wt1svv50.fsf@wheatstone.g10code.de> <827itmvjah.fsf@mid.bfk.de> <82hcspruxi.fsf@mid.bfk.de> Message-ID: <87lki0i33t.fsf@wheatstone.g10code.de> On Tue, 13 Mar 2007 20:40, nicholas.cole at gmail.com said: > I just don't know how to use "OpenPGP streamed encoding": can gpg spit it out? I guess Florian is thinking of the partial length encoding as used with OpenPGP apckets. However, this does not help if people wnat to mix that with the status lines. Shalom-Salam, Werner From fweimer at bfk.de Thu Mar 15 09:24:38 2007 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 15 Mar 2007 09:24:38 +0100 Subject: Injecting Status-fd output In-Reply-To: <87lki0i33t.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 14 Mar 2007 10:30:46 +0100") References: <87wt1svv50.fsf@wheatstone.g10code.de> <827itmvjah.fsf@mid.bfk.de> <82hcspruxi.fsf@mid.bfk.de> <87lki0i33t.fsf@wheatstone.g10code.de> Message-ID: <821wjqrk1l.fsf@mid.bfk.de> * Werner Koch: > On Tue, 13 Mar 2007 20:40, nicholas.cole at gmail.com said: > >> I just don't know how to use "OpenPGP streamed encoding": can gpg spit it out? > > I guess Florian is thinking of the partial length encoding as used > with OpenPGP apckets. However, this does not help if people wnat to > mix that with the status lines. Oh, perhaps I should make my suggestion more explicit. The basic idea is to use data blocks prefixed by explict length information, like OpenPGP does. And for each data block, you can add a flag which indicates the type. Inside GnuPG, you buffer the data in reasonably sized chunks, and write the data only if the buffer is full, or a flush is required because you need to switch block types. It's not necessary to use OpenPGP's bit stuffing. You could use a simple protocol like this: ... DATA 8192\n <8192 data bytes follow> DATA 121\n <121 data bytes follow> STATUS 39\n DECRYPTION_OKAY\n GOODMDC\n END_DECRYPTION\n -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From simon at josefsson.org Thu Mar 15 14:20:32 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 15 Mar 2007 14:20:32 +0100 Subject: Some bits about SCdaemon In-Reply-To: <87odn7cyg6.fsf@wheatstone.g10code.de> (Werner Koch's message of "Mon\, 05 Mar 2007 19\:55\:21 +0100") References: <87odn7cyg6.fsf@wheatstone.g10code.de> Message-ID: <87k5xi3aov.fsf@mocca.josefsson.org> Werner Koch writes: > Get it from: http://g10code.com/docs/scdaemon-ffg2007.pdf Hi! That is quite nice, and got me thinking about making GnuTLS use certificates/keys from gpgsm/scdaemon/etc. I looked at the GnuTLS API, and it is pretty hard coded to get the entire raw private key, but I think it is possible to fix that. Not that many files are affected. However, I'm not sure I have understood the GnuPG 2.x architecture fully. If I were to summarize what GnuTLS need interfaces to do, I believe it would be: * Get a list of private keys, some information about it (e.g., RSA? DSA? etc) and their related X.509 or OpenPGP cert. Possibly the user should be able to use a fingerprint or similar to indicate a particular key or certificate. * Ask GnuPG 2.x to sign something using a particular key. I suppose some external component, typically gpg-agent or seahorse, would be responsible for authorization the request and get the passphrase, I don't think that belongs in GnuTLS. Possibly for servers, having a callback via GnuTLS to get the passphrase would be useful. That seems to be quite simple requirements, but I'm not sure if there is a single GnuPG 2.x component that can help me here. If I understand correctly: Talking to scdaemon only give me smart-card access, but not access to private keys stored under ~/.gnupg. I think the ~/.gnupg use-case is important. GnuTLS shouldn't work only with smart card keys. Talking to gpgsm only give me X.509 certificates, and possibly also signing of them. (Does gpgsm support raw signing, or only CMS?) Using gpgme doesn't give me access to raw RSA/DSA signing, only OpenPGP or CMS (or?). My knowledge of GPGME is weak, and possibly I should be using it. Is there a gpgme server? I'm not sure GnuTLS should link to gpgme directly, the child processes, signal handling, thread issues are problematic, so I would prefer to talk to an external process using IPC. Could we create a gpgme-agent? Help? /Simon From wk at gnupg.org Thu Mar 15 18:07:09 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Mar 2007 18:07:09 +0100 Subject: Injecting Status-fd output In-Reply-To: <821wjqrk1l.fsf@mid.bfk.de> (Florian Weimer's message of "Thu\, 15 Mar 2007 09\:24\:38 +0100") References: <87wt1svv50.fsf@wheatstone.g10code.de> <827itmvjah.fsf@mid.bfk.de> <82hcspruxi.fsf@mid.bfk.de> <87lki0i33t.fsf@wheatstone.g10code.de> <821wjqrk1l.fsf@mid.bfk.de> Message-ID: <871wjqv3k2.fsf@wheatstone.g10code.de> On Thu, 15 Mar 2007 09:24, fweimer at bfk.de said: > It's not necessary to use OpenPGP's bit stuffing. You could use a > simple protocol like this: Given that we now process only one plaintext message, the whole issues is not anymore critical. Reading status-fd separate from the output-fd should not be a problem anymore. In future we will implement an Assuan interface like gpgsm does. This is very similar to your suggestion. Salam-Shalom, Werner From wk at gnupg.org Thu Mar 15 18:23:11 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Mar 2007 18:23:11 +0100 Subject: Some bits about SCdaemon In-Reply-To: <87k5xi3aov.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu\, 15 Mar 2007 14\:20\:32 +0100") References: <87odn7cyg6.fsf@wheatstone.g10code.de> <87k5xi3aov.fsf@mocca.josefsson.org> Message-ID: <87wt1ito8w.fsf@wheatstone.g10code.de> On Thu, 15 Mar 2007 14:20, simon at josefsson.org said: > * Get a list of private keys, some information about it (e.g., RSA? > DSA? etc) and their related X.509 or OpenPGP cert. Possibly the > user should be able to use a fingerprint or similar to indicate a > particular key or certificate. This is possible for the current smart card. Send "SCD LEARN" to the gpg-agent. Listing all available private on-disk keys is not yet possible. The only reason for this is that an implementation of the gpg-agent protocol might not allow to list the keys because they are stored on a HSM which does not implement such a feature. However, for the current implementation it would be easy to add such a command. For now you need to know the public key to check whether gpg-agent has the private part. gpg-agent does not know anything about protocols, so you need to use a hash of the public key (the keygrip) to identify a key. > * Ask GnuPG 2.x to sign something using a particular key. I suppose > some external component, typically gpg-agent or seahorse, would be > responsible for authorization the request and get the passphrase, I > don't think that belongs in GnuTLS. Possibly for servers, having a > callback via GnuTLS to get the passphrase would be useful. The cetral place is gpg-agent. It will take care of signing and decryption and may divert processing to scdaemon. The idea is that you always try to use gpg-agent and only if it is not available, use scdaemon directly. Using gpg-agent has the advantage that it will take care of the PIN. For servers you would use gpg-preset-passphrase to tell gpg-agent in advance about a passphrase. A callback is not easy to implement. The pnly way I see is to have a special pinentry whcih loops back to the actual application (we recently discussed this on emacs-devel). > Talking to scdaemon only give me smart-card access, but not access to > private keys stored under ~/.gnupg. I think the ~/.gnupg use-case is > important. GnuTLS shouldn't work only with smart card keys. Right. However in most cases you will use gpg-agent to proxy commands to scdaemon and then you can also use gpg-agent directly. > Talking to gpgsm only give me X.509 certificates, and possibly also > signing of them. (Does gpgsm support raw signing, or only CMS?) gpgsm is a pure CMS application. > Using gpgme doesn't give me access to raw RSA/DSA signing, only > OpenPGP or CMS (or?). My knowledge of GPGME is weak, and possibly I gpgme is designed for and encryption and signing but not for authentication or stream signing. > should be using it. Is there a gpgme server? I'm not sure GnuTLS > should link to gpgme directly, the child processes, signal handling, > thread issues are problematic, so I would prefer to talk to an I once thought about that. But I doubt that you really need it. Check out gnupg/sm/call-agent.c on how decryption and signing can be delegated to gpg-agent/scdaemon. Shalom-Salam, Werner From simon at josefsson.org Fri Mar 16 04:17:07 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 16 Mar 2007 04:17:07 +0100 Subject: Some bits about SCdaemon In-Reply-To: <87wt1ito8w.fsf@wheatstone.g10code.de> (Werner Koch's message of "Thu\, 15 Mar 2007 18\:23\:11 +0100") References: <87odn7cyg6.fsf@wheatstone.g10code.de> <87k5xi3aov.fsf@mocca.josefsson.org> <87wt1ito8w.fsf@wheatstone.g10code.de> Message-ID: <87lkhxri6k.fsf@mocca.josefsson.org> Werner Koch writes: > On Thu, 15 Mar 2007 14:20, simon at josefsson.org said: > >> * Get a list of private keys, some information about it (e.g., RSA? >> DSA? etc) and their related X.509 or OpenPGP cert. Possibly the >> user should be able to use a fingerprint or similar to indicate a >> particular key or certificate. > > This is possible for the current smart card. Send "SCD LEARN" to the > gpg-agent. I'll try start implement this using smartcards, and hope that it will be easy to adapt the code to non-smartcard cases later on. > Listing all available private on-disk keys is not yet possible. The > only reason for this is that an implementation of the gpg-agent > protocol might not allow to list the keys because they are stored on a > HSM which does not implement such a feature. However, for the current > implementation it would be easy to add such a command. For now you > need to know the public key to check whether gpg-agent has the private > part. Adding that functionality would be really useful for GnuTLS. Another idea is for gpg-agent to present a pull-down list with private keys, and have the user chose one of them. Mozilla works this way when you have multiple private keys locally. Possibly, GnuTLS can also tell the agent for which CAs it should bother to list private keys for, since the TLS server typically tell you this. >> * Ask GnuPG 2.x to sign something using a particular key. I suppose >> some external component, typically gpg-agent or seahorse, would be >> responsible for authorization the request and get the passphrase, I >> don't think that belongs in GnuTLS. Possibly for servers, having a >> callback via GnuTLS to get the passphrase would be useful. > > The cetral place is gpg-agent. It will take care of signing and > decryption and may divert processing to scdaemon. Good. > The idea is that you always try to use gpg-agent and only if it is not > available, use scdaemon directly. Using gpg-agent has the advantage > that it will take care of the PIN. > > For servers you would use gpg-preset-passphrase to tell gpg-agent in > advance about a passphrase. A callback is not easy to implement. The > pnly way I see is to have a special pinentry whcih loops back to the > actual application (we recently discussed this on emacs-devel). Right, I think it makes sense to only talk to gpg-agent. Maybe gpg-agent could act as a proxy for gpgsm --server too? Although I might not need to talk with gpgsm after all... > I once thought about that. But I doubt that you really need it. > Check out gnupg/sm/call-agent.c on how decryption and signing can be > delegated to gpg-agent/scdaemon. Ok, I see. Why doesn't it use the scdaemon-proxy in the agent? Is the scdaemon-proxy idea in the agent a new invention? /Simon From wk at gnupg.org Fri Mar 16 08:38:23 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Mar 2007 08:38:23 +0100 Subject: Some bits about SCdaemon In-Reply-To: <87lkhxri6k.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri\, 16 Mar 2007 04\:17\:07 +0100") References: <87odn7cyg6.fsf@wheatstone.g10code.de> <87k5xi3aov.fsf@mocca.josefsson.org> <87wt1ito8w.fsf@wheatstone.g10code.de> <87lkhxri6k.fsf@mocca.josefsson.org> Message-ID: <871wjptz80.fsf@wheatstone.g10code.de> On Fri, 16 Mar 2007 04:17, simon at josefsson.org said: > Adding that functionality would be really useful for GnuTLS. Okay. Before I add this command it will be very useful to store attributes along with the private keys. For example capabilties of the key (so that a signing is not accidently use for decryption). > Another idea is for gpg-agent to present a pull-down list with private > keys, and have the user chose one of them. Mozilla works this way > when you have multiple private keys locally. That is too much user interface for gpg-agent. A frontend can do that. I don't want to have more code in gpg-agent than required for managing private keys. > Possibly, GnuTLS can also tell the agent for which CAs it should > bother to list private keys for, since the TLS server typically tell > you this. That is a problem as gpg-agent does not now anything aout PKIs. In fact one key might possible be used by several certificates, OpenPGP keys and ssh keys. For smart cards it is really useful to have one smart card for X.509 and OpenPGP. > Maybe gpg-agent could act as a proxy for gpgsm --server too? Although > I might not need to talk with gpgsm after all... You don't need gpgsm. GNUTLS has its own certificate management. Or do you want to use gpgsm for this? I have considered several times to write a certificate validation library but it is quite hard to do this in a generic way. You would need to much callbacks and such whcih makes an API too complicated. >> Check out gnupg/sm/call-agent.c on how decryption and signing can be >> delegated to gpg-agent/scdaemon. > > Ok, I see. Why doesn't it use the scdaemon-proxy in the agent? Is > the scdaemon-proxy idea in the agent a new invention? That is because gpgsm works only with registred smart cards (gpgsm -learn). gpg-agent then knows when to divert operations to a smart card. The idea here is that gpg-agent can ask the user to insert a specific smart card. However, a shortcut for the currently inserted smart card might make sense. Shalom-Salam, Werner From buanzo at buanzo.com.ar Sat Mar 17 13:09:11 2007 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Sat, 17 Mar 2007 09:09:11 -0300 Subject: --list-secret-keys and stdout Message-ID: <45FBDA67.2070901@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear GnuPG developers, I'm the author of a Firefox extension that implements OpenPGP -based digitall signing of HTTP requests (http://enigform.mozdev.org), allowing web applications to authenticate data and identity. Now my problem: I need to implement secret key selection dialog, and while doing research, I decided to use this combo: gpg --with-fingerprint --fixed-list-mode --with-colons --list-secret-keys The problem is that the information is ALWAYS written to stdout, and I can't send it to a file. I've tried: - --status-file status --logger-file logger --attribute-file attr --output out But... always stdout. Enigmail, an extension for Thunderbird you probably know, implements the parsing of that via including an extra XPCOM component for IPC functionality, capturing stdout via IPC. I want to avoid that. So far, my extension only depends on Firefox and gnupg, and works in any platform Firefox and GnuPG work. I can't wrap the call to gpg via bash, because I don't want to introduce new dependencies. So: Is there an undocument way of saving that information to a file? If not, would you implement - --output support for --list-secret-keys? Should I implement it, and send you a patch? Any other ideas/comments? Sincerely, - -- Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica Enigform for Firefox: A secure browsing experience: http://enigform.mozdev.org Mail Hosting Seguro y Consultoria - http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+9pnAlpOsGhXcE0RCsFsAJ4/JX45nMqevVfaFjjN2kdfGHavngCeLLnr D8JxK0B/+VYicn+EY9g3Zw8= =e38k -----END PGP SIGNATURE----- From simon at limmat.switch.ch Fri Mar 9 15:02:56 2007 From: simon at limmat.switch.ch (Simon Leinen) Date: Fri, 9 Mar 2007 15:02:56 +0100 Subject: GnuPG 2.0.3 build error: gpg2keys_ldap requires -lgpg-error Message-ID: <17905.26896.439632.880167@limmat.switch.ch> Trying to compile GnuPG 2.0.3 on a SPARC/Solaris 9 system, I ran into the following error: Making all in keyserver make[2]: Entering directory `/local/src/packages/gnupg/gnupg-2.0.3/keyserver' /opt/SUNWspro/bin/cc -I/usr/local/include -I/usr/local/include -I/usr/local/include -fast -xtarget=ultra -g -xs -o gpg2keys_ldap gpg2keys_ldap-gpgkeys_ldap.o gpg2keys_ldap-ksutil.o gpg2keys_ldap-no-libgcrypt.o ../jnlib/libjnlib.a -lldap -lsocket -lnsl /usr/local/lib/libiconv.so -R/usr/local/lib /usr/local/lib/libintl.so -lc -R/usr/local/lib Undefined first referenced symbol in file gpg_err_code_from_errno gpg2keys_ldap-gpgkeys_ldap.o gpg_err_code_from_syserror gpg2keys_ldap-gpgkeys_ldap.o ld: fatal: Symbol referencing errors. No output written to gpg2keys_ldap make[2]: *** [gpg2keys_ldap] Error 1 make[2]: Leaving directory `/local/src/packages/gnupg/gnupg-2.0.3/keyserver' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/local/src/packages/gnupg/gnupg-2.0.3' make: *** [all] Error 2 I think this can be fixed by adding libgpg-error to keyserver/Makefile.am, and regenerating keyserver/Makefile.in. Here's a patch for the former. Best regards, -- Simon. *** /tmp/T0Wdaaq2 Fri Mar 9 15:00:14 2007 --- Makefile.am Fri Mar 9 14:57:02 2007 *************** *** 41,47 **** gpg2keys_ldap_SOURCES = gpgkeys_ldap.c ksutil.c ksutil.h no-libgcrypt.c gpg2keys_ldap_CPPFLAGS = $(LDAP_CPPFLAGS) $(AM_CPPFLAGS) ! gpg2keys_ldap_LDADD = ../jnlib/libjnlib.a $(LDAPLIBS) $(NETLIBS) $(other_libs) gpg2keys_finger_SOURCES = gpgkeys_finger.c ksutil.c ksutil.h no-libgcrypt.c gpg2keys_finger_CPPFLAGS = $(AM_CPPFLAGS) --- 41,47 ---- gpg2keys_ldap_SOURCES = gpgkeys_ldap.c ksutil.c ksutil.h no-libgcrypt.c gpg2keys_ldap_CPPFLAGS = $(LDAP_CPPFLAGS) $(AM_CPPFLAGS) ! gpg2keys_ldap_LDADD = ../jnlib/libjnlib.a $(LDAPLIBS) $(GPG_ERROR_LIBS) $(NETLIBS) $(other_libs) gpg2keys_finger_SOURCES = gpgkeys_finger.c ksutil.c ksutil.h no-libgcrypt.c gpg2keys_finger_CPPFLAGS = $(AM_CPPFLAGS) From wk at gnupg.org Mon Mar 19 09:40:17 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Mar 2007 09:40:17 +0100 Subject: --list-secret-keys and stdout In-Reply-To: <45FBDA67.2070901@buanzo.com.ar> (Arturo Busleiman's message of "Sat\, 17 Mar 2007 09\:09\:11 -0300") References: <45FBDA67.2070901@buanzo.com.ar> Message-ID: <87ps7562z2.fsf@wheatstone.g10code.de> On Sat, 17 Mar 2007 13:09, buanzo at buanzo.com.ar said: > Is there an undocument way of saving that information to a file? If not, would you implement > --output support for --list-secret-keys? Should I implement it, and send you a patch? Any other No, there is no such option. Eventually we will add this but it needs quite some work because we can't use the standard stdio printf for some reasons (we need an emulation of funopen). I wonder why you are not using gpgme - it takes care of all this and listing the secret keys is the just a matter of: err = gpgme_op_keylist_start (ctx, NULL, 1); fail_if_err (err); while (!(err = gpgme_op_keylist_next (ctx, &key))) { /* Now check key flags or do whatever you want to do with that key. E.g: */ if (key->revoked) { fprintf (stderr, "Key has been revoked\n"); gpgme_key_unref (key); continue } foo (key); gpgme_key_unref (key); } if (gpg_err_code (err) != GPG_ERR_EOF) fail_if_err (err); err = gpgme_op_keylist_end (ctx); fail_if_err (err); This also allows to switch to X.509 keys with just one function call. Further you automagically participate from newer developments, like running gpg as a co-process. Salam-Shalom, Werner From buanzo at buanzo.com.ar Mon Mar 19 11:56:20 2007 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Mon, 19 Mar 2007 07:56:20 -0300 Subject: --list-secret-keys and stdout In-Reply-To: <87ps7562z2.fsf@wheatstone.g10code.de> References: <45FBDA67.2070901@buanzo.com.ar> <87ps7562z2.fsf@wheatstone.g10code.de> Message-ID: <45FE6C54.8060207@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Werner Koch wrote: > I wonder why you are not using gpgme - it takes care of all this and > listing the secret keys is the just a matter of: GPGME? From Within a Firefox Extension, when I intent to avoid more dependencies? So far Enigform just needs Firefox, gpg, and the extension itself. No C++ XPCOM components, etc. Enigmail, the famous Thunderbird extension, uses the ipc js library to capture gpg's stdout and parse it, but the library is not that portable. :( - -- Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica Foros GNU/Buanzo: Respeto, Soluciones y Buena Onda: http://foros.buanzo.com.ar Consulting and Secure Mail Hosting: http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF/mxUAlpOsGhXcE0RCq/zAJ92ZlERn6JMykinbB38sPLNAFhSFgCfYeGs IwxsuiLhgfIPAz+uN4yBHuk= =NSOr -----END PGP SIGNATURE----- From simon at josefsson.org Tue Mar 20 17:51:05 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 20 Mar 2007 17:51:05 +0100 Subject: eccGnuPG In-Reply-To: <200702082205.48034.sbt@megacceso.com> (Sergi Blanch i. Torne's message of "Thu\, 8 Feb 2007 22\:05\:26 +0100") References: <200702082205.48034.sbt@megacceso.com> Message-ID: <877itbuadi.fsf@mocca.josefsson.org> Sergi Blanch i Torne writes: > Hi, > > The elliptic curve project to GnuPG has been moved to a new server. Now the > web address is: > http://www.calcurco.cat/eccGnuPG/ > > And the sources patch sould be available in: > http://www.calcurco.cat/eccGnuPG/src/gnupg-1.4.6-ecc0.1.6.diff.bz2 > > And the beta patch in: > http://www.calcurco.cat/eccGnuPG/src/gnupg-1.4.6-ecc0.2.0beta1.diff.bz2 Some people have asked me about ECC support in GnuTLS, and your work would provide a good foundation for that. What is the status of this work? Any chance ECC support will be integrated into libgcrypt? I am aware of some patent concerns, but I'm actively trying to get more information on the situation. /Simon From wk at gnupg.org Tue Mar 20 18:20:06 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Mar 2007 18:20:06 +0100 Subject: eccGnuPG In-Reply-To: <877itbuadi.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue\, 20 Mar 2007 17\:51\:05 +0100") References: <200702082205.48034.sbt@megacceso.com> <877itbuadi.fsf@mocca.josefsson.org> Message-ID: <87hcsfygqh.fsf@wheatstone.g10code.de> On Tue, 20 Mar 2007 17:51, simon at josefsson.org said: > Some people have asked me about ECC support in GnuTLS, and your work > would provide a good foundation for that. What is the status of this > work? Any chance ECC support will be integrated into libgcrypt? My last information is that we need to do the copyright assignments. Salam-Shalom, Werner From wk at gnupg.org Wed Mar 21 09:09:59 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Mar 2007 09:09:59 +0100 Subject: eccGnuPG In-Reply-To: <200702082205.48034.sbt@megacceso.com> (Sergi Blanch i. Torne's message of "Thu\, 8 Feb 2007 22\:05\:26 +0100") References: <200702082205.48034.sbt@megacceso.com> Message-ID: <87ps73vwyw.fsf@wheatstone.g10code.de> On Thu, 8 Feb 2007 22:05, sbt at megacceso.com said: > The elliptic curve project to GnuPG has been moved to a new server. Now the > web address is: > http://www.calcurco.cat/eccGnuPG/ However, calcurco.cat has only a pending registration, so there is no way to get its IP address. Shalom-Salam, Werner From sbt at megacceso.com Wed Mar 21 10:50:30 2007 From: sbt at megacceso.com (Sergi Blanch i =?iso-8859-1?q?Torn=E9?=) Date: Wed, 21 Mar 2007 10:50:30 +0100 Subject: eccGnuPG In-Reply-To: <877itbuadi.fsf@mocca.josefsson.org> References: <200702082205.48034.sbt@megacceso.com> <877itbuadi.fsf@mocca.josefsson.org> Message-ID: <200703211050.30253.sbt@megacceso.com> On Tuesday 20 March 2007 17:51, Simon Josefsson wrote: > Some people have asked me about ECC support in GnuTLS, and your work > would provide a good foundation for that. What is the status of this > work? Any chance ECC support will be integrated into libgcrypt? The bad think is that I am not full time dedicated on a ecc. As fas as I can, I want to port the code to libgcrypt (and also do a patch for gpg2). But also there are some channel attack that I am working to prevent. > I am aware of some patent concerns, but I'm actively trying to get > more information on the situation. There exist patens over some algorithms, but not the ones that are used on this module. At less, I think, it doesn't use anything patented. ECDSA to sign and EC_Diffie-Hellman scheme plus an AES256 and a SHA256 are the used algorithms. /Sergi. From alon.barlev at gmail.com Wed Mar 21 12:30:19 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 21 Mar 2007 13:30:19 +0200 Subject: eccGnuPG In-Reply-To: <200703211050.30253.sbt@megacceso.com> References: <200702082205.48034.sbt@megacceso.com> <877itbuadi.fsf@mocca.josefsson.org> <200703211050.30253.sbt@megacceso.com> Message-ID: <9e0cf0bf0703210430md11218dh5da70da102f97052@mail.gmail.com> This has been partially one. Does not work yet. http://bugs.gentoo.org/show_bug.cgi?id=159870 I will be happy if anyone has some thought regarding this. Best Regards, Alon Bar-Lev. On 3/21/07, Sergi Blanch i Torn? wrote: > On Tuesday 20 March 2007 17:51, Simon Josefsson wrote: > > Some people have asked me about ECC support in GnuTLS, and your work > > would provide a good foundation for that. What is the status of this > > work? Any chance ECC support will be integrated into libgcrypt? > > The bad think is that I am not full time dedicated on a ecc. As fas as I can, > I want to port the code to libgcrypt (and also do a patch for gpg2). But also > there are some channel attack that I am working to prevent. > > > I am aware of some patent concerns, but I'm actively trying to get > > more information on the situation. > > There exist patens over some algorithms, but not the ones that are used on > this module. At less, I think, it doesn't use anything patented. ECDSA to > sign and EC_Diffie-Hellman scheme plus an AES256 and a SHA256 are the used > algorithms. > > /Sergi. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From simon at josefsson.org Wed Mar 21 13:18:50 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 21 Mar 2007 13:18:50 +0100 Subject: eccGnuPG In-Reply-To: <200703211050.30253.sbt@megacceso.com> ("Sergi Blanch i. =?iso-8859-1?Q?Torn=E9=22's?= message of "Wed\, 21 Mar 2007 10\:50\:30 +0100") References: <200702082205.48034.sbt@megacceso.com> <877itbuadi.fsf@mocca.josefsson.org> <200703211050.30253.sbt@megacceso.com> Message-ID: <87tzwerdqt.fsf@mocca.josefsson.org> Sergi Blanch i Torn? writes: > On Tuesday 20 March 2007 17:51, Simon Josefsson wrote: >> Some people have asked me about ECC support in GnuTLS, and your work >> would provide a good foundation for that. What is the status of this >> work? Any chance ECC support will be integrated into libgcrypt? > > The bad think is that I am not full time dedicated on a ecc. As fas as I can, > I want to port the code to libgcrypt (and also do a patch for gpg2). But also > there are some channel attack that I am working to prevent. Ok. Other than the channel attack, are you aware of any other known problems with the patch? I'd be willing to help with the libgcrypt port if you want. >> I am aware of some patent concerns, but I'm actively trying to get >> more information on the situation. > > There exist patens over some algorithms, but not the ones that are used on > this module. At less, I think, it doesn't use anything patented. ECDSA to > sign and EC_Diffie-Hellman scheme plus an AES256 and a SHA256 are the used > algorithms. That's good to know, thanks. /Simon From wk at gnupg.org Wed Mar 21 13:55:13 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Mar 2007 13:55:13 +0100 Subject: eccGnuPG In-Reply-To: <9e0cf0bf0703210430md11218dh5da70da102f97052@mail.gmail.com> (Alon Bar-Lev's message of "Wed\, 21 Mar 2007 13\:30\:19 +0200") References: <200702082205.48034.sbt@megacceso.com> <877itbuadi.fsf@mocca.josefsson.org> <200703211050.30253.sbt@megacceso.com> <9e0cf0bf0703210430md11218dh5da70da102f97052@mail.gmail.com> Message-ID: <87hcseu572.fsf@wheatstone.g10code.de> On Wed, 21 Mar 2007 12:30, alon.barlev at gmail.com said: > I will be happy if anyone has some thought regarding this. You mean that IDEA is not supported by Libgcrypt? That is on purpose. Nobody needs IDEA theese days and those who still want a 64 bit cipher need to wait until the patent has expired. There is a wealth of non-patented algorithms available for years and thus no need to pour money into the cash box of a company which seriously hindered the use of encryption over the last 15 years. Shalom-Salam, Werner From alon.barlev at gmail.com Wed Mar 21 17:11:30 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 21 Mar 2007 18:11:30 +0200 Subject: app-crypt/pinentry-0.7.2 - gtk2 fails with "** ERROR **: could not grab keyboard" Message-ID: <9e0cf0bf0703210911p276bab1ft8ca3b58d3967217@mail.gmail.com> Hello, Can anyone help? http://bugs.gentoo.org/show_bug.cgi?id=165493 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401957 88 /* Grab the keyboard for maximum security */ 89 static void 90 grab_keyboard (GtkWidget *win, GdkEvent *event, gpointer data) 91 { 92 if (!pinentry->grab) 93 return; 94 95 if (gdk_keyboard_grab (win->window, FALSE, gdk_event_get_time (event))) 96 g_error ("could not grab keyboard"); 97 } gdk_keyboard_grab with GDK_GRAB_NOT_VIEWABLE (3). Best Regards, Alon Bar-Lev. From sbt at megacceso.com Wed Mar 21 17:34:42 2007 From: sbt at megacceso.com (Sergi Blanch i =?iso-8859-1?q?Torn=E9?=) Date: Wed, 21 Mar 2007 17:34:42 +0100 Subject: eccGnuPG In-Reply-To: <87tzwerdqt.fsf@mocca.josefsson.org> References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> Message-ID: <200703211734.43244.sbt@megacceso.com> On Wednesday 21 March 2007 13:18, Simon Josefsson wrote: > Sergi Blanch i Torn? writes: > > The bad think is that I am not full time dedicated on a ecc. As fas as I > > can, I want to port the code to libgcrypt (and also do a patch for gpg2). > > But also there are some channel attack that I am working to prevent. > > Ok. Other than the channel attack, are you aware of any other known > problems with the patch? The patch have one known problem published in the web. But to day I receive the information that could be not accessible from every where; I'm try to solve it as fast as possible. The report say: "Report de Gary D. Huffman, II a 9/Feb/2007: "Corrupt messatges that broke instant messages between to Jabber acounts using "curves as a cypher system. It seems to happen more frequently with small "messages, but that may just be coincidence. > I'd be willing to help with the libgcrypt port if you want. This is the great think of free software, if you want you can. If you have knowledge on the library, you can try. Good results (tested and this thinks) will be published. Also if you have some questions that I can solve, no doubt to ask me. Happily I will answer to you! /Sergi. From wk at gnupg.org Wed Mar 21 19:07:33 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Mar 2007 19:07:33 +0100 Subject: eccGnuPG In-Reply-To: <200703211734.43244.sbt@megacceso.com> (Sergi Blanch i. =?utf-8?Q?Torn=C3=A9's?= message of "Wed\, 21 Mar 2007 17\:34\:42 +0100") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> Message-ID: <87tzweqxlm.fsf@wheatstone.g10code.de> On Wed, 21 Mar 2007 17:34, sbt at megacceso.com said: > This is the great think of free software, if you want you can. If you have > knowledge on the library, you can try. Good results (tested and this thinks) > will be published. Also if you have some questions that I can solve, no doubt Meanwhile I started to port the patch to libgcrypt. Will report as soon as I have some success. Shalom-Salam, Werner From wk at gnupg.org Thu Mar 22 17:27:42 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Mar 2007 17:27:42 +0100 Subject: eccGnuPG In-Reply-To: <87tzweqxlm.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed\, 21 Mar 2007 19\:07\:33 +0100") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> Message-ID: <87mz25mef5.fsf@wheatstone.g10code.de> On Wed, 21 Mar 2007 19:07, wk at gnupg.org said: > Meanwhile I started to port the patch to libgcrypt. Will report as > soon as I have some success. The Libgcrypt SVN now has experimental support for ECDSA. It is still not finished and we need to do something about the performance: Algorithm generate 100*sign 100*verify ---------------------------------------------- DSA 1024/160 - 910ms 810ms DSA 2048/224 - 1560ms 1850ms DSA 3072/256 - 3630ms 4410ms ECDSA 192 bit 110ms 2720ms 5090ms ECDSA 256 bit 130ms 3010ms 6070ms ECDSA 521 bit 910ms 23140ms 48090ms Salam-Shalom, Werner From chris.pitchford at newsint.co.uk Fri Mar 23 12:51:34 2007 From: chris.pitchford at newsint.co.uk (Pitchford, Chris - IT Security Team) Date: Fri, 23 Mar 2007 11:51:34 -0000 Subject: ftp.gnupg.org seems to cause problems with Checkpoint firewall1 and Cisco CSS Message-ID: Hello all, This is a bit of a specific problem with the FTP server serving ftp.gnupg.org, not actually a problem with the product gnupg itself!.. I've noticed that the FTP server fragments the data it sends to clients in the control connection at a really unhelpful point. It sends the response line in one packet, then sends line terminating CR, LF in a new packet of its own. Here's an example of a connection from the FTP server client ftp.gnupg.org SYN ftp.gnupg.org client SYN,ACK client ftp.gnupg.org ACK ftp.gnupg.org client 220 Service ready for new user. ftp.gnupg.org client \r\n (CR, LF) Ok, why did the FTP server send 2 packets for the welcome banner? This will be blocked by Checkpoint Firewall1 since it detects that the first packet did not end in a CR, LF. I've not yet seen any other FTP server that does this. I created a work around for this. I've seen this again, causing problem setting up a data connection. client ftp.gnupg.org PASV\r\n ftp.gnupg.org client 227 Entering Passive Mode (217,69,76,51,162,59). ftp.gnupg.org client \r\n This split causes a problem for a Cisco CSS that is NATing a cluster of FTP proxies to a single IP address. I can't find any evidence in the FTP RFC that states that the CR,LF needs to be sent in a single packet, but I also cannot find any other FTP server exhibiting this strange behaviour. It is certainly a waste to send two packets when one would suffice! It seems that the FTP server is using two calls to write() to send the responses and banners, but that is as much as I can say. Is there any chance you'd consider changing FTP servers? Is it private information or I can I know the daemon you're using so I can investigate why it is doing this and if there is a fix for the server? Cheers Chris Security Consultant News Internation Newspapers Ltd "Please consider the environment before printing this e-mail" The Newspaper Marketing Agency: Opening Up Newspapers: www.nmauk.co.uk This e-mail and all attachments are confidential and may be privileged. If you have received this e-mail in error, notify the sender immediately. Do not use, disseminate, store or copy it in any way. Statements or opinions in this e-mail or any attachment are those of the author and are not necessarily agreed or authorised by News International (NI). NI Group may monitor emails sent or received for operational or business reasons as permitted by law. NI Group accepts no liability for viruses introduced by this e-mail or attachments. You should employ virus checking software. News International Limited, 1 Virginia St, London E98 1XY, is the holding company for the News International group and is registered in England No 81701 From wk at gnupg.org Fri Mar 23 19:21:03 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Mar 2007 19:21:03 +0100 Subject: ftp.gnupg.org seems to cause problems with Checkpoint firewall1 and Cisco CSS In-Reply-To: (Chris Pitchford's message of "Fri\, 23 Mar 2007 11\:51\:34 -0000") References: Message-ID: <87ejnfizxs.fsf@wheatstone.g10code.de> On Fri, 23 Mar 2007 12:51, chris.pitchford at newsint.co.uk said: > in the control connection at a really unhelpful point. It sends the > response line in one packet, then sends line terminating CR, LF in a new > packet of its own. Right, that is how oftpd does it. > I can't find any evidence in the FTP RFC that states that the CR,LF > needs to be sent in a single packet, but I also cannot find any other > FTP server exhibiting this strange behaviour. It is certainly a waste to > send two packets when one would suffice! No, an RFC can never tell this because we are working on the TCP layer and here we have a data stream and don't know about the underlying packet structure. Anyway I changed it so that the CRLF is merged with the line beore write() is called. It should now work for you. However this is not bulletproof because on systems where the internal buffering is shorther than a line if might still get send as two packets. See http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/oftpd/src/telnet_session.c?rev=1.4&root=wk%27s+Stuff&view=auto for the changed file (telnet_session_println). Salam-Shalom, Werner From wk at gnupg.org Wed Mar 28 12:01:06 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Mar 2007 12:01:06 +0200 Subject: eccGnuPG In-Reply-To: <87mz25mef5.fsf@wheatstone.g10code.de> (Werner Koch's message of "Thu\, 22 Mar 2007 17\:27\:42 +0100") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> Message-ID: <87d52t7km5.fsf@wheatstone.g10code.de> Hi, I basically rewrote the new ECC code to get better performance. The implemetaion is very straightforward and not much optimized. A quick test using fast reduction for the NIST curves didn't show any advantages. Here are the numbers: > Algorithm generate 100*sign 100*verify > ---------------------------------------------- > DSA 1024/160 - 910ms 810ms > DSA 2048/224 - 1560ms 1850ms > DSA 3072/256 - 3630ms 4410ms > ECDSA 192 bit 110ms 2720ms 5090ms > ECDSA 256 bit 130ms 3010ms 6070ms > ECDSA 521 bit 910ms 23140ms 48090ms Algorithm generate 100*sign 100*verify ---------------------------------------------- DSA 1024/160 - 410ms 530ms DSA 2048/224 - 1760ms 2260ms DSA 3072/256 - 3950ms 5040ms ECDSA 192 bit 20ms 720ms 1270ms ECDSA 224 bit 40ms 900ms 1650ms ECDSA 256 bit 50ms 1120ms 2090ms ECDSA 384 bit 100ms 2610ms 4900ms ECDSA 521 bit 280ms 6930ms 13240ms The upshot is that we are now more that 3 times faster. The next step is to look out for test vectors and then the code should be ready for use. Salam-Shalom, Werner From simon at josefsson.org Wed Mar 28 12:22:28 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 28 Mar 2007 12:22:28 +0200 Subject: eccGnuPG In-Reply-To: <87d52t7km5.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed\, 28 Mar 2007 12\:01\:06 +0200") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <87d52t7km5.fsf@wheatstone.g10code.de> Message-ID: <87648lvfa3.fsf@mocca.josefsson.org> I found a good resource for ECC test vectors: http://dev.experimentalstuff.com:8082/ I suspect the three most important curves to support are the NIST suite-B ones: NIST P-256 (aka secp256r1), NIST P-384 (aka secp384r1), and NIST P-521 (aka secp521r1) Do you know if libgcrypt support these curves? /Simon From simon at josefsson.org Wed Mar 28 12:16:10 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 28 Mar 2007 12:16:10 +0200 Subject: eccGnuPG In-Reply-To: <87d52t7km5.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed\, 28 Mar 2007 12\:01\:06 +0200") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <87d52t7km5.fsf@wheatstone.g10code.de> Message-ID: <87abxxvfkl.fsf@mocca.josefsson.org> Werner Koch writes: > Algorithm generate 100*sign 100*verify > ---------------------------------------------- > DSA 1024/160 - 410ms 530ms > DSA 2048/224 - 1760ms 2260ms > DSA 3072/256 - 3950ms 5040ms > ECDSA 192 bit 20ms 720ms 1270ms > ECDSA 224 bit 40ms 900ms 1650ms > ECDSA 256 bit 50ms 1120ms 2090ms > ECDSA 384 bit 100ms 2610ms 4900ms > ECDSA 521 bit 280ms 6930ms 13240ms Cool! How does it compare to RSA? > The upshot is that we are now more that 3 times faster. The next step > is to look out for test vectors and then the code should be ready for > use. I'll ask for test vectors for TLS uses. Thanks, Simon From sbt at megacceso.com Wed Mar 28 13:02:18 2007 From: sbt at megacceso.com (Sergi Blanch i =?iso-8859-1?q?Torn=E9?=) Date: Wed, 28 Mar 2007 13:02:18 +0200 Subject: eccGnuPG In-Reply-To: <87abxxvfkl.fsf@mocca.josefsson.org> References: <200702082205.48034.sbt@megacceso.com> <87d52t7km5.fsf@wheatstone.g10code.de> <87abxxvfkl.fsf@mocca.josefsson.org> Message-ID: <200703281302.18978.sbt@megacceso.com> On Wednesday 28 March 2007 12:16, Simon Josefsson wrote: > Werner Koch writes: > > Algorithm generate 100*sign 100*verify > > ---------------------------------------------- > > DSA 1024/160 - 410ms 530ms > > DSA 2048/224 - 1760ms 2260ms > > DSA 3072/256 - 3950ms 5040ms > > ECDSA 192 bit 20ms 720ms 1270ms > > ECDSA 224 bit 40ms 900ms 1650ms > > ECDSA 256 bit 50ms 1120ms 2090ms > > ECDSA 384 bit 100ms 2610ms 4900ms > > ECDSA 521 bit 280ms 6930ms 13240ms > > Cool! How does it compare to RSA? Now is only the digital signature moment, and then the encryption algorithms can come in. Yes, it is true that exist an schema for rsa signature but it have more sense to compare the DSA over finite fields against the same schema over elliptic curves. > > The upshot is that we are now more that 3 times faster. The next step > > is to look out for test vectors and then the code should be ready for > > use. The elliptic curves over finite fields (named E(F_p) uses curve point operations, but this points are defined over this finite field. Notice that DSA calculate some integer operations (in order to thousands of bits) and ECDSA calculate some point operations that will be much integer operations (in order to hundreds of bits). Future work: curves over binary fields (E(F_{2^m})). > Thanks, > Simon From simon at josefsson.org Wed Mar 28 14:20:33 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 28 Mar 2007 14:20:33 +0200 Subject: eccGnuPG In-Reply-To: <87d52t7km5.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed\, 28 Mar 2007 12\:01\:06 +0200") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <87d52t7km5.fsf@wheatstone.g10code.de> Message-ID: <87fy7ptv8u.fsf@mocca.josefsson.org> I get failures for the 512 bit ECDSA signatures sometimes: jas at mocca:~/src/libgcrypt$ tests/benchmark ecc Algorithm generate 100*sign 100*verify ---------------------------------------------- ECDSA 192 bit 20ms 450ms 830ms ECDSA 224 bit 20ms 580ms 1040ms ECDSA 256 bit 30ms 720ms 1300ms ECDSA 384 bit 60ms 1620ms 3180ms ECDSA 521 bit 170ms 4030ms benchmark: verify failed: Bad signature jas at mocca:~/src/libgcrypt$ It seems to fail about 25 % of the time or so. Can you reproduce this? I think the support necessary for ECC-TLS is present in libgcrypt now, so I'll look into integrating it in GnuTLS next. /Simon From wk at gnupg.org Wed Mar 28 14:27:30 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Mar 2007 14:27:30 +0200 Subject: eccGnuPG In-Reply-To: <87648lvfa3.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed\, 28 Mar 2007 12\:22\:28 +0200") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <87d52t7km5.fsf@wheatstone.g10code.de> <87648lvfa3.fsf@mocca.josefsson.org> Message-ID: <871wj95z9p.fsf@wheatstone.g10code.de> On Wed, 28 Mar 2007 12:22, simon at josefsson.org said: > I found a good resource for ECC test vectors: > > http://dev.experimentalstuff.com:8082/ I'll check them out. > NIST P-256 (aka secp256r1), NIST P-384 (aka secp384r1), and NIST P-521 > (aka secp521r1) > > Do you know if libgcrypt support these curves? All supported as well as P-192 and P-224. You may try in libgcryt/tests: ./pkbench --genkey ecdsa 192 ./benchmark ecc What do you need for TLS? Can you collect some resources (rfcs and such) so that I can quickly look it up? Salam-Shalom, Werner From wk at gnupg.org Wed Mar 28 14:31:46 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Mar 2007 14:31:46 +0200 Subject: eccGnuPG In-Reply-To: <87648lvfa3.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed\, 28 Mar 2007 12\:22\:28 +0200") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <87d52t7km5.fsf@wheatstone.g10code.de> <87648lvfa3.fsf@mocca.josefsson.org> Message-ID: <87wt114ki5.fsf@wheatstone.g10code.de> On Wed, 28 Mar 2007 12:22, simon at josefsson.org said: > I found a good resource for ECC test vectors: > > http://dev.experimentalstuff.com:8082/ Thanks, that seems to be enough for now. With the current code it should be possible to implement TLS_ECDH_ECDSA_WITH_*. I'll check the RFC now. Shalom-Salam, Werner From wk at gnupg.org Wed Mar 28 15:17:18 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Mar 2007 15:17:18 +0200 Subject: eccGnuPG In-Reply-To: <87fy7ptv8u.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed\, 28 Mar 2007 14\:20\:33 +0200") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <87d52t7km5.fsf@wheatstone.g10code.de> <87fy7ptv8u.fsf@mocca.josefsson.org> Message-ID: <87odmd4ie9.fsf@wheatstone.g10code.de> On Wed, 28 Mar 2007 14:20, simon at josefsson.org said: > It seems to fail about 25 % of the time or so. Can you reproduce > this? Yes. I realized that too late. It happens with all key sizes. Not sure whetehr I will be abale to debug it today. I spend a bit too much time on ecc recently ;-) Salam-Shalom, Werner From simon at josefsson.org Wed Mar 28 15:23:16 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 28 Mar 2007 15:23:16 +0200 Subject: eccGnuPG In-Reply-To: <87odmd4ie9.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed\, 28 Mar 2007 15\:17\:18 +0200") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <87d52t7km5.fsf@wheatstone.g10code.de> <87fy7ptv8u.fsf@mocca.josefsson.org> <87odmd4ie9.fsf@wheatstone.g10code.de> Message-ID: <87veglsdrv.fsf@mocca.josefsson.org> Werner Koch writes: > On Wed, 28 Mar 2007 14:20, simon at josefsson.org said: > >> It seems to fail about 25 % of the time or so. Can you reproduce >> this? > > Yes. I realized that too late. It happens with all key sizes. Not > sure whetehr I will be abale to debug it today. I spend a bit too > much time on ecc recently ;-) Don't worry, if it works 75% that is good enough for me to use it for now. I'll probably won't have time to implement it today anyway.. /Simon From sbt at megacceso.com Wed Mar 28 18:02:18 2007 From: sbt at megacceso.com (Sergi Blanch i =?iso-8859-1?q?Torn=E9?=) Date: Wed, 28 Mar 2007 18:02:18 +0200 Subject: eccGnuPG In-Reply-To: <87odmd4ie9.fsf@wheatstone.g10code.de> References: <200702082205.48034.sbt@megacceso.com> <87fy7ptv8u.fsf@mocca.josefsson.org> <87odmd4ie9.fsf@wheatstone.g10code.de> Message-ID: <200703281802.19112.sbt@megacceso.com> On Wednesday 28 March 2007 15:17, Werner Koch wrote: > On Wed, 28 Mar 2007 14:20, simon at josefsson.org said: > > It seems to fail about 25 % of the time or so. Can you reproduce > > this? > > Yes. I realized that too late. It happens with all key sizes. Not > sure whetehr I will be abale to debug it today. I spend a bit too > much time on ecc recently ;-) Every times that this appears when I am testing with gdb, the verification broke the normal flow because (x!=r) in the ecc.c:658 comparison. I checking out if the problem was in the signature process, and I thing not. IMHO I think the problem could be in the coordinates conversion from projective to affine. /Sergi. From jan-oliver.wagner at intevation.de Fri Mar 30 13:54:28 2007 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 30 Mar 2007 12:54:28 +0100 Subject: GnuPG 2.0.3: gpgconf.conf and allow-mark-trusted Message-ID: <200703301354.29159.jan-oliver.wagner@intevation.de> Hello Werner, I realized that "allow-mark-trusted" is set to "no-change" hardwired in the source code. I am aware it is set to "change" through gpgconf.conf (if installed correctly). However, I think GnuPG should not hardwire any such things. Or are there good reasons to do so? Next, the default gpgconf.conf should not set anything but only keep some examples (like the one for "allow-mark-trusted") commented out. Then we would have a liberal default and it is subject to packagers or sysadmins to define policies. All the best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From sbt at megacceso.com Fri Mar 30 23:19:22 2007 From: sbt at megacceso.com (Sergi Blanch i Torne) Date: Fri, 30 Mar 2007 23:19:22 +0200 Subject: Fwd: EccGnuPG Bug Report Message-ID: <200703302319.23054.sbt@megacceso.com> Hi, To day I receive a bug report. The affected functions are not in the Libgcrypt port. The solution was discussed also to day with Timo, but the patch is not yet. Sorry, I will do as soon as possible. This bad use of the wipememory() function can be found in sha256_hashing() and aes256_{encrypting,decrypting}() functions. Oh, this bug affect also the other branch, the 0.1. Thanks Timo /Sergi. ---------- Missatge reenviat ---------- Subject: EccGnuPG Bug Report Date: Divendres, 30 de Mar? de 2007 13:20 From: Timo Schulz To: d4372211 at alumnes.eup.udl.es Hi, based on your 0.2.0beta1 patch, I'm couldn't find any information that this problem has been reported before, there is a 'bug' in the way you use the wipememory function: byte *hash_input_buf; wipememory( hash_inp_buf, sizeof hash_inp_buf ); actually it should be wipememory (hash_inp_buf, nbytes); otherwise only sizeof (unsigned char *) == (4 or 8) bytes would be overwritten. Timo ------------------------------------------------------- From sbt at megacceso.com Sat Mar 31 00:37:13 2007 From: sbt at megacceso.com (Sergi Blanch i Torne) Date: Sat, 31 Mar 2007 00:37:13 +0200 Subject: Fwd: EccGnuPG Bug Report In-Reply-To: <200703302319.23054.sbt@megacceso.com> References: <200703302319.23054.sbt@megacceso.com> Message-ID: <200703310037.13432.sbt@megacceso.com> Maybe, is there a solution (or this is what I want to try). The problem was in the call to wipememory(_ptr,_len), exactly in the _len parameter. With an 'sizeof _ptr', could be some architectures where it does not work fine. A candidate to patch is: http://www.calcurco.cat/eccGnuPG/src/gnupg-1.4.7-ecc0.2.0beta2rc1.diff http://www.calcurco.cat/eccGnuPG/src/gnupg-1.4.7-ecc0.1.7rc1.diff As far as I know, the call to 'mpi_get_secure_buffer(MPI a,unsigned *nbytes,int *sign)' that returns the pointer that will be wiped, also show the size with in 'nbytes'. Then a call like 'wipememory(hash_inp_buf,nbytes)' had the data from a previous call like 'hash_inp_buf=mpi_get_secure_buffer(input,&nbytes,&sign);', isn't it? Only one doubt. In the function 'sha256_hashing()' use two vbles related with this problem: 'byte *hash_inp_buf;' and 'byte hash_out_buf[32];'. The first one, use this call to 'mpi_get_secure_buffer()' does not need it. IMHO I should be enough with 'wipememory(hash_out_buf,32*sizeof(byte));', isn't it? I will wait for your comments /Sergi. A Divendres, 30 de Mar? de 2007 23:19, Sergi Blanch i Torne va escriure: > Hi, > > To day I receive a bug report. The affected functions are not in the > Libgcrypt port. The solution was discussed also to day with Timo, but the > patch is not yet. Sorry, I will do as soon as possible. > > This bad use of the wipememory() function can be found in sha256_hashing() > and aes256_{encrypting,decrypting}() functions. > > Oh, this bug affect also the other branch, the 0.1. > > Thanks Timo > > /Sergi. > > ---------- Missatge reenviat ---------- > > Subject: EccGnuPG Bug Report > Date: Divendres, 30 de Mar? de 2007 13:20 > From: Timo Schulz > To: d4372211 at alumnes.eup.udl.es > > Hi, > > based on your 0.2.0beta1 patch, I'm couldn't find any information > that this problem has been reported before, there is a 'bug' in > the way you use the wipememory function: > > byte *hash_input_buf; > > wipememory( hash_inp_buf, sizeof hash_inp_buf ); > > > actually it should be > wipememory (hash_inp_buf, nbytes); > otherwise only sizeof (unsigned char *) == (4 or 8) > bytes would be overwritten. > > > Timo > > ------------------------------------------------------- > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel