From Zwiebelcode at tormail.org Mon Jul 1 17:19:36 2013 From: Zwiebelcode at tormail.org (Zwiebelcode) Date: Mon, 01 Jul 2013 15:19:36 +0000 Subject: New trust system? Message-ID: <1Utft8-000Iy4-Od@internal.tormail.org> Hello gpg developers, i heard, that some people are working on a new trust system for gpg. I would like to ask if you maybe could give me more details about that. I am interessted in this, because I work on OpenIdent, which wants to be a digital alternative to governmental issued passports. In contrast to governmental systems, the digital passports shall have a higher forgery-protections, a strong pseudonymization and multiple contexts. This will provide high privacy. If you want to read more about that: https://gitorious.org/openident/openident/blobs/master/info.txt Would be nice to hear something about your new trust system. Thanks, Zwiebelcode From wk at gnupg.org Mon Jul 1 21:06:18 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Jul 2013 21:06:18 +0200 Subject: Pageant proxy to gpg-agent In-Reply-To: <1358836384.2678.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 22 Jan 2013 15:33:04 +0900") References: <1358740572.2679.2.camel@cfw2.gniibe.org> <1358752839.30621.3.camel@cfw2.gniibe.org> <87622qrjlh.fsf@vigenere.g10code.de> <1358836384.2678.2.camel@cfw2.gniibe.org> Message-ID: <87k3la6qxh.fsf@vigenere.g10code.de> On Tue, 22 Jan 2013 07:33, gniibe at fsij.org said: >> Are we talkig about 2.0 or 2.1? While supporting ECC in 2.1, I fixed a >> couple of flaws. > > I was talking about GnuPG 2.0.17 on Windows. I am using GPG4Win > (2.1.1 beta). > > I think that it's good to backport the changes from 2.1 to 2.0. I just back ported the ssh changed to 2.0. This will also give ecdsa support in 2.0.21. I had to do this back port to start working on integrated pageant support. > Today, I did an experiment for SSH-agent-proxy (against Cygwin > OpenSSH), and it worked for me. Thanks for figuring out the details. > I think that the support of Cygwin Unix Domain socket can be > implemented as an enhancement of libassuan. Perhaps, it's just adding > a flag (or functions) to support Cygwin compatible AF_LOCAL socket. We can eventually do that in 2.1.x. For now support for putty is on my short list. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeanjacquesbrucker at gmail.com Tue Jul 2 14:55:52 2013 From: jeanjacquesbrucker at gmail.com (jbar) Date: Tue, 2 Jul 2013 14:55:52 +0200 Subject: New trust system? In-Reply-To: <1Utft8-000Iy4-Od@internal.tormail.org> References: <1Utft8-000Iy4-Od@internal.tormail.org> Message-ID: <20130702145552.3d3c63ee@gmail.com> You should also be interested about what we have specified and we already used, to create human based digital currencies. I mind particularly the "udid2" (cf. the comments on my certificate). Specification : https://github.com/Open-UDC/open-udc/blob/master/docs/OpenUDC_Authentication_Mechanisms.draft.txt Our web portal : http://www.openudc.org/ On Mon, 01 Jul 2013 15:19:36 +0000 Zwiebelcode wrote: > Hello gpg developers, > > i heard, that some people are working on a new trust system for gpg. I > would like to ask if you maybe could give me more details about that. > > I am interessted in this, because I work on OpenIdent, which wants to be > a digital alternative to governmental issued passports. In contrast to > governmental systems, the digital passports shall have a higher > forgery-protections, a strong pseudonymization and multiple contexts. > This will provide high privacy. > > If you want to read more about that: > https://gitorious.org/openident/openident/blobs/master/info.txt > > Would be nice to hear something about your new trust system. > > Thanks, > Zwiebelcode > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From Zwiebelcode at tormail.org Tue Jul 2 22:07:16 2013 From: Zwiebelcode at tormail.org (Zwiebelcode) Date: Tue, 02 Jul 2013 20:07:16 +0000 Subject: New trust system? In-Reply-To: <20130702145552.3d3c63ee@gmail.com> References: <1Utft8-000Iy4-Od@internal.tormail.org> <20130702145552.3d3c63ee@gmail.com> Message-ID: <1Uu6r5-0007l8-1f@internal.tormail.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the link! it is not exactly what i want to do, but its interessting anyway! Am 02.07.2013 14:55, schrieb jbar: > You should also be interested about what we have specified and we > already used, to create human based digital currencies. > > I mind particularly the "udid2" (cf. the comments on my certificate). > Specification : > https://github.com/Open-UDC/open-udc/blob/master/docs/OpenUDC_Authentication_Mechanisms.draft.txt > > Our web portal : http://www.openudc.org/ > > On Mon, 01 Jul 2013 15:19:36 +0000 > Zwiebelcode wrote: > >> Hello gpg developers, >> >> i heard, that some people are working on a new trust system for gpg. I >> would like to ask if you maybe could give me more details about that. >> >> I am interessted in this, because I work on OpenIdent, which wants to be >> a digital alternative to governmental issued passports. In contrast to >> governmental systems, the digital passports shall have a higher >> forgery-protections, a strong pseudonymization and multiple contexts. >> This will provide high privacy. >> >> If you want to read more about that: >> https://gitorious.org/openident/openident/blobs/master/info.txt >> >> Would be nice to hear something about your new trust system. >> >> Thanks, >> Zwiebelcode >> >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel >> >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJR0zOFAAoJEFCTkZ2uNzgr218H/0obX9Egl9xHVRD3iJsPZ6Yi RjsjkEvm5x9IU8Kw4KtcDu9YtSuUi9KZXFedd3Y5jIjhmc6pmvKuCmn0JK3RHPvZ TZiHklKV7sLuGTfq3NLY2jT3bV8CAAZ+rvL4T4P3KsW7Bqfz1CAdmL2GOk1TK2Tg Kw+wq56KG0vCiljP0oP+R1PmMI3xOWNztFWeIX0n40jlJRySc8Cs2SeuQMnbX+v7 mks8peghw7ZIwr+kGldgyR8E78WYp3iwsMXIopQ2qCAv6OR6e3Sa+hQiy7RYbPD1 weE+o5l7Mox5dVNqwOLwoxHjq3UsvUXIIFLzSF/yMsws7ABcUZ+anLgzT5UKB3w= =WNj1 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jul 3 00:32:50 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2013 00:32:50 +0200 Subject: Pageant proxy to gpg-agent In-Reply-To: <87k3la6qxh.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 01 Jul 2013 21:06:18 +0200") References: <1358740572.2679.2.camel@cfw2.gniibe.org> <1358752839.30621.3.camel@cfw2.gniibe.org> <87622qrjlh.fsf@vigenere.g10code.de> <1358836384.2678.2.camel@cfw2.gniibe.org> <87k3la6qxh.fsf@vigenere.g10code.de> Message-ID: <8738rw7fu5.fsf@vigenere.g10code.de> On Mon, 1 Jul 2013 21:06, wk at gnupg.org said: > We can eventually do that in 2.1.x. For now support for putty is on my > short list. Just did the first successful test with the new code. I'll push it later the day. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Jul 3 03:02:01 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 03 Jul 2013 10:02:01 +0900 Subject: Popup_message_stop In-Reply-To: <1360647468.7158.5.camel@cfw2.gniibe.org> References: <1358219182.2667.8.camel@cfw2.gniibe.org> <1359001349.5224.4.camel@cfw2.gniibe.org> <1360647468.7158.5.camel@cfw2.gniibe.org> Message-ID: <1372813321.3324.2.camel@cfw2.gniibe.org> I have a patch to nPth (reproduced below). Do I need to send DCO for nPth change? diff --git a/src/npth-sigev.c b/src/npth-sigev.c index f1271d1..aab977e 100644 --- a/src/npth-sigev.c +++ b/src/npth-sigev.c @@ -126,6 +126,13 @@ npth_sigev_add (int signum) } +static void +restore_sigmask_for_child_process (void) +{ + pthread_sigmask (SIG_SETMASK, &sigev_unblock, NULL); +} + + /* Finish the list of watched signals. This starts to block them, too. */ void @@ -133,6 +140,7 @@ npth_sigev_fini (void) { /* Block the interesting signals. */ pthread_sigmask (SIG_SETMASK, &sigev_block, NULL); + pthread_atfork (NULL, NULL, restore_sigmask_for_child_process); } -- From gniibe at fsij.org Wed Jul 3 04:10:31 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 03 Jul 2013 11:10:31 +0900 Subject: PUBKEY_USAGE_AUTH Message-ID: <1372817431.3324.4.camel@cfw2.gniibe.org> Hello, I'm currently considering using WebPG for authentication in web application. With Gnuk Token, I have been using a subkey for authentication, that is, a subkey with PUBKEY_USAGE_AUTH flag. But I only use it through gpg-agent for SSH-agent service and Scute for X.509 client certificate authentication. It seems for me that there is no way by gpg frontend or GPGME to use authentication subkey. Does it make sense to add an option like --auth to enable using authkey for --sign or --clearsign? Or some flag to enable gpgme_op_sign using authkey? I know that we can use gpg-connect-agent and PKSIGN. I want somewhat public API for authentication subkey. -- From wk at gnupg.org Wed Jul 3 09:13:26 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2013 09:13:26 +0200 Subject: Popup_message_stop In-Reply-To: <1372813321.3324.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 03 Jul 2013 10:02:01 +0900") References: <1358219182.2667.8.camel@cfw2.gniibe.org> <1359001349.5224.4.camel@cfw2.gniibe.org> <1360647468.7158.5.camel@cfw2.gniibe.org> <1372813321.3324.2.camel@cfw2.gniibe.org> Message-ID: <87ppv05d61.fsf@vigenere.g10code.de> On Wed, 3 Jul 2013 03:02, gniibe at fsij.org said: > I have a patch to nPth (reproduced below). > > Do I need to send DCO for nPth change? No. Go ahead. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From isis at patternsinthevoid.net Wed Jul 3 16:50:48 2013 From: isis at patternsinthevoid.net (isis agora lovecruft) Date: Wed, 3 Jul 2013 14:50:48 +0000 Subject: gnupg-1.1.7, a Python GnuPG wrapper, is released on PyPI Message-ID: <20130703145048.GF13918@patternsinthevoid.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Announcing the release of a more secure Python wrapper for GnuPG on PyPI. About this release - ------------------ This is the first stable release of a module (named 'gnupg' on PyPI)[0], which originated as a fork of python-gnupg.[1] Several problems were found with the upstream version, including a security vulnerability triggered by unvalidated user input, and when used within networked code, can lead to remote arbitrary code execution. Full notes of the audit can be found in the docs/ directory of the git repo [2] and as orgmode?html [3] in the online documentation. The new version [4] is incompatible with the old version, though the changes required to upgrade for software depending on the old version should be slight. Not to mention, the module is now extensively documented,[5] and developed openly. It was downloaded nearly 1000 times on the first day it was uploaded to PyPI. To install: $ [sudo] pip install gnupg References: [0]: https://pypi.python.org/gnupg/ [1]: https://code.google.com/p/python-gnupg/ [2]: https://github.com/isislovecruft/python-gnupg/raw/master/docs/NOTES-python-gnupg-3.1-audit.org [3]: http://pythonhosted.org/gnupg/NOTES-python-gnupg-3.1-audit.html [4]: https://github.com/isislovecruft/python-gnupg/ [5]: https://pythonhosted.org/gnupg/ - -- ?? isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt -----BEGIN PGP SIGNATURE----- iQJuBAEBCgBYBQJR1DpIBYMB4TOASxSAAAAAABoAKGlzaXNAcGF0dGVybnNpbnRo ZXZvaWQubmV0MEE2QTU4QTE0QjU5NDZBQkRFMThFMjA3QTNBREI2N0EyQ0RCOEIz NQAKCRCjrbZ6LNuLNafeEACH23ZjAHyx0a42db8AKo9cpHMur5YH0CtICp3h8z80 CAWMyFSOOK87Dpzx7kWhyXcWIu55LBFGnW8iQyeLMnAmgtpEXuGV47lCpcuwMGmU lsyRY0UBcp1j38uiyc0RHbvdZxY18mG4UgX1dmCnO1ehYdGc7kbMgvcmPdNZWErJ pDLtxO1+8BZwoYEr0ngSJ+p26IaOmaAaKG4/iuGQ7ac9P8w5CPr4k4rNme4u/yvO pn29syvCfo6FDcb5j4SOpJWwLbH1mo5xry6KUJflVLHx779q3sDcz3M9wX4pSeOn RISeo5TcXAca6YZLlMbArAsy/dYjW5bINCkTo4S7zY1VsaeN1uAH6NC9T1BqI+e+ 7APD6DD6/qN0Tjv6rT3TZKugFyFtwn98HZxA78kFWZJQbG6SzzgEvfph7pTgm8Tm EavrXex6LQvY6C93yoSoicoBoIZuCXJ7SmkMvf9GJRfDcj9dLM8DVxb0VkclUaKr AaHAFcdjIZ+CZHOukSHmRhrNKNa+FUnAyIrxcfcDU5gsqpOoLgWwWuFrkHICQMyQ PYkMQ0Dh/xhEA5P1tChX1taxOAVJCIWLhQGFaXLWqPM85a+TC2p0GpRga4oKzdUJ ZFB8hBM5T83614iQ8E5FjA6BvryksfVWoe0TW/212C+zeDOXiQl3LdXjnrtfP1cU bQ== =SfHT -----END PGP SIGNATURE----- From alphazo at gmail.com Wed Jul 3 18:40:59 2013 From: alphazo at gmail.com (Alphazo) Date: Wed, 3 Jul 2013 18:40:59 +0200 Subject: smartcard stub not imported when migrating to gnupg 2.1 Message-ID: Hi, I'm running 2.1.0-beta220 and try to import my key to the new keychain. Here is how my key is defined: - One master key for signing with private key material not present - One subkey for signing protected by passphrase - One subkey for encryption with private key material stored on a cryptostick therefore there is a stub here. I plugged in the CryptoStick and the issued the followed command: # gpg --import ~/.gnupg/secring.gpg I only got prompted for the passphrase for the signing key. Then when I list the private keys I can see them all with a (#) showing that the private key material is not there. gpg --list-secret-keys gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! /home/alpha/.gnupg/pubring.gpg ------------------------------ sec# 4096R/C23D45E6 2010-11-07 uid Test Key ssb 3072R/4BC5DE67 2010-11-07 [expire : 2014-11-03] ssb# 3072R/A45B67C8 2010-11-07 [expire : 2014-11-03] However when trying to decrypt gnupg returns that there is no private key available for this key. It doesn't aks for the cryptostick as well. I also used the --edit-key and then 'toggle' to see the stub but couldn't see it. Is there a way to transfer a stub over from the previous secring.gpg to the new private key storage? Thanks Alphazo BTW, gpg --card-status works fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Jul 4 04:51:45 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 04 Jul 2013 11:51:45 +0900 Subject: Popup_message_stop In-Reply-To: <87ppv05d61.fsf@vigenere.g10code.de> References: <1358219182.2667.8.camel@cfw2.gniibe.org> <1359001349.5224.4.camel@cfw2.gniibe.org> <1360647468.7158.5.camel@cfw2.gniibe.org> <1372813321.3324.2.camel@cfw2.gniibe.org> <87ppv05d61.fsf@vigenere.g10code.de> Message-ID: <1372906305.3163.2.camel@cfw2.gniibe.org> On 2013-07-03 at 09:13 +0200, Werner Koch wrote: > On Wed, 3 Jul 2013 03:02, gniibe at fsij.org said: > > I have a patch to nPth (reproduced below). > > > > Do I need to send DCO for nPth change? > > No. Go ahead. Thanks. Committed and pushed. -- From gniibe at fsij.org Thu Jul 4 05:41:53 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 04 Jul 2013 12:41:53 +0900 Subject: agent: fix for UPDATESTARTUPTTY Message-ID: <1372909313.3163.4.camel@cfw2.gniibe.org> In 2.0.20, I found that: $ gpg-connect-agent updatestartuptty /bye doesn't work. There are two problems for me. (1) When I want to use pinentry for nterminal, there is no way, if I already have gpg-agent with DISPLAY. (2) UPDATESTARTUPTTY doesn't work to switch TTY for pinentry for SSH. For (1), I think that we need to implement something to negate X Window System. Latter is simply a bug. Current implementation: In the function start_command_handler_ssh, the logic puts priority on ctrl->session_env which is initialized by agent_init_default_ctrl. There are always GPG_TTY and TERM defined, because lines around 968 in gpg-agent.c, it says: /* Make sure that we have a default ttyname. */ While UPDATESTARTUPTTY updates opt.startup_env, it doesn't affect at all. Here is a patch to point the issue. Tested and works for me. diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 2f96ef5..6009956 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -3025,8 +3025,7 @@ start_command_handler_ssh (ctrl_t ctrl, gnupg_fd_t sock_client) const char *value; for (idx=0; !err && names[idx]; idx++) - if (!session_env_getenv (ctrl->session_env, names[idx]) - && (value = session_env_getenv (opt.startup_env, names[idx]))) + if ((value = session_env_getenv (opt.startup_env, names[idx]))) err = session_env_setenv (ctrl->session_env, names[idx], value); if (!err && !ctrl->lc_ctype && opt.startup_lc_ctype) -- From bernhard at intevation.de Fri Jul 5 09:30:48 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 5 Jul 2013 09:30:48 +0200 Subject: gnupg-1.1.7, a Python GnuPG wrapper, is released on PyPI In-Reply-To: <20130703145048.GF13918@patternsinthevoid.net> References: <20130703145048.GF13918@patternsinthevoid.net> Message-ID: <201307050930.49798.bernhard@intevation.de> On Wednesday 03 July 2013 at 16:50:48, isis agora lovecruft wrote: > This is the first stable release of a module (named 'gnupg' on PyPI)[0], > which originated as a fork of python-gnupg.[1] What is the difference to pyme and pygpgme? (And if "gnupg" does not use the recommended way of accessing gnupg via gpgme, what is the rationale for it?) -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From daniele.athome at gmail.com Fri Jul 5 16:39:35 2013 From: daniele.athome at gmail.com (Daniele Ricci) Date: Fri, 5 Jul 2013 16:39:35 +0200 Subject: Decrypting with ECDH: no secret key In-Reply-To: References: <87wqpgg9t1.fsf@vigenere.g10code.de> <87k3lgg6gf.fsf@vigenere.g10code.de> Message-ID: Hi, any news on this? I tried to analyze the log but it seems everything is just fine... just a few "XXX byte(s) skipped" but I really don't know if that should be a problem. Please note that this test was done from the latest git version (at that date). Many thanks On Sat, Jun 29, 2013 at 12:26 PM, Daniele Ricci wrote: > Hi, > I was using the beta3 tarball. Shouldn't I? > > Anyway just to be sure I just cloned gnupg from git and tried the same > tests. Same error :-( > Log is attached. > If you need more tests/data (e.g. a trace of some kind) just tell me. > > > On Wed, Jun 26, 2013 at 6:52 PM, Werner Koch wrote: >> On Wed, 26 Jun 2013 18:07, daniele.athome at gmail.com said: >> >>> However, if I try to export it, gpg2 outputs the key "correctly", >>> without the subkey, printing this warning: >>> gpg: key F08342D6/0AF4E702: error receiving key from agent: Bad secret >>> key - skipped >> >> Are you using the old beta tarball or a build from master? If the >> latetr it would be good to see the log output from all tools: Add >> >> log-file socket:///foo/bar/S.log >> debug 1024 >> verbose >> >> to gpg-agent.conf and gpg.conf. Then run >> >> watchgnupg --time-only --force /foo/bar/S.log | tee gnupg.log >> >> on another tty. >> >>> When re-importing the exported secret key in another keyring, the same >>> issue: hash mark after ssb. >> >> Yes, because the subkey is missing but the public key is available and >> has a corresponding private primary key. >> >>> gpg-agent was started in a custom environment (--homedir) and >>> GNUPGHOME set accordingly. >> >> An easy way to debug this is to use >> >> GNUPGHOME=$(pwd) gpg-agent --daemon /bin/bash >> >> in a test directory und use this shell for all tests. >> >>> By the way: I don't know if it's normal, pinentry asked me the key >>> password twice during the export. >> >> Should not as long as the primart key and the subkeys alluse the same >> passphrase. >> >> >> Shalom-Salam, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> > > > > -- > Daniele -- Daniele From thorsten.sick at email.de Mon Jul 8 18:05:21 2013 From: thorsten.sick at email.de (Thorsten Sick) Date: Mon, 08 Jul 2013 18:05:21 +0200 Subject: Passphrase in addition to Fingerprint Message-ID: <1373299521.4742.21.camel@legion> Hello The normal Fingerprint is hard to remember and must be exchanged using a printed out version. It would be cool to also have an easy to remember fingerprint phrase calculated out of the Fingerprint. "twenty annoying green elephants dance in china" Where a small change in the fingerprint changes the whole phrase and the sentence has at least some natural structure. To achieve that use bulding blocks with word lists. So the "twenty annoying" is from a long list also containing "two hundred", "2 drunken", ... The sentence could split like that into building blocks: "twenty annoying| green| elephants| dance| in china" People should be able to remeber their "passphrase" and when meeting they jsut could ask "what was you phrase again" "five aggressive penguins attack harmless hamsters" ? See this bug at: https://sourceforge.net/p/enigmail/bugs/152/ Thanks Thorsten Sick From dkg at fifthhorseman.net Mon Jul 8 19:07:04 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 08 Jul 2013 13:07:04 -0400 Subject: Passphrase in addition to Fingerprint In-Reply-To: <1373299521.4742.21.camel@legion> References: <1373299521.4742.21.camel@legion> Message-ID: <51DAF1B8.8030501@fifthhorseman.net> On 07/08/2013 12:05 PM, Thorsten Sick wrote: > The normal Fingerprint is hard to remember and must be exchanged using a > printed out version. It would be cool to also have an easy to remember > fingerprint phrase calculated out of the Fingerprint. > > "twenty annoying green elephants dance in china" > > Where a small change in the fingerprint changes the whole phrase and the > sentence has at least some natural structure. To achieve that use > bulding blocks with word lists. So the "twenty annoying" is from a long > list also containing "two hundred", "2 drunken", ... > The sentence could split like that into building blocks: > "twenty annoying| green| elephants| dance| in china" > > People should be able to remeber their "passphrase" and when meeting > they jsut could ask "what was you phrase again" "five aggressive > penguins attack harmless hamsters" ? > > See this bug at: > https://sourceforge.net/p/enigmail/bugs/152/ Paul Wise brought this up recently: http://bonedaddy.net/pabs3/log/2013/06/28/openpgp-fingerprint-exchange/ and pointed toward this (older) specification: https://en.wikipedia.org/wiki/PGP_word_list does this match what you're asking about? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Mon Jul 8 22:07:48 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 08 Jul 2013 16:07:48 -0400 Subject: gpgme-android dies when it needs pinentry In-Reply-To: <87zjumrr1z.fsf@vigenere.g10code.de> References: <51C133F8.6000502@guardianproject.info> <87zjumrr1z.fsf@vigenere.g10code.de> Message-ID: <51DB1C14.5020300@guardianproject.info> On 06/19/2013 12:41 PM, Werner Koch wrote: > On Wed, 19 Jun 2013 06:30, hans at guardianproject.info said: > >> But for things like creating a new key, decrypting, signing, etc. gpgme always >> crashes. It does not seem to even try to launch pinentry, because we're not >> seeing and logging from pinentry. Attached in the gpgme log for trying to > > I can't see a gpgme crash for the log. It might be a crash in gpg or > gpg-agent. Can you please check? Having gpg-agent and gpg log files > would also be useful. > >> GPGME 2013-06-19 00:22:03 <0x4227> _gpgme_io_read: enter: fd=0x2b, buffer=0x5c8339b0, count=1024 >> GPGME 2013-06-19 00:22:03 <0x4227> _gpgme_io_read: leave: result=0 > > The first read of the status-fd returns 0, i.e. EOF. That should not > happen. We're working thru all of the various issues here and are finally making good progress. There were a couple different issues happening here, two of which I recently fixed. First, GnuPG-for-Android was making certain gpgme calls in the main UI thread. Those gpgme calls block. pinentry-android launches an Activity, which happens in the UI thread by default. Therefore when a gpgme needed to launch pinentry, gpgme would block waiting for pinentry, and then pinentry could not launch the password prompt because the gpgme call was blocking the UI thread. For generating keys in gpgme, I was giving it the data in the wrong format. Troubleshooting from the command line gave me lots more feedback, and that's now working. I think there are some other lingering issues, but I have to leave them be for now. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From thorsten.sick at email.de Mon Jul 8 23:15:01 2013 From: thorsten.sick at email.de (Thorsten Sick) Date: Mon, 08 Jul 2013 23:15:01 +0200 Subject: Passphrase in addition to Fingerprint In-Reply-To: <51DAF1B8.8030501@fifthhorseman.net> References: <1373299521.4742.21.camel@legion> <51DAF1B8.8030501@fifthhorseman.net> Message-ID: <1373318101.4896.3.camel@legion> Hi Thanks for finding this idea. It is similar but not the same. The old idea you found is a cool trick for reading out loud the fingerprint. What I want is to create a short phrase that you can not get out of your mind. This is similar to the tricks these memory performers use to remember a phone book. This way I can verify the keys of my friends just be meeting them on the streets without business cards. Also good for phone verification. Disadvantage could be the small "key space". But even if it is worse than the fingerprint verification, it is lots better than nothing. Thorsten Sick Am Montag, den 08.07.2013, 13:07 -0400 schrieb Daniel Kahn Gillmor: > On 07/08/2013 12:05 PM, Thorsten Sick wrote: > > The normal Fingerprint is hard to remember and must be exchanged using a > > printed out version. It would be cool to also have an easy to remember > > fingerprint phrase calculated out of the Fingerprint. > > > > "twenty annoying green elephants dance in china" > > > > Where a small change in the fingerprint changes the whole phrase and the > > sentence has at least some natural structure. To achieve that use > > bulding blocks with word lists. So the "twenty annoying" is from a long > > list also containing "two hundred", "2 drunken", ... > > The sentence could split like that into building blocks: > > "twenty annoying| green| elephants| dance| in china" > > > > People should be able to remeber their "passphrase" and when meeting > > they jsut could ask "what was you phrase again" "five aggressive > > penguins attack harmless hamsters" ? > > > > See this bug at: > > https://sourceforge.net/p/enigmail/bugs/152/ > > Paul Wise brought this up recently: > > http://bonedaddy.net/pabs3/log/2013/06/28/openpgp-fingerprint-exchange/ > > and pointed toward this (older) specification: > > https://en.wikipedia.org/wiki/PGP_word_list > > does this match what you're asking about? > > --dkg > From dkg at fifthhorseman.net Tue Jul 9 17:08:41 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 09 Jul 2013 11:08:41 -0400 Subject: Passphrase in addition to Fingerprint In-Reply-To: <1373318101.4896.3.camel@legion> References: <1373299521.4742.21.camel@legion> <51DAF1B8.8030501@fifthhorseman.net> <1373318101.4896.3.camel@legion> Message-ID: <51DC2779.2050406@fifthhorseman.net> On 07/08/2013 05:15 PM, Thorsten Sick wrote: > Thanks for finding this idea. It is similar but not the same. The old > idea you found is a cool trick for reading out loud the fingerprint. > > What I want is to create a short phrase that you can not get out of your > mind. This is similar to the tricks these memory performers use to > remember a phone book. > > This way I can verify the keys of my friends just be meeting them on the > streets without business cards. > > Also good for phone verification. > > Disadvantage could be the small "key space". But even if it is worse > than the fingerprint verification, it is lots better than nothing. If you're talking about actually making a phrase that has significantly less entropy and encouraging people to use that in place of a fingerprint, i think that's a bad idea. It's bad enough that many people seem to think that their 8-character "short keyid" (the last 4 octets of their fingerprint) is a strong identifier; it's not -- it takes an hour or so on cheap consumer hardware to find a colliding short keyid). We shouldn't be introducing new weak identifiers to a system that actually needs strong identifiers. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From thorsten.sick at email.de Tue Jul 9 19:11:28 2013 From: thorsten.sick at email.de (Thorsten Sick) Date: Tue, 09 Jul 2013 19:11:28 +0200 Subject: Passphrase in addition to Fingerprint In-Reply-To: <51DC2779.2050406@fifthhorseman.net> References: <1373299521.4742.21.camel@legion> <51DAF1B8.8030501@fifthhorseman.net> <1373318101.4896.3.camel@legion> <51DC2779.2050406@fifthhorseman.net> Message-ID: <1373389888.3732.18.camel@legion> Hi Daniel I am totally aware that the identifier will be weaker. I was having the idea for a GUI, where the keys are marked by a traffic light (red=not verified, yellow=phrase or similar, green = fingerprint verification). I think if the idea rises or lowers security is very dependend on the way we explain to the average user what to expect from the encrypted channel and how to improve it. Clicking on the yellow sign in front of a signature/decrypted mail could tell the user: "Average security. You verified the Phrase. To improve the security, check the fingerprint by meeting the person and asking them if this is the right one". Passphrase verification is better than no verification at all. So, the question for me is: Are there and use cases for end-users where we can not display something like the traffic light indicating good but not perfect verification ? Security estimation: Having a phrase built out of 5 sections, where each section has 100 options in a list it would be 100x100x100x100x100 different phrases = 10,000,000,000 . And I would take more than 100 options. 160 Bit Fingerprint: 1,461501637?10^48 Thorsten Sick Am Dienstag, den 09.07.2013, 11:08 -0400 schrieb Daniel Kahn Gillmor: > On 07/08/2013 05:15 PM, Thorsten Sick wrote: > > Thanks for finding this idea. It is similar but not the same. The old > > idea you found is a cool trick for reading out loud the fingerprint. > > > > What I want is to create a short phrase that you can not get out of your > > mind. This is similar to the tricks these memory performers use to > > remember a phone book. > > > > This way I can verify the keys of my friends just be meeting them on the > > streets without business cards. > > > > Also good for phone verification. > > > > Disadvantage could be the small "key space". But even if it is worse > > than the fingerprint verification, it is lots better than nothing. > > If you're talking about actually making a phrase that has significantly > less entropy and encouraging people to use that in place of a > fingerprint, i think that's a bad idea. It's bad enough that many > people seem to think that their 8-character "short keyid" (the last 4 > octets of their fingerprint) is a strong identifier; it's not -- it > takes an hour or so on cheap consumer hardware to find a colliding short > keyid). > > We shouldn't be introducing new weak identifiers to a system that > actually needs strong identifiers. > > --dkg > > From wk at gnupg.org Tue Jul 9 21:30:12 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jul 2013 21:30:12 +0200 Subject: Passphrase in addition to Fingerprint In-Reply-To: <1373318101.4896.3.camel@legion> (Thorsten Sick's message of "Mon, 08 Jul 2013 23:15:01 +0200") References: <1373299521.4742.21.camel@legion> <51DAF1B8.8030501@fifthhorseman.net> <1373318101.4896.3.camel@legion> Message-ID: <87r4f7wmyj.fsf@vigenere.g10code.de> On Mon, 8 Jul 2013 23:15, thorsten.sick at email.de said: > What I want is to create a short phrase that you can not get out of your > mind. This is similar to the tricks these memory performers use to > remember a phone book. This has been discussed many years ago. Probably in the OpenPGP WG. There are two problems with that approach: - It does only work for one language. - For most languages the use of Non-ASCII characters is required. IIRC, the outcome of the discussion was that a spelling alphabet should be used. The international spelling alphabets have been designed with non-native speakers in mind; there is enough redundancy in the words that the error rate is very low. We only need Alpha..Foxtrott and the somewhat more problematic digits 0..9. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alphazo at gmail.com Tue Jul 9 23:05:07 2013 From: alphazo at gmail.com (Alphazo) Date: Tue, 9 Jul 2013 23:05:07 +0200 Subject: smartcard stub not imported when migrating to gnupg 2.1 In-Reply-To: References: Message-ID: Hi, Can someone give me some instructions on how to efficiently report the issue with the right debugging options ? Thanks Alphazo On Wed, Jul 3, 2013 at 6:40 PM, Alphazo wrote: > Hi, > > I'm running 2.1.0-beta220 and try to import my key to the new keychain. > Here is how my key is defined: > > - One master key for signing with private key material not present > - One subkey for signing protected by passphrase > - One subkey for encryption with private key material stored on a > cryptostick therefore there is a stub here. > > I plugged in the CryptoStick and the issued the followed command: > > # gpg --import ~/.gnupg/secring.gpg > > I only got prompted for the passphrase for the signing key. > > Then when I list the private keys I can see them all with a (#) showing > that the private key material is not there. > > gpg --list-secret-keys > gpg: NOTE: THIS IS A DEVELOPMENT VERSION! > gpg: It is only intended for test purposes and should NOT be > gpg: used in a production environment or with production keys! > /home/alpha/.gnupg/pubring.gpg > ------------------------------ > sec# 4096R/C23D45E6 2010-11-07 > uid Test Key > ssb 3072R/4BC5DE67 2010-11-07 [expire : 2014-11-03] > ssb# 3072R/A45B67C8 2010-11-07 [expire : 2014-11-03] > > However when trying to decrypt gnupg returns that there is no private key > available for this key. It doesn't aks for the cryptostick as well. > > I also used the --edit-key and then 'toggle' to see the stub but couldn't > see it. > > Is there a way to transfer a stub over from the previous secring.gpg to > the new private key storage? > > Thanks > Alphazo > > BTW, gpg --card-status works fine. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jul 10 13:22:46 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jul 2013 13:22:46 +0200 Subject: smartcard stub not imported when migrating to gnupg 2.1 In-Reply-To: (alphazo@gmail.com's message of "Wed, 3 Jul 2013 18:40:59 +0200") References: Message-ID: <874nc2wtfd.fsf@vigenere.g10code.de> On Wed, 3 Jul 2013 18:40, alphazo at gmail.com said: > - One master key for signing with private key material not present > - One subkey for signing protected by passphrase > - One subkey for encryption with private key material stored on a > cryptostick therefore there is a stub here. > I only got prompted for the passphrase for the signing key. Right. This is because there is just one real secret key. > Then when I list the private keys I can see them all with a (#) showing > that the private key material is not there. > sec# 4096R/C23D45E6 2010-11-07 > uid Test Key > ssb 3072R/4BC5DE67 2010-11-07 [expire : 2014-11-03] > ssb# 3072R/A45B67C8 2010-11-07 [expire : 2014-11-03] What I see is that the secret key for 4BC5DE67 is there. That seems to be the signing subkey. > However when trying to decrypt gnupg returns that there is no private key > available for this key. It doesn't aks for the cryptostick as well. What does "gpg2 --card-status" show? Does it list A45B67C8 as the second key of the card? But wait. Checking the code I see that there is indeed something missing: gpg-agent does not know that a smartcard with the given subkey exists. Thus the internal HAVEKEY query send from gpg to the agent can only return "no such key". Thus what we need is a way for gpg to ask gpg-agent to create a stub key if it is missing; we do this with gpgsm but for whatever reason this has not yet been implemented in 2.1. So, please have some more patience; I need to add this for the next beta. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jul 10 13:39:45 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jul 2013 13:39:45 +0200 Subject: smartcard stub not imported when migrating to gnupg 2.1 In-Reply-To: (alphazo@gmail.com's message of "Wed, 3 Jul 2013 18:40:59 +0200") References: Message-ID: <87zjtuve2m.fsf@vigenere.g10code.de> Hi, here is a simple workaround: Insert the card and run gpg-connect-agent learn /bye this creates the stub (here called a shadowed-private-key). After that a "gpg2 -K" should indicate that the decryption is actually available. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alphazo at gmail.com Wed Jul 10 15:07:06 2013 From: alphazo at gmail.com (Alphazo) Date: Wed, 10 Jul 2013 15:07:06 +0200 Subject: smartcard stub not imported when migrating to gnupg 2.1 In-Reply-To: <87zjtuve2m.fsf@vigenere.g10code.de> References: <87zjtuve2m.fsf@vigenere.g10code.de> Message-ID: Hi Werner, Thanks for coming back to me. I'm glad that it helped to highlight an issue. That being said, workaround doesn't seem to work. After issuing gpg-connect-agent learn /bye I got: gpg-connect-agent learn /bye S PROGRESS learncard k 0 0 S PROGRESS learncard k 0 0 OK Then gpg2 -K correctly showed the stub: ------------------------------ sec# 4096R/C23D45E6 2010-11-07 uid Test Key ssb 3072R/4BC5DE67 2010-11-07 [expire : 2014-11-03] ssb 3072R/A45B67C8 2010-11-07 [expire : 2014-11-03] Then I tried to decrypt a file encrypted with the 0xA45B67C8 key. I got prompted for the PIN that I correctly entered but file refused to decrypt: gpg: encrypted with 3072-bit RSA key, ID A45B67C8, created 2010-11-07 "Test Key" " gpg: public key decryption failed: Wrong secret key used gpg: decryption failed: No secret key Thanks Dany On Wed, Jul 10, 2013 at 1:39 PM, Werner Koch wrote: > Hi, > > here is a simple workaround: > > Insert the card and run > > gpg-connect-agent learn /bye > > this creates the stub (here called a shadowed-private-key). After that > a "gpg2 -K" should indicate that the decryption is actually available. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jul 10 15:38:36 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jul 2013 15:38:36 +0200 Subject: smartcard stub not imported when migrating to gnupg 2.1 In-Reply-To: (alphazo@gmail.com's message of "Wed, 10 Jul 2013 15:07:06 +0200") References: <87zjtuve2m.fsf@vigenere.g10code.de> Message-ID: <87fvvmv8kj.fsf@vigenere.g10code.de> On Wed, 10 Jul 2013 15:07, alphazo at gmail.com said: > gpg: encrypted with 3072-bit RSA key, ID A45B67C8, created 2010-11-07 > "Test Key" " > gpg: public key decryption failed: Wrong secret key used > gpg: decryption failed: No secret key I need to look closer at it. Please give me a few days. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Jul 12 17:49:00 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Jul 2013 11:49:00 -0400 Subject: gpg 1.4.x and 2.0.x differ in output with --with-colons --check-sigs Message-ID: <87bo67dbir.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- It looks to me like gpg and gpg2 differ in output when using --with-colons --check-sigs: 0 dkg at alice:~$ diff -u <(gpg --check-sigs --with-colons ssh://che.mayfirst.org) <(gpg2 --check-sigs --with-colons ssh://che.mayfirst.org) --- /dev/fd/63 2013-07-12 11:38:20.492341784 -0400 +++ /dev/fd/62 2013-07-12 11:38:20.492341784 -0400 @@ -1,5 +1,5 @@ tru::1:1373556281:1373770620:3:1:5 pub:f:2048:1:6D55BC121C106C76:1267149023:::-:::caCA: uid:f::::1267149023::FA9BB45DEC38693028E39E41D8BDD5A9D6234406::ssh\x3a//che.mayfirst.org: -sig:!::1:6D55BC121C106C76:1267149023::::ssh\x3a//che.mayfirst.org:13x: -sig:!::1:CCD2ED94D21739E9:1267149081::::Daniel Kahn Gillmor :10x: +sig:!::1:6D55BC121C106C76:1267149023::::ssh\x3a//che.mayfirst.org:13x:::::8: +sig:!::1:CCD2ED94D21739E9:1267149081::::Daniel Kahn Gillmor :10x:::::10: 1 dkg at alice:~$ in particular, gpg 2.0.20 supplies field 16 for the sig lines, which (according to DETAILS) is the hash algorithm of the signature, but gpg 1.4.12 does not. (8 is SHA-256, 10 is SHA-512). Is this an intentional difference? Is there any reason to avoid having 1.4.x produce this field as well? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From benjamin at py-soft.co.uk Fri Jul 12 19:04:16 2013 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Fri, 12 Jul 2013 18:04:16 +0100 Subject: OpenPGPv5 wish list In-Reply-To: <20130429111532.7e53c7f6@gmail.com> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50D0AB16.5020505@brainhub.org> <2584059.Q9cNNqxsta@inno> <517E0250.1040708@sixdemonbag.org> <20130429111532.7e53c7f6@gmail.com> Message-ID: On 29 April 2013 10:15, Jean-Jacques wrote: > > OpenPGP list is for discussion of how to make the standard itself > > better. > > Yep, so I switched the thread to the other mailing list. > So no need to bcc gnupg-devel at gnupg.org! Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From infinity0 at gmx.com Sat Jul 13 11:39:13 2013 From: infinity0 at gmx.com (Ximin Luo) Date: Sat, 13 Jul 2013 10:39:13 +0100 Subject: phrase "UNTRUSTED good signature" is dangerously misleading Message-ID: <51E12041.3000300@gmx.com> Hello guys, I was an instructor at the Cryptoparty at London Hackspace a few days ago. Another instructor was doing email encryption using Enigmail + GPG. When we got to the part where we receive an email signed by a key which has not yet been verified by a trusted key, GPG outputs the familiar phrase "UNTRUSTED Good signature". Now previously, I didn't think too much of this, since I understand the model of PGP. However, the other instructor in the session told people that in order to make the "UNTRUSTED" go away, you simply set the ownertrust to "full" via the Enigmail interface. This is, of course, the ENTIRELY wrong thing to do. What people should do, and I corrected this later, is (either face-to-face or over a previously verified channel) verify each other's fingerprints, and sign each other's keys. But without a technical understanding of PGP, his suggestion was very reasonable: - the interface has a warning about "UNTRUSTED" - the interface provides a way to set "trust" (actually ownertrust but it doesn't mention the term I guess to "not confuse" the user) - doing this makes the previous warning go away This stems from the concept of "trust" in PGP (= belief that someone else signs certificates honestly and correctly), which is much more specific than the broad concept in English. So one must be careful when using the word "trust" in the UI, not to mix up the two use cases. Whilst technically correct, "UNTRUSTED" is not the main point when you are verifying signatures. The main point is to ensure the key is verified to actually belong to the correct person. So I would suggest rephrasing the warning to something like - "UNVERIFIED Good signature", or - "Good signature from an UNVERIFIED KEY" X -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sat Jul 13 18:36:03 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 13 Jul 2013 12:36:03 -0400 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <51E12041.3000300@gmx.com> References: <51E12041.3000300@gmx.com> Message-ID: <51E181F3.3070604@fifthhorseman.net> On 07/13/2013 05:39 AM, Ximin Luo wrote: > When we got to the part where we receive an email signed by a key which has not > yet been verified by a trusted key, GPG outputs the familiar phrase "UNTRUSTED > Good signature". Now previously, I didn't think too much of this, since I > understand the model of PGP. However, the other instructor in the session told > people that in order to make the "UNTRUSTED" go away, you simply set the > ownertrust to "full" via the Enigmail interface. > > This is, of course, the ENTIRELY wrong thing to do. What people should do, and > I corrected this later, is (either face-to-face or over a previously verified > channel) verify each other's fingerprints, and sign each other's keys. i've seen this exact same mistake made by at least two other people who were well-intentioned and somewhat knowledgeable. when i pointed out the problem with that approach privately (that it was equivalent to adding a new root CA to your browser's X.509 trust chain), one of them was so frustrated by the confusion, and dismayed that they may have led people astray in the past, that they wanted to stop using GnuPG (and therefore OpenPGP) altogether, calling it "too dangerous". While this last might seem a bit like an overreaction, i think the dismay is understandable, coming from someone who is actively trying to help people improve their secure communications. > But without a technical understanding of PGP, his suggestion was very reasonable: > > - the interface has a warning about "UNTRUSTED" > - the interface provides a way to set "trust" (actually ownertrust but it > doesn't mention the term I guess to "not confuse" the user) > - doing this makes the previous warning go away > > This stems from the concept of "trust" in PGP (= belief that someone else signs > certificates honestly and correctly), which is much more specific than the > broad concept in English. So one must be careful when using the word "trust" in > the UI, not to mix up the two use cases. > > Whilst technically correct, "UNTRUSTED" is not the main point when you are > verifying signatures. The main point is to ensure the key is verified to > actually belong to the correct person. So I would suggest rephrasing the > warning to something like > > - "UNVERIFIED Good signature", or > - "Good signature from an UNVERIFIED KEY" I think a change like this is a good idea. If the tool itself can't clearly separate the concept of "ownertrust" from "verified" or "valid" keys, then most users will have little chance of sorting out the distinction themselves. I believe the enigmail authors are already open to patch submissions to clarify the distinction between ownertrust and validity, fwiw. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From infinity0 at gmx.com Sat Jul 13 18:51:03 2013 From: infinity0 at gmx.com (Ximin Luo) Date: Sat, 13 Jul 2013 17:51:03 +0100 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <51E181F3.3070604@fifthhorseman.net> References: <51E12041.3000300@gmx.com> <51E181F3.3070604@fifthhorseman.net> Message-ID: <51E18577.9040603@gmx.com> On 13/07/13 17:36, Daniel Kahn Gillmor wrote: > On 07/13/2013 05:39 AM, Ximin Luo wrote: >> When we got to the part where we receive an email signed by a key which has not >> yet been verified by a trusted key, GPG outputs the familiar phrase "UNTRUSTED >> Good signature". Now previously, I didn't think too much of this, since I >> understand the model of PGP. However, the other instructor in the session told >> people that in order to make the "UNTRUSTED" go away, you simply set the >> ownertrust to "full" via the Enigmail interface. >> >> This is, of course, the ENTIRELY wrong thing to do. What people should do, and >> I corrected this later, is (either face-to-face or over a previously verified >> channel) verify each other's fingerprints, and sign each other's keys. > > i've seen this exact same mistake made by at least two other people who > were well-intentioned and somewhat knowledgeable. when i pointed out > the problem with that approach privately (that it was equivalent to > adding a new root CA to your browser's X.509 trust chain), one of them > was so frustrated by the confusion, and dismayed that they may have led > people astray in the past, that they wanted to stop using GnuPG (and > therefore OpenPGP) altogether, calling it "too dangerous". > > While this last might seem a bit like an overreaction, i think the > dismay is understandable, coming from someone who is actively trying to > help people improve their secure communications. > >> But without a technical understanding of PGP, his suggestion was very reasonable: >> >> - the interface has a warning about "UNTRUSTED" >> - the interface provides a way to set "trust" (actually ownertrust but it >> doesn't mention the term I guess to "not confuse" the user) >> - doing this makes the previous warning go away >> >> This stems from the concept of "trust" in PGP (= belief that someone else signs >> certificates honestly and correctly), which is much more specific than the >> broad concept in English. So one must be careful when using the word "trust" in >> the UI, not to mix up the two use cases. >> >> Whilst technically correct, "UNTRUSTED" is not the main point when you are >> verifying signatures. The main point is to ensure the key is verified to >> actually belong to the correct person. So I would suggest rephrasing the >> warning to something like >> >> - "UNVERIFIED Good signature", or >> - "Good signature from an UNVERIFIED KEY" > > I think a change like this is a good idea. If the tool itself can't > clearly separate the concept of "ownertrust" from "verified" or "valid" > keys, then most users will have little chance of sorting out the > distinction themselves. > I just realised that "UNVERIFIED Good signature" might be confusing too, because the signature is verified but the key isn't. Perhaps we should say "UNVALIDATED" instead, and this would be consistent with the PGP docs' use of the word "validity" to refer to a key that has been validated/verified to belong to its claimed owners. Another thing the interface can do is pop up a big massive warning when people try to set ownertrust on keys that haven't been validated by an already-trusted key. > I believe the enigmail authors are already open to patch submissions to > clarify the distinction between ownertrust and validity, fwiw. > > --dkg > -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Sat Jul 13 19:01:32 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 13 Jul 2013 19:01:32 +0200 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <51E181F3.3070604@fifthhorseman.net> References: <51E12041.3000300@gmx.com> <51E181F3.3070604@fifthhorseman.net> Message-ID: <7085142.jy8auBHj4k@inno.berlin.laging.de> Am Sa 13.07.2013, 12:36:03 schrieb Daniel Kahn Gillmor: > i've seen this exact same mistake made by at least two other people who > were well-intentioned and somewhat knowledgeable. I believe the wording is a problem; I may have mentioned that here before. The term "trust" confuses more or less everyone (once I even found a mix up in the GnuPG docs...). It should simply be forbidden to use the term "trust" at all. "owner trust" is not better as this is not about the owner but about the key. I suggest to call this either "certification trust" or (getting rid of "trust" completely) "certification value", "certification quality" or the like. I would also prefer not to use "marginal" and "complete" in both contexts. Maybe validity classes can be called "none", "not enough", and "enough". Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From ekleog at gmail.com Sat Jul 13 20:22:23 2013 From: ekleog at gmail.com (Leo Gaspard) Date: Sat, 13 Jul 2013 20:22:23 +0200 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <51E18577.9040603@gmx.com> References: <51E12041.3000300@gmx.com> <51E181F3.3070604@fifthhorseman.net> <51E18577.9040603@gmx.com> Message-ID: <20130713182223.GA750@leortable> On Sat, Jul 13, 2013 at 05:51:03PM +0100, Ximin Luo wrote: > I just realised that "UNVERIFIED Good signature" might be confusing too, > because the signature is verified but the key isn't. > > Perhaps we should say "UNVALIDATED" instead, and this would be consistent with > the PGP docs' use of the word "validity" to refer to a key that has been > validated/verified to belong to its claimed owners. Just to say that, IMHO, even the "good" signature is misleading. Maybe am I wrong, but I believe it means too much "this signature is OK". Maybe just "UNVALIDATED signature" ? Yet I'm not at all familiar with GnuPG warnings, so... Cheers, Leo From rjh at sixdemonbag.org Sun Jul 14 06:01:48 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 14 Jul 2013 00:01:48 -0400 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <51E181F3.3070604@fifthhorseman.net> References: <51E12041.3000300@gmx.com> <51E181F3.3070604@fifthhorseman.net> Message-ID: <51E222AC.1030105@sixdemonbag.org> On 07/13/2013 12:36 PM, Daniel Kahn Gillmor wrote: > I believe the enigmail authors are already open to patch submissions > to clarify the distinction between ownertrust and validity, fwiw. While patches are always welcome, I think I can say (as the UI nerd for Enigmail) that these patches are exceedingly unlikely to be implemented. Enigmail's policy is that our messages must mirror GnuPG's messages. That way users don't have to learn two separate sets of terminology. If you want this to happen, the proper way to go forward is to convince the GnuPG developers to change the way GnuPG talks about ownertrust, good signatures versus verified signatures, and so on. If GnuPG makes those changes we will likely mirror them in short order, but for right now Enigmail has no interest in deviating from GnuPG's messages. (That said, I agree the good/verified, trust/ownertrust, etc., concepts are all wrapped up in some thoroughly incomprehensible language.) From wk at gnupg.org Sun Jul 14 09:40:56 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 14 Jul 2013 09:40:56 +0200 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <51E222AC.1030105@sixdemonbag.org> (Robert J. Hansen's message of "Sun, 14 Jul 2013 00:01:48 -0400") References: <51E12041.3000300@gmx.com> <51E181F3.3070604@fifthhorseman.net> <51E222AC.1030105@sixdemonbag.org> Message-ID: <87r4f1pp13.fsf@vigenere.g10code.de> On Sun, 14 Jul 2013 06:01, rjh at sixdemonbag.org said: > If you want this to happen, the proper way to go forward is to convince > the GnuPG developers to change the way GnuPG talks about ownertrust, > good signatures versus verified signatures, and so on. If GnuPG makes We already did this many years ago. Actually I can't find the phrase the OP complained about. Here is an example checking a signature using a different account. The key has been freshly imported: gpg: Signature made Thu Dec 20 20:48:35 2012 CET using RSA key ID 4F25E3B6 gpg: Good signature from "Werner Koch (dist sig)" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 It seems that Enigmail creates the string. Looking at the output of GPA gives: |4F25E386|Key NOT valid|Werner Koch (dist sig)|Uncertain signature ...| [orange] If the key is valid (trusted), it would be |4F25E386|valid|Werner Koch (dist sig)|Good signature ...| [green] GPA uses the GPGME library which provides the needed information. Thus the code is pretty simple: if (data->summary & GPGME_SIGSUM_VALID) { text = _("Valid"); color = "green"; } else if (data->summary & GPGME_SIGSUM_RED) { text = _("Bad"); color = "red"; } else if (data->summary & GPGME_SIGSUM_KEY_MISSING) { text = _("Unknown Key"); color = "red"; } else if (data->summary & GPGME_SIGSUM_KEY_REVOKED) { text = _("Revoked Key"); color = "red"; } else if (data->summary & GPGME_SIGSUM_KEY_EXPIRED) { text = _("Expired Key"); color = "orange"; } else { /* If we arrived here we know the key is available, the signature is * not bad, but it's not completely valid. So, the signature is good * but the key is not valid. */ text = _("Key NOT valid"); color = "orange"; } Thus GPA explicitly talks about the key and not about the signature if there are problems with the key. IIRC, KMail does something very similar. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at gmx.com Sun Jul 14 12:14:16 2013 From: infinity0 at gmx.com (Ximin Luo) Date: Sun, 14 Jul 2013 11:14:16 +0100 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <87r4f1pp13.fsf@vigenere.g10code.de> References: <51E12041.3000300@gmx.com> <51E181F3.3070604@fifthhorseman.net> <51E222AC.1030105@sixdemonbag.org> <87r4f1pp13.fsf@vigenere.g10code.de> Message-ID: <51E279F8.8050803@gmx.com> On 14/07/13 08:40, Werner Koch wrote: > On Sun, 14 Jul 2013 06:01, rjh at sixdemonbag.org said: > >> If you want this to happen, the proper way to go forward is to convince >> the GnuPG developers to change the way GnuPG talks about ownertrust, >> good signatures versus verified signatures, and so on. If GnuPG makes > > We already did this many years ago. Actually I can't find the phrase > the OP complained about. Here is an example checking a signature using > a different account. The key has been freshly imported: > > gpg: Signature made Thu Dec 20 20:48:35 2012 CET using RSA key ID 4F25E3B6 > gpg: Good signature from "Werner Koch (dist sig)" > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > Primary key fingerprint: D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 > I can also confirm this; it does indeed appear the bad phrase originates from Enigmail and not GnuPG, or perhaps something that sits in between the two. For the GnuPG warning, I think the "This key is not certified with a trusted signature!" is succinct and technically accurate. However the follow-up explanation (and there ought to be a follow-up) could still be confusing to non-techies, and does not suggest a course of action. Perhaps something like: gpg: WARNING: This key is not certified with a trusted signature! gpg: It may not actually belong to e.g. . gpg: See keysigning(7) for guidance on how to fix this. so that it actually communicates to the user it's a problem to be fixed, rather than an un-actionable warning. It's analogous to certificate warnings in browsers; I imagine you guys can take some inspiration from those. I would even go so far as to not exit 0 in this situation, but that might break existing programs. X > It seems that Enigmail creates the string. Looking at the output of GPA > gives: > > |4F25E386|Key NOT valid|Werner Koch (dist sig)|Uncertain signature ...| > [orange] > > If the key is valid (trusted), it would be > > |4F25E386|valid|Werner Koch (dist sig)|Good signature ...| > [green] > > GPA uses the GPGME library which provides the needed information. Thus > the code is pretty simple: > -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From infinity0 at gmx.com Sun Jul 14 13:04:39 2013 From: infinity0 at gmx.com (Ximin Luo) Date: Sun, 14 Jul 2013 12:04:39 +0100 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <51E279F8.8050803@gmx.com> References: <51E12041.3000300@gmx.com> <51E181F3.3070604@fifthhorseman.net> <51E222AC.1030105@sixdemonbag.org> <87r4f1pp13.fsf@vigenere.g10code.de> <51E279F8.8050803@gmx.com> Message-ID: <51E285C7.6080407@gmx.com> On 14/07/13 11:14, Ximin Luo wrote: > On 14/07/13 08:40, Werner Koch wrote: >> On Sun, 14 Jul 2013 06:01, rjh at sixdemonbag.org said: >> >>> If you want this to happen, the proper way to go forward is to convince >>> the GnuPG developers to change the way GnuPG talks about ownertrust, >>> good signatures versus verified signatures, and so on. If GnuPG makes >> >> We already did this many years ago. Actually I can't find the phrase >> the OP complained about. Here is an example checking a signature using >> a different account. The key has been freshly imported: >> >> gpg: Signature made Thu Dec 20 20:48:35 2012 CET using RSA key ID 4F25E3B6 >> gpg: Good signature from "Werner Koch (dist sig)" >> gpg: WARNING: This key is not certified with a trusted signature! >> gpg: There is no indication that the signature belongs to the owner. >> Primary key fingerprint: D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 >> > > I can also confirm this; it does indeed appear the bad phrase originates from > Enigmail and not GnuPG, or perhaps something that sits in between the two. > I've filed a bug to Enigmail: https://sourceforge.net/p/enigmail/bugs/158/ > For the GnuPG warning, I think the "This key is not certified with a trusted > signature!" is succinct and technically accurate. However the follow-up > explanation (and there ought to be a follow-up) could still be confusing to > non-techies, and does not suggest a course of action. > > Perhaps something like: > > gpg: WARNING: This key is not certified with a trusted signature! > gpg: It may not actually belong to e.g. . > gpg: See keysigning(7) for guidance on how to fix this. > Actually, probably better to point to the gnupg-doc instead of writing a new man page. /usr/share/doc/gnupg-doc/mini-HOWTO/GPGMiniHowto-3.html#ss3.6 is quite nice and short but still quite jargon-heavy IMO. Also this is completely wrong: "Ownertrust is a value that the owner of a key uses to determine the level of trust for a certain key." Ownertrust is the level of trust[1] that the local GnuPG instance has in a key. A *trust signature* is what the owner of that signature/key uses to comment on their level of trust[1] for a certain other key. [1] specifically certification-trust as termed by Hauke Laging in a previous post I will send in a patch when I get some time. > so that it actually communicates to the user it's a problem to be fixed, rather > than an un-actionable warning. It's analogous to certificate warnings in > browsers; I imagine you guys can take some inspiration from those. I would even > go so far as to not exit 0 in this situation, but that might break existing > programs. -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sun Jul 14 17:05:09 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 14 Jul 2013 17:05:09 +0200 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <51E279F8.8050803@gmx.com> (Ximin Luo's message of "Sun, 14 Jul 2013 11:14:16 +0100") References: <51E12041.3000300@gmx.com> <51E181F3.3070604@fifthhorseman.net> <51E222AC.1030105@sixdemonbag.org> <87r4f1pp13.fsf@vigenere.g10code.de> <51E279F8.8050803@gmx.com> Message-ID: <87bo65p4gq.fsf@vigenere.g10code.de> On Sun, 14 Jul 2013 12:14, infinity0 at gmx.com said: > gpg: WARNING: This key is not certified with a trusted signature! > gpg: It may not actually belong to e.g. . > gpg: See keysigning(7) for guidance on how to fix this. The think here is that often there is no need to "fix" anything. Using the WoT is just one way to validate a key; there are other - which is the reason why the fingerprint is printed below. Changing the message text is a difficult matter: We need to get all the translations and in most cases in turns out that the new version is not much better. Thus we better don't change something which has done its job okay for many years. In any case, the non-experienced user is expected to use a different user interface than gpg on the command line. Thus all improvements should go into the GUI, which has more ways to explain what is going on. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Sun Jul 14 18:34:48 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 14 Jul 2013 18:34:48 +0200 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <87bo65p4gq.fsf@vigenere.g10code.de> References: <51E12041.3000300@gmx.com> <51E279F8.8050803@gmx.com> <87bo65p4gq.fsf@vigenere.g10code.de> Message-ID: <5634443.ERI4Ir9bGW@inno.berlin.laging.de> Am So 14.07.2013, 17:05:09 schrieb Werner Koch: > Thus we better don't change something which has done its > job okay for many years. Measured by what? After all the claim of this thread is that it does its job badly. > In any case, the non-experienced user is expected to use a different > user interface than gpg on the command line. Thus all improvements > should go into the GUI, which has more ways to explain what is going > on. I would accept that as a good solution (would suggest some additions to the documentation, though) but that is obviously conflicting with the Enigmail team's position. But with this clear statement the IMHO only reasonable decision by the Enigmail team is to change their policy. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From nicholas.cole at gmail.com Sun Jul 14 20:36:11 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 14 Jul 2013 19:36:11 +0100 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <5634443.ERI4Ir9bGW@inno.berlin.laging.de> References: <51E12041.3000300@gmx.com> <51E279F8.8050803@gmx.com> <87bo65p4gq.fsf@vigenere.g10code.de> <5634443.ERI4Ir9bGW@inno.berlin.laging.de> Message-ID: On Sun, Jul 14, 2013 at 5:34 PM, Hauke Laging wrote: > Am So 14.07.2013, 17:05:09 schrieb Werner Koch: > > > Thus we better don't change something which has done its > > job okay for many years. > > Measured by what? After all the claim of this thread is that it does its > job > badly. > > > > In any case, the non-experienced user is expected to use a different > > user interface than gpg on the command line. Thus all improvements > > should go into the GUI, which has more ways to explain what is going > > on. > > I would accept that as a good solution (would suggest some additions to the > documentation, though) but that is obviously conflicting with the Enigmail > team's position. But with this clear statement the IMHO only reasonable > decision by the Enigmail team is to change their policy. I am not sure whether or not the GnuPG messages need to change. GnuPG itself is often used by people with a good technical knowledge. But I *do* think that front-ends could consider a change in their wording. >From a user's perspective, things are much clearer (I suspect) if the word 'signature' is reserved for emails, documents etc. In English, at least, it is surely clearer if we talk about 'certifying' keys, rather than 'signing' them. This would let us talk about 'uncertified' keys, which I suspect is clearer. So the message to the user could be: "Good Signature but from an uncertified key" or somesuch. I know that, from a technical perspective, a certification is a signature, but from a user's perspective signed data is very different from certifying a key, and the re-use of the same term does cause confusion. Rather than 'owner trust', or even 'introducer trust' we should talk about whether to trust the certifications provided by a particular key. Eg: "Trust in Certifications made by this Key: MARGINAL". But as Werner rightly points out, there is the issue of how to translate this in to other languages. Best wishes, N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infinity0 at gmx.com Mon Jul 15 00:37:59 2013 From: infinity0 at gmx.com (Ximin Luo) Date: Sun, 14 Jul 2013 23:37:59 +0100 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: References: <51E12041.3000300@gmx.com> <51E279F8.8050803@gmx.com> <87bo65p4gq.fsf@vigenere.g10code.de> <5634443.ERI4Ir9bGW@inno.berlin.laging.de> Message-ID: <51E32847.7050906@gmx.com> On 14/07/13 19:36, Nicholas Cole wrote: > > > > On Sun, Jul 14, 2013 at 5:34 PM, Hauke Laging > wrote: > > Am So 14.07.2013, 17:05:09 schrieb Werner Koch: > > > Thus we better don't change something which has done its > > job okay for many years. > > Measured by what? After all the claim of this thread is that it does its job > badly. > > > > In any case, the non-experienced user is expected to use a different > > user interface than gpg on the command line. Thus all improvements > > should go into the GUI, which has more ways to explain what is going > > on. > > I would accept that as a good solution (would suggest some additions to the > documentation, though) but that is obviously conflicting with the Enigmail > team's position. But with this clear statement the IMHO only reasonable > decision by the Enigmail team is to change their policy. > > > I am not sure whether or not the GnuPG messages need to change. GnuPG itself is often used by people with a good technical knowledge. > > But I *do* think that front-ends could consider a change in their wording. > I'm persuaded by the argument that the GPG CLI doesn't need to be super-instructive for non-technical users. Anyhow I'll continue pushing Enigmail to improve their phrasing, and I'll still send in that patch for gnupg-doc. > From a user's perspective, things are much clearer (I suspect) if the word 'signature' is reserved for emails, documents etc. > > In English, at least, it is surely clearer if we talk about 'certifying' keys, rather than 'signing' them. This would let us talk about 'uncertified' keys, which I suspect is clearer. So the message to the user could be: "Good Signature but from an uncertified key" or somesuch. > > I know that, from a technical perspective, a certification is a signature, but from a user's perspective signed data is very different from certifying a key, and the re-use of the same term does cause confusion. > Actually, this more precise terminology already exists, but people don't use it for some reason. Also, when you say "certifying", more precisely you mean a "certifying the validity of" - there are other types of certificates, e.g. trust certificates (tsign). To save time I'll just link myself :p - https://github.com/infinity0/pubkeys#terminology > Rather than 'owner trust', or even 'introducer trust' we should talk about whether to trust the certifications provided by a particular key. Eg: "Trust in Certifications made by this Key: MARGINAL". > This is still problematic as trust signatures could be used to infer trust transitively beyond ownertrusted keys. (Currently this is not done, but potentially could be.) "Trust root" may be better, and hints at the analogous root CAs in the X.509 hierarchy. > But as Werner rightly points out, there is the issue of how to translate this in to other languages. > > Best wishes, > > N. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Mon Jul 15 01:29:07 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 15 Jul 2013 01:29:07 +0200 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: References: <51E12041.3000300@gmx.com> <5634443.ERI4Ir9bGW@inno.berlin.laging.de> Message-ID: <31227774.OjxnysWMYR@inno.berlin.laging.de> Am So 14.07.2013, 19:36:11 schrieb Nicholas Cole: > I am not sure whether or not the GnuPG messages need to change. GnuPG > itself is often used by people with a good technical knowledge. That's right but I am afraid that these people tend to consider GnuPG the norm and don't know about this discussion. Would it make sense to have a crypto wording RfC? Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Jul 15 09:22:29 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Jul 2013 09:22:29 +0200 Subject: phrase "UNTRUSTED good signature" is dangerously misleading In-Reply-To: <5634443.ERI4Ir9bGW@inno.berlin.laging.de> (Hauke Laging's message of "Sun, 14 Jul 2013 18:34:48 +0200") References: <51E12041.3000300@gmx.com> <51E279F8.8050803@gmx.com> <87bo65p4gq.fsf@vigenere.g10code.de> <5634443.ERI4Ir9bGW@inno.berlin.laging.de> Message-ID: <87ppuknv7u.fsf@vigenere.g10code.de> On Sun, 14 Jul 2013 18:34, mailinglisten at hauke-laging.de said: > Measured by what? After all the claim of this thread is that it does its job > badly. Nope. The claim is that Enigmail shows a confusing message. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Mon Jul 15 22:44:09 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 15 Jul 2013 16:44:09 -0400 Subject: using Callback Based Data Buffers with Java Message-ID: <51E45F19.30205@guardianproject.info> I'm trying to use the "Callback Based Data Buffers" in Java/JNI to implement GnuPGData/gpgme_data_t objects that allow gpgme to work with Java InputStreams and OutputStreams. Conceptually its simple, InputStreams have a read() method, OutputStreams have a write() method, and they just need to be hooked up to gpgme_data_read_cb() and gpgme_data_write_db() respectively. But of course the devil is in the details. Right now I'm struggling with the two incompatible declarations of the callback functions in gpgme.h and data.h. gpgme.h ------- typedef ssize_t (*gpgme_data_read_cb_t) (void *handle, void *buffer, size_t size); data.h ------ typedef gpgme_ssize_t (*gpgme_data_read_cb) (gpgme_data_t dh, void *buffer, size_t size); For the GnuPGData.c implementation of the Java class that corresponds to gpgme_data_t, it needs to include both gpgme.h and data.h since it needs to get the definition of the gpgme_data struct in order to access elements of it. Or maybe I'm missing something. I've tried a bunch of things, but gcc is always telling me: jni/GnuPGData.c:101:9: error: 'gpgme_data_read_cb' redeclared as different kind of symbol In file included from jni/GnuPGData.c:9:0: ./external/gpgme/src/data.h:39:25: note: previous declaration of 'gpgme_data_read_cb' was here jni/GnuPGData.c: In function 'gpgme_data_read_cb': I'm using gpgme 1.4.2~ commit c29dad2315406bed75b9547103650bef642e6aa7. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Tue Jul 16 00:03:38 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Jul 2013 00:03:38 +0200 Subject: using Callback Based Data Buffers with Java In-Reply-To: <51E45F19.30205@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 15 Jul 2013 16:44:09 -0400") References: <51E45F19.30205@guardianproject.info> Message-ID: <877ggrlbut.fsf@vigenere.g10code.de> On Mon, 15 Jul 2013 22:44, hans at guardianproject.info said: > For the GnuPGData.c implementation of the Java class that corresponds to > gpgme_data_t, it needs to include both gpgme.h and data.h since it needs to No way. data.h is internal to gpgme and not part of the API. It may change with any release. Internal data structures may never be used by other applications or even language bindings. The reason why gpgme_data_t is an opaque pointer is just to not expose it in the API. A language binding need to take this as an opaque pointer and is not allowed to assume anything about it. The only exception is NULL, which means that the data object is not allocated. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Tue Jul 16 03:19:09 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 15 Jul 2013 21:19:09 -0400 Subject: using Callback Based Data Buffers with Java In-Reply-To: <877ggrlbut.fsf@vigenere.g10code.de> References: <51E45F19.30205@guardianproject.info> <877ggrlbut.fsf@vigenere.g10code.de> Message-ID: <51E49F8D.3050201@guardianproject.info> On 07/15/2013 06:03 PM, Werner Koch wrote: > On Mon, 15 Jul 2013 22:44, hans at guardianproject.info said: > >> For the GnuPGData.c implementation of the Java class that corresponds to >> gpgme_data_t, it needs to include both gpgme.h and data.h since it needs to > > No way. data.h is internal to gpgme and not part of the API. It may > change with any release. Internal data structures may never be used by > other applications or even language bindings. The reason why > gpgme_data_t is an opaque pointer is just to not expose it in the API. > > A language binding need to take this as an opaque pointer and is not > allowed to assume anything about it. The only exception is NULL, which > means that the data object is not allocated. Ok, that makes sense. So I have to figure out the proper way here. I'm using gpgme_data_new_from_stream() in gpgmeDataNewFromFilename(): FILE* stream = fopen(filename_str, mode_str); gpgme_error_t err = gpgme_data_new_from_stream(&data, stream); Then in gpgmeDataRelease(), I believe I'm responsible for closing that stream. So I need to maintain the FILE *stream outside of gpgme_data_t? I looked around a lot for examples of code that uses gpgme_data_new_from_stream() and gpgme_data_new_from_cbs() but didn't find any. I'd love some pointers for that. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Tue Jul 16 07:44:22 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Jul 2013 07:44:22 +0200 Subject: using Callback Based Data Buffers with Java In-Reply-To: <51E49F8D.3050201@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 15 Jul 2013 21:19:09 -0400") References: <51E45F19.30205@guardianproject.info> <877ggrlbut.fsf@vigenere.g10code.de> <51E49F8D.3050201@guardianproject.info> Message-ID: <8738rfkqix.fsf@vigenere.g10code.de> On Tue, 16 Jul 2013 03:19, hans at guardianproject.info said: > Ok, that makes sense. So I have to figure out the proper way here. I'm using > gpgme_data_new_from_stream() in gpgmeDataNewFromFilename(): Which is merly a wrapper around stdio streams (fopen,fread,fwrite,fclose). > Then in gpgmeDataRelease(), I believe I'm responsible for closing that stream. Right. > So I need to maintain the FILE *stream outside of gpgme_data_t? I looked > around a lot for examples of code that uses gpgme_data_new_from_stream() and > gpgme_data_new_from_cbs() but didn't find any. I'd love some pointers for that. An example for the latter is gpgme/tests/gpg/t-encrypt-large.c . More complex examples are in gpgol. For example gpgol/src/pgpmime.c or engine.c. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From daniel.leidert.spam at gmx.net Sun Jul 21 11:59:02 2013 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Sun, 21 Jul 2013 11:59:02 +0200 Subject: gpg 1.4.x and 2.0.x differ in output with --with-colons --check-sigs In-Reply-To: <87bo67dbir.fsf@alice.fifthhorseman.net> References: <87bo67dbir.fsf@alice.fifthhorseman.net> Message-ID: <1374400742.4984.3.camel@haktar.debian.wgdd.de> Am Freitag, den 12.07.2013, 11:49 -0400 schrieb Daniel Kahn Gillmor: > It looks to me like gpg and gpg2 differ in output when using > --with-colons --check-sigs: > > 0 dkg at alice:~$ diff -u <(gpg --check-sigs --with-colons ssh://che.mayfirst.org) <(gpg2 --check-sigs --with-colons ssh://che.mayfirst.org) > --- /dev/fd/63 2013-07-12 11:38:20.492341784 -0400 > +++ /dev/fd/62 2013-07-12 11:38:20.492341784 -0400 > @@ -1,5 +1,5 @@ > tru::1:1373556281:1373770620:3:1:5 > pub:f:2048:1:6D55BC121C106C76:1267149023:::-:::caCA: > uid:f::::1267149023::FA9BB45DEC38693028E39E41D8BDD5A9D6234406::ssh\x3a//che.mayfirst.org: > -sig:!::1:6D55BC121C106C76:1267149023::::ssh\x3a//che.mayfirst.org:13x: > -sig:!::1:CCD2ED94D21739E9:1267149081::::Daniel Kahn Gillmor :10x: > +sig:!::1:6D55BC121C106C76:1267149023::::ssh\x3a//che.mayfirst.org:13x:::::8: > +sig:!::1:CCD2ED94D21739E9:1267149081::::Daniel Kahn Gillmor :10x:::::10: > 1 dkg at alice:~$ > > > in particular, gpg 2.0.20 supplies field 16 for the sig lines, which > (according to DETAILS) is the hash algorithm of the signature, but gpg > 1.4.12 does not. (8 is SHA-256, 10 is SHA-512). Is this an intentional > difference? > > Is there any reason to avoid having 1.4.x produce this field as well? See http://bugs.debian.org/672658. However, I wasn't sure, if we should apply it to Debian. I decided to do not for Wheezy. Would be nice, if this patch would make it officially into the 1.4 series. Regards, Daniel From hans at guardianproject.info Tue Jul 23 02:20:13 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 22 Jul 2013 20:20:13 -0400 Subject: file extension confusion: --clearsign makes binary .asc Message-ID: <51EDCC3D.4010007@guardianproject.info> I'm sorting thru the GnuPG file extensions these days. One thing I just noticed is that "gpg2 --clearsign icon.png" creates a binary file called "icon.png.asc". The signature is ASCII but the rest is still the plain old binary. Shouldn't that file be .gpg or .sig? .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From lion at lion.leolix.org Tue Jul 23 12:33:57 2013 From: lion at lion.leolix.org (Philipp Schafft) Date: Tue, 23 Jul 2013 12:33:57 +0200 Subject: file extension confusion: --clearsign makes binary .asc In-Reply-To: <51EDCC3D.4010007@guardianproject.info> References: <51EDCC3D.4010007@guardianproject.info> Message-ID: <20130723103402.2AE667A265@priderock.keep-cool.org> reflum. On Mon, 2013-07-22 at 20:20 -0400, Hans-Christoph Steiner wrote: > I'm sorting thru the GnuPG file extensions these days. One thing I just > noticed is that "gpg2 --clearsign icon.png" creates a binary file called > "icon.png.asc". The signature is ASCII but the rest is still the plain old > binary. Shouldn't that file be .gpg or .sig? --clearsign just generates a signature that includes a 'clear' (readable) copy of the document (not a OpenPGP message with a data block that may be compressed or otherwise made un-readable without a OpenPGP implementation processing the message). This is *only* for stuff that can be read anyway like plain text. This is not designed for binary content. For binary content just use the normal sign option or use a detached signature. --clearsign is just a extention for *text* only. It will be as readable as the source data. PNGs can't be read directly by a user without a picture viewer so the clearsign result cann't be. Hope this was of some help :). Have a good day! -- Philipp. (Rah of PH2) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From timprepscius at gmail.com Tue Jul 23 15:27:22 2013 From: timprepscius at gmail.com (Tim Prepscius) Date: Tue, 23 Jul 2013 09:27:22 -0400 Subject: minimal pseudo code for encrypting message to multiple recipients Message-ID: Hello, I am considering integrating pgp-mime into an web e-mail client I've written. I am wondering if anyone has or can point to simple pseudo code, or simple code, for the pgp encryption process. I have a user's RSA public 2048 bit key. I want to encrypt a mail-mime-block. I want to do it in such a way that it is compatible with mail reading pgp-mime programs which have the user's RSA pub/private key-pair. And I'd like to do it in the simplest of manners. I've read the pgp-mime specification. I understand that I'm going to construct a "mime within a mime" I get that part. After I've constructed the canonicalized mime, what is the simplest compatible encryption process? I assume it is BASE64(RSA(AES-KEY) + AES(MAIL) + PADDING) + SIG of some sort. But am having problems finding a simple code segment which illustrates this. I'm not interested in supporting a full pgp-mime code set at the moment. Just a minimal first version. Thank you for any help you can offer, I don't mind reading through code, but I'd like to, if possible, skip to a simple example. ;-) Cheers, -tim From bernhard at intevation.de Wed Jul 24 11:59:09 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 24 Jul 2013 11:59:09 +0200 Subject: minimal pseudo code for encrypting message to multiple recipients In-Reply-To: References: Message-ID: <201307241159.10563.bernhard@intevation.de> On Tuesday 23 July 2013 at 15:27:22, Tim Prepscius wrote: > I am considering integrating pgp-mime into an web e-mail client I've > written. The gpgme bindungs of the language of your choice usually has simple examples. (And yes, gpgme is the simplest way to do a safe crypto operation with gnupg.) -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Jul 25 11:53:33 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 11:53:33 +0200 Subject: [Announce] [security fix] Libgcrypt 1.5.3 released Message-ID: <87a9lb7yoy.fsf@vigenere.g10code.de> Hello! I am pleased to announce the availability of Libgcrypt version 1.5.3. This is a *security fix* release for the stable branch. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.5.3: * Mitigate the Yarom/Falkner flush+reload side-channel attack on RSA secret keys. See . [ Note that Libgcrypt is used by GnuPG 2.x and thus this release fixes the above problem. The fix for GnuPG < 2.0 can be found in the just released GnuPG 1.4.14. ] Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.3.tar.bz2 (1.5M) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.3.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.3.tar.gz (1.8M) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.3.tar.gz.sig Alternativley you may upgrade version 1.5.2 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.2-1.5.3.diff.bz2 (4k) The SHA-1 checksums are: 2c6553cc17f2a1616d512d6870fe95edf6b0e26e libgcrypt-1.5.3.tar.bz2 184405c91d1ab4877caefb1a6458767e5f0b639e libgcrypt-1.5.3.tar.gz b711fe3ddf534bb6f11823542036eb4a32e0c914 libgcrypt-1.5.2-1.5.3.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . [2] See http://www.gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Jul 25 12:26:55 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 12:26:55 +0200 Subject: [Announce] [security fix] GnuPG 1.4.14 released Message-ID: <8738r37x5c.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-1 release: Version 1.4.14. This is a *security fix* release and all users of GnuPG < 2.0 are advised to updated to this version. See below for the impact of the problem. For users of GnuPG >= 2.0 a new version of Libgcrypt (1.5.3) has been released which fixes the problem for them. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, smartcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880. Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build, and also better portable to ancient platforms. In contrast to GnuPG-2 (e.g version 2.0.20) it comes with no support for S/MIME, Secure Shell, or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. What's New =========== * Mitigate the Yarom/Falkner flush+reload side-channel attack on RSA secret keys. See . * Fixed IDEA for big-endian CPUs * Improved the diagnostics for failed keyserver lockups. * Minor bug and portability fixes. Impact of the Cache Side-Channel Attack ======================================= Here is the abstract from the Yarom and Falkner paper: Flush+Reload is a cache side-channel attack that monitors access to data in shared pages. In this paper we demonstrate how to use the attack to extract private encryption keys from GnuPG. The high resolution and low noise of the Flush+Reload attack enables a spy program to recover over 98% of the bits of the private key in a single decryption or signing round. Unlike previous attacks, the attack targets the last level L3 cache. Consequently, the spy program and the victim do not need to share the execution core of the CPU. The attack is not limited to a traditional OS and can be used in a virtualised environment, where it can attack programs executing in a different VM. I general the use of private keys on multi-user machines is imminent dangerous due to a variety of possibly attacks. Example for such attacks are locally exploitable vulnerabilities and all kind of side channel attacks which can't be mitigated by the operating system. Thus the best advise is to use a private key only on a fully trusted machine; i.e. a machine with full control over the software which may run on it. However, it is common to put private keys on servers for example to process encrypted mail. If the server hardware is shared with other users it is thus important to update GnuPG so to avoid the described attack. On a pure desktop machine, with only one user, mounting this attack is probably not effective because there are easier ways to gain access to the machine and thus the keys. For best protection of private keys, smartcards are often the best choice. Getting the Software ==================== First of all, decide whether you really need GnuPG version 1.4.x - most users are better off with the modern GnuPG 2.0.x version. Then follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.14 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.14.tar.bz2 (3601k) gnupg-1.4.14.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.14.tar.gz (4967k) gnupg-1.4.14.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.13-1.4.14.diff.bz2 (14k) A patch file to upgrade a 1.4.13 GnuPG source tree. This patch does not include updates of the language files. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.14.exe (1567k) gnupg-w32cli-1.4.14.exe.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.14.tar.bz2 you would use this command: gpg --verify gnupg-1.4.14.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 | gpg --import or using a keyserver like gpg --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 1E42B367. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.14.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.14.tar.bz2 and check that the output matches the first line from the following list: 6202181ba2871fb3448c751a573b4ae0c4770806 gnupg-1.4.14.tar.bz2 607691dd42a24f39fd74dded20375c4c0bc47d2c gnupg-1.4.14.tar.gz e7623a6b8b6de00d3788246d3e51fde1ce7b5897 gnupg-1.4.13-1.4.14.diff.bz2 ac9e89240ce37810febf59e28db655d1271b2fea gnupg-w32cli-1.4.14.exe Internationalization ==================== GnuPG comes with support for 29 languages. The Chinese (Simple and Traditional), Czech, Danish, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish, Ukrainian, and Turkish translations are close to be complete. Support ======= A listing with commercial support offers for GnuPG is available at: http://www.gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software take up a most of their resources. To allow them continue their work they ask to either purchase a support contract, engage them for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, donating money, spreading the word, or answering questions on the mailing lists. Thanks to Yoval Yarom for providing the paper in advance and testing the fix. Happy Hacking, The GnuPG Team (David, Werner and the other contributors) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Jul 25 16:25:17 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 16:25:17 +0200 Subject: file extension confusion: --clearsign makes binary .asc In-Reply-To: <51EDCC3D.4010007@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 22 Jul 2013 20:20:13 -0400") References: <51EDCC3D.4010007@guardianproject.info> Message-ID: <87k3ke7m42.fsf@vigenere.g10code.de> On Tue, 23 Jul 2013 02:20, hans at guardianproject.info said: > I'm sorting thru the GnuPG file extensions these days. One thing I just > noticed is that "gpg2 --clearsign icon.png" creates a binary file called > "icon.png.asc". The signature is ASCII but the rest is still the plain old > binary. Shouldn't that file be .gpg or .sig? The .asc suffix indicates that this is a human readable file and as such could be directly send using email or fido.net. The .sig indicates a binary detached signature. The .gpg is GnuPG's version of .pgp and indicates a binary format. The use of the suffixes stems form PGP 2. I used them to make migration easier. Well, except for the self-advertising .gpg suffix. GPG does not care about the suffix, but uses the content to decide which type of file it is. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jul 25 16:25:59 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 16:25:59 +0200 Subject: gpg 1.4.x and 2.0.x differ in output with --with-colons --check-sigs In-Reply-To: <1374400742.4984.3.camel@haktar.debian.wgdd.de> (Daniel Leidert's message of "Sun, 21 Jul 2013 11:59:02 +0200") References: <87bo67dbir.fsf@alice.fifthhorseman.net> <1374400742.4984.3.camel@haktar.debian.wgdd.de> Message-ID: <87fvv27m2w.fsf@vigenere.g10code.de> On Sun, 21 Jul 2013 11:59, daniel.leidert.spam at gmx.net said: > apply it to Debian. I decided to do not for Wheezy. Would be nice, if > this patch would make it officially into the 1.4 series. Sorry, too late for 1.4.14. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Thu Jul 25 17:05:41 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 25 Jul 2013 11:05:41 -0400 Subject: file extension confusion: --clearsign makes binary .asc In-Reply-To: <87k3ke7m42.fsf@vigenere.g10code.de> References: <51EDCC3D.4010007@guardianproject.info> <87k3ke7m42.fsf@vigenere.g10code.de> Message-ID: <51F13EC5.4080100@guardianproject.info> On 07/25/2013 10:25 AM, Werner Koch wrote: > On Tue, 23 Jul 2013 02:20, hans at guardianproject.info said: >> I'm sorting thru the GnuPG file extensions these days. One thing I just >> noticed is that "gpg2 --clearsign icon.png" creates a binary file called >> "icon.png.asc". The signature is ASCII but the rest is still the plain old >> binary. Shouldn't that file be .gpg or .sig? > > The .asc suffix indicates that this is a human readable file and as such > could be directly send using email or fido.net. Right, so when you do --clearsign without --armor on a binary file, the resulting file is all binary, except for the signature part. That means it is neither human readable nor can be sent directly using email. So in that situation, the .asc file extension does not make sense. > The .sig indicates a binary detached signature. > > The .gpg is GnuPG's version of .pgp and indicates a binary format. > > The use of the suffixes stems form PGP 2. I used them to make migration > easier. Well, except for the self-advertising .gpg suffix. > > GPG does not care about the suffix, but uses the content to decide which > type of file it is. How can you use gpg2 or gpgme to detect the contents of a .gpg file? I'm trying to do that right now. From everything that I've seen in gpg2 and gpgme, you need to manually specify the operation to do on the .gpg file, i.e. "gpg2 --import" or "gpg2 --decrypt". I want GPG on Android to be able to receive a .gpg file and then do the right thing without the user having to tell GPG that the .gpg file is keys, encrypted content, a signed file, etc. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Thu Jul 25 17:15:36 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 17:15:36 +0200 Subject: file extension confusion: --clearsign makes binary .asc In-Reply-To: <51F13EC5.4080100@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 25 Jul 2013 11:05:41 -0400") References: <51EDCC3D.4010007@guardianproject.info> <87k3ke7m42.fsf@vigenere.g10code.de> <51F13EC5.4080100@guardianproject.info> Message-ID: <87y58u657r.fsf@vigenere.g10code.de> On Thu, 25 Jul 2013 17:05, hans at guardianproject.info said: > Right, so when you do --clearsign without --armor on a binary file, the Clearsign always enables the armor option. The sole purpose of clearsign is to send human readable (aka plain ascii) text using a simple ascii encapsulation. If you don't feed it with ascii (or utf-8) you still get the clearsign format. Actually it is not even possible to use clearsign for non-ascii because the specs demand certain conversation which are not reversible (line ending, trailing whitespace, ^From). > How can you use gpg2 or gpgme to detect the contents of a .gpg file? I'm I'll answer that in another mail. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jul 25 18:05:08 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 18:05:08 +0200 Subject: Identify a gpg file (was: file extension confusion: --clearsign makes binary .asc) In-Reply-To: <51F13EC5.4080100@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 25 Jul 2013 11:05:41 -0400") References: <51EDCC3D.4010007@guardianproject.info> <87k3ke7m42.fsf@vigenere.g10code.de> <51F13EC5.4080100@guardianproject.info> Message-ID: <87txji62x7.fsf_-_@vigenere.g10code.de> On Thu, 25 Jul 2013 17:05, hans at guardianproject.info said: > "gpg2 --import" or "gpg2 --decrypt". I want GPG on Android to be able to > receive a .gpg file and then do the right thing without the user having to > tell GPG that the .gpg file is keys, encrypted content, a signed file, etc. You are right. GPGME needs to know what it shall do. Although gpg usually does the right thing, it does not automatically import files - you need to use --import. I would consider the latter a feature. Back to GPGME. I recall that for some projects we often talked about your needs but eventually get around it with simple methods. For example GpgEX (the Windows file explorer extension) uses a list of suffixes to decide whether to show sign/encrypt or verify/decrypt at the top of the context menu. This more or less works but is not very comfortable. GPA (src/filetype.c) and GpgOL have code to distinguish between CMS/X.509 and OpenPGP but that is all we have. I agree that a generic function in GPGME to do what file(1) does for OpenPGP files would be quite useful. Unfortunately we have not yet had the time to implement it. src/filetype.c along with a list of commonly used suffixes might be a start, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Thu Jul 25 18:32:23 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 25 Jul 2013 12:32:23 -0400 Subject: file extension confusion: --clearsign makes binary .asc In-Reply-To: <87y58u657r.fsf@vigenere.g10code.de> References: <51EDCC3D.4010007@guardianproject.info> <87k3ke7m42.fsf@vigenere.g10code.de> <51F13EC5.4080100@guardianproject.info> <87y58u657r.fsf@vigenere.g10code.de> Message-ID: <51F15317.6070407@guardianproject.info> On 07/25/2013 11:15 AM, Werner Koch wrote: > On Thu, 25 Jul 2013 17:05, hans at guardianproject.info said: > >> Right, so when you do --clearsign without --armor on a binary file, the > > Clearsign always enables the armor option. The sole purpose of > clearsign is to send human readable (aka plain ascii) text using a > simple ascii encapsulation. If you don't feed it with ascii (or utf-8) > you still get the clearsign format. Actually it is not even possible to > use clearsign for non-ascii because the specs demand certain > conversation which are not reversible (line ending, trailing whitespace, > ^From). So are you saying that OpenPGP's spec for --clearsign does not allow for base64-encoded binary data? If so, I think that running "gpg --clearsign" on a binary file should give a warning that its not a supported format. I just tried --clearsign with a PNG on my Linux Mint/Maya machine, and both gpg 1.4.11 and gpg2 2.0.17. In both cases, the resulting file was not ASCII, but the format I described: binary data and ASCII signature. I attached the PNG and the resulting file. $ gpg --clearsign icon.png You need a passphrase to unlock the secret key for user: "Hans-Christoph Steiner " 4096-bit RSA key, ID 374BBE81, created 2009-06-20 $ less icon.png.asc "icon.png.asc" may be a binary file. See it anyway? $ gpg --version gpg (GnuPG) 1.4.11 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 $ rm icon.png.asc $ gpg2 --clearsign icon.png You need a passphrase to unlock the secret key for user: "Hans-Christoph Steiner " 4096-bit RSA key, ID 374BBE81, created 2009-06-20 $ less icon.png.asc "icon.png.asc" may be a binary file. See it anyway? $ gpg2 --version gpg (GnuPG) 2.0.17 libgcrypt 1.5.0 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: icon.png Type: image/png Size: 9413 bytes Desc: not available URL: -------------- next part -------------- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ?PNG  IHDRHHU?G =iCCPiccx?SgTS?=???BK???KoR RB??Ti????@????"?q????"??A??y(??(6T??}??7o????9g??}>F`?D???dJ?<6. 'w T ??@?- ??????????m@n???8?P?? $ ????B?2r22 ?t?%[ ?j;e?Ov?$??(S*@?@&???X????`(??s??`???`???)d`? S???GE?3(???x?W\!?S?d??Tn!?? \]?x?87C?P? ????ee????3?FvD????9;?:;?8?:|????????????????E??????? ?e ???/?? ?B??_??????T?B?fg???k+ m??_??? _????????????  ? ?2??r<[&?q?? ??.??wL?'??b?P?GK?i ???$ I??H???????k`?~?B[P???. ??%??w???1??w0??? h?? ?? ????4P6h?>??#??;x??P??8XBH?L?C.,?UP%??B?Z??F8-p???????@? j??\? B???h ??G ? h%Z? B?????>G?0??3?l0.??B?x,?c?b????6????b#?{??"??;!?0? $,",'???? Ba???$???nD>1??B?%+?u?c???[????!??\H??8Ri ?????D:C?!????d?6??A% ? ry;??4?:y???B?P )??x??R@?? ???\? R?jTS?5?*?.??Qk?m???8M?fN?E??h?h??F?y?C?+:?nDw???%??J?a?Ez?=C?a??1J??~??=?+&?i??b?3? ?z?9?c?;??? _E??B?Z?Y?? U???????|? ??WUG?jfj<5??r?j??jw???Y??????/?i?5?4?4D??4?i?0?1???V?jY?Yl??g??K??????34?5?4?5Oj?r0?????q?pns>L??=Ej?kh?4?k?m8ndn4?????1?k?l???x???$?d?I??}S?)?4?t?i??[3s???f-fC?Z?|?|??L O?E57-I?\?t???P+'?T?j???????z?u?4?4?i?i5???0l?mrll?l9????-?/?L???6?u?}?w??????0?????7G+G?c????????WLo??r?? ?]3?:??B??:?;}rvq?;7:???$??p??es????DW??'\?9?)????n??~?}h??L???? F ?? ???Y??????4?x?x>?2?y?y z[z?y?~?c?#?9????[?;????v?i?????{?o???????$?L 10(pS? ? _???v??lvG#(2?*?I?U?y????? ?r?`?Gry?P?G???T??? OR%y???;?mzh?????LJfb?q??4]??????#???z?-?hT $??F??g?*? ??Ki?\????S??.7:?h?z?4?k????????]BX"\??p?}???]?,OZ??xE??+???J_?S?}Ay???1?? ? W?? X?P?R$/???}??u?u?u????s???r?}IE??Ra??o ???fbC??2?]I?oo??t?\?t??(?h????8?:V?4/n mIm?m?k?9>?x{?{?m???D?I?e?h? OM???=vFvf?l????????????}>??? ??uzw???q??%?K?/s/?\q?????u?'???u;w7_u??z??Z[??S?=????{??M??+????=???; wz??????~???+?R{T?X?q???7?:??????z??A????????q??)?i??`????a??k??=x.{>>R??/;^X???W?_?FcG^?_N?V?J????3^????=~??f?m?;?w?s?w~??08????????A?NdNL????%c3? cHRMz%??????u0?`:?o?_?FbKGD??????? pHYs  ???IDATx??kl?????? ?IY???W?[??f7M???#t???u??-?F?u??"?&???FQ h>?k;1??v?M'????8?eQ?(Q??? 9??z??wf8?e?&=?? g????????????}?0 E?\.9?3)??K1??,`?1 !???$??N?S9q?D{dd???????w? O=?I?X?\n??K)???l?r]w?u??8??R(?L ?IE~ ?q ?+??I??? ?T*?\.??{??]@???g?oa?Q????,===????O }??gll?8?i6?lnnR??i6???O??q? ??8x?G.??T*1<9???!?V? X__gyy???U:??L?|>O>?'??b?6Q??>?v?QA?P`?]LNNR.??d2?J%???????^??y???g?????Z???T,i6??}??????????W???{7}?YZZb~~?F???y???199???????????&j??J? .P???r??}??????>????7}?3g?`?azz??s??a&''???????}fff8y?$?N???s????$ ccc?}??LMMQ,?Z???AO ??|?g?}?O?>}?=??3?j5 ?????g???={???u??_???[?8N?f??N?????r?:;;?z???k???]CCC??m????B????f?I7???h4~Z,/ ?~???)????^??? |?????/???R.???l???????&Ij?=?????'??,_??o?z??]??LOOJkM??DA?^gaa?$Ip]?r??k???9v??=???VWWo ?? ?????3g~??o??S?N? ;v`?6A???@??BJ?S ??V???|?????????s?R?iY??r-?"????>o???O? =?'N??^??R@???'??I???_?~??_{??o??????0 {? )?^?s?}?K_b?]?????YYYA???$I??|>?3g????????;???rx???O??z??T?U2? aR?Th6?T*r??1?F??????mnn??}?1????I??B)E?Z??j??t3???O????u?z????_??_dff?sss ???z?Z?????u?0$I??z??-???? ;???U?T? ?^Q???j5N?:utnnn%I???7?????:u?T(?? ? ?v?M?Z%?????w??)`?P?Z%I?|?V?x?"J)??N?G)??g9s???_??Wt????0h???????C???j?C?^?????]?'?????f?(?2???M&&&h6??Tb?????????/???233s???m?|?I???2>>N?\?Y??E?j?F??WJ?=K????("I?j??v??n?jA?sss?^????v???E? =J?V??????kH??\??]?$????5?X?-?1q Q?_7??l6??? C?g7;??:??S??????E ????^??z??????F)??`o(??t:A????#I?R??????dq EJ???u%?=PZ?m?=@an3?;5z?VJ?[?????\??PoB=6?; hp^?^??\oT?7?w?.?????)?7?A???a@????\?[ ??y???!????1h??????? ??????]1Y???c0???}??G?z?????#?Kr?\???X?Q at q?Hyt???c??_}c?\?f$!???~??Em??g??y??l?"?+}$y???R? ?B?@.?#[?b[F??!r? ?k???}???eu6? ?G 7???ep?R???E??'2v?[??u??4??)KJ?X# ??D'DID?Q at a?P?rum??In ?\?z?~?\?>??5G?v0?q3???k???K ??,???s?`?Y3??RZ?0Y??c?????????Q?*?)??E??u ?@? ?d?????c9e?[???_??CL???T?????(s??+ ??'P?B?Z ???U???X??*"61J+?Qh?0??ip\?\? ?Do?P?B"?DK?HE?];??s??>?)(????$F???(?VZp?~???? ?$Rb+F?UW?2I ???NP??`?v ????^?1@??M;nc ??N 9?q*?z???=Ui?????Y??M!?qD??A?????i?m:A? N??? ?-??Dx[?)`Fw?'?h1???X??1??? ?g????TP?N?????tH?m ???E??{?A?> ?????>A?a??G!Q 'I??4# B??B ?'?B /???B1?!?Pt?"????? ??h?>B??H;n#o?;I?N?? UH?#??[???5?v?Em?Fm??f}?v?E?$*NCN?TIR?d???t=F?=? H????Pa@???? ?p??w?5;3;?S?do?#?Uj?j??nJA??C;i?H? ?? a???#??'>V.??t??U??G ??? ?p?+V7]?????_O?!?a???.?????{8 )nPK7 ??j??b[6?????X|?P???V???=@????-C???2N?? ??)w?Z.? ??K?opj?}f??-?x??r?????0$?DN@?????Dl66y?WX?Gq?@~8????R??%?T?????&?z %????B`?abd7?R???R??'7(j'$????&?$d?2? (???.?>?^??J???'d?d?Y??,?R??"=?????`"??4??4"?z@? H?B??? ????)?]??]c{X?,?IG?t?4??Q at +oV??h????h??`z???_?z?1?$???]O?#?? Fi?2?H?b??5Fk??-?2??Ie?h?es?=?=~??j$I?t??< ?Z?7??[iZo??????x??0 ?h?}???&?i?I[???,?w?:??????1?{??]$&&T??H"? 5*T?T??/?? FvW?K?? ? YHq????/?Qc ???0?S?9B"t?~Lbt??BE??d} ?H??!??o?%??F????B??~ ?l??Q?cy?? TBt?????"????y???m??@?l????rv~?I?$??2?s???,???tp?b?-?UL'?H?c??5W?E???+? I??p?????S?e[?9???a?&tD?$???K?D(?*(??$}????7h+???%? ???~?j??o???1!?m??e? e?J "cHdB?w?K??5o!R??*??Xdn??18??f??[^?@i?-??+??????d ???\29????,pA??P?eZ?[?b?!???D!}!??#???UC??????Rz at EW??]??Z??n?X??]??36?g#]?A ?21?1qoWc ?1?$RD?p3$n%?'??"?7%1:?[?6W?|??2?[??f-??n?|?z?L?Y?E????8X???Xi3M??F?A?t?HE??1piG????X??*-?[1??0?`9??]erwe?T???Ib??M?:w?o?{ 1)??^???e??b??Zt?????$?H'm? ??w??{?MR :?$?JW?D???iK??z????? Q "??? c??N4?o7?A??t?1Bn-????\Ka*@?I??hT???l?f???o?w??^??Y?6?????VQ?A?R ??X +t??[?s?yPiOa??V+C+??,?'v?}e?r?l0Wl??7%5X?EqG??,?? ??H?*?H???l??BJ{ 4?.k?e9y???????? (I??~H ??????vlrC9r#???N???7?HaI??????rV_??tY??4????G??[=@?R?W?m?uo?c?RJr?,??v? ?-?:?o??????????[Jc?Fk?@?Qs5??!???????`???A*??????r!!???vm?????3?2$:?v??T?N$??~??????U???7?sLt?\? >?`yE?E??e^'????'x????ZV7?\???A?DX??$*!??~rw?:? ?? ?c?:c9?G?H(?\jW$]?1?? m???o?R??\?????T ??R??@H??]???"?Q??6[2Dr?w???1i??6F'?sKNA?~?{u??v?h??;?,O~L? $??? (Hans-Christoph Steiner's message of "Thu, 25 Jul 2013 12:32:23 -0400") References: <51EDCC3D.4010007@guardianproject.info> <87k3ke7m42.fsf@vigenere.g10code.de> <51F13EC5.4080100@guardianproject.info> <87y58u657r.fsf@vigenere.g10code.de> <51F15317.6070407@guardianproject.info> Message-ID: <877gge5zlc.fsf@vigenere.g10code.de> On Thu, 25 Jul 2013 18:32, hans at guardianproject.info said: > base64-encoded binary data? If so, I think that running "gpg --clearsign" on > a binary file should give a warning that its not a supported format. The question is what is a binary file? It is hard for a machine to figure that out and Unix tradition does not distinguish between binary and plain text (in contrast to Windows). > gpg 1.4.11 and gpg2 2.0.17. In both cases, the resulting file was not ASCII, > but the format I described: binary data and ASCII signature. I attached the Sure. If you don't want that you need to base64 encode the to be signed data first. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From timprepscius at gmail.com Thu Jul 25 18:32:05 2013 From: timprepscius at gmail.com (Tim Prepscius) Date: Thu, 25 Jul 2013 12:32:05 -0400 Subject: minimal pseudo code for encrypting message to multiple recipients Message-ID: Sorry for starting a new message, somehow I only get the digest and not the reply to my posted message. Anyhow. I'm actually looking for pseudo code for a minimal implementation of pgp-mime. Not using gpgme. This is going to be part of a web client: java -> gwt -> javascript. No C code. So.. I have a feeling this is an impossible request. And that perhaps a full implementation is the *only* implementation. I believe that bouncy castle has pgp support. So I will probably be able to use that. I was hoping to find something like: A minimal pgp-mime. 1. Canonicalize message. 2. Write a "encrypted/pgp-mime" mime-part. 3. Within mime-part write b64(encrypt(canon-message)). Where encrypt is "rsa(aes-256-key) + aes-256(message) + sha-256(previously written bytes)" 4. Add mime-part attachment in format: Some indicator of encryption version used. And my public key. ... I'm looking for a simplest of simple implementations which could then be expanded on. Perhaps this is impossible. -tim From hans at guardianproject.info Thu Jul 25 19:31:21 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 25 Jul 2013 13:31:21 -0400 Subject: file extension confusion: --clearsign makes binary .asc In-Reply-To: <877gge5zlc.fsf@vigenere.g10code.de> References: <51EDCC3D.4010007@guardianproject.info> <87k3ke7m42.fsf@vigenere.g10code.de> <51F13EC5.4080100@guardianproject.info> <87y58u657r.fsf@vigenere.g10code.de> <51F15317.6070407@guardianproject.info> <877gge5zlc.fsf@vigenere.g10code.de> Message-ID: <51F160E9.8020805@guardianproject.info> On 07/25/2013 01:17 PM, Werner Koch wrote: > On Thu, 25 Jul 2013 18:32, hans at guardianproject.info said: > >> base64-encoded binary data? If so, I think that running "gpg --clearsign" on >> a binary file should give a warning that its not a supported format. > > The question is what is a binary file? It is hard for a machine to > figure that out and Unix tradition does not distinguish between binary > and plain text (in contrast to Windows). > >> gpg 1.4.11 and gpg2 2.0.17. In both cases, the resulting file was not ASCII, >> but the format I described: binary data and ASCII signature. I attached the > > Sure. If you don't want that you need to base64 encode the to be signed > data first. "less" does a pretty good job of figuring out what is a binary or not, and issues its warning based on it. I think something similar would make stuff like this in gpg much less confusing. It would allow gpg to add the file extension that makes the most sense, and then in turn when people use that file, the format will be better described by the file extension. It may seem like a trivial issue to many, but its stuff like this that makes PGP hard to use for most people. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From hans at guardianproject.info Thu Jul 25 20:36:30 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 25 Jul 2013 14:36:30 -0400 Subject: Identify a gpg file In-Reply-To: <87txji62x7.fsf_-_@vigenere.g10code.de> References: <51EDCC3D.4010007@guardianproject.info> <87k3ke7m42.fsf@vigenere.g10code.de> <51F13EC5.4080100@guardianproject.info> <87txji62x7.fsf_-_@vigenere.g10code.de> Message-ID: <51F1702E.5050707@guardianproject.info> On 07/25/2013 12:05 PM, Werner Koch wrote: > On Thu, 25 Jul 2013 17:05, hans at guardianproject.info said: > >> "gpg2 --import" or "gpg2 --decrypt". I want GPG on Android to be able to >> receive a .gpg file and then do the right thing without the user having to >> tell GPG that the .gpg file is keys, encrypted content, a signed file, etc. > > You are right. GPGME needs to know what it shall do. Although gpg > usually does the right thing, it does not automatically import files - > you need to use --import. I would consider the latter a feature. I agree it should not automatically import keys in a .gpg. I think if it detects that the .gpg file contains keys, it should present the user with a summary of the contents and ask the user whether she wants to import them. > Back to GPGME. I recall that for some projects we often talked about > your needs but eventually get around it with simple methods. For > example GpgEX (the Windows file explorer extension) uses a list of > suffixes to decide whether to show sign/encrypt or verify/decrypt at the > top of the context menu. This more or less works but is not very > comfortable. GPA (src/filetype.c) and GpgOL have code to distinguish > between CMS/X.509 and OpenPGP but that is all we have. > > I agree that a generic function in GPGME to do what file(1) does for > OpenPGP files would be quite useful. Unfortunately we have not yet had the > time to implement it. src/filetype.c along with a list of commonly > used suffixes might be a start, though. I think the best and easiest solution for this is using explicit file extensions by default everywhere. So things like .pkr for public keys, .skr for private keys, .sig for binary detach-sign, etc. Any specific format that does not already have its own file extension should get a new one. Then gpg should avoid adding the ambiguous extensions, like .gpg, .pgp, .asc, but continue to accept them. I could probably find some time in the not-too-distant future to implement this. As a side note, the file-5.14 detection could use some improvement. Its not detecting keys and detached signatures as something distinct. It seems that the logic in gpa/src/filetype.c could be contributed to file. $ for f in *.gpg *.sig *skr *pkr; do file $f;done icon-encrypted-not-signed.png.gpg: data icon.png.gpg: data pubring.gpg: GPG key public ring secret.gpg: data secring.gpg: data trustdb.gpg: GPG key trust database version 3 icon.png.sig: data public-keys.pkr.sig: data secret-keys.skr: data public-keys.pkr: data .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 939 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Jul 25 21:14:22 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 21:14:22 +0200 Subject: file extension confusion: --clearsign makes binary .asc In-Reply-To: <51F160E9.8020805@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 25 Jul 2013 13:31:21 -0400") References: <51EDCC3D.4010007@guardianproject.info> <87k3ke7m42.fsf@vigenere.g10code.de> <51F13EC5.4080100@guardianproject.info> <87y58u657r.fsf@vigenere.g10code.de> <51F15317.6070407@guardianproject.info> <877gge5zlc.fsf@vigenere.g10code.de> <51F160E9.8020805@guardianproject.info> Message-ID: <87ppu64fld.fsf@vigenere.g10code.de> On Thu, 25 Jul 2013 19:31, hans at guardianproject.info said: > "less" does a pretty good job of figuring out what is a binary or not, and Less is a tool to display data to users. And that is its only purpose. GPG is a too to sign or encrypt data and not to display it to users. Thus it should stay away from too much cleverness. > issues its warning based on it. I think something similar would make stuff > like this in gpg much less confusing. It would allow gpg to add the file > extension that makes the most sense, and then in turn when people use that > file, the format will be better described by the file extension. The usual way you use tools in Unix is in a pipeline. Here a suffix does not make any sense. This is the reason why Unix tools shall not care about them. > It may seem like a trivial issue to many, but its stuff like this that makes > PGP hard to use for most people. CMS/X.509 is not different. There is even no agreement on a de-facto standard suffix for certificates. In any case, the use of --clearsign has long been deprecated because it has too many problems. For example the user needs to know the structure of the mail to decide what has actually been signed (armor headers are for example not signed). For any new application I would suggest to use a detached signature. Only detached signatures make it pretty clear what has been signed. If that is not possible MIME is a well specified way to convey data along with meta data. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jul 25 21:19:58 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 21:19:58 +0200 Subject: Identify a gpg file In-Reply-To: <51F1702E.5050707@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 25 Jul 2013 14:36:30 -0400") References: <51EDCC3D.4010007@guardianproject.info> <87k3ke7m42.fsf@vigenere.g10code.de> <51F13EC5.4080100@guardianproject.info> <87txji62x7.fsf_-_@vigenere.g10code.de> <51F1702E.5050707@guardianproject.info> Message-ID: <87li4u4fc1.fsf@vigenere.g10code.de> On Thu, 25 Jul 2013 20:36, hans at guardianproject.info said: > extensions by default everywhere. So things like .pkr for public keys, .skr > for private keys, .sig for binary detach-sign, etc. Any specific format that With two drawbacks: You need to have a filename and you need extra code to handle data with a wrong suffix. Yes, that happends. > should avoid adding the ambiguous extensions, like .gpg, .pgp, .asc, but That is easy. GPGME does not know anything about suffixes and with GPG you should specificy the filename anyway yourself. The extensions are only used by default for convenience. > As a side note, the file-5.14 detection could use some improvement. Its not > detecting keys and detached signatures as something distinct. It seems that > the logic in gpa/src/filetype.c could be contributed to file. Last time I checked file(1) uses a not too simple pattern matching system, thus it is not easy to re-use the code - but possible. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jul 25 21:28:34 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 21:28:34 +0200 Subject: minimal pseudo code for encrypting message to multiple recipients In-Reply-To: (Tim Prepscius's message of "Thu, 25 Jul 2013 12:32:05 -0400") References: Message-ID: <87hafi4exp.fsf@vigenere.g10code.de> On Thu, 25 Jul 2013 18:32, timprepscius at gmail.com said: > I'm actually looking for pseudo code for a minimal implementation of pgp-mime. You may want to look at gnupg/tools/gpgparsemail.c for a parser. Building messages is actually more trivial; maybe gpgol/src/mimemaker.c is of some help. Well, not pseudo code. For pseudo code you should just read RFC-3156 which has a lot of good examples. > And that perhaps a full implementation is the *only* implementation. Creating PGP/MIME is really simple. > A minimal pgp-mime. > > 1. Canonicalize message. > 2. Write a "encrypted/pgp-mime" mime-part. > 3. Within mime-part write b64(encrypt(canon-message)). Depends on whether you want to sign or encrypt. Encrypt is easy; really easy I mean. It is just a fixed block. > Where encrypt is "rsa(aes-256-key) + aes-256(message) + > sha-256(previously written bytes)" Nope: That is more complicated, you need to read the OpenPGP standard. Don't even try to come up with your own encryption protocol. > Some indicator of encryption version used. And my public key. Sending the public key is not common with OpenPGP - You send it out of band. Only S/MIME resorts to this kludged due to the non-standardized way of looking up keys (Oh well, unless you use the global X.500 directory ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Jul 25 22:12:51 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 25 Jul 2013 16:12:51 -0400 Subject: minimal pseudo code for encrypting message to multiple recipients In-Reply-To: References: Message-ID: <51F186C3.1010908@fifthhorseman.net> On 07/25/2013 12:32 PM, Tim Prepscius wrote: > This is going to be part of a web client: java -> gwt -> javascript. > No C code. [...] > A minimal pgp-mime. Your requirements sound very specific, and perhaps make this list not the best place for this question. This list is about the development of GnuPG, which is written in C. If you just want a javascript implementation of OpenPGP, you might be interested in: http://openpgpjs.org/ I don't have any good recommendations for javascript libraries for encapsulating the MIME objects, but basic MIME encapsulation is pretty straightforward text manipulation, and the PGP/MIME specification is pretty clear: https://tools.ietf.org/html/rfc3156 hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From timprepscius at gmail.com Thu Jul 25 23:37:05 2013 From: timprepscius at gmail.com (Tim Prepscius) Date: Thu, 25 Jul 2013 17:37:05 -0400 Subject: minimal pseudo code for encrypting message to multiple recipients In-Reply-To: <87hafi4exp.fsf@vigenere.g10code.de> References: <87hafi4exp.fsf@vigenere.g10code.de> Message-ID: Thank you for this. I'm looking at mimemaker.c now. -tim On 7/25/13, Werner Koch wrote: > On Thu, 25 Jul 2013 18:32, timprepscius at gmail.com said: > >> I'm actually looking for pseudo code for a minimal implementation of >> pgp-mime. > > You may want to look at gnupg/tools/gpgparsemail.c for a parser. > Building messages is actually more trivial; maybe gpgol/src/mimemaker.c > is of some help. Well, not pseudo code. For pseudo code you should > just read RFC-3156 which has a lot of good examples. > >> And that perhaps a full implementation is the *only* implementation. > > Creating PGP/MIME is really simple. > >> A minimal pgp-mime. >> >> 1. Canonicalize message. >> 2. Write a "encrypted/pgp-mime" mime-part. >> 3. Within mime-part write b64(encrypt(canon-message)). > > Depends on whether you want to sign or encrypt. Encrypt is easy; really > easy I mean. It is just a fixed block. > >> Where encrypt is "rsa(aes-256-key) + aes-256(message) + >> sha-256(previously written bytes)" > > Nope: That is more complicated, you need to read the OpenPGP standard. > Don't even try to come up with your own encryption protocol. > >> Some indicator of encryption version used. And my public key. > > Sending the public key is not common with OpenPGP - You send it out of > band. Only S/MIME resorts to this kludged due to the non-standardized > way of looking up keys (Oh well, unless you use the global X.500 > directory ;-) > > > > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > From eric at regit.org Fri Jul 26 14:38:09 2013 From: eric at regit.org (Eric Leblond) Date: Fri, 26 Jul 2013 14:38:09 +0200 Subject: gpgme optimisation for multiple checks Message-ID: <1374842289.3998.16.camel@tiger2> Hello, I'm a newbie in GPGME usage and I apologize in advance for that question. I would like to know how I can optimize a software that is doing multiple verifications of signatures. I'm reusing the context but it seems this is not enough and I observer a fork of a gpg server for each signature verification. I've tried to use the disable 'reset feature' available by patching and rebuilding gpgme code but this does not seem to work. --- gpgme1.0-1.4.2.orig/src/verify.c +++ gpgme1.0-1.4.2/src/verify.c @@ -884,7 +884,7 @@ gpgme_op_verify (gpgme_ctx_t ctx, gpgme_ if (!ctx) return TRACE_ERR (gpg_error (GPG_ERR_INV_VALUE)); - err = verify_start (ctx, 1, sig, signed_text, plaintext); + err = verify_start (ctx, 257, sig, signed_text, plaintext); if (!err) err = _gpgme_wait_one (ctx); return TRACE_ERR (err); It works for a few signatures but then crash. BR, -- Eric Leblond Blog: https://home.regit.org/ From wk at gnupg.org Fri Jul 26 17:47:12 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 26 Jul 2013 17:47:12 +0200 Subject: gpgme optimisation for multiple checks In-Reply-To: <1374842289.3998.16.camel@tiger2> (Eric Leblond's message of "Fri, 26 Jul 2013 14:38:09 +0200") References: <1374842289.3998.16.camel@tiger2> Message-ID: <87ehal2uin.fsf@vigenere.g10code.de> On Fri, 26 Jul 2013 14:38, eric at regit.org said: > I would like to know how I can optimize a software that is doing > multiple verifications of signatures. > I'm reusing the context but it seems this is not enough and I observer a Right, this is what you should do. However, it does not matter in practice when using gpg (gpgsm is a bit better in this regard). The idea is that we can improve gpgme and all applications would benefit from that improvement. What is missing in gpg is a server mode so that gpg can be run by gpgme as a coprocess. There is some very basic support for this but it is far from being complete. Up until now there was no real pressure to finish that feature. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Fri Jul 26 18:26:29 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 26 Jul 2013 12:26:29 -0400 Subject: Identify a gpg file In-Reply-To: <87li4u4fc1.fsf@vigenere.g10code.de> References: <51EDCC3D.4010007@guardianproject.info> <87k3ke7m42.fsf@vigenere.g10code.de> <51F13EC5.4080100@guardianproject.info> <87txji62x7.fsf_-_@vigenere.g10code.de> <51F1702E.5050707@guardianproject.info> <87li4u4fc1.fsf@vigenere.g10code.de> Message-ID: <51F2A335.4050508@guardianproject.info> On 07/25/2013 03:19 PM, Werner Koch wrote: > On Thu, 25 Jul 2013 20:36, hans at guardianproject.info said: > >> extensions by default everywhere. So things like .pkr for public keys, .skr >> for private keys, .sig for binary detach-sign, etc. Any specific format that > > With two drawbacks: You need to have a filename and you need extra code > to handle data with a wrong suffix. Yes, that happends. > >> should avoid adding the ambiguous extensions, like .gpg, .pgp, .asc, but > > That is easy. GPGME does not know anything about suffixes and with GPG > you should specificy the filename anyway yourself. The extensions are > only used by default for convenience. GPGME does not need to know about file extensions but gpg does since it is automatically adding file extensions to files that it generates. The file extensions should be standardized across all OpenPGP implementation, this will make it possible to people to double-click the files and have the right app open, and have that app be able to walk the user thru the right procedure for that data type. >> As a side note, the file-5.14 detection could use some improvement. Its not >> detecting keys and detached signatures as something distinct. It seems that >> the logic in gpa/src/filetype.c could be contributed to file. > > Last time I checked file(1) uses a not too simple pattern matching > system, thus it is not easy to re-use the code - but possible. Hopefully I'll find some time to look into that. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From mmn at hethane.se Tue Jul 30 00:40:40 2013 From: mmn at hethane.se (Mikael Nordfeldth) Date: Tue, 30 Jul 2013 00:40:40 +0200 Subject: --batch --gen-key error with "Key-Type: default" In-Reply-To: <87iozx37fo.fsf@vigenere.g10code.de> References: <51F1958A.9000203@hethane.se> <51F24B79.9030107@hethane.se> <87iozx37fo.fsf@vigenere.g10code.de> Message-ID: <51F6EF68.7040707@hethane.se> 2013-07-26 13:08, Werner Koch skrev: > On Fri, 26 Jul 2013 12:12, mmn at hethane.se said: > >> Nevertheless, is there any interest in making gnupg 1.x support the >> 'default' algorithm feature? > No. [...] > > However, if it is a simple change, I would accept it, anyway. In master > this was commit 49b00ffd. Something like the attached patch? I made it the same defaults as gnupg2 has (RSA-2048). The code is almost entirely copied from 49b00ffd. It applies cleanly to gnupg-1.4.14 and current state of STABLE-BRANCH-1-4 The only thing I haven't added was a changelog entry explaining the differences like the changelog entry for 49b00ffd: * keygen.c (DEFAULT_STD_ALGO, DEFAULT_STD_KEYSIZE): New. (ask_keysize): Use new macro. (gen_rsa): Set default size if NBITS is 0. (get_parameter_algo): Add algo name "default". Add arg R_DEFAULT. (proc_parameter_file): Process default flag. Essentially the only thing (except for some line layouts and indentations) I had to modify to fit gnupg1.x was the algorithm numerical ID mapping macro (#define DEFAULT_STD_ALGO is set to PUBKEY_ALGO_RSA instead of GCRY_PK_RSA, both equaling numeric 1 for RSA) checks/tests run as they should. Keep note though that I am not the most experienced C developer and I encourage others to verify the patch as I may have missed some small detail in difference between gnupg and gnupg2. But I made sure at least that there are no left over unchanged get_parameter_algo calls or anything. -- Mikael Nordfeldth http://blog.mmn-o.se/ Xmpp/mail: mmn at hethane.se -------------- next part -------------- A non-text attachment was scrubbed... Name: default_key_type_backport_from_gnupg2_to_gnupg1.patch Type: text/x-patch Size: 9549 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: