From goncc123rr at gmail.com Mon Aug 1 01:38:08 2016 From: goncc123rr at gmail.com (Dylan Wang (Hyu)) Date: Mon, 01 Aug 2016 07:38:08 +0800 Subject: Suddenly unable to use gpg-agent with putty In-Reply-To: <20160731152014.000033e4@seibercom.net> References: <20160731152014.000033e4@seibercom.net> Message-ID: I'm using putty 0.66, just upgrading to latest 0.67 and problem still, and I found that pageant tray not appear in my taskbar (I remember it's there when I using gpg2.0) right now if Iexecute pageant manually without open putty, it will shows, but if I opened putty, I can't find pagaent in my process list and even after I close putty, excute pageant will give me pageant is alreay running error. No idea what's happening here, should this be normal case? On ??, 8? 1, 2016 at 3:20 ??, Jerry wrote: On Sun, 31 Jul 2016 16:03:37 +0000, Dylan Wang stated: >Putty gives me disconnected no supported authentication methods error, >and not asking me for pinentry pin, but I could do git sign without >problem. I didn't change server settings all my server can't ssh with >putty now, and I double check sshcontrol file, it doesn't change and >correctly configured, also enable-putty-support is in my >gpg-agent.conf. I tried everything I could do, re-plug my keys, >reboot, reinstall & configure gnupg, restart gpg-agent...my settings >always works well on the past few months. Right now I completely can't >figure out what's happened here, I'm running gpg 2.1.14 on windows 10, >below are the detailed log for gpg-agent: > >? gpg-agent --daemon --verbose --debug-level guru >--enable-putty-support gpg-agent[12792]: enabled debug flags: command >mpi crypto memory cache memstat hashing ipc >gpg-agent[12792]: listening on socket >'C:\Users\goncc\AppData\Roaming\gnupg\S.gpg-agent' >gpg-agent[12792]: gpg-agent (GnuPG) 2.1.14 started >gpg-agent[12792]: putty message loop thread started >gpg-agent[12792]: handler 0x4 for fd 496 started >gpg-agent[12792]: DBG: chan_0x000001f0 -> OK Pleased to meet you >gpg-agent[12792]: DBG: chan_0x00000270 <- OK Pleased to meet you >gpg-agent[12792]: DBG: chan_0x00000270 -> GETINFO pid >gpg-agent[12792]: DBG: chan_0x000001f0 <- GETINFO pid >gpg-agent[12792]: DBG: chan_0x000001f0 -> D 12792 >gpg-agent[12792]: DBG: chan_0x00000270 <- D 12792 >gpg-agent[12792]: DBG: chan_0x000001f0 -> OK >gpg-agent[12792]: DBG: chan_0x00000270 <- OK >gpg-agent[12792]: DBG: chan_0x00000270 -> BYE >gpg-agent[12792]: DBG: chan_0x000001f0 <- BYE >gpg-agent[12792]: DBG: chan_0x000001f0 -> OK closing connection >gpg-agent[12792]: handler 0x4 for fd 496 terminated > >Much appreciate if someone could help me or give me some advice on how >to debug this. > >Thanks, >Dylan > What version of PUTTY are you using? -- Jerry _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lachlan at twopif.net Mon Aug 1 07:31:15 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Mon, 1 Aug 2016 15:01:15 +0930 Subject: DKIM and email address proof-of-control Message-ID: <5596d79c-5257-4c40-1cba-08af9f870a34@twopif.net> Hello, Has anyone had a go at using DKIM signatures as a way of verifying control of an email address with GPG? I've seen a few mentions of the idea online, particularly here: https://security.stackexchange.com/questions/107417/pgp-key-signing-robot-dkim-verified-emails/ https://github.com/keybase/keybase-issues/issues/373 I'm thinking of building a robot-CA-type arrangement that includes either a DKIM signature or a link to one in a signature notation. By including the fingerprint in such a way that the canonicalisation doesn't allow it to be hidden from the user, it would allow us to use existing infrastructure to demonstrate that the mail provider allows a user to send mail from an address, without individual users having to request the key in the first instance in order to use TOFU. The idea wouldn't be to replace the web of trust or long-term TOFU, but to provide a service like PGP Global Directory that doesn't have a central point of failure. Some of the problems that I can see: 1. Is the assumption valid that (absent server or endpoint compromise) only a user authorised by the provider can get a DKIM signature on mail with a From address from that provider? We need to be careful to avoid allowing people to get a signature in the name of a mailing list, for example. This may be possible to solve via whitelisting. 2. Is there anything that can get lost in the canonicalisation? For example, a mailto: link might provide an apparently-blank message with a fingerprint at the bottom after a screenfull of newlines. My experiments with Gmail and Thunderbird suggest that this cannot be easily done with the subject line, making that the best place to put the fingerprint. 3. How do you protect against attacks involving reply-to? Is the lack of a Re: in the subject line sufficiently convincing? 4. Given that DNSSec isn't universal, can we do better than trusting DNS results for the public key queries without just shifting the single point of failure somewhere else? 5. This only validates the email address, not the name. I'm not aware of any way to signal this without a custom notation, though I would be most pleased to hear otherwise. If there is a catastrophic flaw in the idea, then any feedback would be very much appreciated. Thanks, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Mon Aug 1 11:49:48 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 1 Aug 2016 10:49:48 +0100 Subject: DKIM and email address proof-of-control In-Reply-To: <5596d79c-5257-4c40-1cba-08af9f870a34@twopif.net> References: <5596d79c-5257-4c40-1cba-08af9f870a34@twopif.net> Message-ID: <18010525427.20160801104948@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Monday 1 August 2016 at 6:31:15 AM, in , Lachlan Gunn wrote: > Hello, > Has anyone had a go at using DKIM signatures as a > way of verifying > control of an email address with GPG? > I've seen a few mentions of the idea online, > particularly here: > https://security.stackexchange.com/questions/107417/pgp-key-signing-robot-dkim-verified-emails/ > > https://github.com/keybase/keybase-issues/issues/373 [snipped] > Some of the problems that I can see: > 1. Is the assumption valid that (absent server or > endpoint compromise) > only a user authorised by the provider can get a > DKIM signature on mail > with a From address from that provider? The links you provided point out that DKIM certifies only the domain of the email address, not the user part. The From address in the email header may not be the same as the MAIL FROM part of the SMTP dialogue. It might be that the first is trusted at example.com while the second is attacker at example.com. And both may differ from the credentials used to sign into the SMTP server. > 3. How do you protect against attacks involving > reply-to? Is the lack > of a Re: in the subject line sufficiently convincing? IMHO, no. What about:- reply numbering, such as "Re[2]:"? Non-english versions, such as "Aw:"? changed subject lines, for example to begin with a help ticket number or simply to make the subject match the content? - -- Best regards MFPA My mind works like lightning... one brilliant flash and it's gone -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJXnxtFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwHWoH+wQHHdece6Q7eWz5jttIUeoR H6VTG6zGUgHKxlWSSG36RPlwkVOyoAayvEf0EJtliJa7RqgxiLdvoYAUkDN9K8eU 2YTGMSru0Mn+4W4iSqp2F5jiYXseAO8+EF4rgMqvIlg/ysbRSwhVEPMVqW34RrYZ ycMdLGWzxLe//obvi9Ddn++9eA/cRzpReIQUbdNkvA3iXSeTYjHZNTaU4DngdoJN x8b4UlCBxbDj9tkWgHGipc75YXllmKlW+Y/9c2+xq4E6gpiblGcOcEt6hKvhSpC/ uVLKCxPy8B4QvSRUDSENVrv3b2m+sctL7dt7H0mdWSMLH172fgybk+Q1N7V93WOI vgQBFgoAZgUCV58bW18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45EcDAP97Ag7JxcmwQqOzXDXAe702jtP2 qeTh9oi4tMSdb0buvwD9HqUju3uUKYYAOVHZi97u3+axuiIRsbSw8Yt/8oWTWQU= =YevK -----END PGP SIGNATURE----- From whitey at mixnym.net Mon Aug 1 17:54:36 2016 From: whitey at mixnym.net (whitey at mixnym.net) Date: Mon, 01 Aug 2016 15:54:36 -0000 Subject: Which GPG version? Message-ID: Hello, I see that there are three versions of GnuPG available. Assuming no hardware constraints, is there any reason to choose Classic 1.4 or Stable 2.0 instead of Modern 2.1? It appears to do everything the others can and more. Whitey From peter at digitalbrains.com Mon Aug 1 19:28:25 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 1 Aug 2016 19:28:25 +0200 Subject: Which GPG version? In-Reply-To: References: Message-ID: <924b4b23-07c2-3264-25e4-fdf1bf6b5a59@digitalbrains.com> On 01/08/16 17:54, whitey at mixnym.net wrote: > I see that there are three versions of GnuPG available. Assuming no hardware > constraints, is there any reason to choose Classic 1.4 or Stable 2.0 instead > of Modern 2.1? It appears to do everything the others can and more. I think usually the constraints are software constraints. But 1.4 might be more appropriate in for instance a headless server. I suppose that counts as a hardware constraint indeed :-). I'd say, go for 2.1. I think 2.0 is more for people who wish to stick to 2.0 for whatever reason. If you don't have any particular motivation to use 2.0 or 1.4, you should go for 2.1. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From johanw at vulcan.xs4all.nl Mon Aug 1 19:53:17 2016 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Mon, 01 Aug 2016 19:53:17 +0200 Subject: Which GPG version? In-Reply-To: References: Message-ID: <579F8C8D.6030302@vulcan.xs4all.nl> On 01-08-2016 17:54, whitey at mixnym.net wrote: > I see that there are three versions of GnuPG available. Assuming > no hardware constraints, is there any reason to choose Classic 1.4 > or Stable 2.0 instead of Modern 2.1? It appears to do everything > the others can and more. It does not. If you want to be able to read pgp 2.x encoded archives you'd better go for 1.4. If you insist on using elleptic curve keys you need 2.1. As for 2.0 and 2.1, I think the interface of 2.0 is more stable so if you use scripting, a 2.1 update might break it. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From peter at digitalbrains.com Mon Aug 1 21:12:21 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 1 Aug 2016 21:12:21 +0200 Subject: Which GPG version? In-Reply-To: <579F8C8D.6030302@vulcan.xs4all.nl> References: <579F8C8D.6030302@vulcan.xs4all.nl> Message-ID: <33e3d1ec-24e3-2dfa-74d9-d4073153350f@digitalbrains.com> On 01/08/16 19:53, Johan Wevers wrote: > It does not. If you want to be able to read pgp 2.x encoded archives you'd > better go for 1.4. Incidentally, for this use case I'd personally recommend to use 2.1 for everything except accessing those ancient archives, and just use 1.4 for that, if that is something that works for you. > I think the interface of 2.0 is more stable so if you use scripting, a 2.1 > update might break it. I'm sure you know, but the OP might not: in this case, you're scripting in a way not approved by the GnuPG devs, i.e., using interfaces meant for humans instead of machines. 2.1 even has some functions that 2.0 does not with regard to easy scripting (--quick-add-[stuff] and friends). I don't know whether there is stuff that 2.0 can do that 2.1 can't at the moment, though (which is different from stability, it's feature completeness). HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From patrick at enigmail.net Mon Aug 1 21:48:08 2016 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 1 Aug 2016 21:48:08 +0200 Subject: Which GPG version? In-Reply-To: <924b4b23-07c2-3264-25e4-fdf1bf6b5a59__9784.89141348309$1470072572$gmane$org@digitalbrains.com> References: <924b4b23-07c2-3264-25e4-fdf1bf6b5a59__9784.89141348309$1470072572$gmane$org@digitalbrains.com> Message-ID: On 01.08.16 19:28, Peter Lebbing wrote: > On 01/08/16 17:54, whitey at mixnym.net wrote: >> I see that there are three versions of GnuPG available. Assuming no hardware >> constraints, is there any reason to choose Classic 1.4 or Stable 2.0 instead >> of Modern 2.1? It appears to do everything the others can and more. > > I think usually the constraints are software constraints. But 1.4 might be more > appropriate in for instance a headless server. I suppose that counts as a > hardware constraint indeed :-). > > I'd say, go for 2.1. I think 2.0 is more for people who wish to stick to 2.0 for > whatever reason. If you don't have any particular motivation to use 2.0 or 1.4, > you should go for 2.1. I see the world a little different :-) 2.1 is the current development branch, where we sometimes see heavy changes that can cause bugs, crashes and incompatibilities with other software. 2.0 is stable and only receives a limited number of well-tested changes and security fixes. If you want to try new features like curve-based encryption, or if you are a developer, then go for 2.1. Otherwise, if you are a regular end-user, then go for 2.0 and wait with upgrading until 2.1 has become mature. This will result in 2.2 being released. Patrick From dkg at fifthhorseman.net Mon Aug 1 22:37:23 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 01 Aug 2016 16:37:23 -0400 Subject: Which GPG version? In-Reply-To: <33e3d1ec-24e3-2dfa-74d9-d4073153350f@digitalbrains.com> References: <579F8C8D.6030302@vulcan.xs4all.nl> <33e3d1ec-24e3-2dfa-74d9-d4073153350f@digitalbrains.com> Message-ID: <87r3a8dy4c.fsf@alice.fifthhorseman.net> On Mon 2016-08-01 15:12:21 -0400, Peter Lebbing wrote: > On 01/08/16 19:53, Johan Wevers wrote: >> It does not. If you want to be able to read pgp 2.x encoded archives you'd >> better go for 1.4. > > Incidentally, for this use case I'd personally recommend to use 2.1 for > everything except accessing those ancient archives, and just use 1.4 for that, > if that is something that works for you. > >> I think the interface of 2.0 is more stable so if you use scripting, a 2.1 >> update might break it. > > I'm sure you know, but the OP might not: in this case, you're scripting in a way > not approved by the GnuPG devs, i.e., using interfaces meant for humans instead > of machines. > > 2.1 even has some functions that 2.0 does not with regard to easy scripting > (--quick-add-[stuff] and friends). I don't know whether there is stuff that 2.0 > can do that 2.1 can't at the moment, though (which is different from stability, > it's feature completeness). fwiw, i agree with Peter that 2.1 appears at the moment to be better for all use cases except for parsing archives of old documents that use formats we currently believe to be at least partially broken. --dkg From lachlan at twopif.net Tue Aug 2 03:32:17 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Tue, 2 Aug 2016 11:02:17 +0930 Subject: DKIM and email address proof-of-control In-Reply-To: <18010525427.20160801104948@riseup.net> References: <5596d79c-5257-4c40-1cba-08af9f870a34@twopif.net> <18010525427.20160801104948@riseup.net> Message-ID: <31f732aa-defe-23a0-9e66-15fa057d50fd@twopif.net> Hi, thanks for the response. > The links you provided point out that DKIM certifies only the domain > of the email address, not the user part. The From address in the email > header may not be the same as the MAIL FROM part of the SMTP dialogue. > It might be that the first is trusted at example.com while the second is > attacker at example.com. And both may differ from the credentials used to > sign into the SMTP server. That is true. My feeling that this is not a problem is based on two arguments: 1. Domain validation is fine because whoever controls the domain ultimately determines which user has which address. Any form of email validation is vulnerable to this, the best you can do is to try to detect such tampering by forcing them to put a public key onto SKS or such. This is still much better than what we have now, where we just have to trust that the Robot CA hasn't misissued a signature, an attacker needs to at least compromise each domain separately. 2. With Gmail at least, the From seems to be replaced with the account that I log in from, yielding the following (lachlan at twopif.net is a Google Apps address): From: Lachlan Gunn X-Google-Original-From: Lachlan Gunn I would have thought that any sane MTA would do either this or outright reject such an email, but maybe I'm overoptimistic. This is why I meant that whitelisting might be a good idea---if it is known that they have anti-spoofing measures in place then their signature has value, if not then no. > IMHO, no. What about:- > > reply numbering, such as "Re[2]:"? > > Non-english versions, such as "Aw:"? > > changed subject lines, for example to begin with a help ticket > number or simply to make the subject match the content? I guess I should clarify this to mean that the subject would have to be "VALIDATE-EMAIL-F3E3..." without any other text around it. Dashes are there so that misleading spacing cannot be canonicalised away. Subject lines wouldn't ever be changed and expected to remain valid, because the process would be "Send a blank email with the subject line "VALIDATE-EMAIL-". Thanks again for your comments, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Aug 2 11:29:58 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Aug 2016 11:29:58 +0200 Subject: Please, fix batch mode for gpg --edit-key-trust In-Reply-To: (John Buehrer's message of "Wed, 27 Jul 2016 15:46:19 +0200") References: Message-ID: <87shunmsbt.fsf@wheatstone.g10code.de> On Wed, 27 Jul 2016 15:46, john at zuri.ch said: > I'm surprised anything GNU doesn't automatically read input from a redirected STDIN, > that's Unix 101. It does. However, we have often need two input channels. For example for the data and the passphrase. You can't mix them. The edit interface is for human use only. If you want to to use it form a script you need to tell gpg about this with the option --command-fd and --status-fd. And you need to have write a FSM to properly interact with gpg's edit command. However, there is an easier solution: Switch to GnuPG 2.1 and use one of the --quick-* command for the most common edit operations. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From 2014-667rhzu3dc-lists-groups at riseup.net Tue Aug 2 11:37:53 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 2 Aug 2016 10:37:53 +0100 Subject: DKIM and email address proof-of-control In-Reply-To: <31f732aa-defe-23a0-9e66-15fa057d50fd@twopif.net> References: <5596d79c-5257-4c40-1cba-08af9f870a34@twopif.net> <18010525427.20160801104948@riseup.net> <31f732aa-defe-23a0-9e66-15fa057d50fd@twopif.net> Message-ID: <2910379436.20160802103753@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 2 August 2016 at 2:32:17 AM, in , Lachlan Gunn wrote: > 2. With Gmail at least, the From seems to be > replaced with the account > that I log in from, yielding the following > (lachlan at twopif.net is a > Google Apps address): > From: Lachlan Gunn > X-Google-Original-From: Lachlan Gunn > Does that mean you sent the email from the @gmail.com address, but because you happened to be logged in with the @twopif.net address Google took it upon themselves to change the from address? I wouldn't like that: it is not up to the email provider to choose which of my email addresses I expose to which contacts. > I would have thought that any sane MTA would do > either this or outright > reject such an email, but maybe I'm overoptimistic. Rejecting with a clear message indicating the reason makes more sense to me. > This is why I meant > that whitelisting might be a good idea---if it is > known that they have > anti-spoofing measures in place then their signature > has value, if not > then no. Even if they have such measures in place, the account may have extra addresses or aliases configured to send messages (GMX, Gmail, Yahoo, Riesup all allow this in slightly differing forms). Presumably a signature from a provider that allows this would have lower value than one from a provider that does not, but higher valve than one from a provider who was not known to have anti-spoofing measures in place? > I guess I should clarify this to mean that the > subject would have to be > "VALIDATE-EMAIL-F3E3..." without any other text > around it. Dashes are > there so that misleading spacing cannot be > canonicalised away. Subject > lines wouldn't ever be changed and expected to > remain valid, because the > process would be "Send a blank email with the > subject line > "VALIDATE-EMAIL-". In that case, what attacks involving reply-to are you wishing to protect against? - -- Best regards MFPA A nod is as good as a wink to a blind bat! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJXoGnyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwBRcH/33cCcYFBvBYKcvqAkDHjyzp EWkNZ+LDRDo6Fj8CXkvbFOyvd7f48OMPe2GDBeuS5wCIC2NmnzrdjkYs5O7npp6X YY7H9tbM4E1dq6SW0YHJyQCHphUTZZHMIsWbaumlKTCdPDvSzLeL75oOTO6L9aoI PFAyMNUT56pFVQmA+lMO1kTsTi+B9Dl8ZnKULczpdnmqukqAhmxEflBjhWDNm1JM jlkPQ4kwaDh6zrVo7/Id94wIaEEagGG1cTFbe5rn0DhDtJh0wVvv8bH7wIW3jbTs bQCp3xsfGtqMds7tJ89LL3Vo6uCwIf+ovJ6qApW3gdp9P6+kdOFDl2mO0EtdaxuI vgQBFgoAZgUCV6Bp8l8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45F4kAP95nRhcsrRx1oeLbswMcoUanhFO KjiyY43lnLA0jyHf0wD/egCqkI+8woiZc3UssntGQQw8jxPPixoVbZhTGOjNUw8= =R+Vw -----END PGP SIGNATURE----- From wk at gnupg.org Tue Aug 2 12:14:24 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Aug 2016 12:14:24 +0200 Subject: improvements for "Git Access" page In-Reply-To: (Filipp Gunbin's message of "Mon, 25 Jul 2016 17:44:46 +0300") References: Message-ID: <87shunlbpb.fsf@wheatstone.g10code.de> On Mon, 25 Jul 2016 16:44, fgunbin at fastmail.fm said: > - page url is https://www.gnupg.org/download/cvs_access.html , while > it's certainly not "cvs" now. Or was "vcs" meant? It is CVS because in 1997 we not even had Subversion. Changing existing URLs is a no-go. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From lachlan at twopif.net Tue Aug 2 13:07:14 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Tue, 2 Aug 2016 20:37:14 +0930 Subject: DKIM and email address proof-of-control In-Reply-To: <2910379436.20160802103753@riseup.net> References: <5596d79c-5257-4c40-1cba-08af9f870a34@twopif.net> <18010525427.20160801104948@riseup.net> <31f732aa-defe-23a0-9e66-15fa057d50fd@twopif.net> <2910379436.20160802103753@riseup.net> Message-ID: > Does that mean you sent the email from the @gmail.com address, but > because you happened to be logged in with the @twopif.net address > Google took it upon themselves to change the from address? I wouldn't > like that: it is not up to the email provider to choose which of my > email addresses I expose to which contacts. I mean that I connect to Google's SMTP server with Thunderbird using the "lachlan at twopif.net" login details, but configure the account's email address to be lachlan.gunn at gmail.com, so that From: and MAIL FROM are both @gmail. > Rejecting with a clear message indicating the reason makes more sense > to me. Yes, however I expect that they decided that it would generate too much confusion if people who mis-spelt their email address slightly were unable to send mail. > Even if they have such measures in place, the account may have extra > addresses or aliases configured to send messages (GMX, Gmail, Yahoo, > Riesup all allow this in slightly differing forms). Presumably a > signature from a provider that allows this would have lower value than > one from a provider that does not, but higher valve than one from a > provider who was not known to have anti-spoofing measures in place? I'm not sure exactly what you mean, but I don't think the existence of such aliases is a problem---unless I misunderstand, ultimately the sender still controls the alias, and it is no different from any other email address in that respect. > In that case, what attacks involving reply-to are you wishing to > protect against? The main thing is to prevent things like putting request at roboca into the to: field in a mass email and then bank on someone hitting reply-to-all, or by putting it into Reply-To. Checking the subject line seems fairly reasonable, and requiring an email in response to one the CA---In-Reply-To is signed in my test messages, you can use a signature as the message ID---ought to make things more difficult for anyone but the CA. Thanks, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Tue Aug 2 16:05:53 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 2 Aug 2016 15:05:53 +0100 Subject: DKIM and email address proof-of-control In-Reply-To: References: <5596d79c-5257-4c40-1cba-08af9f870a34@twopif.net> <18010525427.20160801104948@riseup.net> <31f732aa-defe-23a0-9e66-15fa057d50fd@twopif.net> <2910379436.20160802103753@riseup.net> Message-ID: <1579442642.20160802150553@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tuesday 2 August 2016 at 12:07:14 PM, in , Lachlan Gunn wrote: > I mean that I connect to Google's SMTP server with > Thunderbird using the > "lachlan at twopif.net" login details, but configure > the account's email > address to be lachlan.gunn at gmail.com, so that From: > and MAIL FROM are > both @gmail. And, from your previous post, Google takes it upon themselves to change the "From:" header to "Lachlan Gunn " and insert a new "X-Google-Original-From:" header containing the detail from your original "From:" header. So Google chooses to expose two of your email addresses to the recipient instead of just the one you used for that message. To me that is not good. But to bring it back on-topic, would a DKIM signature on such a message be for the gmail.com domain or the twopif.net domain? > I'm not sure exactly what you mean, but I don't > think the existence of > such aliases is a problem---unless I misunderstand, > ultimately the > sender still controls the alias, and it is no > different from any other > email address in that respect. You're right. The DKIM signature says that the email was sent from _an_ authorised account at that domaim but not _which_ authorised account, so I guess it doesn't matter if the email address is an alias. > The main thing is to prevent things like putting > request at roboca into the > to: field in a mass email and then bank on someone > hitting reply-to-all, > or by putting it into Reply-To. Is this a Denial of Service attack, rather than an attempt to get roboca to certify something it shouldn't? > Checking the subject line seems fairly reasonable, > and requiring an > email in response to one the CA---In-Reply-To is > signed in my test > messages, you can use a signature as the message > ID---ought to make > things more difficult for anyone but the CA. I thought the message-ID had to end in a fully qualified domain name. - -- Best regards MFPA Do what you can, with what you have, where you are. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJXoKjFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwFl0IAL1HHiElzNQi2VuxAxlycvGE eJ8vO3MNoPAXpY7hNByUU9X2TSPk1hmip2JM3Jv3MeZuxklFQceMVcCmcqTl52iD /mWm6jXooMZMJdbsl4yE/AEhd4vlioXPIzmvRZ8JIHXnZ221qdpRZkwQoyRvWTmj fmIZu26d5ghY0dsOOQMD5vkCLR120dYpDj2N6fZvV9jZ/UqfbHGf8IGkM1iYashL rYgYkN3ngyw45hN5XL0VzVeRiqUMCbzjom6414p49Jw6KaBHoZzPOMb0DGEEbhE0 S/EyoDiCazhhe9ABlUE4tEfdLiVba0/K6roJcalraac3g3UL92wt2WBzel8L11WI vgQBFgoAZgUCV6Co0F8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45ET0AQCBbxecjM2YUHpOjRwNKQVHiKn7 khgG1DB6CRhyPwYq4AEA1vz7ZwGnh/5ekfdBDxUTY/CZjO/wtEFGhP1OTRI/wwY= =xYP5 -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Tue Aug 2 17:06:40 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 02 Aug 2016 11:06:40 -0400 Subject: improvements for "Git Access" page In-Reply-To: <87shunlbpb.fsf@wheatstone.g10code.de> References: <87shunlbpb.fsf@wheatstone.g10code.de> Message-ID: <874m73dxbz.fsf@alice.fifthhorseman.net> On Tue 2016-08-02 06:14:24 -0400, Werner Koch wrote: > On Mon, 25 Jul 2016 16:44, fgunbin at fastmail.fm said: > >> - page url is https://www.gnupg.org/download/cvs_access.html , while >> it's certainly not "cvs" now. Or was "vcs" meant? > > It is CVS because in 1997 we not even had Subversion. Changing existing > URLs is a no-go. but a permanent HTTP 301 or 302 redirect to a URL that matches the current state of the world is OK, right? --dkg From wk at gnupg.org Tue Aug 2 18:26:05 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Aug 2016 18:26:05 +0200 Subject: improvements for "Git Access" page In-Reply-To: <874m73dxbz.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 02 Aug 2016 11:06:40 -0400") References: <87shunlbpb.fsf@wheatstone.g10code.de> <874m73dxbz.fsf@alice.fifthhorseman.net> Message-ID: <87r3a7i1cy.fsf@wheatstone.g10code.de> On Tue, 2 Aug 2016 17:06, dkg at fifthhorseman.net said: > but a permanent HTTP 301 or 302 redirect to a URL that matches the > current state of the world is OK, right? Okay, okay. The canonical URL is now https://gnupg.org/download/git.html with redirects for cvs_access.html and download/cvs_access.html. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From marcel.behlau at elfin.de Tue Aug 2 18:33:30 2016 From: marcel.behlau at elfin.de (Marcel Behlau) Date: Tue, 2 Aug 2016 18:33:30 +0200 Subject: Reduce GPGME memory usage Message-ID: <390e08e7-2884-6169-9139-db0ac0c41ba3@elfin.de> Hi, i'm using gpgme for encryption and signing of updates for an embedded linux system. The old version worked fine, now i have to port the stuff to a new system with fewer RAM and bigger update files. This generates some problems , if the maximum RAM is used, caused by to big update files. In my workflow, i'm compare the signer keys of the updatefiles and the expected keys, but the "gpgme_get_key" functions fails with a "Invalid crypto engine" error. Is the error message correct at this position? The gpgme_op_decrypt_verify, gpgme_op_decrypt_result and gpgme_op_verify_result work before properly. The size of the update files will be reduced before the release, so i'm hoping, the system will finaly work. But this is very critical, if someday, the applications, which are running on the system, using to much RAM. So 'm now trying to reduce the memory usage for the complete update process. My gpgme encrypted updatefile contains a single tar file, the tar file contains all necessary files for the update. I'm using libtar to extract the files to the installation path, libtar is working directly on the gpgme memory buffer. The complete update is stored during the process in the memory. This leads to the problems with to few RAM. Is there a way, to reduce the size of the gpgme memory buffer, maybe by reloading (and redecrypting ) data chunks from the orignal crypted update file? The original update file is loaded via stream. I found the " Callback Based Data Buffers" in the documation. It is possible, to use this buffers, to realize the reloading behavior? Thanks in advance, Marcel -- Dipl. Ing (FH) Marcel Behlau (Software Developer) ELFIN GmbH Siegburger Stra?e 215 50679 K?ln Germany Tel: +49 (221) 6778932-0 Fax: +49 (221) 6778932-2 marcel.behlau at elfin.de www.elfin.de From lachlan at twopif.net Wed Aug 3 03:42:36 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Wed, 3 Aug 2016 11:12:36 +0930 Subject: DKIM and email address proof-of-control In-Reply-To: <1579442642.20160802150553@riseup.net> References: <5596d79c-5257-4c40-1cba-08af9f870a34@twopif.net> <18010525427.20160801104948@riseup.net> <31f732aa-defe-23a0-9e66-15fa057d50fd@twopif.net> <2910379436.20160802103753@riseup.net> <1579442642.20160802150553@riseup.net> Message-ID: Le 2016-08-02 ? 23:35, MFPA a ?crit : > But to bring it back > on-topic, would a DKIM signature on such a message be for the > gmail.com domain or the twopif.net domain? It the key is from twopif.net, though obviously Google have the private key rather than myself. > Is this a Denial of Service attack, rather than an attempt to get > roboca to certify something it shouldn't? No, the idea is that you send an email to victim at example.com and roboca at roboca.com and when the victim hits reply-to-all the response goes to the CA as well. If such an email is considered acceptable, then an attacker who can get hold of the email now has a proof-of-sending. > I thought the message-ID had to end in a fully qualified domain name. Yes, you would do something like @roboca.net. But thinking about it further, this would mean that you couldn't mandate a clean subject line (no Re: etc.) without user intervention. I guess I'll go ahead and start building, then we'll see how it looks in practice. Thanks, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From chewmeek at gmail.com Wed Aug 3 08:25:11 2016 From: chewmeek at gmail.com (Chew Meek) Date: Wed, 3 Aug 2016 09:25:11 +0300 Subject: Novice mistake; where did the sks-keyservers.net sertificate go? (fresh Debian, firefox) In-Reply-To: References: Message-ID: Hello, The firefox browser didn't ask where to download the certificate, it just put it somewhere! Seems to me a bit difficult task to find it on my computer. Br, Chew -------------- next part -------------- An HTML attachment was scrubbed... URL: From riber at calico-jack.dk Wed Aug 3 09:32:51 2016 From: riber at calico-jack.dk (Mikkel Riber) Date: Wed, 3 Aug 2016 09:32:51 +0200 Subject: Unable to batch decrypt messages on Windows References: <000001d1cd30$6f1a1680$4d4e4380$@calico-jack.dk> <331517645.20160624191738@riseup.net> Message-ID: <000001d1ed59$3e7a74e0$bb6f5ea0$@calico-jack.dk> I looked into the code (not a c programmer - so won't comment if below behavior was intended or not) but managed to find some hints how to decrypt messages with --passphrase For me it was necessary to add --pinentry-mode loopback for it to work.. It now looks like this: gpg2 --decrypt --armor --pinentry-mode loopback --batch --passphrase XXXXX enc.txt Maybe other could find this usefull as well. -----Original Message----- From: Mikkel Riber [mailto:riber at calico-jack.dk] Sent: 4. juli 2016 07:07 To: 'MFPA' <2014-667rhzu3dc-lists-groups at riseup.net>; 'Mikkel Riber on GnuPG-Users' Subject: SV: Unable to batch decrypt messages on Windows Thank you very much for you input - much appreciated. Yes, it worked with empty password. Then it is possible to decrypt passwords without interaction. I would however prefer to have password - any suggestions to get this to work with password? -----Oprindelig meddelelse----- Fra: MFPA [mailto:2014-667rhzu3dc-lists-groups at riseup.net] Sendt: 24. juni 2016 20:18 Til: Mikkel Riber on GnuPG-Users Cc: Mikkel Riber Emne: Re: Unable to batch decrypt messages on Windows -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thursday 23 June 2016 at 10:20:06 AM, in , Mikkel Riber wrote: > Any input is welcome, thank you. Does it work if you simply use a key for which you have set an empty password? - -- Best regards MFPA You can't build a reputation on what you are going to do -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJXbXlLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwbNkH/19khCFnXCmwDW0NX4bnfaPe QTW78fKxCNdSWoknzVpQOa496LZwVUIt5PwPACm8a1+6/MPNB5XUwgjUazX797Wd n+6mM+G74iLawjQrPiXjjwDbEy4cGIkzjz5+To/jptNTNFSDWYKfVhWAe9TOw0Md tMWoqnmFfsd3UrbaCEryBgaNyu7EUhAzm6RU5hPwTrmLzQFgrI3pFR30GNWNQmcb QDqMJ7rihM7nrk4F+XgdwgKk/Hs61CQB3ZTgd4KAr90VNn+hbeoqQ7CUTZCiJs1M I6IdcuwX4i/Q9qKHGHbce/jsqk6Xsj+hkkcnvmQ/dTNLupmnch2TXy8Kmv7kPP6I vgQBFgoAZgUCV215WV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45OJFAQCiBzXyZOAjdZ14iaH97UOCppwy pbg6E/sBZK32d1BC+QEAvL0ofIhKrZcHtcBPb36Nlqs2Qij18F6dpY0VY8rYygg= =GJPe -----END PGP SIGNATURE----- From justus at g10code.com Wed Aug 3 14:54:30 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 03 Aug 2016 14:54:30 +0200 Subject: Reduce GPGME memory usage In-Reply-To: <390e08e7-2884-6169-9139-db0ac0c41ba3@elfin.de> References: <390e08e7-2884-6169-9139-db0ac0c41ba3@elfin.de> Message-ID: <87shumrp15.fsf@europa.jade-hamburg.de> Hello :) Marcel Behlau writes: > The old version worked fine, now i have to port the stuff to a new > system with fewer RAM and bigger update files. This generates some > problems , if the maximum RAM is used, caused by to big update files. In > my workflow, i'm compare the signer keys of the updatefiles and the > expected keys, but the "gpgme_get_key" functions fails with a "Invalid > crypto engine" error. Is the error message correct at this position? The > gpgme_op_decrypt_verify, gpgme_op_decrypt_result and > gpgme_op_verify_result work before properly. Did gpgme_get_key work before for you? Looking at the source of gpgme_get_key I see that it clones the context, so maybe you are setting up the context in a special way that makes it fail? Does the gpgme_op_keylist_start interface work for you? If you are able to construct a minimal test case, feel free to open a bug report. > The size of the update files will be reduced before the release, so i'm > hoping, the system will finaly work. But this is very critical, if > someday, the applications, which are running on the system, using to > much RAM. So 'm now trying to reduce the memory usage for the complete > update process. > > My gpgme encrypted updatefile contains a single tar file, the tar file > contains all necessary files for the update. I'm using libtar to extract > the files to the installation path, libtar is working directly on the > gpgme memory buffer. The complete update is stored during the process in > the memory. This leads to the problems with to few RAM. Is there a way, > to reduce the size of the gpgme memory buffer, maybe by reloading (and > redecrypting ) data chunks from the orignal crypted update file? The > original update file is loaded via stream. I found the " Callback Based > Data Buffers" in the documation. It is possible, to use this buffers, to > realize the reloading behavior? I just tried, and the callbacks can indeed be used to implement a streaming interface, e.g.: ~~~ snip ~~~ import sys import pyme def do_write(data): sys.stdout.write(chr(data[0])) return 1 data = pyme.Data(cbs=(None, do_write, None, lambda: None, None)) with pyme.Context() as c: c.decrypt(sys.stdin, sink=data) ~~~ snap ~~~ Likewise you can feed the source in smaller chunks to the engine. If that is not enough, you might want to look at TinyGPG, a library implementing a subset of the OpenPGP protocol, that is written with embedded systems in mind: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=tgpg.git;a=summary Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Aug 3 22:18:08 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 03 Aug 2016 16:18:08 -0400 Subject: Novice mistake; where did the sks-keyservers.net sertificate go? (fresh Debian, firefox) In-Reply-To: References: Message-ID: <87mvktbo8v.fsf@alice.fifthhorseman.net> On Wed 2016-08-03 02:25:11 -0400, Chew Meek wrote: > The firefox browser didn't ask where to download the certificate, it just > put it somewhere! Seems to me a bit difficult task to find it on my > computer. Try clicking the ? icon (downward-pointing arrow) to the left of the firefox address bar to see the recent downloads drawer, or pressing ctrl+shift+Y (or whatever your system's native keybindings are) to open up firefox's downloads window. from there, you should be able to see all the things you've downloaded and do operations like "open containing folder" which should help you find it. hth, --dkg From taltman at gmail.com Thu Aug 4 02:37:00 2016 From: taltman at gmail.com (taltman) Date: Wed, 3 Aug 2016 17:37:00 -0700 Subject: Advice on key set-up for work at employer Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I would like people's advice on the optimal set-up for the following scenario: I would like to use GPG encryption at my work, both for encrypting files and for protecting email correspondence. The trick is that I can image that at some point far in the future, if I need to leave my work for whatever reason, they'd want access to those files. The threat model here is, as an employee, I want to protect the corporate data as best as I can, but I trust my employers to have access to their own data. In other words, I'm not trying to hide anything from my employer. I also anticipate that while unlikely that they'd be interested in getting access to this data, I still need to provide a mechanism for them to retain access. I'm assuming that this will involve giving them access to the keyring files, and the password to the keyring . Assuming that I couldn't just re-encrypt everything to a different key at that far-flung date, and that I wouldn't want to forfeit my private key and password to my personal GPG keyring, I think that the following set up would be optimal: 1. Create a new GPG keyring specific for my identity with my employer 2. Cross-sign my existing personal GPG key with the employer-specific GPG key 3. Do proper key hygiene things (backups, revocation certs, etc.) on employer-specific key It seems with this set-up I can simply just turn over the password to the private key of the employer-specific GPG keyring if I'm ever obligated to give them access to their files. This keeps a nice clean separation between their property, and my personal GPG keyring. When it comes time to end my time at the employer, I can revoke the employer-specific key. If I no longer am able to use the employer-specific GPG keyring, I can at least revoke my signature of the employer-specific keyring if my former employer gains the password to the keyring. As far as I can tell, just creating a separate employer-specific set of signing/encrypting/authenticating sub-keys wouldn't be sufficient, but I'm open to someone showing me that I'm mistaken. I'd be interested in hearing people's thoughts on this scenario. Thanks in advance! Best regards, ~Tomer Altman - -- - --- Encrypted email preferred. GPG Public Key: https://bit.ly/1S5qWZJ Key fingerprint = DFE8 7D60 D452 9C4F 5D1F 7515 F55F BB30 1719 7991 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXoo4sAAoJEMAutzpeVLZSpfEP+wZVU9S+OwYQVvpIE0YVLzZP IzTdDuNePSxO2AtC+x3N8m1F+5Vv6caQj7Dry6XONDaDVhA3JUR0p2xBlE1Gd/+s DyTStaU0a/7lo+tenxB8rrSSt1nsFeeh6wRYC+ZW93/JjuaeC4dp0GHiiZFNEbnZ fGbALp3nhBKY7mhLq50X5nKCJhPt//arF4uK7NHVvP5Ttq88ngN3c6Dyx+LPnw2S EY8WoojsO74PchHPGJie2blbGwGS+Yq4Eh42GRCVQ+UB2Ko8vn9UfkI6/4NHvmgc B6bgqSET3Cgzt00pa641ZriTO75RZTCZ+zSYEEFyXzJti0vhUSX2XX0qABfxTOjs wnEUTqIO28gAkMk6cqWm0Pv/qmvfntA+Q/xyyp1im60xb/zsGA4xgqObDATFTyFG B/wk3bEElOHGpwXIIC78ITlBt+Oee25LyAuxZEXu6mrKZ3bFQySflYQTDS79jcyK uO4kUiBKiRbJDvDWth+v9PvPTxgZ14/bv8OqtEo9mHAz5gJWuo8BgtAjgizjGio0 zOUhcH4sQxwtNEU6VyJ9NKI/2MG7CkzwXAgndPN6LYLr6JJClrduhH+1+eHfEgoN jXeVFPlr9AMZe58ONXydbQ2jg/v6Kv5gHtvMnxzAsg3NB6tHYzWMoIpnvrXUjdiX M/QxHyEJbZWR/hgjoGiW =MOFm -----END PGP SIGNATURE----- From andrewg at andrewg.com Thu Aug 4 09:33:00 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 4 Aug 2016 08:33:00 +0100 Subject: Advice on key set-up for work at employer In-Reply-To: References: Message-ID: <818EDCFC-1771-49DC-AF5E-E8A2BD2F6A35@andrewg.com> On 4 Aug 2016, at 01:37, taltman wrote: *snip* > > 1. Create a new GPG keyring specific for my identity with my employer > 2. Cross-sign my existing personal GPG key with the employer-specific > GPG key > 3. Do proper key hygiene things (backups, revocation certs, etc.) on > employer-specific key > > It seems with this set-up I can simply just turn over the password to > the private key of the employer-specific GPG keyring if I'm ever > obligated to give them access to their files. This keeps a nice clean > separation between their property, and my personal GPG keyring. When it > comes time to end my time at the employer, I can revoke the > employer-specific key. If I no longer am able to use the > employer-specific GPG keyring, I can at least revoke my signature of the > employer-specific keyring if my former employer gains the password to > the keyring. Yes, this is the textbook case for having a separate primary key for a particular identity. I have implemented this myself. A From dkg at fifthhorseman.net Thu Aug 4 15:13:38 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Aug 2016 09:13:38 -0400 Subject: Advice on key set-up for work at employer In-Reply-To: References: Message-ID: <877fbw8ynx.fsf@alice.fifthhorseman.net> On Wed 2016-08-03 20:37:00 -0400, taltman wrote: > 1. Create a new GPG keyring specific for my identity with my employer > 2. Cross-sign my existing personal GPG key with the employer-specific > GPG key > 3. Do proper key hygiene things (backups, revocation certs, etc.) on > employer-specific key yes, this is a sensible plan. > It seems with this set-up I can simply just turn over the password to > the private key of the employer-specific GPG keyring if I'm ever > obligated to give them access to their files. This keeps a nice clean > separation between their property, and my personal GPG keyring. When it > comes time to end my time at the employer, I can revoke the > employer-specific key. If I no longer am able to use the > employer-specific GPG keyring, I can at least revoke my signature of the > employer-specific keyring if my former employer gains the password to > the keyring. Even better -- if you need to leave the workplace, you can: 0) revoke the primary key entirely and publish the revocation. 1) destroy the primary secret key. 2) give your employers the secret key material for the *encryption-capable* subkey only. The rationale for this is that while they may need access to your confidential work-related communications, they don't need to be able to masquerade as you (signing documents, certifying other keys, etc). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dr_ming_yn at icloud.com Thu Aug 4 18:05:15 2016 From: dr_ming_yn at icloud.com (=?GB2312?B?w/e/wuzH?=) Date: Fri, 05 Aug 2016 00:05:15 +0800 Subject: scdaemon loses connection when I unplug/replug a crypto-stick Message-ID: ???? iPhone From dkg at fifthhorseman.net Fri Aug 5 00:30:18 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Aug 2016 18:30:18 -0400 Subject: Please, fix batch mode for gpg --edit-key-trust In-Reply-To: References: Message-ID: <87zios5fr9.fsf@alice.fifthhorseman.net> On Wed 2016-07-27 09:46:19 -0400, John Buehrer wrote: > $ printf "5\n" | gpg2 --batch --edit-key 67A92459607354C7 trust quit > ... > Please decide how far you trust this user to correctly verify other users' keys > (by looking at passports, checking fingerprints from different sources, etc.) > > 1 = I don't know or won't say > 2 = I do NOT trust > 3 = I trust marginally > 4 = I trust fully > 5 = I trust ultimately > m = back to the main menu > > *gpg: Sorry, we are in batchmode - can't get input* another way to do this would be to use --import-ownertrust: echo $FINGERPRINT:$VAL: | gpg --import-ownertrust where $VAL is pulled from this list (see g10/trustdb.h; i don't know whether it is documented anywhere else): #define TRUST_MASK 15 #define TRUST_UNKNOWN 0 /* o: not yet calculated/assigned */ #define TRUST_EXPIRED 1 /* e: calculation may be invalid */ #define TRUST_UNDEFINED 2 /* q: not enough information for calculation */ #define TRUST_NEVER 3 /* n: never trust this pubkey */ #define TRUST_MARGINAL 4 /* m: marginally trusted */ #define TRUST_FULLY 5 /* f: fully trusted */ #define TRUST_ULTIMATE 6 /* u: ultimately trusted */ /* Trust values not covered by the mask. */ #define TRUST_FLAG_REVOKED 32 /* r: revoked */ #define TRUST_FLAG_SUB_REVOKED 64 /* r: revoked but for subkeys */ #define TRUST_FLAG_DISABLED 128 /* d: key/uid disabled */ #define TRUST_FLAG_PENDING_CHECK 256 /* a check-trustdb is pending */ #define TRUST_FLAG_TOFU_BASED 512 /* The trust value is based on * the TOFU information. */ I do note that when VAL=0 in the above formulation, --import-ownertrust doesn't touch the value for $FINGERPRINT, though -- so i don't know whether there's a way to use --import-ownertrust to revert to a fully "unknown" state ("2" is probably the closest equivalent). hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From thecissou98 at hotmail.fr Sat Aug 6 10:44:41 2016 From: thecissou98 at hotmail.fr (Le Roy Francis) Date: Sat, 6 Aug 2016 08:44:41 +0000 Subject: Generate private key on smartcard GPGME Message-ID: Hi, I can't figure out how to generate directly a key pair on a smartcard (I am working with a Nitrokey) using GPGPME. How can I do that and is it even possible ? Thanks. F.L.R. From ng0 at we.make.ritual.n0.is Sat Aug 6 14:29:04 2016 From: ng0 at we.make.ritual.n0.is (ng0) Date: Sat, 06 Aug 2016 12:29:04 +0000 Subject: gpgscm In-Reply-To: <87twfncnr1.fsf@europa.jade-hamburg.de> References: <87fur8v098.fsf@we.make.ritual.n0.is> <87twfncnr1.fsf@europa.jade-hamburg.de> Message-ID: <87fuqi3wtr.fsf@we.make.ritual.n0.is> Hi, Justus Winter writes: > Hello :) > > ng0 writes: > >> While doing the update of gnupg from 2.1.13 to 2.1.14 I found out >> that you now include a modified version of tinyscheme for running >> your tests/opengpg/ tests. >> >> Are the changes you apply to tinyscheme generic enough to >> contribute to upstream, so that we can just include a modified >> tinyscheme software to run tests/opengpg/ tests during the check >> phase of GnuPG? > > Yes they are, and I tried to push my changes upstream well before we > merged the new test suite into our master branch. Sadly, my efforts > were not successful. You can find the details in TinySCHEMEs mailing > list archive. Okay, thanks. I'll read up on this. >> If they aren't, could you move the gpgscm binary outside of the >> source of gnupg to not include bundled dependencies, or in some >> more convinient way for you? > > I consider bundling of gpgscm no worse than bundling scdaemon, or say > gpgtar. The plan is to let it mature within the GnuPG repository, and > once we are confident that it fits all our needs, we will move it to > libgpg-error, and use it for other test suites too. > >> As there seems to be no general developer list for GnuPG I'll use >> this list, we can move the discussion elsewhere if it does not >> fit in here. > > There is gnupg-devel, see > https://www.gnupg.org/documentation/mailing-lists.html. Indeed, I did not see this the first time. Thanks, I'll address questions I might have in the future to gnupg-devel. We solved the packaging of gnupg-2.1.14 now to let gpgscm run and not package it on its own like I first intended. Many packages depend on this, so the updates did not make it into the recent 0.11 release image of GuixSD and guix, but they are going to be built soon. > Cheers, > Justus Thanks for taking the time to reply, -- ?? ng0 Current Keys: https://we.make.ritual.n0.is/ng0.txt For non-prism friendly talk find me on http://www.psyced.org From caro at nymph.paranoici.org Sun Aug 7 16:35:41 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sun, 7 Aug 2016 14:35:41 +0000 (UTC) Subject: Standard gnupg folder created despite --homedir parameter Message-ID: <20160807143541.00DDC1031E4D@remailer.paranoici.org> Hello! Migrating a Windows encryption tool from 1.4.20 I need help with GnuPG 2.1.14. Though using the --homedir parameter, with certain gpg commands a gnupg folder is created in %APPDATA% (C:\Users\%USERNAME%\AppData\Roaming). Is there a reason for having that folder or is it just a bug? Any chance to avoid that? I'm addressing this rather unimportant 'feature' 'cause I'm maintaining a portable application and don't want the host system to be altered in any way. | gpg (GnuPG) 2.1.14 | libgcrypt 1.7.2 | Copyright (C) 2016 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: F:/PortableApps/MyProject/gpg | Supported algorithms: | Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA | Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, | CAMELLIA128, CAMELLIA192, CAMELLIA256 | Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 | Compression: Uncompressed, ZIP, ZLIB, BZIP2 | Microsoft Windows [Version 6.1.7600] | Copyright (c) 2009 Microsoft Corporation. All rights reserved. | | f:\PortableApps\MyProject\gpg>gpgconf --homedir F:\PortableApps\MyProject\gpg --list-dirs | sysconfdir:C%3a\ProgramData\GNU\etc\gnupg | bindir:f%3a\PortableApps\MyProject\gpg | libexecdir:f%3a\PortableApps\MyProject\gpg | libdir:f%3a\PortableApps\MyProject\gpg\lib\gnupg | datadir:f%3a\PortableApps\MyProject\gpg\share\gnupg | localedir:f%3a\PortableApps\MyProject\gpg\share\locale | dirmngr-socket:F%3a\PortableApps\MyProject\gpg\S.dirmngr | dirmngr-sys-socket:C%3a\Windows\S.dirmngr | agent-ssh-socket:F%3a\PortableApps\MyProject\gpg\S.gpg-agent.ssh | agent-socket:F%3a\PortableApps\MyProject\gpg\S.gpg-agent | homedir:F%3a\PortableApps\MyProject\gpg TIA Caro From kristian.fiskerstrand at sumptuouscapital.com Sun Aug 7 16:40:08 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sun, 7 Aug 2016 16:40:08 +0200 Subject: [Announcement] SKS 1.1.6 Released Message-ID: <870addba-f748-8cdb-83b3-99d0587b84db@sumptuouscapital.com> Hello lists, We are pleased to announce the availability of a new stable SKS release: Version 1.1.6. SKS is an OpenPGP keyserver whose goal is to provide easy to deploy, decentralized, and highly reliable synchronization. That means that a key submitted to one SKS server will quickly be distributed to all key servers, and even wildly out-of-date servers, or servers that experience spotty connectivity, can fully synchronize with rest of the system. What's New in 1.1.6 ==================== - Add support for Elliptic Curve keys based on Curve25519 (both Ed25519/EdDSA and encryption keys based on these curves) - Fix format of md5sum file by adding a 2nd space to be format compliant - Improvements to sks build stack space requirements - Misc updates and fixes to web interface and typical config file Note when upgrading from earlier versions of SKS ==================== The default values for pagesize settings changed in SKS 1.1.4. To continue using an existing DB from earlier versions without rebuilding, explicit settings have to be added to the sksconf file. pagesize: 4 ptree_pagesize: 1 Getting the Software ==================== SKS can be downloaded from https://bitbucket.org/skskeyserver/sks-keyserver Prerequisites ==================== There are a few prerequisites to building this code. You need: * ocaml-4.0 or later. Get it from * Berkeley DB version 4.6.* or later, whereby 4.8 or later is recommended. You can find the appropriate versions at * GNU Make and a C compiler (e.g gcc) Verifying the integrity of the download ==================== Releases of SKS are signed using the SKS Keyserver Signing Key available on public keyservers with the KeyID 0x41259773973A612A and has a fingerprint of C90E F143 0B3A C0DF D00E 6EA5 4125 9773 973A 612A. Using GnuPG, verification can be accomplished by, first, retrieving the signing key using gpg --keyserver pool.sks-keyservers.net --recv-key 0x41259773973A612A followed by verifying that you have the correct key gpg --keyid-format long --fingerprint 0x41259773973A612A should produce: pub 4096R/41259773973A612A 2012-06-27 Key fingerprint = C90E F143 0B3A C0DF D00E 6EA5 4125 9773 973A 612A A check should also be made that the key is signed by trustworthy other keys; gpg --list-sigs 0x41259773973A612A and the fingerprint should be verified through other trustworthy sources. Once you are certain that you have the correct key downloaded, you can create a local signature, in order to remember that you have verified the key. gpg --lsign-key 0x41259773973A612A Finally; verifying the downloaded file can be done using gpg --keyid-format long --verify sks-x.y.z.tgz.asc The resulting output should be similar to gpg: Signature made Wed Jun 27 12:52:39 2012 CEST gpg: using RSA key 41259773973A612A gpg: Good signature from "SKS Keyserver Signing Key" Thanks ==================== We have to thank all the people who helped with this release, by discussions on the mailing list, submitting patches, or opening issues for items that needed our attention. Happy Hacking, The SKS Team (Yaron, John, Kristian, Phil, and the other contributors) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Sun Aug 7 16:46:00 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sun, 7 Aug 2016 16:46:00 +0200 Subject: sks-keyservers.net: Changes to subset pool (Was: [Announcement] SKS 1.1.6 Released) In-Reply-To: <870addba-f748-8cdb-83b3-99d0587b84db@sumptuouscapital.com> References: <870addba-f748-8cdb-83b3-99d0587b84db@sumptuouscapital.com> Message-ID: <9c922f72-1ad8-2143-6583-5302d36f66b8@sumptuouscapital.com> On 08/07/2016 04:40 PM, Kristian Fiskerstrand wrote: > Hello lists, > > We are pleased to announce the availability of a new stable SKS > release: Version 1.1.6. > > SKS is an OpenPGP keyserver whose goal is to provide easy to deploy, > decentralized, and highly reliable synchronization. That means that a > key submitted to one SKS server will quickly be distributed to all key > servers, and even wildly out-of-date servers, or servers that experience > spotty connectivity, can fully synchronize with rest of the system. > > What's New in 1.1.6 > ==================== > - Add support for Elliptic Curve keys based on Curve25519 (both > Ed25519/EdDSA and encryption keys based on these curves) > - Fix format of md5sum file by adding a 2nd space to be format > compliant > - Improvements to sks build stack space requirements > - Misc updates and fixes to web interface and typical config file Following the release of SKS 1.1.6 I expect to make this the minimum required version for the subset pool when a sufficient number of servers have been upgraded to the new version. This means that subset.pool.sks-keyservers.net will be ECC safe for all of ECDSA (NIST, Brainpool, serpent etc as defined by RFC6637) as well as Ed25519 signing and Curve25519 encryption keys. https://sks-keyservers.net/overview-of-pools.php#pool_subset will be updated when this change happens in, hopefully a relatively short time. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "If the facts don't fit the theory, change the facts" (Albert Einstein) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From james.king at thegeekgroup.org Sun Aug 7 05:48:09 2016 From: james.king at thegeekgroup.org (James King) Date: Sat, 6 Aug 2016 23:48:09 -0400 Subject: Gnu PG - Trouble with Make Message-ID: Hey there, gnupg-2.0.30 (from tarball) and all dependencies extracted. ./configure runs fine make returns No targets specified and no makefile found. Stop. directory contains "Makefile.am" if I rename to Makefile, and run make returns missing separator. Stop. Insight appreciated, thanks -- James King -- -- This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Aug 8 08:24:16 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Aug 2016 08:24:16 +0200 Subject: Gnu PG - Trouble with Make In-Reply-To: (James King's message of "Sat, 6 Aug 2016 23:48:09 -0400") References: Message-ID: <87twev22y7.fsf@wheatstone.g10code.de> On Sun, 7 Aug 2016 05:48, james.king at thegeekgroup.org said: > ./configure runs fine The configure run creates the Makefile(s), look at the output: [...] configure: creating ./config.status config.status: creating m4/Makefile config.status: creating Makefile [...] Do you see thse lines or did configure terminate with an error message? > directory contains "Makefile.am" if I rename to Makefile, and run make You can't do that; Makefile.am and Makefile.in are templates ffrom which a Makefile is created by configure. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Mon Aug 8 08:48:16 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Aug 2016 08:48:16 +0200 Subject: Generate private key on smartcard GPGME In-Reply-To: (Le Roy Francis's message of "Sat, 6 Aug 2016 08:44:41 +0000") References: Message-ID: <87popj21u7.fsf@wheatstone.g10code.de> On Sat, 6 Aug 2016 10:44, thecissou98 at hotmail.fr said: > am working with a Nitrokey) using GPGPME. > > How can I do that and is it even possible ? That is a bit more complicate as you need to use the generic --card-edit interface. gpa/src/gpgmeedit.c and gpa/src/gpagenkeycardop.c make use if it. Time for another --quick-foo command to make this easier I guess. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From cornelius.koelbel at netknights.it Mon Aug 8 12:27:21 2016 From: cornelius.koelbel at netknights.it (Cornelius =?ISO-8859-1?Q?K=F6lbel?=) Date: Mon, 08 Aug 2016 12:27:21 +0200 Subject: several GPG smartcards connected at the same time Message-ID: <1470652041.4700.38.camel@puckel> Hello, I am wondering if it is possible to have several GnuPG Smartcards connected. Let's assume I have several smartcards, one has a PGP key of identy1 at example.com, the other of identity2 at example.com. If I now try to decrypt something which is encrypted for identity2 at example.com would the gpg-agent/scdaemon be smart enough to ask the correct smartcard with the right identity/private key? Thanks a lot Cornelius -- Cornelius K?lbel cornelius.koelbel at netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Gesch?ftsf?hrer: Cornelius K?lbel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From thecissou98 at hotmail.fr Mon Aug 8 13:15:50 2016 From: thecissou98 at hotmail.fr (Le Roy Francis) Date: Mon, 8 Aug 2016 11:15:50 +0000 Subject: Building gpgme on windows with GCC 5.1.0 Message-ID: Hi, I have difficulties building gpgme on windows. I have tried to cross compile on ubuntu, but I was unable to found a cross compile toolchain with gcc version 5.1.0.. Building with MSYS on windows also gave me error. Is there a simple way of building gpgme on windows ? Thanks. FLR. From justus at g10code.com Mon Aug 8 14:46:12 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 08 Aug 2016 14:46:12 +0200 Subject: Building gpgme on windows with GCC 5.1.0 In-Reply-To: References: Message-ID: <87eg5za0ob.fsf@europa.jade-hamburg.de> Hi :) Le Roy Francis writes: > Hi, I have difficulties building gpgme on windows. I have tried to cross > compile on ubuntu, but I was unable to found a cross compile toolchain > with gcc version 5.1.0.. Do you need exactly that version? Debian has a gcc 5.4 cross toolchain: % apt-cache policy gcc-mingw-w64-i686 gcc-mingw-w64-i686: Installed: 4.9.1-19+14.3 Candidate: 4.9.1-19+14.3 Version table: 6.1.1-6+19 300 300 http://httpredir.debian.org/debian experimental/main amd64 Packages 5.4.0-4+18.2 350 350 http://httpredir.debian.org/debian unstable/main amd64 Packages *** 4.9.1-19+14.3 900 900 http://httpredir.debian.org/debian jessie/main amd64 Packages 100 /var/lib/dpkg/status > Building with MSYS on windows also gave me error. Is there a simple > way of building gpgme on windows ? No idea. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From wk at gnupg.org Mon Aug 8 15:01:37 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Aug 2016 15:01:37 +0200 Subject: Building gpgme on windows with GCC 5.1.0 In-Reply-To: <87eg5za0ob.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Mon, 08 Aug 2016 14:46:12 +0200") References: <87eg5za0ob.fsf@europa.jade-hamburg.de> Message-ID: <87mvknxvm6.fsf@wheatstone.g10code.de> On Mon, 8 Aug 2016 14:46, justus at g10code.com said: > Do you need exactly that version? Debian has a gcc 5.4 cross toolchain: Take a bit of care: Mingw is known to introduce regression with new compilers or runtimes. For the binaries distributed by gnupg.org we currently use 4.9.1. If you install GnuPG 2.1 for Windows it will also bring you a decent gpgme with header files and import libs. We only support cross-building from Unix. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From dkg at fifthhorseman.net Mon Aug 8 08:11:02 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 08 Aug 2016 02:11:02 -0400 Subject: [Sks-devel] [Announcement] SKS 1.1.6 Released In-Reply-To: <870addba-f748-8cdb-83b3-99d0587b84db@sumptuouscapital.com> References: <870addba-f748-8cdb-83b3-99d0587b84db@sumptuouscapital.com> Message-ID: <87wpjryemh.fsf@alice.fifthhorseman.net> On Sun 2016-08-07 10:40:08 -0400, Kristian Fiskerstrand wrote: > We are pleased to announce the availability of a new stable SKS > release: Version 1.1.6. great, thanks! > Note when upgrading from earlier versions of SKS > ==================== > The default values for pagesize settings changed in SKS 1.1.4. To > continue using an existing DB from earlier versions without rebuilding, > explicit settings have to be added to the sksconf file. > pagesize: 4 > ptree_pagesize: 1 it's not clear to me what this means: are these settings that should be added to sksconf if they weren't already there and you're using an existing database without rebuilding? what if those variables are already set in the sksconf file but they have different values? what if they weren't set, sks was upgraded, and the database wasn't rebuilt? what sort of failures should server operators expect? > Getting the Software > ==================== > SKS can be downloaded from > https://bitbucket.org/skskeyserver/sks-keyserver https://bitbucket.org/skskeyserver/sks-keyserver/downloads has some very strange text in it: sks-1.1.6.tgz Is there a reason for the newline and leading whitespace? That causes debian/watch to fail to discover the new tarball. > A check should also be made that the key is signed by > trustworthy other keys; > > gpg --list-sigs 0x41259773973A612A This doesn't actually validate the retrieved signatures, fwiw. you probably want --check-sigs instead of --list-sigs. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Aug 8 16:25:35 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 08 Aug 2016 10:25:35 -0400 Subject: [Sks-devel] [Announcement] SKS 1.1.6 Released In-Reply-To: <273a0937-ffe2-f031-19c6-c2138fcdd604@sumptuouscapital.com> References: <870addba-f748-8cdb-83b3-99d0587b84db@sumptuouscapital.com> <87wpjryemh.fsf@alice.fifthhorseman.net> <273a0937-ffe2-f031-19c6-c2138fcdd604@sumptuouscapital.com> Message-ID: <87lh07xrq8.fsf@alice.fifthhorseman.net> Thanks for the clarifications, Kristian! followup below about bitbucket: On Mon 2016-08-08 10:16:38 -0400, Kristian Fiskerstrand wrote: >> https://bitbucket.org/skskeyserver/sks-keyserver/downloads >> >> has some very strange text in it: >> >> >> sks-1.1.6.tgz >> >> >> Is there a reason for the newline and leading whitespace? That causes >> debian/watch to fail to discover the new tarball. >> > > You'll have to ask bitbucket.. we don't control the HTML template of the > downloads page. i've opened https://bitbucket.org/site/master/issues/13130/downloads-page-has-spurious-whitespace feel free to nudge them on it -- as a lead on the project they might be more receptive to your prodding than to mine. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Mon Aug 8 16:16:38 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 8 Aug 2016 16:16:38 +0200 Subject: [Sks-devel] [Announcement] SKS 1.1.6 Released In-Reply-To: <87wpjryemh.fsf@alice.fifthhorseman.net> References: <870addba-f748-8cdb-83b3-99d0587b84db@sumptuouscapital.com> <87wpjryemh.fsf@alice.fifthhorseman.net> Message-ID: <273a0937-ffe2-f031-19c6-c2138fcdd604@sumptuouscapital.com> On 08/08/2016 08:11 AM, Daniel Kahn Gillmor wrote: > On Sun 2016-08-07 10:40:08 -0400, Kristian Fiskerstrand wrote: > .. >> Note when upgrading from earlier versions of SKS >> ==================== >> The default values for pagesize settings changed in SKS 1.1.4. To >> continue using an existing DB from earlier versions without rebuilding, >> explicit settings have to be added to the sksconf file. >> pagesize: 4 >> ptree_pagesize: 1 > > it's not clear to me what this means: are these settings that should be > added to sksconf if they weren't already there and you're using an > existing database without rebuilding? yes; if the database was built before 1.1.4 originally (which was released in July 2012), values between 1.1.4, 1.1.5 and 1.1.6 are consistent, so if you've upgraded to 1.1.5 this must already be properly set. > > what if those variables are already set in the sksconf file but they > have different values? Then you retain the different values > > what if they weren't set, sks was upgraded, and the database wasn't > rebuilt? what sort of failures should server operators expect? Errors loading BDB environment / starting SKS. > >> Getting the Software >> ==================== >> SKS can be downloaded from >> https://bitbucket.org/skskeyserver/sks-keyserver > > https://bitbucket.org/skskeyserver/sks-keyserver/downloads > > has some very strange text in it: > > > sks-1.1.6.tgz > > > Is there a reason for the newline and leading whitespace? That causes > debian/watch to fail to discover the new tarball. > You'll have to ask bitbucket.. we don't control the HTML template of the downloads page. > >> A check should also be made that the key is signed by >> trustworthy other keys; >> >> gpg --list-sigs 0x41259773973A612A > > This doesn't actually validate the retrieved signatures, fwiw. you > probably want --check-sigs instead of --list-sigs. Fair point, will update announcement template. > > Regards, > > --dkg > -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Nomina stultorum scribuntur ubique locorum Fools have the habit of writing their names everywhere -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From james.king at thegeekgroup.org Mon Aug 8 12:19:33 2016 From: james.king at thegeekgroup.org (James King) Date: Mon, 8 Aug 2016 06:19:33 -0400 Subject: Gnu PG - Trouble with Make In-Reply-To: <87twev22y7.fsf@wheatstone.g10code.de> References: <87twev22y7.fsf@wheatstone.g10code.de> Message-ID: ./configure run in the gnupg-2.0.30 directory returns 'required libraries not found', i.e, the GNU portable threads library, which I've downloaded from ftp://ftp.gnu.org/gnu/pth/ unpacked, and installed ./configure make sudo make install Aside from "make[2]: Nothing to be done for `install-exec-am'." Everything appears normal, except ./configure for gnu PG will continue to return "library missing" On Mon, Aug 8, 2016 at 2:24 AM, Werner Koch wrote: > On Sun, 7 Aug 2016 05:48, james.king at thegeekgroup.org said: > > ./configure runs fine > > The configure run creates the Makefile(s), look at the output: > > [...] > configure: creating ./config.status > config.status: creating m4/Makefile > config.status: creating Makefile > [...] > > Do you see thse lines or did configure terminate with an error message? > > > directory contains "Makefile.am" if I rename to Makefile, and run make > > You can't do that; Makefile.am and Makefile.in are templates ffrom which > a Makefile is created by configure. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > /* Join us at OpenPGP.conf */ > > -- James King -- -- This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sinclair.andersen at usabilitypartners.se Mon Aug 8 18:20:57 2016 From: sinclair.andersen at usabilitypartners.se (Sinclair Andersen) Date: Mon, 8 Aug 2016 18:20:57 +0200 Subject: Standard gnupg folder created despite --homedir parameter In-Reply-To: References: Message-ID: <20160808182057.a4550940e28b8311b7d44fad@usabilitypartners.se> > Date: Sun, 7 Aug 2016 14:35:41 +0000 (UTC) > From: Carola Grunwald > To: gnupg-users at gnupg.org > Subject: Standard gnupg folder created despite --homedir parameter > Message-ID: <20160807143541.00DDC1031E4D at remailer.paranoici.org> > Content-Type: text/plain; charset=us-ascii > > Hello! > > Migrating a Windows encryption tool from 1.4.20 I need help with GnuPG > 2.1.14. > > Though using the --homedir parameter, with certain gpg commands a gnupg > folder is created in %APPDATA% (C:\Users\%USERNAME%\AppData\Roaming). Is > there a reason for having that folder or is it just a bug? Any chance > to avoid that? > > I'm addressing this rather unimportant 'feature' 'cause I'm maintaining > a portable application and don't want the host system to be altered in > any way. > > | gpg (GnuPG) 2.1.14 > | libgcrypt 1.7.2 > | Copyright (C) 2016 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: F:/PortableApps/MyProject/gpg > | Supported algorithms: > | Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > | Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > | CAMELLIA128, CAMELLIA192, CAMELLIA256 > | Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > | Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > | Microsoft Windows [Version 6.1.7600] > | Copyright (c) 2009 Microsoft Corporation. All rights reserved. > | > | f:\PortableApps\MyProject\gpg>gpgconf --homedir F:\PortableApps\MyProject\gpg --list-dirs > | sysconfdir:C%3a\ProgramData\GNU\etc\gnupg > | bindir:f%3a\PortableApps\MyProject\gpg > | libexecdir:f%3a\PortableApps\MyProject\gpg > | libdir:f%3a\PortableApps\MyProject\gpg\lib\gnupg > | datadir:f%3a\PortableApps\MyProject\gpg\share\gnupg > | localedir:f%3a\PortableApps\MyProject\gpg\share\locale > | dirmngr-socket:F%3a\PortableApps\MyProject\gpg\S.dirmngr > | dirmngr-sys-socket:C%3a\Windows\S.dirmngr > | agent-ssh-socket:F%3a\PortableApps\MyProject\gpg\S.gpg-agent.ssh > | agent-socket:F%3a\PortableApps\MyProject\gpg\S.gpg-agent > | homedir:F%3a\PortableApps\MyProject\gpg > > TIA > > Caro > Hello Caro, I'm afraid I don't have a solution for you, but since I have been looking for precisely the same myself for over a year now, I thought I reply anyway. I run GnuPG 1.4.20 from inside a Veracrypt volume together with a number other portable apps, like Pidgin, Thunderbird, that is stored and back uped on a couple of thumbdrives and other media. I do this by having created a start.bat file that I start GnuPG from: setlocal set GNUPGHOME=. cmd.exe endlocal Feeling that it is only a matter of time before one must leave 1.4.x behind (a feeling, mind you, maybe it will outlive some of us), I have been looking for a way to run at least version 2.0.30 from inside a Veracrypt volume and, as you say "don't want the host system to be altered in any way." If by any chance someone on this list has an answer to this, someone mails you or you find a solution, I'd be more than happy if you'd share. If that happens to me, I be sure to do the same. Regards, FDS From nik at naturalnet.de Mon Aug 8 21:18:40 2016 From: nik at naturalnet.de (Dominik George) Date: Mon, 08 Aug 2016 21:18:40 +0200 Subject: Moving from RSA to Ed25519 Message-ID: <10667936.O9o76ZdvQC@portux> Hi, I was thinking about moving from rsa4096 to ed25519. I really do not want to lose all the signatures on my key. What I could do is add the ed25519 signature and encryption keys to my existing rsa key as subkeys, but I guess this will not improve security because my RSA signature key could still be used. From my understanding it is not possible to expire the primary key and keep subkeys. Did I get something wrong? If not, what is the smoothest thing to do to migrate? Cheers, Nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George ? Mobil: +49-1520-1981389 Teckids e.V. ? FrOSCon e.V. ? OpenRheinRuhr e.V. Fellowship of the FSFE ? Piratenpartei Deutschland Opencaching Deutschland e.V. ? Debian Contributor LPIC-3 Linux Enterprise Professional (Security) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 888 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Mon Aug 8 23:29:52 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 08 Aug 2016 17:29:52 -0400 Subject: Moving from RSA to Ed25519 In-Reply-To: <10667936.O9o76ZdvQC@portux> References: <10667936.O9o76ZdvQC@portux> Message-ID: <874m6vx833.fsf@alice.fifthhorseman.net> On Mon 2016-08-08 15:18:40 -0400, Dominik George wrote: > I was thinking about moving from rsa4096 to ed25519. > > I really do not want to lose all the signatures on my key. > > What I could do is add the ed25519 signature and encryption keys to my > existing rsa key as subkeys, but I guess this will not improve security > because my RSA signature key could still be used. > > From my understanding it is not possible to expire the primary key and keep > subkeys. that is correct. > Did I get something wrong? If not, what is the smoothest thing to do to > migrate? Now is not a good time to migrate, especially if you want to keep all of your certifications intact. Many people do not have access to a version of GnuPG that is capable of supporting elliptic curve crypto, even on the public side (encrypting data, verifying signatures). You'd be better off waiting to migrate unless you have a very specific use case with a group of peers who you know will be able to use those keys with you. --dkg From cannon at cannon-ciota.info Tue Aug 9 00:09:51 2016 From: cannon at cannon-ciota.info (Cannon) Date: Mon, 8 Aug 2016 22:09:51 +0000 Subject: GPG smartcard shrinks in size Message-ID: <6ba2258c-2a74-cf97-9fb6-42804083bf74@cannon-ciota.info> Using the OpenPGP Smartcard V2.1 used to store 4096 key. Then was used to store 3072 length key for short time. Problem is that I am unable to use it for 4096 keys anymore. How to reset card so I can use it again for 4096 key? Thank you -- Cannon PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 Email: cannon at cannon-ciota.info Bitmessage Address: BM-2cVaTbC8fJ5UDDaBBs4jPQoFNp1PfNhxqU Ricochet-IM: ricochet:hfddt2csxnsb2mdq From cannon at cannon-ciota.info Tue Aug 9 00:29:02 2016 From: cannon at cannon-ciota.info (Cannon) Date: Mon, 8 Aug 2016 22:29:02 +0000 Subject: Signing statement with master key? Message-ID: This is a hypothetical scenario. Lets say if I have a keypair. The master key is set to SC (signing and certification) which are the default settings. The master key pair is only used on airgap with safe data transfer between airgap and network connected computer. Is it safe and possible to use the master key (not subkeys) to sign a statement? -- Cannon PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 Email: cannon at cannon-ciota.info Bitmessage Address: BM-2cVaTbC8fJ5UDDaBBs4jPQoFNp1PfNhxqU Ricochet-IM: ricochet:hfddt2csxnsb2mdq From lopaki at gmail.com Mon Aug 8 23:51:10 2016 From: lopaki at gmail.com (Scott Lambdin) Date: Mon, 8 Aug 2016 17:51:10 -0400 Subject: Gnu PG - Trouble with Make In-Reply-To: References: <87twev22y7.fsf@wheatstone.g10code.de> Message-ID: Can you tell from the context which library is missing? --Scott On Mon, Aug 8, 2016 at 6:19 AM, James King wrote: > ./configure run in the gnupg-2.0.30 directory returns 'required libraries > not found', i.e, the GNU portable threads library, which I've downloaded > from ftp://ftp.gnu.org/gnu/pth/ unpacked, and installed > > ./configure > make > sudo make install > > Aside from "make[2]: Nothing to be done for `install-exec-am'." > > Everything appears normal, except ./configure for gnu PG will continue to > return "library missing" > > > On Mon, Aug 8, 2016 at 2:24 AM, Werner Koch wrote: > >> On Sun, 7 Aug 2016 05:48, james.king at thegeekgroup.org said: >> > ./configure runs fine >> >> The configure run creates the Makefile(s), look at the output: >> >> [...] >> configure: creating ./config.status >> config.status: creating m4/Makefile >> config.status: creating Makefile >> [...] >> >> Do you see thse lines or did configure terminate with an error message? >> >> > directory contains "Makefile.am" if I rename to Makefile, and run make >> >> You can't do that; Makefile.am and Makefile.in are templates ffrom which >> a Makefile is created by configure. >> >> >> Salam-Shalom, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> /* Join us at OpenPGP.conf */ >> >> > > > -- > James King -- > > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review or distribution by others is > strictly prohibited. If you are not the intended recipient please contact > the sender and delete all copies. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- Eat like you give a damn. Go vegan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Aug 9 01:53:06 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 08 Aug 2016 19:53:06 -0400 Subject: Signing statement with master key? In-Reply-To: References: Message-ID: <87popix1gd.fsf@alice.fifthhorseman.net> On Mon 2016-08-08 18:29:02 -0400, Cannon wrote: > This is a hypothetical scenario. > Lets say if I have a keypair. > The master key is set to SC (signing and certification) which are the > default settings. The master key pair is only used on airgap with safe > data transfer between airgap and network connected computer. > Is it safe and possible to use the master key (not subkeys) to sign a > statement? yes, it is certainly possible. I'm not sure what you mean "is it safe" -- safe against what? It's certainly no less safe than the common/default mode of operation, where the primary key is not airgapped, and there is no separate signing-capable subkey. This is a sensible and well-supported use case. --dkg From gniibe at fsij.org Tue Aug 9 02:05:11 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 9 Aug 2016 09:05:11 +0900 Subject: GPG smartcard shrinks in size In-Reply-To: <6ba2258c-2a74-cf97-9fb6-42804083bf74@cannon-ciota.info> References: <6ba2258c-2a74-cf97-9fb6-42804083bf74@cannon-ciota.info> Message-ID: <9a1052b0-bf11-8423-1c36-89df3f8785fb@fsij.org> On 08/09/2016 07:09 AM, Cannon wrote: > Using the OpenPGP Smartcard V2.1 used to store 4096 key. Then was used > to store 3072 length key for short time. Problem is that I am unable to > use it for 4096 keys anymore. How to reset card so I can use it again > for 4096 key? No worries. I think that you can just generate keys of 4096 or put keys of 4096 by keytocard. OpenPGP Smartcard supports multiple key length. Since the card protocol only supports a single information of key length per key, a card looks like as if it only supports a specific key size. (There is no way in the protocol to represent multiple key length information.) When a user invokes "generate" or "keytocard" command, GnuPG will adjust the key attribute of a card to a specific size of key length. Once it is generated or written by keytocard, you will see it's 4096. Or, do you have a specific problem when you say "unable to use it for 4096 keys anymore"? Please describe the problem. -- From caro at nymph.paranoici.org Tue Aug 9 02:37:09 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Tue, 9 Aug 2016 00:37:09 +0000 (UTC) Subject: Standard gnupg folder created despite --homedir parameter References: <20160808182057.a4550940e28b8311b7d44fad@usabilitypartners.se> Message-ID: <20160809003709.DA41A100B300@remailer.paranoici.org> Sinclair Andersen wrote: >> From: Carola Grunwald >> Subject: Standard gnupg folder created despite --homedir parameter >> Migrating a Windows encryption tool from 1.4.20 I need help with GnuPG >> 2.1.14. >> >> Though using the --homedir parameter, with certain gpg commands a gnupg >> folder is created in %APPDATA% (C:\Users\%USERNAME%\AppData\Roaming). Is >> there a reason for having that folder or is it just a bug? Any chance >> to avoid that? >> >> I'm addressing this rather unimportant 'feature' 'cause I'm maintaining >> a portable application and don't want the host system to be altered in >> any way. >I'm afraid I don't have a solution for you, but since I have been looking for precisely the same myself for over a year now, I thought I reply anyway. >I run GnuPG 1.4.20 from inside a Veracrypt volume together with a number other portable apps, like Pidgin, Thunderbird, that is stored and back uped on a couple of thumbdrives and other media. >I do this by having created a start.bat file that I start GnuPG from: > > setlocal > set GNUPGHOME=. > cmd.exe > endlocal > >Feeling that it is only a matter of time before one must leave 1.4.x behind (a feeling, mind you, maybe it will outlive some of us), I have been looking for a way to run at least version 2.0.30 from inside a Veracrypt volume and, as you say "don't want the host system to be altered in any way." > >If by any chance someone on this list has an answer to this, someone mails you or you find a solution, I'd be more than happy if you'd share. If that happens to me, I be sure to do the same. Deal! I'm sure the GPG devel team has an understanding of the implications for people in an authoritarian society being compromised by such needless data residues of their purportedly hidden correspondence. Kind regards, Caro From gniibe at fsij.org Tue Aug 9 02:39:43 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 9 Aug 2016 09:39:43 +0900 Subject: several GPG smartcards connected at the same time In-Reply-To: <1470652041.4700.38.camel@puckel> References: <1470652041.4700.38.camel@puckel> Message-ID: On 08/08/2016 07:27 PM, Cornelius K?lbel wrote: > I am wondering if it is possible to have several GnuPG Smartcards > connected. Currently, this configuration is not supported by scdaemon. I don't know any portable technical solution (supporting GNU/Linux, Windows, and MacOS X, etc.) to handle multiple card readers (and/or cards) simultaneously by a single application. Now, GnuPG 2.1 internal CCID driver has migrated to newer libusb. So, I think that we can consider a solution by the internal CCID driver, supporting multiple card readers (or card) simultaneously by a single application. I don't know how a possible libusb solution is portable, though. > Let's assume I have several smartcards, > one has a PGP key of identy1 at example.com, the other of > identity2 at example.com. In fact, I am using multiple tokens daily for gniibe at fsij.org; ed25519 with 249CB3771750745D5CDD323CE267B052364F028D, rsa2048 with 124124BD3B4862AF7A0A42F100B45EBD4CA7BABE. It annoys me somehow. > If I now try to decrypt something which is encrypted for > identity2 at example.com would the gpg-agent/scdaemon be smart enough to > ask the correct smartcard with the right identity/private key? If there is no token inserted, it fails. If a correct token is inserted, it goes well. If a different token is inserted, GnuPG asks a user to remove a different token and to insert another token. This is the current behavior. There is a small problem yet. When GnuPG sees an encrypted message for both of E267B052364F028D, 00B45EBD4CA7BABE, it handle a possible key in a sequence (as listed in an encrypted message). Suppose key list is: E267B052364F028D and 00B45EBD4CA7BABE, and I already inserted a token for 00B45EBD4CA7BABE in my computer. GnuPG asks me to change a token when it finds E267B052364F028D in an encrypted message, even if the message can be decrypted by the token inserted already. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ndk.clanbo at gmail.com Tue Aug 9 08:57:26 2016 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 9 Aug 2016 08:57:26 +0200 Subject: several GPG smartcards connected at the same time In-Reply-To: References: <1470652041.4700.38.camel@puckel> Message-ID: Il 09/08/2016 02:39, NIIBE Yutaka ha scritto: > Currently, this configuration is not supported by scdaemon. I don't > know any portable technical solution (supporting GNU/Linux, Windows, > and MacOS X, etc.) to handle multiple card readers (and/or cards) > simultaneously by a single application. Isn't it what PKCS#11 is for? If GnuPG supported PKCS#11 it would open a whole new world, like the ability to use generic cards. IMVHO "fixing" GnuPG to handle multiple cards and readers would actually create something really similar to PKCS#11... BYtE, Diego From justus at g10code.com Tue Aug 9 10:27:01 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 09 Aug 2016 10:27:01 +0200 Subject: several GPG smartcards connected at the same time In-Reply-To: References: <1470652041.4700.38.camel@puckel> Message-ID: <8737megxey.fsf@europa.jade-hamburg.de> NdK writes: > If GnuPG supported PKCS#11 it would open a whole new world, like the > ability to use generic cards. We have such a module: http://scute.org/ Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ndk.clanbo at gmail.com Tue Aug 9 10:34:41 2016 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 9 Aug 2016 10:34:41 +0200 Subject: several GPG smartcards connected at the same time In-Reply-To: <8737megxey.fsf@europa.jade-hamburg.de> References: <1470652041.4700.38.camel@puckel> <8737megxey.fsf@europa.jade-hamburg.de> Message-ID: Il 09/08/2016 10:27, Justus Winter ha scritto: >> If GnuPG supported PKCS#11 it would open a whole new world, like the >> ability to use generic cards. > We have such a module: http://scute.org/ That's exactly the opposite: Scute allows a PKCS#11 app to access an OpenPGP card (but isn't it redundant, since OpenPGP cards are supported[1] by native opensc driver?). If GnuPG/scd supported PKCS#11 you could tell it to use a key on any non-openpgp card as a GnuPG native key (some configuration could be required). [1] https://github.com/OpenSC/OpenSC/wiki/OpenPGP-card BYtE, Diego From wk at gnupg.org Tue Aug 9 10:56:35 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Aug 2016 10:56:35 +0200 Subject: several GPG smartcards connected at the same time In-Reply-To: (NdK's message of "Tue, 9 Aug 2016 08:57:26 +0200") References: <1470652041.4700.38.camel@puckel> Message-ID: <87fuqetj5o.fsf@wheatstone.g10code.de> On Tue, 9 Aug 2016 08:57, ndk.clanbo at gmail.com said: > If GnuPG supported PKCS#11 it would open a whole new world, like the > ability to use generic cards. Nope. That is entirely unrelated. PKCS#11 is a clumsy standard to allow the use of proprietary cards using proprietary middleware/drivers/whatever_they_call_it. If you have an open specification for a card you can easily write the required glue code and add it to scdaemon. You may also use a PKCS#15 card and scdaemon would work just fine with it - if there would not be so many different flavors of that standard. Using more that one card is more of an organisational problem. 10 years ago or so I did some tests and it basically worked. However, back then it was hard enough to convince people to buy just _one_ reader and thus I dropped all efforts to make multipe reader/card support well working. It is also questionable whether having two cards plugged in is a good idea: You increase the attack surface and malware can make use of any of those cards. This makes it hard for a user to notice unexpected use of a card. >From a practical point of view I would love to see support for two cards: When doing a release I have to swap my cards for commit signatures and release signatures all the time. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Tue Aug 9 11:34:02 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Aug 2016 11:34:02 +0200 Subject: [Announce] OpenPGP.conf early bird ends in 3 days Message-ID: <87wpjqs2ut.fsf@wheatstone.g10code.de> Hello! 5 weeks to go for the first OpenPGP conference on September 8 and 9 and 3 days to register with early bird discount. Hurry up. OpenPGP.conf is a place to meet, discuss, and learn about latest developments of OpenPGP aware applications and what technical measures can be deployed to repel the ever increasing trend to mass surveillance. We have two full days with topics around the protocol and use of OpenPGP. There will also be enough time to discuss with experienced users and developers. The talks and their speakers are: - A few concerns regarding PGP, new directions by Stefan 'stf' Marsiske - A Simple Solution to Key Discovery by Werner Koch - A stateless model for browser encryption in GlobaLeaks by Nick Skelsey - An update on the sks-keyservers.net services by Kristian Fiskerstrand - Automated use of GnuPG through GPGME by Andre Heinecke - Bypass Pinentry for good by Seiya Kawashima - Gnuk 1.2 by Yutaka NIIBE - GnuPG in Debian by Daniel Kahn Gillmor - History of OpenPGP by Lutz Donnerhacke - NEXTLEAP and automatic E2E emails by Holger Krekel - OpenKeychain UX decisions by Dominik Sch?rmann and Vincent Breitmoser - The Mathematical Mesh: Management of keys by Phillip Hallam-Baker - The State of three contracts from the German BSI by Bernhard Reiter - Transparent key management at LEAP by meskio For details see https://openpgp-conf.org . The organizer told me that there are still sufficient resources in their conference fee grant program. See you in Cologne, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 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 Tue Aug 9 12:10:21 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Aug 2016 12:10:21 +0200 Subject: Standard gnupg folder created despite --homedir parameter In-Reply-To: <20160808182057.a4550940e28b8311b7d44fad@usabilitypartners.se> (Sinclair Andersen's message of "Mon, 8 Aug 2016 18:20:57 +0200") References: <20160808182057.a4550940e28b8311b7d44fad@usabilitypartners.se> Message-ID: <87bn12s16a.fsf@wheatstone.g10code.de> On Mon, 8 Aug 2016 18:20, sinclair.andersen at usabilitypartners.se said: > set GNUPGHOME=. Don't use a relative path for GNUPGHOME unless you use gnupg 2.1. Regarding those portable applications: On Windows systems it is possible to install GnuPG as a portable application. In this case only this command line option is considered, all other ways to set a home directory are ignored. To install GnuPG as a portable application under Windows, create an empty file name 'gpgconf.ctl' in the same directory as the tool 'gpgconf.exe'. The root of the installation is than that directory; or, if 'gpgconf.exe' has been installed directly below a directory named 'bin', its parent directory. You also need to make sure that the following directories exist and are writable: 'ROOT/home' for the GnuPG home and 'ROOT/usr/local/var/cache/gnupg' for internal cache files. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From n3npq at me.com Tue Aug 9 05:00:29 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 08 Aug 2016 23:00:29 -0400 Subject: [Sks-devel] [Announcement] SKS 1.1.6 Released In-Reply-To: <273a0937-ffe2-f031-19c6-c2138fcdd604@sumptuouscapital.com> References: <870addba-f748-8cdb-83b3-99d0587b84db@sumptuouscapital.com> <87wpjryemh.fsf@alice.fifthhorseman.net> <273a0937-ffe2-f031-19c6-c2138fcdd604@sumptuouscapital.com> Message-ID: <59359594-76E2-41C7-ACB6-A30938CEDA86@me.com> > >> >> what if they weren't set, sks was upgraded, and the database wasn't >> rebuilt? what sort of failures should server operators expect? > > Errors loading BDB environment / starting SKS. > A couple of nitpicks, peripheral to BDB, specific to SKS, related to pagesize: The sampleConfig/sksconf.typical file includes these lines: # KDB/key 65536 pagesize: 128 # # KDB/keyid 32768 keyid_pagesize: 64 1) The naming of ?pagesize? (likely BDB hysterical naming) does not follow the other table(s) naming: one would expect ?key_pagesize?. 2) There is no ?keyid_pagesize?. In fact, if you set that variable, then sks fails to run with an obscure error. (there?s likely a different config variable name in the sources, haven?t looked). The second failure is seen iff sksconf is in the current directory when running sks_build.sh. Which brings up another another nitpick: if trying to set per-table pagesize using sksconf, then a warning message might be useful if the current directory does *NOT* contain a valid sksconf. (aside: note-to-self) There is likely a way to change pagesize without having to reload from a dump. I?ll see if I can dig out the details. todo++. hth -------------- next part -------------- An HTML attachment was scrubbed... URL: From thecissou98 at hotmail.fr Wed Aug 10 00:20:05 2016 From: thecissou98 at hotmail.fr (Le Roy Francis) Date: Tue, 9 Aug 2016 22:20:05 +0000 Subject: Debug code parameter Message-ID: Hi, How can I produce code like keygen.valid or cardedit.genkeys.storekeytype with gpg on the command line ? Thanks. FLR From caro at nymph.paranoici.org Wed Aug 10 01:23:32 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Tue, 9 Aug 2016 23:23:32 +0000 (UTC) Subject: Standard gnupg folder created despite --homedir parameter References: <20160808182057.a4550940e28b8311b7d44fad@usabilitypartners.se> <87bn12s16a.fsf@wheatstone.g10code.de> Message-ID: <20160809232332.DF01710320F7@remailer.paranoici.org> Hello Werner, many thanks for your involvement in this discussion. GPG 2.1 took big steps towards becoming a truly portable application. On Tue, 09 Aug 2016 12:10:21 +0200, Werner Koch wrote: >On Mon, 8 Aug 2016 18:20, sinclair.andersen at usabilitypartners.se said: > >> set GNUPGHOME=. > >Don't use a relative path for GNUPGHOME unless you use gnupg 2.1. > >Regarding those portable applications: > > On Windows systems it is possible to install GnuPG as a portable > application. In this case only this command line option is > considered, all other ways to set a home directory are ignored. > > To install GnuPG as a portable application under Windows, create an > empty file name 'gpgconf.ctl' in the same directory as the tool > 'gpgconf.exe'. The root of the installation is than that > directory; or, if 'gpgconf.exe' has been installed directly below a > directory named 'bin', its parent directory. You also need to make > sure that the following directories exist and are writable: > 'ROOT/home' for the GnuPG home and 'ROOT/usr/local/var/cache/gnupg' > for internal cache files. May I ask how that translates into the Windows world? Is it a way to get rid of the ...\AppData\Roaming\gnupg folder? I have all executables in my gpg main folder and call gpg.exe exclusively from that directory with a '--homedir "...\gpg"' parameter, while that gnupg folder still gets created. Thanks Caro From peter at digitalbrains.com Wed Aug 10 10:40:29 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 10 Aug 2016 10:40:29 +0200 Subject: Standard gnupg folder created despite --homedir parameter In-Reply-To: <20160809232332.DF01710320F7@remailer.paranoici.org> References: <20160808182057.a4550940e28b8311b7d44fad@usabilitypartners.se> <87bn12s16a.fsf@wheatstone.g10code.de> <20160809232332.DF01710320F7@remailer.paranoici.org> Message-ID: On 10/08/16 01:23, Carola Grunwald wrote: > May I ask how that translates into the Windows world? Is it a way to > get rid of the ...\AppData\Roaming\gnupg folder? While the directory names give off a strong Unixy vibe[1], the text says "On Windows systems" and "under Windows". Have you tried to create those directories? I don't think there is any "translation", this is how you should do it on Windows specifically. (The gpgconf tool is also indicated as 'gpgconf.exe', on Unix systems it would not have an extension.) Try this: F:\PortableApps\MyProject\gpg\gpgconf.exe F:\PortableApps\MyProject\gpg\gpgconf.ctl F:\PortableApps\MyProject\gpg\home F:\PortableApps\MyProject\gpg\usr\local\var\cache\gnupg HTH, Peter. [1] Heck, /usr/local/var/cache/gnupg is the concatenation of two standard Linux directory names. Two for the price of one! It's an odd one, that. Makes you wonder whether it's a copy-paste error. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Aug 10 11:16:24 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 10 Aug 2016 11:16:24 +0200 Subject: Which GPG version? In-Reply-To: References: <924b4b23-07c2-3264-25e4-fdf1bf6b5a59__9784.89141348309$1470072572$gmane$org@digitalbrains.com> Message-ID: <0e08371d-f0e4-9f00-01e8-990463d1dc57@digitalbrains.com> On 01/08/16 21:48, Patrick Brunschwig wrote: > I see the world a little different :-) The world even! :-) > If you want to try new features like curve-based encryption, or if you > are a developer, then go for 2.1. Otherwise, if you are a regular > end-user, then go for 2.0 and wait with upgrading until 2.1 has become > mature. This will result in 2.2 being released. What do you base this view upon? I based my advice upon two instances I can remember Werner expressing his view about this: On 04/05/16 11:55, Werner Koch wrote[1]: > On Wed, 4 May 2016 11:40, peter at digitalbrains.com said: > >> Werner, would you recommend they use 2.1 or 2.0 for the Debian Live CD? > > 2.1 of course Note that this is about a Live CD which is expected to be used by people with larger than average security concerns. You mention the "regular end-user" yourself. I'd say some of the intended audience of the Live CD have more stringent needs even than the "regular end-user". On the other hand, a Live CD for key management is a quite different scenario than day-to-day use on a regular OS. And the second, thanks to Lachlan Gunn for reminding me the other day: On 02/06/16 21:47, Werner Koch wrote[2]: > On Thu, 2 Jun 2016 12:43, dashohoxha at gmail.com said: > >> How far is the branch 2.1 from a stable release? > > it is not just stable, but modern! Go and use it. So what makes you say that 2.1 will not be for end-users until 2.2 has been released? I don't think that is the versioning model of the GnuPG project. It wasn't during the 1.4/2.0 period, before 2.1 was released. HTH, Peter. [1] https://lists.gnupg.org/pipermail/gnupg-users/2016-May/055943.html [2] https://lists.gnupg.org/pipermail/gnupg-users/2016-June/056107.html -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From caro at nymph.paranoici.org Thu Aug 11 00:22:20 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Wed, 10 Aug 2016 22:22:20 +0000 (UTC) Subject: Standard gnupg folder created despite --homedir parameter References: <20160808182057.a4550940e28b8311b7d44fad@usabilitypartners.se> <87bn12s16a.fsf@wheatstone.g10code.de> <20160809232332.DF01710320F7@remailer.paranoici.org> Message-ID: <20160810222220.457711031E4D@remailer.paranoici.org> On Wed, 10 Aug 2016 10:40:29 +0200, Peter Lebbing wrote: >On 10/08/16 01:23, Carola Grunwald wrote: >> May I ask how that translates into the Windows world? Is it a way to >> get rid of the ...\AppData\Roaming\gnupg folder? > >While the directory names give off a strong Unixy vibe[1], the text says "On >Windows systems" and "under Windows". Have you tried to create those >directories? I don't think there is any "translation", this is how you should do >it on Windows specifically. (The gpgconf tool is also indicated as >'gpgconf.exe', on Unix systems it would not have an extension.) > >Try this: > >F:\PortableApps\MyProject\gpg\gpgconf.exe >F:\PortableApps\MyProject\gpg\gpgconf.ctl >F:\PortableApps\MyProject\gpg\home >F:\PortableApps\MyProject\gpg\usr\local\var\cache\gnupg > >HTH, > >Peter. > >[1] Heck, /usr/local/var/cache/gnupg is the concatenation of two standard Linux >directory names. Two for the price of one! It's an odd one, that. Makes you >wonder whether it's a copy-paste error. Many many thanks Werner & Peter, You made my day! It works great the way you told me. Please excuse my slow-wittedness concerning the unixoid folder names. Marvellous support here. Keep on with your important work! Bye Caro From peter at digitalbrains.com Thu Aug 11 12:46:42 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 11 Aug 2016 12:46:42 +0200 Subject: Standard gnupg folder created despite --homedir parameter In-Reply-To: <20160810222220.457711031E4D@remailer.paranoici.org> References: <20160808182057.a4550940e28b8311b7d44fad@usabilitypartners.se> <87bn12s16a.fsf@wheatstone.g10code.de> <20160809232332.DF01710320F7@remailer.paranoici.org> <20160810222220.457711031E4D@remailer.paranoici.org> Message-ID: On 11/08/16 00:22, Carola Grunwald wrote: > You made my day! Great! > Please excuse my slow-wittedness > concerning the unixoid folder names. No need to apologise, I wouldn't be able to count the number of times I misread something and later wondered how I could have missed it. And in this case, it's even clear how you could have missed it: the odd names and the fact that / is used as a directory separator, rather than the \ of DOS and Windows. > Keep on with your important work! Without disparaging the work I actually do ;-), I'm not affiliated with GnuPG. This mailing list is just a hobby for me. Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From rjh at sixdemonbag.org Thu Aug 11 16:20:38 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 11 Aug 2016 10:20:38 -0400 Subject: Standard gnupg folder created despite --homedir parameter In-Reply-To: References: <20160808182057.a4550940e28b8311b7d44fad@usabilitypartners.se> <87bn12s16a.fsf@wheatstone.g10code.de> <20160809232332.DF01710320F7@remailer.paranoici.org> <20160810222220.457711031E4D@remailer.paranoici.org> Message-ID: <6e1c8099-32bb-b4c2-51a7-d3af111ac063@sixdemonbag.org> > No need to apologise, I wouldn't be able to count the number of times > I misread something and later wondered how I could have missed it. In fact, an excellent rule of thumb for this list is there are no experts -- just idiots who have carefully kept track of their mistakes. :) > I'm not affiliated with GnuPG. This mailing list is just a hobby for > me. Watch your back, Jack. A lot of people who are affiliated with GnuPG started out with the "it's just a hobby!" line. :) From andrewg at andrewg.com Thu Aug 11 16:25:31 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 11 Aug 2016 15:25:31 +0100 Subject: Standard gnupg folder created despite --homedir parameter In-Reply-To: <6e1c8099-32bb-b4c2-51a7-d3af111ac063@sixdemonbag.org> References: <20160808182057.a4550940e28b8311b7d44fad@usabilitypartners.se> <87bn12s16a.fsf@wheatstone.g10code.de> <20160809232332.DF01710320F7@remailer.paranoici.org> <20160810222220.457711031E4D@remailer.paranoici.org> <6e1c8099-32bb-b4c2-51a7-d3af111ac063@sixdemonbag.org> Message-ID: <06c17e12-fb40-160c-9489-334ee5d49093@andrewg.com> On 11/08/16 15:20, Robert J. Hansen wrote: >> No need to apologise, I wouldn't be able to count the number of times >> I misread something and later wondered how I could have missed it. > > In fact, an excellent rule of thumb for this list is there are no > experts -- just idiots who have carefully kept track of their > mistakes. :) The definition of "expert" is someone who's made all the same mistakes as you, just earlier. ;-) A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From sinclair.andersen at usabilitypartners.se Thu Aug 11 18:34:20 2016 From: sinclair.andersen at usabilitypartners.se (Sinclair Andersen) Date: Thu, 11 Aug 2016 18:34:20 +0200 Subject: Standard gnupg folder created despite --homedir parameter Message-ID: On 11/08/16 00:22, Carola Grunwald wrote: >> Try this: >> >> F:\PortableApps\MyProject\gpg\gpgconf.exe >> F:\PortableApps\MyProject\gpg\gpgconf.ctl >> F:\PortableApps\MyProject\gpg\home >> F:\PortableApps\MyProject\gpg\usr\local\var\cache\gnupg >> >> HTH, >> >> Peter. > > Many many thanks Werner & Peter, > > You made my day! > > It works great the way you told me. Please excuse my slow-wittedness > concerning the unixoid folder names. Marvellous support here. Actually Peter, you made two days. ;) I can only agree with Caro in thanking you both. All teh best, Sinclair From daniel at hillsdalecorp.com Mon Aug 15 15:33:47 2016 From: daniel at hillsdalecorp.com (Daniel H. Werner) Date: Mon, 15 Aug 2016 06:33:47 -0700 Subject: 2 Q's Message-ID: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> I have finally and successfully gotten GPG up and running on my Mac desktop and my Mac laptop (and also on my iPhone with iPGMail). Your application is so superior to the earlier version of PGP that I used some years ago. My hat is off to everyone who working on this! I have 2 questions: 1) How can I set the time for retention of the Passphrase? and 2) What is the best way to automatically send my Public Key to message recipients? Thanks. Daniel _______________________________ Daniel H. Werner, President Hillsdale Corporation 9 Oregon Yacht Club Portland, OR 97202 USA www.hillsdalecorp.com Cell: (503) 709-0950 Confidentiality Notice: The information contained in this e-mail is confidential and for the intended recipient(s) alone. It may contain privileged and confidential information and is covered by Non-Disclosure Agreements. If you are not an intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this e-mail in error, please notify us immediately. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: HSDL_Logo_H.smjpg.jpg Type: image/jpeg Size: 8411 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From fa-ml at ariis.it Tue Aug 16 00:48:25 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Tue, 16 Aug 2016 00:48:25 +0200 Subject: 2 Q's In-Reply-To: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> Message-ID: <20160815224825.GA19876@casa.casa> On Mon, Aug 15, 2016 at 06:33:47AM -0700, Daniel H. Werner wrote: > 2) What is the best way to automatically send my Public Key to message recipients? Why not upload it to your site (if you have it) or to a keyserver? From eric.pruitt at gmail.com Tue Aug 16 02:36:36 2016 From: eric.pruitt at gmail.com (Eric Pruitt) Date: Mon, 15 Aug 2016 17:36:36 -0700 Subject: 2 Q's In-Reply-To: <20160815224825.GA19876@casa.casa> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <20160815224825.GA19876@casa.casa> Message-ID: <20160816003636.GB5275@sinister.codevat.com> On Tue, Aug 16, 2016 at 12:48:25AM +0200, Francesco Ariis wrote: > On Mon, Aug 15, 2016 at 06:33:47AM -0700, Daniel H. Werner wrote: > > 2) What is the best way to automatically send my Public Key to > > message recipients? > > Why not upload it to your site (if you have it) or to a keyserver? Following up on this, it's fairly common for people to add email headers with information that can be used to fetch a public key. For example, all of the emails I send using Mutt include this header: X-PGP-Key: https://www.codevat.com/pgp.asc#0x8DDDE2E6053692AB There are some other variants of this header like "OpenPGP: ...", and "PGP-Key: ..." I thought X-PGP-Key was supposed to become the standard, but I just read an IETF draft (https://www.ietf.org/archive/id/draft-josefsson-openpgp-mailnews-header-07.txt), and it looks like "OpenPGP" is what you _should_ use, so I will probably change mine after I do some more research. Eric From mirimir at riseup.net Tue Aug 16 02:32:09 2016 From: mirimir at riseup.net (Mirimir) Date: Mon, 15 Aug 2016 18:32:09 -0600 Subject: 2 Q's In-Reply-To: <20160815224825.GA19876@casa.casa> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <20160815224825.GA19876@casa.casa> Message-ID: <5e796dfb-0af5-c579-533e-5771365d4e48@riseup.net> On 08/15/2016 04:48 PM, Francesco Ariis wrote: > On Mon, Aug 15, 2016 at 06:33:47AM -0700, Daniel H. Werner wrote: >> 2) What is the best way to automatically send my Public Key to message recipients? > > Why not upload it to your site (if you have it) or to a keyserver? I like . From rjh at sixdemonbag.org Tue Aug 16 15:00:47 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Aug 2016 09:00:47 -0400 Subject: 2 Q's In-Reply-To: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> Message-ID: <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> > 1) How can I set the time for retention of the Passphrase? This depends on what version of GnuPG you're using. The mechanism changed between GnuPG 1.4 and 2.0. Look for a configuration file called "gpg-agent.conf" (normally found in ~/.gnupg; dunno where it would be stored on iOS). Open it up with your favorite text editor and look for the line: default-cache-ttl That's the duration, in seconds, your passphrase will be retained. 3600 seconds is one hour, and 86400 seconds is one day. > 2) What is the best way to automatically send my Public Key to message > recipients? Don't. Public keys are big and a little obnoxious. Send your public certificate to a keyserver. In your email signature, you can say something like "OpenPGP Certificate ID: 1DCBDC01B44427C7". Anyone can then retrieve your public certificate by typing something like: $ gpg --keyserver pool.sks-keyservers.net --recv-key 1DCBDC01B44427C7 ... and presto, they get it and import it into GnuPG, all in one statement. From rjh at sixdemonbag.org Tue Aug 16 15:48:25 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Aug 2016 09:48:25 -0400 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: <201608161500.04678.bernhard@intevation.de> References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <7D23F54FC682AC47A4CDA79EF435336A25A04A1B@HQITEXCH07.pclc0.merkle.local> <87h9tbppwy.fsf@vigenere.g10code.de> <201608161500.04678.bernhard@intevation.de> Message-ID: [puts on official FAQ maintainer hat] > Just noticed that the FAQ (and documentation) could be improved > to recommend some gpg.conf options: I'm weakly against this. If we want to recommend people put something in gpg.conf, what we should be doing is changing the default behavior to be that, rather than expecting people to set an option. I agree that long keyids are preferable for the future, but I think the proper fix here is to make them the default behavior. As always, though, if the list consensus is to do it in gpg.conf, I'll amend the FAQ to recommend such. Does anyone have any strong opinions on the matter? From bernhard at intevation.de Tue Aug 16 16:05:17 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 16 Aug 2016 16:05:17 +0200 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <201608161500.04678.bernhard@intevation.de> Message-ID: <201608161605.17974.bernhard@intevation.de> Am Dienstag, 16. August 2016 15:48:25 schrieb Robert J. Hansen: > [puts on official FAQ maintainer hat] > > > Just noticed that the FAQ (and documentation) could be improved > > to recommend some gpg.conf options: > > I'm weakly against this. If we want to recommend people put something > in gpg.conf, what we should be doing is changing the default behavior to > be that, rather than expecting people to set an option. > > I agree that long keyids are preferable for the future, but I think the > proper fix here is to make them the default behavior. > > As always, though, if the list consensus is to do it in gpg.conf, I'll > amend the FAQ to recommend such. Does anyone have any strong opinions > on the matter? I've got the impression from Werner that this is the current state of affairs: Recommend keyid-format long, but do not make it a default. (*) I am all for making it a default with GnuPG 2.1 at least, because people should profit from using a stable API like GPGME. But unless it is the default in most installations out there, I'd welcome having it in the FAQ. (*) There probably was previous discussion about this which I could not easily find. Please point me to it by pm or take the subject to gnupg-devel. Best, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Aug 16 16:08:46 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 16 Aug 2016 16:08:46 +0200 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: <201608161605.17974.bernhard@intevation.de> References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <201608161500.04678.bernhard@intevation.de> <201608161605.17974.bernhard@intevation.de> Message-ID: <556e8bc1-aec5-bd0d-4ec7-a9803a986bfa@sumptuouscapital.com> On 08/16/2016 04:05 PM, Bernhard Reiter wrote: > Am Dienstag, 16. August 2016 15:48:25 schrieb Robert J. Hansen: >> [puts on official FAQ maintainer hat] >> > > I am all for making it a default with GnuPG 2.1 at least, because people > The default in 2.1 is no keyid at all, but print full fingerprint so setting 0xlong here will be a degrade -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Quidquid latine dictum sit, altum videtur. Anything said in Latin sounds profound -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Tue Aug 16 16:14:24 2016 From: bernhard at intevation.de (bernhard at intevation.de) Date: Tue, 16 Aug 2016 16:14:24 +0200 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: <556e8bc1-aec5-bd0d-4ec7-a9803a986bfa@sumptuouscapital.com> References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <201608161605.17974.bernhard@intevation.de> <556e8bc1-aec5-bd0d-4ec7-a9803a986bfa@sumptuouscapital.com> Message-ID: <201608161614.24388.bernhard@intevation.de> Am Dienstag, 16. August 2016 16:08:46 schrieb Kristian Fiskerstrand: > > I am all for making it a default with GnuPG 2.1 at least, because people > > The default in 2.1 is no keyid at all, but print full fingerprint so > setting 0xlong here will be a degrade Ah thanks, this was introduced with 2.1.13 and I tested the behaviour on an earlier 2.1 version where it make a difference. So it is a recommendation for GnuPG v <=2.0. -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Aug 16 15:00:00 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 16 Aug 2016 15:00:00 +0200 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: <87h9tbppwy.fsf@vigenere.g10code.de> References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <7D23F54FC682AC47A4CDA79EF435336A25A04A1B@HQITEXCH07.pclc0.merkle.local> <87h9tbppwy.fsf@vigenere.g10code.de> Message-ID: <201608161500.04678.bernhard@intevation.de> Just noticed that the FAQ (and documentation) could be improved to recommend some gpg.conf options: Am Montag, 23. M?rz 2015 18:46:53 schrieb Werner Koch: > On Mon, 23 Mar 2015 17:29, CRivard at merkleinc.com said: > > Question though - the gpg.conf file is optional? If I want one I must > > create it? > > Yes, it is optional. If you have more than one key it is advisable to > create one and add > > --8<---------------cut here---------------start------------->8--- > default-key 1234567812345678 > encrypt-to 1234567812345678 > keyid-format long > keyserver hkp://keys.gnupg.net > --8<---------------cut here---------------end--------------->8--- > > So that gpg knows which is your default key (in this example the one > with key id 1234567812345678), to which key all messages shall be > encrypted in addition to the recipients (so that you can decrypt your > own mails), that a keyserver shall be used, and finally to use the long > keyid format. > > Depending on the mail program, you need to add an encrypt-to in any > case. So keyid-format long seems to be a general recommendation for a gpg.conf. Reason: collisions with 32bit pubkey-ids, see evil32.com. Drawback: possibly may break some scripts (*)? And the FAQ should pick this up, the current version has | 8.7 What options should I put in my configuration file? | |The good news is, you really shouldn?t need to. https://www.gnupg.org/faq/gnupg-faq.html#new_user_gpg_conf I could not find this recommendation in the texinfo manual. (*) Was it discussed somewhere, which tools are affected, btw? Best, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Tue Aug 16 16:57:07 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Aug 2016 10:57:07 -0400 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: <201608161614.24388.bernhard@intevation.de> References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <201608161605.17974.bernhard@intevation.de> <556e8bc1-aec5-bd0d-4ec7-a9803a986bfa@sumptuouscapital.com> <201608161614.24388.bernhard@intevation.de> Message-ID: <5fbf8bca-6aea-43f7-c77b-61ac4906fc1a@sixdemonbag.org> > Ah thanks, this was introduced with 2.1.13 and I tested the > behaviour on an earlier 2.1 version where it make a difference. > So it is a recommendation for GnuPG v <=2.0. Concur. I'll make the change shortly. From joshuaaschaeffer at gmail.com Tue Aug 16 22:23:01 2016 From: joshuaaschaeffer at gmail.com (Spoofy32 .) Date: Tue, 16 Aug 2016 16:23:01 -0400 Subject: Assistance with decryption failure, gpg unable to find secret key that actually exists Message-ID: Greetings! I am currently having an issue with decrypting a simple text file encrypted by gpg using a key pair that I was able to successfully import (including the private key). The key material in the secret key packet is unencrypted to keep things simple. Despite both the public and private keys being present when I list them with gpg --list-keys and gpg --list-secret-keys, I receive the following error messages: gpg: public key decryption failed: Wrong secret key used -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshuaaschaeffer at gmail.com Tue Aug 16 22:39:11 2016 From: joshuaaschaeffer at gmail.com (Spoofy32 .) Date: Tue, 16 Aug 2016 16:39:11 -0400 Subject: [Resend] Assistance with decryption failure, gpg unable to find secret key that actually exists Message-ID: Apologies, I sent the previous email to the list before I finished typing it (and I didn't have the undo send option enabled)! Please disregard that email and my apologies for any inconvenience. Actually intended text: Greetings! I am currently having an issue with decrypting a simple text file encrypted by gpg using a key pair that I was able to successfully import (including the private key). The key material in the secret key packet is unencrypted to keep things simple. Despite both the public and private keys being present when I list them with gpg --list-keys and gpg --list-secret-keys, I receive the following error messages when trying to decrypt: gpg: public key decryption failed: Wrong secret key used gpg: decryption failed: No secret key The key IDs in the --list-keys outputs match between the private and public keys. As much as I can determine, the output from gpg --list-packets on the key file matches what is outlined in the packet formats described in the RFC 4880. The file I am trying to decrypt was encrypted with gpg. I am confident in a lack of syntax errors when typing in the commands. Unfortunately, the debug flags haven't seemed to provide anything useful. While I assume there is an issue with the key packet construction that prevents gpg from understanding where the key material starts/ends, I can't figure out what the issue is. Any assistance on gathering more information would be much appreciated and I am happy to provide any interesting details. Thank you for your time in this matter :) Much Appreciated, Josh Schaeffer -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabri.philippe at gmail.com Wed Aug 17 12:06:02 2016 From: gabri.philippe at gmail.com (Gabriel Philippe) Date: Wed, 17 Aug 2016 12:06:02 +0200 Subject: 2 Q's In-Reply-To: <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> Message-ID: On Tue, Aug 16, 2016 at 3:00 PM, Robert J. Hansen wrote: >> 2) What is the best way to automatically send my Public Key to message >> recipients? > > Don't. Public keys are big and a little obnoxious. Send your public > certificate to a keyserver. In your email signature, you can say > something like "OpenPGP Certificate ID: 1DCBDC01B44427C7". Obnoxious also. "gpg --batch --keyserver-options auto-key-retrieve" does the job, or clicking on a button within Thunderbird. If some people don't know how to fetch a public key from a signature, it's better not to trust encryption with them. Concerning key servers, unless in very specific cases, I think keys should be on big and commonly used keyservers which synchronize among themselves. Otherwise new signatures, IDs, and revocations will not get propagated when people refresh their keyring. -- Gabriel From rjh at sixdemonbag.org Wed Aug 17 15:21:32 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 17 Aug 2016 09:21:32 -0400 Subject: 2 Q's In-Reply-To: References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> Message-ID: <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> > Concerning key servers, unless in very specific cases, I think keys > should be on big and commonly used keyservers which synchronize among > themselves. Otherwise new signatures, IDs, and revocations will not > get propagated when people refresh their keyring. You're assuming people refresh their keyrings. Although that's a recommended practice, it appears to be the opinion of the minority. My certificate 0x23806BE5D6B98E10 has been revoked for seven months now, and yet people continue to use it instead of 0x1DCBDC01B44427C7. If they had refreshed their keyrings even once in that time period, they would no longer be able to encrypt to 0x23806BE5D6B98E10. Before people ask: (a) yes, I did inform people of the certificate change (b) six months later I revoked 0x23806BE5D6B98E10, (c) so it's now a year post-notice, seven months post-revoke (d) and people still keep using the old one. (P.S.: if I bcc'd you on this, please type "gpg --refresh" now... :) ) From andrewg at andrewg.com Wed Aug 17 15:27:18 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Aug 2016 14:27:18 +0100 Subject: 2 Q's In-Reply-To: <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> Message-ID: <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> On 17/08/16 14:21, Robert J. Hansen wrote: >> Concerning key servers, unless in very specific cases, I think keys >> should be on big and commonly used keyservers which synchronize among >> themselves. Otherwise new signatures, IDs, and revocations will not >> get propagated when people refresh their keyring. > > You're assuming people refresh their keyrings. Although that's a > recommended practice, it appears to be the opinion of the minority. That sounds like an argument for marking downloaded local copies of public keys stale after a certain period, similarly to DNS TTL... A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Aug 17 15:52:59 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 17 Aug 2016 09:52:59 -0400 Subject: 2 Q's In-Reply-To: <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> Message-ID: <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> > That sounds like an argument for marking downloaded local copies of > public keys stale after a certain period, similarly to DNS TTL... That suggestion fills me with horror. Key management is *already* a nightmare without adding this to it. Better by far to provide a cronjob that can do the refreshing automatically -- or, on Windows, to write a service to do it. From juanmi.3000 at gmail.com Wed Aug 17 16:19:49 2016 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Wed, 17 Aug 2016 16:19:49 +0200 Subject: 2 Q's In-Reply-To: <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> Message-ID: <53064053-499a-0b7d-874f-70aa26251a4e@gmail.com> On 2016-08-17 at 15:52, Robert J. Hansen wrote: > Better by far to provide a cronjob that can do the refreshing > automatically -- or, on Windows, to write a service to do it. > Or an scheduled task. -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF From bernhard at intevation.de Wed Aug 17 16:24:45 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 17 Aug 2016 16:24:45 +0200 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: <5fbf8bca-6aea-43f7-c77b-61ac4906fc1a@sixdemonbag.org> References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <201608161614.24388.bernhard@intevation.de> <5fbf8bca-6aea-43f7-c77b-61ac4906fc1a@sixdemonbag.org> Message-ID: <201608171624.49432.bernhard@intevation.de> Am Dienstag, 16. August 2016 16:57:07 schrieb Robert J. Hansen: > > Ah thanks, this was introduced with 2.1.13 and I tested the > > behaviour on an earlier 2.1 version where it make a difference. > > So it is a recommendation for GnuPG v <=2.0. > > Concur. I'll make the change shortly. Thanks. To meanwhile spread the word, I have temporarily added the following news to the wiki.gnupg.org == News * 2016-08-16: Somebody uploaded the [[https://evil32.org|evil32]] pubkeys to keyservers. It is time to remind people to set the default {{{keyid-format long}}} in their {{{gpg.conf}}} to use 64bit keyids. This is for GnuPG v<=2.0.x as 2.2 will have an even longer default. If you have scripts or software that breaks, point it out to it's devs and maybe suggest switching to [[./APIs|GPGME]]. ---- In German, Heise reported this today: http://www.heise.de/newsticker/meldung/Haufenweise-Fake-PGP-Schluessel-im-Umlauf-3297175.html -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Aug 17 16:27:30 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 17 Aug 2016 16:27:30 +0200 Subject: [Resend] Assistance with decryption failure, gpg unable to find secret key that actually exists In-Reply-To: References: Message-ID: <201608171627.30547.bernhard@intevation.de> Am Dienstag, 16. August 2016 22:39:11 schrieb Spoofy32 .: > The key IDs in the --list-keys outputs match between the private and public > keys. Given the round of fake keys that were available yesterday from a number of keyservers, I additionally recommend checking and comparing the long keyid. gpg2 --keyid-format=long --list-keys gpg2 -d -vv yourfile.txt -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Aug 17 16:29:33 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 17 Aug 2016 16:29:33 +0200 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: <201608171624.49432.bernhard@intevation.de> References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <201608161614.24388.bernhard@intevation.de> <5fbf8bca-6aea-43f7-c77b-61ac4906fc1a@sixdemonbag.org> <201608171624.49432.bernhard@intevation.de> Message-ID: On 08/17/2016 04:24 PM, Bernhard Reiter wrote: > Am Dienstag, 16. August 2016 16:57:07 schrieb Robert J. Hansen: >>> Ah thanks, this was introduced with 2.1.13 and I tested the >>> behaviour on an earlier 2.1 version where it make a difference. >>> So it is a recommendation for GnuPG v <=2.0. >> >> Concur. I'll make the change shortly. > > Thanks. > To meanwhile spread the word, I have temporarily added the following news to > the wiki.gnupg.org > > == News > * 2016-08-16: Somebody uploaded the [[https://evil32.org|evil32]] pubkeys to > keyservers. It is time to remind people to set > the default {{{keyid-format long}}} in their {{{gpg.conf}}} to use 64bit I'm not sure I like this, it avoids the actual issue of people using non-verified keys (and verification would be using fingerprint to begin with, although I might read it without the proper context in this email) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Aquila non capit muscas The eagle does not hunt flies -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Aug 17 16:36:05 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Aug 2016 15:36:05 +0100 Subject: 2 Q's In-Reply-To: <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> Message-ID: <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> On 17/08/16 14:52, Robert J. Hansen wrote: >> That sounds like an argument for marking downloaded local copies of >> public keys stale after a certain period, similarly to DNS TTL... > > That suggestion fills me with horror. Key management is *already* a > nightmare without adding this to it. ;-) Key management is a nightmare whether you add tests or not. At least with tests you *know* how bad it is...! The above suggestion would only be workable in combination with auto-key-locate, of course. A prompt to proceed with a stale key in the case of limited network access might also be useful. But the substantial point is that a) regular key refreshes should be default behaviour and b) failure to refresh keys on time should be an error. > Better by far to provide a cronjob that can do the refreshing > automatically -- or, on Windows, to write a service to do it. Parcimonie already exists. But it's an optional extra that most people don't install (or even know of). People shouldn't be expected to install or configure extras before they have a (safely) usable system. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From jerry at seibercom.net Wed Aug 17 16:54:35 2016 From: jerry at seibercom.net (Jerry) Date: Wed, 17 Aug 2016 10:54:35 -0400 Subject: 2 Q's In-Reply-To: <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> Message-ID: <20160817105435.00003eca@seibercom.net> On Wed, 17 Aug 2016 15:36:05 +0100, Andrew Gallagher stated: >Parcimonie already exists. But it's an optional extra that most people >don't install (or even know of). People shouldn't be expected to >install or configure extras before they have a (safely) usable system. Okay, I give up. What is "Parcimonie"? -- Jerry From wk at gnupg.org Wed Aug 17 16:53:57 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Aug 2016 16:53:57 +0200 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: (Kristian Fiskerstrand's message of "Wed, 17 Aug 2016 16:29:33 +0200") References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <201608161614.24388.bernhard@intevation.de> <5fbf8bca-6aea-43f7-c77b-61ac4906fc1a@sixdemonbag.org> <201608171624.49432.bernhard@intevation.de> Message-ID: <87ziobxx8a.fsf@wheatstone.g10code.de> On Wed, 17 Aug 2016 16:29, kristian.fiskerstrand at sumptuouscapital.com said: > I'm not sure I like this, it avoids the actual issue of people using > non-verified keys (and verification would be using fingerprint to begin > with, although I might read it without the proper context in this email) Displaying the long keyid has been suggested for 10 years but you are fully right, it does not help. I just put this into the 1.4 README NEVER use the keyid to verify a key - always use the complete fingerprint. The keyid is just a convenience handle to identify a key by a short semi-unique name which is trivial to spoof. You may want to put the line "keyid-format long" into your gpg.conf to tell gpg to print the long keyid (which is still spoof-able). FWIW, I really wonder why people seem to use the keyid to check keys. Most of us have been in key signing parties and learned that one needs to mumble the _fingerprint_. Some oldtimers still have the habit of also comparing the keyid and the creation date, but that was only helpful in PGP-2 times to mitigate a problem in the PGP-2 key format. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From bernhard at intevation.de Wed Aug 17 17:04:45 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 17 Aug 2016 17:04:45 +0200 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: <87ziobxx8a.fsf@wheatstone.g10code.de> References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <87ziobxx8a.fsf@wheatstone.g10code.de> Message-ID: <201608171704.45722.bernhard@intevation.de> Am Mittwoch, 17. August 2016 16:53:57 schrieb Werner Koch: > FWIW, I really wonder why people seem to use the keyid to check keys. It is not done to check keys, it done to distinquish keys to select in user interfaces. You could call this some sort of "checking" of course, but it is a usability problem. -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Wed Aug 17 17:07:34 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Aug 2016 16:07:34 +0100 Subject: 2 Q's In-Reply-To: <20160817105435.00003eca@seibercom.net> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> <20160817105435.00003eca@seibercom.net> Message-ID: <74c1ad74-0ccf-89bd-69f2-6a02ff8a16e8@andrewg.com> On 17/08/16 15:54, Jerry wrote: > On Wed, 17 Aug 2016 15:36:05 +0100, Andrew Gallagher stated: > >> Parcimonie already exists. But it's an optional extra that most people >> don't install (or even know of). People shouldn't be expected to >> install or configure extras before they have a (safely) usable system. > > Okay, I give up. What is "Parcimonie"? "parcimonie is a daemon that slowly refreshes a gpg public keyring from a keyserver." https://packages.debian.org/jessie/parcimonie (The original homepage isn't responding) A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Aug 17 17:32:03 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 17 Aug 2016 17:32:03 +0200 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: <201608171704.45722.bernhard@intevation.de> References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <87ziobxx8a.fsf@wheatstone.g10code.de> <201608171704.45722.bernhard@intevation.de> Message-ID: <7e034e5a-16a9-d6e5-2747-76e43b3aac51@sumptuouscapital.com> On 08/17/2016 05:04 PM, Bernhard Reiter wrote: > Am Mittwoch, 17. August 2016 16:53:57 schrieb Werner Koch: >> FWIW, I really wonder why people seem to use the keyid to check keys. > > It is not done to check keys, it done to distinquish keys to select > in user interfaces. At which point even short keyid isn't an issue as long as they only select amongst valid keys to begin with, unless they actually have two people with colliding keyids by coincidence that they communicate with. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "We can only see a short distance ahead, but we can see plenty there that needs to be done." (Alan Turing) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From gabri.philippe at gmail.com Wed Aug 17 17:36:36 2016 From: gabri.philippe at gmail.com (Gabriel Philippe) Date: Wed, 17 Aug 2016 17:36:36 +0200 Subject: 2 Q's In-Reply-To: <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> Message-ID: On Wed, Aug 17, 2016 at 3:21 PM, Robert J. Hansen wrote: > You're assuming people refresh their keyrings. Although that's a > recommended practice, it appears to be the opinion of the minority. I am used to being a minority. :) > My > certificate 0x23806BE5D6B98E10 has been revoked for seven months now, > and yet people continue to use it instead of 0x1DCBDC01B44427C7. If > they had refreshed their keyrings even once in that time period, they > would no longer be able to encrypt to 0x23806BE5D6B98E10. Set an expiration date to your key one year from now. Every 6 months, postpone this expiration date to 6 more months. It's too late for these people, but in the future and same conditions, others won't have a false security feeling when writing to you: if they keep using the wrong tkey, they will get a warning. -- Gabriel From andrewg at andrewg.com Wed Aug 17 17:43:43 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Aug 2016 16:43:43 +0100 Subject: 2 Q's In-Reply-To: References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> Message-ID: On 17/08/16 16:36, Gabriel Philippe wrote: > > Set an expiration date to your key one year from now. Every 6 months, > postpone this expiration date to 6 more months. It's too late for > these people, but in the future and same conditions, others won't have > a false security feeling when writing to you: if they keep using the > wrong tkey, they will get a warning. Computers were invented to liberate us from such drudgery. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From gabri.philippe at gmail.com Wed Aug 17 17:43:56 2016 From: gabri.philippe at gmail.com (Gabriel Philippe) Date: Wed, 17 Aug 2016 17:43:56 +0200 Subject: 2 Q's In-Reply-To: <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> Message-ID: On Wed, Aug 17, 2016 at 4:36 PM, Andrew Gallagher wrote: > Parcimonie already exists. But it's an optional extra that most people > don't install (or even know of). People shouldn't be expected to > install or configure extras before they have a (safely) usable system. I wonder if it's possible to bring real security to people without them understanding the complicated things that happen behind the user interface. I think not. However, I agree with you Parcimonie should be widerly spread. -- Gabriel From lachlan at twopif.net Wed Aug 17 16:53:09 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Thu, 18 Aug 2016 00:23:09 +0930 Subject: 2 Q's In-Reply-To: <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> Message-ID: Le 18 ao?t 2016 00:09, "Andrew Gallagher" a ?crit : > Parcimonie already exists. But it's an optional extra that most people > don't install (or even know of). People shouldn't be expected to > install or configure extras before they have a (safely) usable system. I coincidentally am working on a daemon to do this, actually a superset of what Parcimonie does. Significantly though it shouldn't need Tor or Perl for basic functionality, so running it in the background on a Windows machine in a corporate network will at least be vaguely plausible with a reasonably-sized executable. If anyone has feature requests for such a thing then I'd be interested to hear. Thanks, Lachlan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Wed Aug 17 17:52:28 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Aug 2016 16:52:28 +0100 Subject: 2 Q's In-Reply-To: References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> Message-ID: <90e81ec2-ec20-8260-e930-45d2d2824bee@andrewg.com> On 17/08/16 16:43, Gabriel Philippe wrote: > On Wed, Aug 17, 2016 at 4:36 PM, Andrew Gallagher wrote: >> Parcimonie already exists. But it's an optional extra that most people >> don't install (or even know of). People shouldn't be expected to >> install or configure extras before they have a (safely) usable system. > > I wonder if it's possible to bring real security to people without > them understanding the complicated things that happen behind the user > interface. I think not. The only thing that can't be worked around is out-of-band identity verification - but better tools can make that process less painful. Everything else is automatable in principle. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From gabri.philippe at gmail.com Wed Aug 17 18:03:08 2016 From: gabri.philippe at gmail.com (Gabriel Philippe) Date: Wed, 17 Aug 2016 18:03:08 +0200 Subject: 2 Q's In-Reply-To: References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> Message-ID: On Wed, Aug 17, 2016 at 5:43 PM, Andrew Gallagher wrote: > On 17/08/16 16:36, Gabriel Philippe wrote: >> >> Set an expiration date to your key one year from now. Every 6 months, >> postpone this expiration date to 6 more months. It's too late for >> these people, but in the future and same conditions, others won't have >> a false security feeling when writing to you: if they keep using the >> wrong tkey, they will get a warning. > > Computers were invented to liberate us from such drudgery. I know several people for whom you can find public keys on keyservers with no expiration date, who have lost the private key. Long time ago, just testing PGP, disk crash with no backup... Sometimes they still using the same e-mail address. Maybe softwares creating keys should impose expiration dates, unless in export modes. Maybe softwares using keys should automatically postpone expiration dates and re-export the keys... But computers can't do everything. People have to learn and understand some basics, and practice. -- Gabriel From jonas.hedman at fripost.org Wed Aug 17 16:55:30 2016 From: jonas.hedman at fripost.org (Jonas Hedman) Date: Wed, 17 Aug 2016 16:55:30 +0200 Subject: 2 Q's In-Reply-To: <20160817105435.00003eca@seibercom.net> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> <20160817105435.00003eca@seibercom.net> Message-ID: <20160817145530.GA9801@bruce> On 16-08-17 10:54, Jerry wrote: > On Wed, 17 Aug 2016 15:36:05 +0100, Andrew Gallagher stated: > > >Parcimonie already exists. But it's an optional extra that most people > >don't install (or even know of). People shouldn't be expected to > >install or configure extras before they have a (safely) usable system. > > Okay, I give up. What is "Parcimonie"? https://github.com/EtiennePerot/parcimonie.sh -- Jonas Hedman PGP: 8F72 C5BE AAFA B4BA 8F46 9185 5C39 89E0 616B B08C XMPP: nstr at nstr.se 3778B2B8 1E1F192A E12F7046 EACA5C35 24F05C7E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From juanmi.3000 at gmail.com Wed Aug 17 18:16:44 2016 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Wed, 17 Aug 2016 18:16:44 +0200 Subject: 2 Q's In-Reply-To: <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> Message-ID: <6d8e48c0-b903-51e0-8cc9-76e4f00a4cfa@gmail.com> On 2016-08-17 at 16:36, Andrew Gallagher wrote: > Parcimonie already exists. But it's an optional extra that most people > don't install (or even know of). People shouldn't be expected to > install or configure extras before they have a (safely) usable system. > Last time I checked, Parcimonie wasn't made on Windows so: ? I know about it ? I would love to install it ? I can't install it -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Aug 17 18:06:56 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Aug 2016 18:06:56 +0200 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] Message-ID: <87fuq3xtun.fsf@wheatstone.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of new Libgcrypt and GnuPG versions to *fix a critical security problem*. Felix D?rre and Vladimir Klebanov from the Karlsruhe Institute of Technology found a bug in the mixing functions of Libgcrypt's random number generator: An attacker who obtains 4640 bits from the RNG can trivially predict the next 160 bits of output. This bug exists since 1998 in all GnuPG and Libgcrypt versions. Impact ====== All Libgcrypt and GnuPG versions released before 2016-08-17 are affected on all platforms. A first analysis on the impact of this bug in GnuPG shows that existing RSA keys are not weakened. For DSA and Elgamal keys it is also unlikely that the private key can be predicted from other public information. This needs more research and I would suggest _not to_ overhasty revoke keys. Solution ======== If you are using a vendor supplied version of GnuPG or Libgcrypt: * Wait for an update from your vendor. If you are using a GnuPG-2 version (2.0.x or 2.1.x): * Update Libgcrypt. We have released these fixed versions of Libgcrypt: 1.7.3, 1.6.6, and 1.5.6. See below for download information. If you are using GnuPG-1 version (1.4.x): * Update as soon as possible to GnuPG 1.4.21. See below for download information. Support ======= For help on developing with GnuPG or Libgcrypt you should read the included manuals and ask on the appropriate mailing list [1,2]. A listing with commercial support offers for GnuPG and Libgcrypt and related software is available at the GnuPG web site [3]. Maintenance and development of GnuPG and Libgcrypt is mostly financed by donations; see . We need your donations to continue our work. Thanks ====== We like to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Thanks to Felix D?rre and Vladimir Klebanov for sending us a draft of their research paper and working with us on a solution. Also many thanks to all our donors [4]. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source tarballs and their digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.3.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.3.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.6.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.6.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.6.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.6.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.21.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.21.tar.bz2.sig These files are also available via HTTP: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.3.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.3.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.6.6.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.6.6.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.5.6.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.5.6.tar.bz2.sig https://gnupg.org/ftp/gcrypt/gnupg/gnupg-1.4.21.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-1.4.21.tar.bz2.sig Checking the Integrity ====================== In order to check that the version you downloaded is an original and unmodified file please follow the instructions found at . In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.7.4.tar.bz2 you would use this command: gpg --verify libgcrypt-1.7.4.tar.bz2.sig libgcrypt-1.7.4.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. - If you are not able to use GnuPG, you have to verify the SHA-1 checksum. For example: sha1sum libgcrypt-1.7.3.tar.bz2 and check that the output matches the first line from the this list: 5a034291e7248592605db448481478e6c963aa9c libgcrypt-1.7.3.tar.bz2 a05cba7037e6cbc68dcf3ea5b45f703b79fa234f libgcrypt-1.7.3.tar.gz ad79fd0b6963e1049612aa5d98e1a0b8eb775701 libgcrypt-1.6.6.tar.bz2 d11b6ca1d55eb12f5d3091a5169d874806007130 libgcrypt-1.6.6.tar.gz 62eade7cd3545efee1a87512d54f69151abbae47 libgcrypt-1.5.6.tar.bz2 8d3f55cce21e17f21d0c991cccf6bf52ec244353 libgcrypt-1.5.6.tar.gz e3bdb585026f752ae91360f45c28e76e4a15d338 gnupg-1.4.21.tar.bz2 97bfba0e4db7cb1a3458f73240481767cb7fe90e gnupg-1.4.21.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users 'at' gnupg.org mailing list. [1] https://lists.gnupg.org/mailman/listinfo/gnupg-devel [2] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel [3] https://www.gnupg.org/service.html [4] https://gnupg.org/donate/kudos.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 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 andrewg at andrewg.com Wed Aug 17 18:41:29 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Aug 2016 17:41:29 +0100 Subject: 2 Q's In-Reply-To: References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> Message-ID: <4711ed5d-ce9c-db38-9192-7ffc36300602@andrewg.com> On 17/08/16 17:03, Gabriel Philippe wrote: > On Wed, Aug 17, 2016 at 5:43 PM, Andrew Gallagher wrote: >> On 17/08/16 16:36, Gabriel Philippe wrote: >>> >>> Set an expiration date to your key one year from now. Every 6 months, >>> postpone this expiration date to 6 more months. It's too late for >>> these people, but in the future and same conditions, others won't have >>> a false security feeling when writing to you: if they keep using the >>> wrong tkey, they will get a warning. >> >> Computers were invented to liberate us from such drudgery. > > I know several people for whom you can find public keys on keyservers > with no expiration date, who have lost the private key. Long time ago, > just testing PGP, disk crash with no backup... Sometimes they still > using the same e-mail address. /me raises his hand guiltily My only hope is that someday 1024-bit DSA keys will be generally deprecated... > Maybe softwares creating keys should impose expiration dates, unless > in export modes. Yes, absolutely. And it should also be made much clearer that expiration dates can be extended indefinitely. I threw away two perfectly good primary keys before I learned this handy fact. > Maybe softwares using keys should automatically > postpone expiration dates and re-export the keys... No, because you misplacing your private key and me failing to download your revocation are different problems, with different burdens of responsibility and different urgencies. A weekly or even daily keyring refresh could be considered prudent - but weekly key expirations would be extreme. To use the DNS analogy again, "TTL" and "expiry" are different numbers. One is a cache refresh schedule and one is a cache invalidation schedule. Not the same thing at all. > But computers > can't do everything. People have to learn and understand some basics, > and practice. The entire point of civilisation is that you don't need to know everything. Sure, computer geeks should know these things. But your granny should never need to know what goes on under the hood of her software, any more than she needs to know how to refine diesel or bump a yale lock. If you make the barriers to entry too high, people just won't bother. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From mailinglist at darac.org.uk Wed Aug 17 17:37:24 2016 From: mailinglist at darac.org.uk (Darac Marjal) Date: Wed, 17 Aug 2016 16:37:24 +0100 Subject: 2 Q's In-Reply-To: <74c1ad74-0ccf-89bd-69f2-6a02ff8a16e8@andrewg.com> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> <20160817105435.00003eca@seibercom.net> <74c1ad74-0ccf-89bd-69f2-6a02ff8a16e8@andrewg.com> Message-ID: <20160817153724.r2vdr5z62ivn24g7@darac.org.uk> On Wed, Aug 17, 2016 at 04:07:34PM +0100, Andrew Gallagher wrote: >On 17/08/16 15:54, Jerry wrote: >> On Wed, 17 Aug 2016 15:36:05 +0100, Andrew Gallagher stated: >> >>> Parcimonie already exists. But it's an optional extra that most people >>> don't install (or even know of). People shouldn't be expected to >>> install or configure extras before they have a (safely) usable system. >> >> Okay, I give up. What is "Parcimonie"? > >"parcimonie is a daemon that slowly refreshes a gpg public keyring >from a keyserver." > >https://packages.debian.org/jessie/parcimonie > >(The original homepage isn't responding) There's also a shell-based reimplementation, if the dependencies of the original are a bit too heavy: https://github.com/EtiennePerot/parcimonie.sh -- For more information, please reread. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: not available URL: From ben at adversary.org Wed Aug 17 18:59:37 2016 From: ben at adversary.org (Ben McGinnes) Date: Thu, 18 Aug 2016 02:59:37 +1000 Subject: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions In-Reply-To: <7e034e5a-16a9-d6e5-2747-76e43b3aac51@sumptuouscapital.com> References: <7D23F54FC682AC47A4CDA79EF435336A25A04920@HQITEXCH07.pclc0.merkle.local> <87ziobxx8a.fsf@wheatstone.g10code.de> <201608171704.45722.bernhard@intevation.de> <7e034e5a-16a9-d6e5-2747-76e43b3aac51@sumptuouscapital.com> Message-ID: <20160817165937.GB78958@adversary.org> On Wed, Aug 17, 2016 at 05:32:03PM +0200, Kristian Fiskerstrand wrote: > On 08/17/2016 05:04 PM, Bernhard Reiter wrote: > > Am Mittwoch, 17. August 2016 16:53:57 schrieb Werner Koch: > >> FWIW, I really wonder why people seem to use the keyid to check keys. > > > > It is not done to check keys, it done to distinquish keys to select > > in user interfaces. > > At which point even short keyid isn't an issue as long as they only > select amongst valid keys to begin with, unless they actually have two > people with colliding keyids by coincidence that they communicate with. I've actually had precisely this problem in the past, but both keys belonged to certain (different) individuals who each thought it would be "cool" to generate a key with the short ID of 0x00000000. So annoying. Both of them disappeared from whichever forum or list they'd been encountered on and those keys are amongst the few that have been more trouble than they're worth and deleted. Normally I leave the ever expanding keyring to, well, expand. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed Aug 17 20:15:31 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 17 Aug 2016 14:15:31 -0400 Subject: 2 Q's In-Reply-To: <20160817105435.00003eca@seibercom.net> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> <20160817105435.00003eca@seibercom.net> Message-ID: <29bdc03d-8c95-55df-fd50-72299dd9fda4@sixdemonbag.org> > Okay, I give up. What is "Parcimonie"? A poorly-thought-out answer to a problem that doesn't exist. Parcimonie is a key refreshing daemon. (So far, cool! It's a real problem. Solving this problem is cool.) In order to defend against completely hypothetical movie plot attacks, it insists on refreshing the keys spread out over a long period of time and routing everything through Tor. The developers of Parcimonie claim that if you refresh your keyring all at once, you're giving someone monitoring keyservers information about your social graph and that could be useful in defeating your privacy. That's true, but it's also missing the point. There are literally *thousands* of things people could hypothetically be doing to defeat your privacy: should we have thousands of tools to defend against these thousands of hypotheticals, or should we instead ask that we focus our efforts on the very real risks we face? Solving real problems is good. "Solving" hypothetical ones, I'm not fond of... From andrewg at andrewg.com Wed Aug 17 20:35:00 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Aug 2016 19:35:00 +0100 Subject: 2 Q's In-Reply-To: <29bdc03d-8c95-55df-fd50-72299dd9fda4@sixdemonbag.org> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> <20160817105435.00003eca@seibercom.net> <29bdc03d-8c95-55df-fd50-72299dd9fda4@sixdemonbag.org> Message-ID: <3ba49a43-81b7-f056-a719-169982f42d1d@andrewg.com> On 17/08/16 19:15, Robert J. Hansen wrote: > > Parcimonie is a key refreshing daemon. (So far, cool! It's a real > problem. Solving this problem is cool.) In order to defend against > completely hypothetical movie plot attacks, it insists on refreshing the > keys spread out over a long period of time and routing everything > through Tor. Public keys are low-latency things anyway, so it matters little if parcimonie is being overly paranoid for the average user. The only problem arises when $WORK decides to block tor - but you can fool parcimonie into using plain https (just need to read between the lines of the man page). This is an excellent example of how software ecosystems take on lives of their own. When the only people who are using your system in anger are people with different political priorities to yours, don't be surprised when they fix the problems that you haven't got round to fixing yet in ways that you don't approve of. ;-) A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Aug 17 20:38:02 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Aug 2016 19:38:02 +0100 Subject: 2 Q's In-Reply-To: <3ba49a43-81b7-f056-a719-169982f42d1d@andrewg.com> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> <9d74fb84-3653-bd35-fcd2-5c62d9825bb1@andrewg.com> <20160817105435.00003eca@seibercom.net> <29bdc03d-8c95-55df-fd50-72299dd9fda4@sixdemonbag.org> <3ba49a43-81b7-f056-a719-169982f42d1d@andrewg.com> Message-ID: On 17/08/16 19:35, Andrew Gallagher wrote: > > Public keys are low-latency things D'oh. s/low/high/ A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From joshuaaschaeffer at gmail.com Wed Aug 17 16:00:46 2016 From: joshuaaschaeffer at gmail.com (Spoofy32 .) Date: Wed, 17 Aug 2016 10:00:46 -0400 Subject: [Resend] Assistance with decryption failure, gpg unable to find secret key that actually exists In-Reply-To: References: Message-ID: --status-file outputs: [GNUPG:] ENC_TO XXXXXXXXXXXXXXXX 1 0 [GNUPG:] GOOD_PASSPHRASE [GNUPG:] ERROR pkdecrypt_failed 18 [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_FAILED [GNUPG:] END_DECRYPTION Is there a place where error code 18 is defined? On Wed, Aug 17, 2016 at 8:33 AM, Daniel Ranft wrote: > Did you already check the status output? There are 2 options for having a > look at them: --status-fd and --status-file - whatever you prefer. > The syntax of this status output is described in the DETAILS file in the > gnupg src/doc folder. > > Best Regards > Mantiorix > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Aug 18 07:22:21 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 18 Aug 2016 14:22:21 +0900 Subject: [Resend] Assistance with decryption failure, gpg unable to find secret key that actually exists In-Reply-To: References: Message-ID: On 08/17/2016 11:00 PM, Spoofy32 . wrote: > --status-file outputs: > > [GNUPG:] ENC_TO XXXXXXXXXXXXXXXX 1 0 > [GNUPG:] GOOD_PASSPHRASE > [GNUPG:] ERROR pkdecrypt_failed 18 > [GNUPG:] BEGIN_DECRYPTION > [GNUPG:] DECRYPTION_FAILED > [GNUPG:] END_DECRYPTION > > Is there a place where error code 18 is defined? > In libgpg-error/doc/errorref.txt, it says: 18 GPG_ERR_WRONG_SECKEY Wrong secret key used In the code of GnuPG, this error occurs when decryption by your private key is finished to get the secret session key, but the result of the secret session key is found malformed. I'm reading gnupg/g10/pubkey-enc.c. -- From wk at gnupg.org Thu Aug 18 09:14:27 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Aug 2016 09:14:27 +0200 Subject: [Resend] Assistance with decryption failure, gpg unable to find secret key that actually exists In-Reply-To: (NIIBE Yutaka's message of "Thu, 18 Aug 2016 14:22:21 +0900") References: Message-ID: <87lgzutup8.fsf@wheatstone.g10code.de> On Thu, 18 Aug 2016 07:22, gniibe at fsij.org said: > In libgpg-error/doc/errorref.txt, it says: > > 18 GPG_ERR_WRONG_SECKEY Wrong secret key used BTW, the tool gpg-error is a quick way to get this data: $ gpg-error 18 18 = (0, 18) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_WRONG_SECKEY) \ = (Unspecified source, Wrong secret key used) You can also do "gpg-error --list" to grep for things. errorref.txt has more detailed descriptions for some error codes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From HariharanShweta at JohnDeere.com Thu Aug 18 08:22:39 2016 From: HariharanShweta at JohnDeere.com (Hariharan Shweta) Date: Thu, 18 Aug 2016 06:22:39 +0000 Subject: Decryption failed: No secret key found (Please help !) Message-ID: Hi Team, We have setup the entire GnuPG software along with the keys in our Linux server. We are able to encrypt our message and send it to our vendor. even our vendor is able to decrypt it at their end. But we are not able to decrypt the message sent by the vendor to us. We tried decrypting the error from OS level . this is the error we got - root at ldxsap23: ~/.gnupg # gpg -v -v --decrypt /basis/home/sh34191/PYRESULT_KS_20160728192815.csv.pgp gpg: armor: BEGIN PGP MESSAGE :pubkey enc packet: version 3, algo 16, keyid D0D64F4A31743B64 data: [2045 bits] data: [2047 bits] gpg: public key is 31743B64 :pubkey enc packet: version 3, algo 16, keyid 4D5FEB7E55572F4B data: [2047 bits] data: [2042 bits] gpg: public key is 55572F4B :encrypted data packet: length: unknown mdc_method: 2 gpg: encrypted with ELG key, ID 55572F4B gpg: encrypted with ELG key, ID 31743B64 gpg: decryption failed: No secret key After checking the error logs, I found that the public key in the above mentioned log does not match our vendor's key number . So, I'm not sure if this value changes in the process or encryption/decryption or the error is something different. I really need your help in resolving this. These are my vendor's key pub 1024D/85093D7F 2011-12-22 uid gvqua01 (xxxxxxxx) > sub 2048g/CF00F368 2011-12-22 these are the libraries and their corresponding versions we have installed in our server. Please help us out here. LIBRARY/PACKAGE VERSION GnuPG stable 2.0.30 libgpg -error 1.23 libgcrypt 1.6.5 libksba 1.3.4 Libassuan 2.4.2 pth 2.0.7 zlib 1.2.8 Thanks. Regards, Shweta -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at adversary.org Thu Aug 18 11:10:22 2016 From: ben at adversary.org (Ben McGinnes) Date: Thu, 18 Aug 2016 19:10:22 +1000 Subject: Decryption failed: No secret key found (Please help !) In-Reply-To: References: Message-ID: <20160818091022.GC1215@adversary.org> On Thu, Aug 18, 2016 at 06:22:39AM +0000, Hariharan Shweta wrote: > Hi Team, > > > > We have setup the entire GnuPG software along with the keys in our > Linux server. We are able to encrypt our message and send it to our > vendor. even our vendor is able to decrypt it at their end. But we > are not able to decrypt the message sent by the vendor to us. [SNIP] > mdc_method: 2 > > gpg: encrypted with ELG key, ID 55572F4B > > gpg: encrypted with ELG key, ID 31743B64 > > gpg: decryption failed: No secret key It means they have not encrypted the message to your public key. Have you sent it to them? Is 0x31743B64 your key? That one isn't on the keyservers, whereas both the ADP ones are. Regards, Ben P.S. You know this is a public mailing list, right? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From pgut001 at cs.auckland.ac.nz Thu Aug 18 13:13:55 2016 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 18 Aug 2016 11:13:55 +0000 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] In-Reply-To: <87fuq3xtun.fsf@wheatstone.g10code.de> References: <87fuq3xtun.fsf@wheatstone.g10code.de> Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> Werner Koch writes: >Felix D?rre and Vladimir Klebanov from the Karlsruhe Institute of Technology >found a bug in the mixing functions of Libgcrypt's random number generator: >An attacker who obtains 4640 bits from the RNG can trivially predict the next >160 bits of output. This bug exists since 1998 in all GnuPG and Libgcrypt >versions. Are any more details on what the problem is available? This predates my Usenix Security paper that looked at various PRNGs, and the Kelsey, Schneier, Wagner and Hall PRNG paper didn't look at GPG either. Others looked mostly at one specific generator, often /dev/random, but also the Windows and OpenSSL ones. (OK, I'm downloading an older source archive now, let's see if I can find the flaw before Werner posts a reply :-). Peter. From pgut001 at cs.auckland.ac.nz Thu Aug 18 13:38:53 2016 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 18 Aug 2016 11:38:53 +0000 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> References: <87fuq3xtun.fsf@wheatstone.g10code.de>, <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> [Redirected to gnupg-devel rather than gnupg-users because it seems more appropriate there] I wrote: >OK, I'm downloading an older source archive now, let's see if I can find the >flaw before Werner posts a reply :-) So I think I've managed to reverse-engineer what the code is doing (there are no code comments explaining it). It's not at all what I described in my PRNG paper, but I can't tell if that's an accident or by design because, well, there are no code comments. What the GnuPG code does is mix the next 64 bytes and then overwrite the preceding 20 bytes with the mixed output, however this doesn't propagate any entropy along through the buffer. Quoting the original paper: Assuming the use of MD5, which has a 64-byte input and 16-byte output, we would hash the 16+64 bytes at locations n-16... n+63 and then write the resulting 16-byte hash to locations n ... n+15 (the chaining which is performed explicitly by PGP is performed implicitly here by including the previously processed 16 bytes in the input to the hash function). We then move forward 16 bytes and repeat the process, wrapping the input around to the start of the buffer when the end of the buffer is reached. The overlapping of the data input to each hash means that each 16-byte block which is processed is influenced by all the surrounding bytes The GnuPG code however only hashes the next 64 bytes, and then uses the output to overwrite the current 20 bytes (it uses RMD160, not MD5, since it's a bit newer than the original paper). No state is carried along. Peter. From HariharanShweta at JohnDeere.com Thu Aug 18 11:21:36 2016 From: HariharanShweta at JohnDeere.com (Hariharan Shweta) Date: Thu, 18 Aug 2016 09:21:36 +0000 Subject: Decryption failed: No secret key found (Please help !) In-Reply-To: <20160818091022.GC1215@adversary.org> References: <20160818091022.GC1215@adversary.org> Message-ID: Hi Ben, Thanks for the response. We have provided them our public key. The key 31743B64 is not our public key. I'm confused as our vendor is able to decrypt our message but we are not able to do it. Any advise is appreciated. Regards, Shweta -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Ben McGinnes Sent: Thursday, August 18, 2016 2:40 PM To: gnupg-users at gnupg.org Subject: Re: Decryption failed: No secret key found (Please help !) On Thu, Aug 18, 2016 at 06:22:39AM +0000, Hariharan Shweta wrote: > Hi Team, > > > > We have setup the entire GnuPG software along with the keys in our > Linux server. We are able to encrypt our message and send it to our > vendor. even our vendor is able to decrypt it at their end. But we are > not able to decrypt the message sent by the vendor to us. [SNIP] > mdc_method: 2 > > gpg: encrypted with ELG key, ID 55572F4B > > gpg: encrypted with ELG key, ID 31743B64 > > gpg: decryption failed: No secret key It means they have not encrypted the message to your public key. Have you sent it to them? Is 0x31743B64 your key? That one isn't on the keyservers, whereas both the ADP ones are. Regards, Ben P.S. You know this is a public mailing list, right? From sbutler at fchn.com Thu Aug 18 15:54:09 2016 From: sbutler at fchn.com (Steve Butler) Date: Thu, 18 Aug 2016 13:54:09 +0000 Subject: Decryption failed: No secret key found (Please help !) In-Reply-To: References: <20160818091022.GC1215@adversary.org> Message-ID: <09234b556b3b48418660c22828971cc0@t1l1exchmbs-01.fchn.com> -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Hariharan Shweta Thanks for the response. We have provided them our public key. The key 31743B64 is not our public key. I'm confused as our vendor is able to decrypt our message but we are not able to do it. Any advise is appreciated. From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Ben McGinnes Sent: Thursday, August 18, 2016 2:40 PM > > We have setup the entire GnuPG software along with the keys in our > Linux server. We are able to encrypt our message and send it to our > vendor. even our vendor is able to decrypt it at their end. But we are > not able to decrypt the message sent by the vendor to us. Let's say that you public key has an ID of PKA and your vendor has public key ID of PKB. When you encrypt your message to the vendor you encrypt with their PKB key ID. If you also want to decrypt that same message later for yourself you need to also encrypt it to PKA (encrypt to both key IDs). When your vendor sends a message to you they need to encrypt to your public key ID of PKA. It looks like they encrypted the message to two public keys. However, neither one is yours. You need to contact the vendor and ensure they encrypt messages to you with your PKA key ID. [Substitute actual fingerprint values as needed.] Give them the key IDs to which they did encrypt the message as that will help them figure out what they did wrong on their end. On a couple of occasions I've had vendors send me their private key along with the public key. [Holding head in hands!] You may need to hold their hands to get this working right for you. --Steve -- CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. From wk at gnupg.org Thu Aug 18 19:19:46 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Aug 2016 19:19:46 +0200 Subject: [Announce] GnuPG 2.1.15 released Message-ID: <8737m2ouz1.fsf@wheatstone.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.15. See below for a list of new features and bug fixes. About GnuPG ============= The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) comes with the latest features and is suggested for most users. This announcement is about this branch. - GnuPG "stable" (2.0) is the currently mostly used branch which will be maintain until 2017-12-31. - GnuPG "classic" (1.4) is a simplified version of GnuPG, required on very old platforms or to decrypt data created with PGP-2 keys. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. Noteworthy changes in version 2.1.15 ==================================== * gpg: Remove the --tofu-db-format option and support for the split TOFU database. * gpg: Add option --sender to prepare for coming features. * gpg: Add option --input-size-hint to help progress indicators. * gpg: Extend the PROGRESS status line with the counted unit. * gpg: Avoid publishing the GnuPG version by default with --armor. * gpg: Properly ignore legacy keys in the keyring cache. * gpg: Always print fingerprint records in --with-colons mode. * gpg: Make sure that keygrips are printed for each subkey in --with-colons mode. * gpg: New import filter "drop-sig". * gpgsm: Fix a bug in the machine-readable key listing. * gpg,gpgsm: Block signals during keyring updates to limits the effects of a Ctrl-C at the wrong time. * g13: Add command --umount and other fixes for dm-crypt. * agent: Fix regression in SIGTERM handling. * agent: Cleanup of the ssh-agent code. * agent: Allow import of overly long keys. * scd: Fix problems with card removal. * dirmngr: Remove all code for running as a system service. * tools: Make gpg-wks-client conforming to the specs. * tests: Improve the output of the new regression test tool. * tests: Distribute the standalone test runner. * tests: Run each test in a clean environment. * Spelling and grammar fixes. A detailed description of the changes found in the 2.1 branch can be found at . Please be aware that there are still known bugs which we are working on. Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.15 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.15.tar.bz2 (5590k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.15.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.15.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.15.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.15_20160818.exe (3569k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.15_20160818.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.15_20160818.exe https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.15_20160818.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. This Windows installer comes with TOFU support, translations, and support for Tor; it is still missing HKPS support, though. This Windows installer also fixes the Libgcrypt bug we announced yesterday. 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 version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.15.tar.bz2 you would use this command: gpg --verify gnupg-2.1.15.tar.bz2.sig gnupg-2.1.15.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.15.tar.bz2, you run the command like this: sha1sum gnupg-2.1.15.tar.bz2 and check that the output matches the next line: 908c86dac8e9a1fbf47e1605e570b11391b04ece gnupg-2.1.15.tar.bz2 c13fdb4daa2a2c715d86365e6ab6c3b70506340e gnupg-w32-2.1.15_20160818.exe 6e23249ed44f06638e760e06ab9f80112a257913 gnupg-w32-2.1.15_20160818.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated (2161 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow our postings at and . Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project employs 3 full-time developers, one part-timer, and one contractor. They all work exclusivly on GnuPG and closely related software like Libgcrypt and GPA. Please consider to donate via: https://gnupg.org/donate/ Conference ========== The OpenPGP.conf starts in 3 weeks; if you like to attended do not hesitate to ask for a grant towards the participation fee. See https://openpgp-conf.org Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and donating money. For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Aug 18 20:21:01 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Aug 2016 20:21:01 +0200 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Thu, 18 Aug 2016 11:38:53 +0000") References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> Message-ID: <87r39mndki.fsf@wheatstone.g10code.de> On Thu, 18 Aug 2016 13:38, pgut001 at cs.auckland.ac.nz said: > So I think I've managed to reverse-engineer what the code is doing (there are > no code comments explaining it). It's not at all what I described in my PRNG No need to reverse engineer the code. Well, unless you are looking at that 18 year old code from 1.4. Here is the description from Libgcrypt before the fix: * Mix the 600 byte pool. Note that the 64 byte scratch area directly * follows the pool. The numbers in the diagram give the number of * bytes. * <................600...............> <.64.> * pool |------------------------------------| |------| * <..44..> <20> * | | * | +-----+ * +-----------------------------------|--+ * v v * |------| * * | * +---------------------------------------+ * v * <20> * pool' |------------------------------------| * <20><20><..44..> * | | * | +------------------------------+ * +-------------------------------------+ | * v v * |------| * * | * +-----------------------------------+ * v * <20> * pool'' |------------------------------------| * <20><20><20><..44..> * | | * | +--------------------------+ * +---------------------------------+ | * v v * |------| * * * and so on until we did this for all 30 blocks. * * To better protect against implementation errors in this code, we * xor a digest of the entire pool into the pool before mixing. Earlier versions had the same comment but using a different markup; see end of the mail. I updated the comment while looking at the research paper. > there are no code comments. What the GnuPG code does is mix the next 64 bytes > and then overwrite the preceding 20 bytes with the mixed output, however this > doesn't propagate any entropy along through the buffer. Quoting the original We have 30 slots of 20 bytes and for each slot we take the previous 20 bytes and the next 44 bytes, hash them and put them into the current slot. Thus the state is carried along _except for the last slot_, which nobody figured out in the last 18 years. Despite several code audits, including one by an German random pope. Only a few weeks ago there was an audit and the guy who worked on this produced pretty diagrams showing the operation as they should be; i.e. derived from the code and not from the above comment. He didn't noticed the hole either and I looked at his documents only after I received the paper. > The GnuPG code however only hashes the next 64 bytes, and then uses the output > to overwrite the current 20 bytes (it uses RMD160, not MD5, since it's a bit > newer than the original paper). No state is carried along. Nope. We recently switched from RMD160 to SHA1 for other reasons but that does not matter. The reason why only 64 bytes are hashed is that it allows the use of the bare transform function. IIRC, old Cryptlib versions did the same but I guess you changed that to the full hash machinery in the course of your doctoral work. I _might_ have introduced the hole to mix in more bytes in each step. Or it was a plain bug. Here is the description for the fixed code: * <................600...............> <.64.> * pool |------------------------------------| |------| * <20><.24.> <20> * | | +-----+ * +-----|-------------------------------|-+ * +-------------------------------|-|-+ * v v v * |------| * * +---------------------------------------+ * v * <20> * pool' |------------------------------------| * <20><20><.24.> * +---|-----|---------------------------+ * +-----|---------------------------|-+ * +---------------------------|-|-+ * v v v * |------| * * | * +-----------------------------------+ * v * <20> * pool'' |------------------------------------| * <20><20><20><.24.> * +---|-----|-----------------------+ * +-----|-----------------------|-+ * +-----------------------|-|-+ * v v v * Salam-Shalom, Werner p.s. Here is the old comment on how the pool is mixed (libgcrypt 1.7.2) * Mix the pool: * * |........blocks*20byte........|20byte|..44byte..| * <..44byte..> <20byte> * | | * | +------+ * +---------------------------|----------+ * v v * |........blocks*20byte........|20byte|..44byte..| * <.....64bytes.....> * | * +----------------------------------+ * Hash * v * |.............................|20byte|..44byte..| * <20byte><20byte><..44byte..> * | | * | +---------------------+ * +-----------------------------+ | * v v * |.............................|20byte|..44byte..| * <.....64byte......> * | * +-------------------------+ * Hash * v * |.............................|20byte|..44byte..| * <20byte><20byte><..44byte..> -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From mwood at IUPUI.Edu Thu Aug 18 21:55:33 2016 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 18 Aug 2016 15:55:33 -0400 Subject: 2 Q's In-Reply-To: <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> References: <67B0DD37-DB52-403A-9A29-5EA25DE79195@hillsdalecorp.com> <52b3623d-3cb4-a8b4-c3a2-552bcfa2f881@sixdemonbag.org> <629ba5d1-64da-3df4-09eb-51158e34e5b6@sixdemonbag.org> <99dab34e-87bf-1ff4-9de5-06dc147a2021@andrewg.com> <88fc4ad1-be19-9455-6694-f53b1ae622f3@sixdemonbag.org> Message-ID: <20160818195533.GA5505@IUPUI.Edu> On Wed, Aug 17, 2016 at 09:52:59AM -0400, Robert J. Hansen wrote: > > That sounds like an argument for marking downloaded local copies of > > public keys stale after a certain period, similarly to DNS TTL... > > That suggestion fills me with horror. Key management is *already* a > nightmare without adding this to it. > > Better by far to provide a cronjob that can do the refreshing > automatically -- or, on Windows, to write a service to do it. No need for yet another service; use Task Scheduler to run the refresh command periodically. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From telegraph at gmx.net Thu Aug 18 23:51:55 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Thu, 18 Aug 2016 23:51:55 +0200 Subject: strange error message, how to delete key Message-ID: <20160818215155.GB7630@len.workgroup> Dear gnupg users/developers, I get strange errormessages when listing keys, e.g.: $ gpg --list-key doesnotexist gpg: Oops: keyid_from_fingerprint: no pubkey gpg: Oops: keyid_from_fingerprint: no pubkey gpg: key 0x00000000 occurs more than once in the trustdb gpg: Oops: keyid_from_fingerprint: no pubkey gpg: key 0x00000000 occurs more than once in the trustdb gpg: Oops: keyid_from_fingerprint: no pubkey gpg: key 0x00000000 occurs more than once in the trustdb gpg: Oops: keyid_from_fingerprint: no pubkey gpg: key 0x00000000 occurs more than once in the trustdb gpg: Oops: keyid_from_fingerprint: no pubkey gpg: key 0x00000000 occurs more than once in the trustdb gpg: error reading key: public key not found This strange key 0x00000000 is not deletable: p$ gpg --delete-keys 0x00000000 gpg: key "0x00000000" not found: eof gpg: 0x00000000: delete key failed: eof Any ideas, how to get rid of this? Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From ben at adversary.org Fri Aug 19 19:01:30 2016 From: ben at adversary.org (Ben McGinnes) Date: Sat, 20 Aug 2016 03:01:30 +1000 Subject: strange error message, how to delete key In-Reply-To: <20160818215155.GB7630@len.workgroup> References: <20160818215155.GB7630@len.workgroup> Message-ID: <20160819170130.GD1215@adversary.org> On Thu, Aug 18, 2016 at 11:51:55PM +0200, Gregor Zattler wrote: > Dear gnupg users/developers, > > I get strange errormessages when listing keys, e.g.: > > $ gpg --list-key doesnotexist > gpg: Oops: keyid_from_fingerprint: no pubkey > gpg: Oops: keyid_from_fingerprint: no pubkey > gpg: key 0x00000000 occurs more than once in the trustdb > gpg: Oops: keyid_from_fingerprint: no pubkey > gpg: key 0x00000000 occurs more than once in the trustdb > gpg: Oops: keyid_from_fingerprint: no pubkey > gpg: key 0x00000000 occurs more than once in the trustdb > gpg: Oops: keyid_from_fingerprint: no pubkey > gpg: key 0x00000000 occurs more than once in the trustdb > gpg: Oops: keyid_from_fingerprint: no pubkey > gpg: key 0x00000000 occurs more than once in the trustdb > gpg: error reading key: public key not found > > This strange key 0x00000000 is not deletable: > > p$ gpg --delete-keys 0x00000000 > gpg: key "0x00000000" not found: eof > gpg: 0x00000000: delete key failed: eof > > > Any ideas, how to get rid of this? I had this problem a while back when a certain person (I've encountered 2 and I think there are about half a dozen) joined another mailing list I'm on for a time. You need to isolate the keys by the 64-bit long key ID and delete those. I recommend starting with a check for this key and deleting it: 0xB4156B9700000000 The problem occurrs when multiple keys with a short key ID of all zeroes is created and entered. You'll probably need to delete and rebuild your trustdb from scratch and then avoid importing keys with short IDs like that. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From telegraph at gmx.net Fri Aug 19 21:16:47 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Fri, 19 Aug 2016 21:16:47 +0200 Subject: strange error message, how to delete key In-Reply-To: <20160819170130.GD1215@adversary.org> References: <20160818215155.GB7630@len.workgroup> <20160819170130.GD1215@adversary.org> Message-ID: <20160819191647.GA10139@len.workgroup> Hi Ben, * Ben McGinnes [20. Aug. 2016]: > On Thu, Aug 18, 2016 at 11:51:55PM +0200, Gregor Zattler wrote: >> I get strange errormessages when listing keys, e.g.: >> >> $ gpg --list-key doesnotexist >> gpg: Oops: keyid_from_fingerprint: no pubkey >> gpg: Oops: keyid_from_fingerprint: no pubkey >> gpg: key 0x00000000 occurs more than once in the trustdb >> gpg: Oops: keyid_from_fingerprint: no pubkey >> gpg: key 0x00000000 occurs more than once in the trustdb >> gpg: Oops: keyid_from_fingerprint: no pubkey >> gpg: key 0x00000000 occurs more than once in the trustdb >> gpg: Oops: keyid_from_fingerprint: no pubkey >> gpg: key 0x00000000 occurs more than once in the trustdb >> gpg: Oops: keyid_from_fingerprint: no pubkey >> gpg: key 0x00000000 occurs more than once in the trustdb >> gpg: error reading key: public key not found >> >> This strange key 0x00000000 is not deletable: >> >> p$ gpg --delete-keys 0x00000000 >> gpg: key "0x00000000" not found: eof >> gpg: 0x00000000: delete key failed: eof >> >> >> Any ideas, how to get rid of this? > > I had this problem a while back when a certain person (I've > encountered 2 and I think there are about half a dozen) joined another > mailing list I'm on for a time. You need to isolate the keys by the > 64-bit long key ID and delete those. I recommend starting with a > check for this key and deleting it: > > 0xB4156B9700000000 > > The problem occurrs when multiple keys with a short key ID of all > zeroes is created and entered. Thanks for your answer but in my case this seems not to be the cause: I did a gpg --list-public-keys |sed -e "s/ //g"|grep 000 and gpg --fingerprint --list-public-keys |sed -e "s/ //g"|grep 000 and there are no keys with key ids or fingerprints ending in more than two zeros. Any other ideas? Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From pgut001 at cs.auckland.ac.nz Fri Aug 19 14:08:01 2016 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri, 19 Aug 2016 12:08:01 +0000 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] In-Reply-To: <87r39mndki.fsf@wheatstone.g10code.de> References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz>, <87r39mndki.fsf@wheatstone.g10code.de> Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF4129@uxcn10-5.UoA.auckland.ac.nz> Werner Koch writes: >No need to reverse engineer the code. Well, unless you are looking at that >18 year old code from 1.4. Here is the description from Libgcrypt before the >fix: Ah, I was looking at cipher/random.c, for which the sole comment is /* loop over the pool */. >The reason why only 64 bytes are hashed is that it allows the use of the bare >transform function. IIRC, old Cryptlib versions did the same but I guess you >changed that to the full hash machinery in the course of your doctoral work. Yeah, the last time the raw hash was used was in the 2002 release, since then the code has used the high-level interface because calling into a low-level internal function isn't very portable, and it makes the result harder to analyse. So now I explicitly hash $hashsize + 64 bytes, $hashsize bytes before the current position for chaining and 64 bytes after. Peter. From ben at adversary.org Fri Aug 19 22:09:34 2016 From: ben at adversary.org (Ben McGinnes) Date: Sat, 20 Aug 2016 06:09:34 +1000 Subject: strange error message, how to delete key In-Reply-To: <20160819191647.GA10139@len.workgroup> References: <20160818215155.GB7630@len.workgroup> <20160819170130.GD1215@adversary.org> <20160819191647.GA10139@len.workgroup> Message-ID: <20160819200934.GE1215@adversary.org> On Fri, Aug 19, 2016 at 09:16:47PM +0200, Gregor Zattler wrote: > > Thanks for your answer but in my case this seems not to be the > cause: I did a > > gpg --list-public-keys |sed -e "s/ //g"|grep 000 > > and > > gpg --fingerprint --list-public-keys |sed -e "s/ //g"|grep 000 > > and there are no keys with key ids or fingerprints ending in > more than two zeros. > > Any other ideas? You may have had them in the past and the entry is still in the trustdb. So deleting it and forcing a rebuild (you can always move the old one somewhere else instead) should recreate the thing without those errors. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From telegraph at gmx.net Sat Aug 20 18:05:17 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Sat, 20 Aug 2016 18:05:17 +0200 Subject: SOLVED (was: Re: strange error message, how to delete key 0x00000000) In-Reply-To: <20160819200934.GE1215@adversary.org> References: <20160818215155.GB7630@len.workgroup> <20160819170130.GD1215@adversary.org> <20160819191647.GA10139@len.workgroup> <20160819200934.GE1215@adversary.org> Message-ID: <20160820160517.GB6700@len.workgroup> Hi Ben, * Ben McGinnes [20. Aug. 2016]: > On Fri, Aug 19, 2016 at 09:16:47PM +0200, Gregor Zattler wrote: >> >> Thanks for your answer but in my case this seems not to be the >> cause: I did a >> >> gpg --list-public-keys |sed -e "s/ //g"|grep 000 >> >> and >> >> gpg --fingerprint --list-public-keys |sed -e "s/ //g"|grep 000 >> >> and there are no keys with key ids or fingerprints ending in >> more than two zeros. >> >> Any other ideas? > > You may have had them in the past and the entry is still in the > trustdb. This was it. Amazing numbers of key fingerprints ending in at least 8 zeros. > So deleting it and forcing a rebuild (you can always move > the old one somewhere else instead) should recreate the thing without > those errors. Instead I did gpg --export-ownertrust, grep -v 00000000: and imported the result, thus I did not loose my ownertrust settings (e.g. which keys are mine = ultimate trusted). Thanks for your help, Gregor -- -... --- .-. . -.. ..--.. ...-.- From SLinnebur at redrobin.com Fri Aug 19 17:56:41 2016 From: SLinnebur at redrobin.com (Scott Linnebur) Date: Fri, 19 Aug 2016 15:56:41 +0000 Subject: File Encrypted with Primary key Message-ID: I have an issue that I just cannot figure out. What I'm trying to do is move a file between two organizations using two different transports while encrypting the file. On one side they use ipswitch movit to encrypt the file and post it to a sftp site. Then from my end I use camel to pick up the file, decrypt it and place it where it needs to go internally. What I have done is generate a key pair with GPG and have given the other company my public key to encrypt with as well as imported the key rings into Camel. Testing... They post the encrypted file and when my camel process pull is down I get the error "exception creating cipher". If I manually pull down the file I can decrypt it fine with GPG. If I encrypt a test file with my own public key and feed it to Camel it decrypts fine. This is where I think the problem is but I can't figure out a way to prove it. When I generated the key pair with GPG, it created a primary and secondary keys. Primary has usage set to SC and secondary set to E. When I look at the file they sent me, it's encrypted with the primary key. That file fails in the camel process but is successful in a manual GPG decyption process. When I encrypt a file with GPG it uses the secondary key and I can decrypt it with Camel or manually with GPG. I have a suspicion that is the cause but I can't test it. I can't find anyway to force the primary key to encrypt and I can't figure out how to generate a key pair without secondary keys in it. Any ideas how to troubleshoot this? The secondary party is not helpful and they are using their standard process with moveit to encrypt it and aren't likely to change that, especially if I can't prove that's what's wrong. Scott Linnebur IT Solutions Architect (303) 846-6176 Desk (720) 334-5206 Cell slinnebur at redrobin.com [RedRobin_Email_Logo_White_NoClearance] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 31200 bytes Desc: image001.jpg URL: From karol at babioch.de Sun Aug 21 00:11:45 2016 From: karol at babioch.de (Karol Babioch) Date: Sun, 21 Aug 2016 00:11:45 +0200 Subject: Deleting SSH key(s) from agent Message-ID: Hi all, I'm experimenting with using GPG as SSH agent. This basically works fine, although I'm missing some advanced features, which the original ssh-agent(1) provides. More specifically it seems to be impossible to delete identities from the agent once they are added. ssh-add -D returns: "All identities removed.". However, it is actually not removed and is still available afterwards. It seems to be possible to deactivate the key through the sshcontrol file, i.e. by commenting it out. While this removes it temporarily from the agent, simply commenting it back in, activates the key again, At least as long as the TTL is not yet expired. All in all this is not a great solution. The same is true for locking the agent down. This feature seems to be not implemented at all. I can lock the agent, but it makes no difference whether or not it is actually locked or unlocked, it always operates normally. Are these "advanced" features simply not implemented, or am I missing something here? How are you dealing with this? Thanks in advance! Best regards, Karol Babioch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sun Aug 21 12:27:37 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 21 Aug 2016 12:27:37 +0200 Subject: Deleting SSH key(s) from agent In-Reply-To: References: Message-ID: <3dea7fe6-1f23-781f-3e78-045bf9ed193f@digitalbrains.com> On 21/08/16 00:11, Karol Babioch wrote: > More specifically it seems to be impossible to delete identities from > the agent once they are added. Let me answer by example: ---------------------8<------------------->8--------------------- $ ssh-add -l 2048 27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1 cardno:000500000241 (RSA) 2048 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 /home/peter/.ssh/id_rsa (RSA) 256 03:92:b4:ff:0b:8c:dc:39:63:d0:18:c1:1e:78:12:ff test_id (ED25519) $ gpg-connect-agent > KEYINFO --ssh-list --ssh-fpr S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - 1 P 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - S S KEYINFO 5D73C7891879A68CE056175C3563F7064B03BAE8 D - - - P 03:92:b4:ff:0b:8c:dc:39:63:d0:18:c1:1e:78:12:ff - S OK > DELETE_KEY 5D73C7891879A68CE056175C3563F7064B03BAE8 OK > /bye $ ssh-add -l 2048 27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1 cardno:000500000241 (RSA) 2048 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 /home/peter/.ssh/id_rsa (RSA) ---------------------8<------------------->8--------------------- gpg-agent does not identify keys by the SSH fingerprint, but rather by a so-called keygrip. First I listed my keys known to ssh-add. Then I requested the same list through gpg-connect-agent, and this time it will show the keygrip as well as the SSH fingerprint. Using the information I thus learned, I was able to execute the DELETE_KEY statement using the keygrip of the "test_id" key I wanted to delete. Note that you can also delete the file "~/.gnupg/private-keys-v1.d/{KEYGRIP}.key" instead of using the DELETE_KEY agent command. > The same is true for locking the agent down. This feature seems to be > not implemented at all. I can lock the agent, but it makes no difference > whether or not it is actually locked or unlocked, it always operates > normally. You can make the GnuPG agent forget any cached passphrases through: $ gpg-connect-agent reloadagent /bye While this is different from "ssh-add -x", it's also a form of locking down. Note that I answered these questions using GnuPG v2.1. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sun Aug 21 12:54:15 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 21 Aug 2016 12:54:15 +0200 Subject: File Encrypted with Primary key In-Reply-To: References: Message-ID: I have no experience with the software you mention. Keep that in mind while reading my ramblings. On 19/08/16 17:56, Scott Linnebur wrote: > I have a suspicion that is the cause but I can?t test it. My key looks like this: $ gpg2 -k de500b3e pub rsa2048/DE500B3E 2009-11-12 [C] [expires: 2017-10-19] uid [ultimate] Peter Lebbing sub rsa2048/DE6CDCA1 2009-11-12 [S] [expires: 2017-10-19] sub rsa2048/73A33BEE 2009-11-12 [E] [expires: 2017-10-19] sub rsa2048/B65D8246 2009-12-05 [A] [expires: 2017-10-19] If something is encrypted to this key, gpg2 will mention the following: $ gpg2 test.gpg gpg: encrypted with 2048-bit RSA key, ID 73A33BEE, created 2009-11-12 "Peter Lebbing " So it explicitly tells me that it was encrypted to the encryption-capable subkey 73A33BEE. If it tells you that it was encrypted to the primary key ID instead, I think your analysis is right. > I can?t find > anyway to force the primary key to encrypt I don't think it is possible to force a key to be used in a way that is not indicated as a capability for that key. If something encrypts to a key that is not encryption-capable, that seems to me to be a major bug. Subkeys and key capability flags have been around for practically forever by now. Software that can't deal with this is not OpenPGP compatible and probably ancient. > and I can?t figure out how to > generate a key pair without secondary keys in it. It's possible, but first lets take a look if there is a different solution. Keys that can both sign and encrypt are frowned upon. The primary key necessarily has the Certify capability, which is a form of signing. So it shouldn't get the Encrypt capability. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From brian at minton.name Sun Aug 21 14:59:13 2016 From: brian at minton.name (Brian Minton) Date: Sun, 21 Aug 2016 12:59:13 +0000 Subject: File Encrypted with Primary key In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 You can use gpg --list-packets to see exactly what OpenPGP packets are present in the ciphertext. That would show you in great detail exactly what their software sent you. -----BEGIN PGP SIGNATURE----- iIAEAREKACghHEJyaWFuIE1pbnRvbiA8YnJpYW5AbWludG9uLm5hbWU+BQJXuaWV AAoJEGuOs6Blz7qpQUUA+wWcZe2Dod/SfyClhZW99j985S2Raji6R+0si31K7vYo AP9zynHbX0fmTIRXTelRtkxE1Tp816Dtn5FeZbjUlprzvw== =hhbz -----END PGP SIGNATURE----- On Sun, Aug 21, 2016, 6:53 AM Peter Lebbing wrote: > I have no experience with the software you mention. Keep that in mind > while reading my ramblings. > > On 19/08/16 17:56, Scott Linnebur wrote: > > I have a suspicion that is the cause but I can?t test it. > > My key looks like this: > > $ gpg2 -k de500b3e > pub rsa2048/DE500B3E 2009-11-12 [C] [expires: 2017-10-19] > uid [ultimate] Peter Lebbing > sub rsa2048/DE6CDCA1 2009-11-12 [S] [expires: 2017-10-19] > sub rsa2048/73A33BEE 2009-11-12 [E] [expires: 2017-10-19] > sub rsa2048/B65D8246 2009-12-05 [A] [expires: 2017-10-19] > > If something is encrypted to this key, gpg2 will mention the following: > > $ gpg2 test.gpg > gpg: encrypted with 2048-bit RSA key, ID 73A33BEE, created 2009-11-12 > "Peter Lebbing " > > So it explicitly tells me that it was encrypted to the > encryption-capable subkey 73A33BEE. If it tells you that it was > encrypted to the primary key ID instead, I think your analysis is right. > > > I can?t find > > anyway to force the primary key to encrypt > > I don't think it is possible to force a key to be used in a way that is > not indicated as a capability for that key. If something encrypts to a > key that is not encryption-capable, that seems to me to be a major bug. > Subkeys and key capability flags have been around for practically > forever by now. Software that can't deal with this is not OpenPGP > compatible and probably ancient. > > > and I can?t figure out how to > > generate a key pair without secondary keys in it. > > It's possible, but first lets take a look if there is a different > solution. Keys that can both sign and encrypt are frowned upon. The > primary key necessarily has the Certify capability, which is a form of > signing. So it shouldn't get the Encrypt capability. > > HTH, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at adversary.org Sun Aug 21 22:42:34 2016 From: ben at adversary.org (Ben McGinnes) Date: Mon, 22 Aug 2016 06:42:34 +1000 Subject: SOLVED (was: Re: strange error message, how to delete key 0x00000000) In-Reply-To: <20160820160517.GB6700@len.workgroup> References: <20160818215155.GB7630@len.workgroup> <20160819170130.GD1215@adversary.org> <20160819191647.GA10139@len.workgroup> <20160819200934.GE1215@adversary.org> <20160820160517.GB6700@len.workgroup> Message-ID: <20160821204234.GE64203@adversary.org> On Sat, Aug 20, 2016 at 06:05:17PM +0200, Gregor Zattler wrote: > Hi Ben, > * Ben McGinnes [20. Aug. 2016]: >> On Fri, Aug 19, 2016 at 09:16:47PM +0200, Gregor Zattler wrote: >> >> You may have had them in the past and the entry is still in the >> trustdb. > > This was it. Excellent. :) > Amazing numbers of key fingerprints ending in at least 8 zeros. Yeah, betting on someone thinking they're more clever than they actually are is always a safe bet. >> So deleting it and forcing a rebuild (you can always move >> the old one somewhere else instead) should recreate the thing without >> those errors. > > Instead I did gpg --export-ownertrust, grep -v 00000000: and > imported the result, thus I did not loose my ownertrust settings > (e.g. which keys are mine = ultimate trusted). Yeah, that's a pretty good solution too. I vaguely recall editing mine, but it was a while ago and the main thing I took away from the experience was that it was another fine example in the info sec world that "a little knowledge is a dangerous thing." ;) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From peter at digitalbrains.com Mon Aug 22 18:34:54 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 22 Aug 2016 18:34:54 +0200 Subject: File Encrypted with Primary key In-Reply-To: References: Message-ID: <8b4be611-0bc6-b8ca-b6ae-dbb462e8d6a5@digitalbrains.com> On 22/08/16 16:45, Scott Linnebur wrote: > Any idea why MoveIt would be encrypting this way? I thought OpenPGP-compliant implementations were required to respect the key flags, but on scanning the OpenPGP RFC (I took RFC 4880), it does not seem to be the case. That is, it is not required that compliant software encrypt to an encryption-capable key. But perhaps I missed the relevant part where it said it is a MUST/SHOULD NOT requirement... I did find this statement: > * Many security protocol designers think that it is a bad idea to use > a single key for both privacy (encryption) and integrity > (signatures). In fact, this was one of the motivating forces > behind the V4 key format with separate signature and encryption > keys. If you as an implementer promote dual-use keys, you should > at least be aware of this controversy. > And in addition?why does GPG > decrypt the file correctly? I'm surprised that GnuPG will happily decrypt with a key that does not have the Encrypt capability set. But perhaps it is precisely because OpenPGP-compliant software is allowed to ignore key usage flags. I might be a bit out of my league with this particular problem. I have no hard answers. But when it is confirmed that it is intended behaviour of GnuPG, perhaps the problem is that "camel" is too strict. And perhaps they actually want to be; it could be intended behaviour of "camel". In that case, "camel" and "MoveIt" are simply incompatible. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From SLinnebur at redrobin.com Mon Aug 22 16:45:46 2016 From: SLinnebur at redrobin.com (Scott Linnebur) Date: Mon, 22 Aug 2016 14:45:46 +0000 Subject: File Encrypted with Primary key In-Reply-To: References: Message-ID: Those commands verify what I was talking about. I would have included them originally but my post was already too long. I don?t work with encryption much but it didn?t seem right. Any idea why MoveIt would be encrypting this way? I tried to find any issues with that product but didn?t come up with much. Is there any hard documentation anywhere that would state this that I could send them? I know they are going to assume their product is working correctly. I would assume they use it with other customers. And in addition?why does GPG decrypt the file correctly? Thanks for your help on this. c:\Program Files (x86)\GNU\GnuPG\pub>gpg --edit-key ID at email.com gpg (GnuPG) 2.0.30; Copyright (C) 2015 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 2048R/617C9C82 created: 2016-08-10 expires: never usage: SC trust: ultimate validity: ultimate sub 2048R/D9D25C9A created: 2016-08-10 expires: never usage: E [ultimate] (1). ID c:\Program Files (x86)\GNU\GnuPG\pub>gpg --list-packets c:\users\user\desktop\TEST160811100826.txt.pgp :pubkey enc packet: version 3, algo 1, keyid 855D6DB5617C9C82 data: [2048 bits] You need a passphrase to unlock the secret key for user: " ID " 2048-bit RSA key, ID 617C9C82, created 2016-08-10 :encrypted data packet: length: 68 mdc_method: 2 gpg: encrypted with 2048-bit RSA key, ID 617C9C82, created 2016-08-10 " ID " :compressed packet: algo=1 :literal data packet: mode b (62), created 1470924984, name="TEST.txt", raw data: 19 bytes Scott Linnebur IT Solutions Architect (303) 846-6176 Desk (720) 334-5206 Cell slinnebur at redrobin.com [RedRobin_Email_Logo_White_NoClearance] From: Brian Minton [mailto:brian at minton.name] Sent: Sunday, August 21, 2016 6:59 AM To: Peter Lebbing ; Scott Linnebur ; gnupg-users at gnupg.org Subject: Re: File Encrypted with Primary key -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 You can use gpg --list-packets to see exactly what OpenPGP packets are present in the ciphertext. That would show you in great detail exactly what their software sent you. -----BEGIN PGP SIGNATURE----- iIAEAREKACghHEJyaWFuIE1pbnRvbiA8YnJpYW5AbWludG9uLm5hbWU+BQJXuaWV AAoJEGuOs6Blz7qpQUUA+wWcZe2Dod/SfyClhZW99j985S2Raji6R+0si31K7vYo AP9zynHbX0fmTIRXTelRtkxE1Tp816Dtn5FeZbjUlprzvw== =hhbz -----END PGP SIGNATURE----- On Sun, Aug 21, 2016, 6:53 AM Peter Lebbing > wrote: I have no experience with the software you mention. Keep that in mind while reading my ramblings. On 19/08/16 17:56, Scott Linnebur wrote: > I have a suspicion that is the cause but I can?t test it. My key looks like this: $ gpg2 -k de500b3e pub rsa2048/DE500B3E 2009-11-12 [C] [expires: 2017-10-19] uid [ultimate] Peter Lebbing > sub rsa2048/DE6CDCA1 2009-11-12 [S] [expires: 2017-10-19] sub rsa2048/73A33BEE 2009-11-12 [E] [expires: 2017-10-19] sub rsa2048/B65D8246 2009-12-05 [A] [expires: 2017-10-19] If something is encrypted to this key, gpg2 will mention the following: $ gpg2 test.gpg gpg: encrypted with 2048-bit RSA key, ID 73A33BEE, created 2009-11-12 "Peter Lebbing >" So it explicitly tells me that it was encrypted to the encryption-capable subkey 73A33BEE. If it tells you that it was encrypted to the primary key ID instead, I think your analysis is right. > I can?t find > anyway to force the primary key to encrypt I don't think it is possible to force a key to be used in a way that is not indicated as a capability for that key. If something encrypts to a key that is not encryption-capable, that seems to me to be a major bug. Subkeys and key capability flags have been around for practically forever by now. Software that can't deal with this is not OpenPGP compatible and probably ancient. > and I can?t figure out how to > generate a key pair without secondary keys in it. It's possible, but first lets take a look if there is a different solution. Keys that can both sign and encrypt are frowned upon. The primary key necessarily has the Certify capability, which is a form of signing. So it shouldn't get the Encrypt capability. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 31200 bytes Desc: image001.jpg URL: From anthony at cajuntechie.org Mon Aug 22 23:22:44 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Mon, 22 Aug 2016 16:22:44 -0500 Subject: OpenPGP Smartcard recommendations Message-ID: <7aecb8fb-5682-c00f-7bb0-7f2770dc4fd9@cajuntechie.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Everyone, I'm wanting to solidify my key security and I'm just not comfortable with having my OpenPGP key on my computer all the time. So I'd like to move to a smartcard solution. I've gone to the kernelconcepts.de page and tried to contact them but it looks like the domain simply isn't accepting mail and the site might just be a zombie. So I decided to come here and ask as well. Can anyone recommend a solid OpenPGP smartcard solution that meets the following criteria: 1) Supports up to 4096 bit RSA keys 2) Generates keys completely on the card 3) Can sign, encrypt, decrypt 4) Preferably has some tamper resistence 5) Can import an existing RSA key Also, since I'm pretty new to smartcard solutions, I'm also in the market for a reader. If you have any suggestions for one of those, I'd appreciate it too. If it makes a difference, I'm in the USA. Thanks, Anthony - -- OpenPGP Key: 4096R/0x028ADF7453B04B15 Other Key Info: http://www.cajuntechie.org/p/my-pgp-key.html XMPP?Jabber: cajuntech at dukgo.com VoIP/SIP: 17772471988101 at in.callcentric.com -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXu20kAAoJEAKK33RTsEsV5FcP/1+O1wvaEe7kRk1g2Am1J4X1 stQj8cf+wfWNuSO1Q1lOhEPbnAQGr1Kyq/BjLzO9nI9ViiIudlw1CTT6GnVBpkma +vXGNe0+SB99YszS/JQ0eMd1jk1IDGi1CdE52SYbtbooqSDDt3WgveiQZnGKz5Qm 2U/AZHP5rtyiEI1pOkc+i1Pwc0CZ99X9+PsPGffM+ijIgcZwm+UCitKlOfK3oERt dorXuvTkutRy8iSa4tBjGCBcDWdyNgbLQ6u8pV28KndLxXRr+D6JWw7euWpDLgp5 JK+5fQGoPnyRRy0sMkrBZ14WempgtRu7Ta6SjluxrTCg+/JfQ3tVIRB/CYe1cImr FfkjBBX6KCbokupFw1q10Dcf4y34vM8gRkxwRQAMNGW+9nq4KHAUhUhEFbPyfZFF kF7MSq1o1nZ1u1CA46+VP6pdVh7aCZJqjAwigfWeDRdFrk7mT0u53v/orvR8uXVj S/BrpYETkcQoyiWI4ToUD6AtfM6U9vl4nmodqYol0LZ36uXxkJBQnuoXc0eWLM61 83mCt8iHW3e7OydiWbH1Y+l9ZzjhEnVQyRhN4UjBtI+iDhjCfPfXRpwSf/bBwISy BF1/dD1Pu/sJQv1se9J+wet3bl3xyrpYv2Mdlj/xM7uczD14C7w+miCUmncvniEd xdH8nuXs2/uSZEaXu2W8 =4KIj -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Tue Aug 23 00:12:42 2016 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 22 Aug 2016 18:12:42 -0400 Subject: File Encrypted with Primary key In-Reply-To: References: Message-ID: <8116737E-EB5A-468A-80DC-BF1C8EBDD1B7@jabberwocky.com> On Aug 19, 2016, at 11:56 AM, Scott Linnebur wrote: > > I have an issue that I just cannot figure out. What I?m trying to do is move a file between two organizations using two different transports while encrypting the file. On one side they use ipswitch movit to encrypt the file and post it to a sftp site. Then from my end I use camel to pick up the file, decrypt it and place it where it needs to go internally. What I have done is generate a key pair with GPG and have given the other company my public key to encrypt with as well as imported the key rings into Camel. > > Testing? > They post the encrypted file and when my camel process pull is down I get the error ?exception creating cipher?. > If I manually pull down the file I can decrypt it fine with GPG. > If I encrypt a test file with my own public key and feed it to Camel it decrypts fine. > > This is where I think the problem is but I can?t figure out a way to prove it. When I generated the key pair with GPG, it created a primary and secondary keys. Primary has usage set to SC and secondary set to E. When I look at the file they sent me, it?s encrypted with the primary key. That file fails in the camel process but is successful in a manual GPG decyption process. When I encrypt a file with GPG it uses the secondary key and I can decrypt it with Camel or manually with GPG. I have a suspicion that is the cause but I can?t test it. I can?t find anyway to force the primary key to encrypt and I can?t figure out how to generate a key pair without secondary keys in it. Any ideas how to troubleshoot this? The secondary party is not helpful and they are using their standard process with moveit to encrypt it and aren?t likely to change that, especially if I can?t prove that?s what?s wrong. I have seen this before - basically the Moveit code is using a buggy/older OpenPGP engine that does the wrong thing and ignores key flags. Your key has an RSA primary key, and their engine sees that and concludes that since it's RSA, it can encrypt to it. GPG properly respects key flags so uses the subkey. There is only one fix for this, but two workarounds: 1 (the true fix): Get Moveit to fix their OpenPGP engine. That's likely not an easy task since Moveit most likely purchased it from an upstream vendor (I'm going to guess Symantec - I have a vague recollection the previous time I saw this was with the Symantec code), so the actual fix would need to be from the upstream vendor, then Moveit would have to integrate it, and then whoever you're communicating with would have to update Moveit. Given that this problem still exists in 2016, I'm going to guess that a fix here is not going to happen any time soon! 2 (workaround A): You can generate a key that explicitly permits encrypting to the primary key. Then both GPG and Moveit will encrypt to the primary and everyone can interoperate. This is not ideal as it is best practice to split the signing and encryption capabilities, but should solve your immediate problem. 3 (workaround B): Don't use an RSA primary key. Instead of generating a RSA primary key with an RSA subkey, generate a DSA primary key with an Elgamal subkey (or for that matter, an RSA subkey - what matters here is the primary is DSA). This pretty much forces the Moveit code to encrypt to the subkey since there is no way to encrypt to a DSA primary key (it's a signature-only algorithm). My advice would be to try workaround B first. If they're using the same engine that I saw before, it was smart enough to handle that case and would properly use the subkey. David From karol at babioch.de Tue Aug 23 02:54:39 2016 From: karol at babioch.de (Karol Babioch) Date: Tue, 23 Aug 2016 02:54:39 +0200 Subject: OpenPGP Smartcard recommendations In-Reply-To: <7aecb8fb-5682-c00f-7bb0-7f2770dc4fd9@cajuntechie.org> References: <7aecb8fb-5682-c00f-7bb0-7f2770dc4fd9@cajuntechie.org> Message-ID: <6a8a369f-cc0f-1443-2dfc-2e4557065053@babioch.de> Hi, Am 22.08.2016 um 23:22 schrieb Anthony Papillion: > I've gone to the kernelconcepts.de page and tried to contact them but > it looks like the domain simply isn't accepting mail and the site > might just be a zombie. I'm pretty sure you've done something wrong here. I just placed and received an order last week. > Can anyone recommend a solid OpenPGP smartcard solution that meets the > following criteria: Besides the smartcards from kernelconcepts, you can also become an FSFE member to get such a card [1]. Personally I absolutely love the YubiKey (4 Nano) [2]. It meets all of your criteria and can do a lot more (U2F, PIV, token, HOTP, TOTP, etc.). It is also a lot smaller than a real smartcard and can be left in the USB port all of the time. The Gemalto USB token (and/or real smartcards) are rather unhandy - at least for me. Best regards, Karol Babioch P.S.: I should also mention that there is some debate about the open source nature of the YubiKey 4, since its firmware is not open to review any longer. Should this be a criterion for you, you have to go with another solution. You'll find details on the story at [3]. [1]: https://fsfe.org/fellowship/card.html [2]: https://www.yubico.com/products/yubikey-hardware/yubikey4/ [3]: https://www.yubico.com/2016/05/secure-hardware-vs-open-source/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From cornelius.koelbel at netknights.it Tue Aug 23 05:38:42 2016 From: cornelius.koelbel at netknights.it (cornelius.koelbel) Date: Tue, 23 Aug 2016 05:38:42 +0200 Subject: AW: OpenPGP Smartcard recommendations Message-ID: Hi Anthony, You may also take a look at the Nitrokey.?Kind regards?Cornelius? Cornelius K?lbel?+49 151 2960 1417 NetKnights GmbHHttp://NetKnights. It +49 561 3166 797 -------- Urspr?ngliche Nachricht --------Von: Anthony Papillion Datum: 22.08.16 23:22 (GMT+01:00) An: gnupg-users at gnupg.org Betreff: OpenPGP Smartcard recommendations -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Everyone, I'm wanting to solidify my key security and I'm just not comfortable with having my OpenPGP key on my computer all the time. So I'd like to move to a smartcard solution. I've gone to the kernelconcepts.de page and tried to contact them but it looks like the domain simply isn't accepting mail and the site might just be a zombie. So I decided to come here and ask as well. Can anyone recommend a solid OpenPGP smartcard solution that meets the following criteria: 1) Supports up to 4096 bit RSA keys 2) Generates keys completely on the card 3) Can sign, encrypt, decrypt 4) Preferably has some tamper resistence 5) Can import an existing RSA key Also, since I'm pretty new to smartcard solutions, I'm also in the market for a reader. If you have any suggestions for one of those, I'd appreciate it too. If it makes a difference, I'm in the USA. Thanks, Anthony - -- OpenPGP Key:??? 4096R/0x028ADF7453B04B15 Other Key Info: http://www.cajuntechie.org/p/my-pgp-key.html XMPP?Jabber:??? cajuntech at dukgo.com VoIP/SIP:?????? 17772471988101 at in.callcentric.com -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXu20kAAoJEAKK33RTsEsV5FcP/1+O1wvaEe7kRk1g2Am1J4X1 stQj8cf+wfWNuSO1Q1lOhEPbnAQGr1Kyq/BjLzO9nI9ViiIudlw1CTT6GnVBpkma +vXGNe0+SB99YszS/JQ0eMd1jk1IDGi1CdE52SYbtbooqSDDt3WgveiQZnGKz5Qm 2U/AZHP5rtyiEI1pOkc+i1Pwc0CZ99X9+PsPGffM+ijIgcZwm+UCitKlOfK3oERt dorXuvTkutRy8iSa4tBjGCBcDWdyNgbLQ6u8pV28KndLxXRr+D6JWw7euWpDLgp5 JK+5fQGoPnyRRy0sMkrBZ14WempgtRu7Ta6SjluxrTCg+/JfQ3tVIRB/CYe1cImr FfkjBBX6KCbokupFw1q10Dcf4y34vM8gRkxwRQAMNGW+9nq4KHAUhUhEFbPyfZFF kF7MSq1o1nZ1u1CA46+VP6pdVh7aCZJqjAwigfWeDRdFrk7mT0u53v/orvR8uXVj S/BrpYETkcQoyiWI4ToUD6AtfM6U9vl4nmodqYol0LZ36uXxkJBQnuoXc0eWLM61 83mCt8iHW3e7OydiWbH1Y+l9ZzjhEnVQyRhN4UjBtI+iDhjCfPfXRpwSf/bBwISy BF1/dD1Pu/sJQv1se9J+wet3bl3xyrpYv2Mdlj/xM7uczD14C7w+miCUmncvniEd xdH8nuXs2/uSZEaXu2W8 =4KIj -----END PGP SIGNATURE----- _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony at cajuntechie.org Tue Aug 23 08:03:17 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Tue, 23 Aug 2016 01:03:17 -0500 Subject: OpenPGP Smartcard recommendations In-Reply-To: <6a8a369f-cc0f-1443-2dfc-2e4557065053@babioch.de> References: <7aecb8fb-5682-c00f-7bb0-7f2770dc4fd9@cajuntechie.org> <6a8a369f-cc0f-1443-2dfc-2e4557065053@babioch.de> Message-ID: <7a2f0365-c123-db07-373f-b9817ed9bbe1@cajuntechie.org> Thanks for the reply. I have an older Yubikey Classic and still use it to this day for a lot of things. It's awesome. I'll definitely take a look at the newer keys you mentioned and see if they are something I could use. Thanks for the recommendation. I might also join the FSFE. Does it matter that I am not in Europe (I'm in the USA)? Thanks, Anthony On 8/22/2016 7:54 PM, Karol Babioch wrote: > Hi, > > Am 22.08.2016 um 23:22 schrieb Anthony Papillion: >> I've gone to the kernelconcepts.de page and tried to contact them but >> it looks like the domain simply isn't accepting mail and the site >> might just be a zombie. > > I'm pretty sure you've done something wrong here. I just placed and > received an order last week. > >> Can anyone recommend a solid OpenPGP smartcard solution that meets the >> following criteria: > > Besides the smartcards from kernelconcepts, you can also become an FSFE > member to get such a card [1]. > > Personally I absolutely love the YubiKey (4 Nano) [2]. It meets all of > your criteria and can do a lot more (U2F, PIV, token, HOTP, TOTP, etc.). > It is also a lot smaller than a real smartcard and can be left in the > USB port all of the time. The Gemalto USB token (and/or real smartcards) > are rather unhandy - at least for me. > > Best regards, > Karol Babioch > > P.S.: I should also mention that there is some debate about the open > source nature of the YubiKey 4, since its firmware is not open to review > any longer. Should this be a criterion for you, you have to go with > another solution. You'll find details on the story at [3]. > > [1]: https://fsfe.org/fellowship/card.html > [2]: https://www.yubico.com/products/yubikey-hardware/yubikey4/ > [3]: https://www.yubico.com/2016/05/secure-hardware-vs-open-source/ > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From anthony at cajuntechie.org Tue Aug 23 07:53:41 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Tue, 23 Aug 2016 00:53:41 -0500 Subject: AW: OpenPGP Smartcard recommendations In-Reply-To: References: Message-ID: This looks exactly like what I'm looking for! Thanks for the recommendation. Definitely going to get one. Many thanks again. Anthony On 8/22/2016 10:38 PM, cornelius.koelbel wrote: > > Hi Anthony, > > You may also take a look at the Nitrokey. Kind regards Cornelius > > > Cornelius K?lbel +49 151 2960 1417 > > NetKnights GmbH Http://NetKnights. It +49 561 3166 797 > > > -------- Urspr?ngliche Nachricht -------- Von: Anthony Papillion > Datum: 22.08.16 23:22 (GMT+01:00) An: > gnupg-users at gnupg.org Betreff: OpenPGP Smartcard recommendations > > Hello Everyone, > > I'm wanting to solidify my key security and I'm just not > comfortable with having my OpenPGP key on my computer all the time. > So I'd like to move to a smartcard solution. > > I've gone to the kernelconcepts.de page and tried to contact them > but it looks like the domain simply isn't accepting mail and the > site might just be a zombie. So I decided to come here and ask as > well. > > Can anyone recommend a solid OpenPGP smartcard solution that meets > the following criteria: > > 1) Supports up to 4096 bit RSA keys 2) Generates keys completely on > the card 3) Can sign, encrypt, decrypt 4) Preferably has some > tamper resistence 5) Can import an existing RSA key > > Also, since I'm pretty new to smartcard solutions, I'm also in the > market for a reader. If you have any suggestions for one of those, > I'd appreciate it too. If it makes a difference, I'm in the USA. > > Thanks, Anthony > > > _______________________________________________ Gnupg-users mailing > list Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From karol at babioch.de Tue Aug 23 10:20:58 2016 From: karol at babioch.de (Karol Babioch) Date: Tue, 23 Aug 2016 10:20:58 +0200 Subject: Deleting SSH key(s) from agent In-Reply-To: <3dea7fe6-1f23-781f-3e78-045bf9ed193f@digitalbrains.com> References: <3dea7fe6-1f23-781f-3e78-045bf9ed193f@digitalbrains.com> Message-ID: <7cc26deb-26fc-14b8-921c-4f2b002d5a87@babioch.de> Hi, Am 21.08.2016 um 12:27 schrieb Peter Lebbing: > Let me answer by example: Thank you very much. I even knew about gpg-connect-agent, but didn't connect the dots. I was too focussed on getting it to work through the ssh-add interface. It does indeed work as outlined. However it seems to be more complicated than before, since I need to keep track of keygrips now. How are you guys dealing with multiple SSH keys while making sure the correct one is being used? Best regards, Karol Babioch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Aug 23 10:36:12 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 23 Aug 2016 10:36:12 +0200 Subject: Deleting SSH key(s) from agent In-Reply-To: <7cc26deb-26fc-14b8-921c-4f2b002d5a87@babioch.de> References: <3dea7fe6-1f23-781f-3e78-045bf9ed193f@digitalbrains.com> <7cc26deb-26fc-14b8-921c-4f2b002d5a87@babioch.de> Message-ID: On 23/08/16 10:20, Karol Babioch wrote: > How are you guys dealing with multiple SSH keys while making sure the > correct one is being used? I don't make sure the correct one is used. The challenge that is signed with your private key is based on data provided by both the server and the client. I have never heard of an attack that allowed a challenge for one SSH server to be used as authentication to a different SSH server. In other words, I've never heard of an attack where a rogue SSH server can impersonate you on a different server when you authenticate to the rogue server. If I'm mistaken, I'd like to know. But I suspect the system was correctly designed to thwart such a thing. So I don't think there is a need to ensure the correct key is used. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From karol at babioch.de Tue Aug 23 10:46:24 2016 From: karol at babioch.de (Karol Babioch) Date: Tue, 23 Aug 2016 10:46:24 +0200 Subject: Deleting SSH key(s) from agent In-Reply-To: References: <3dea7fe6-1f23-781f-3e78-045bf9ed193f@digitalbrains.com> <7cc26deb-26fc-14b8-921c-4f2b002d5a87@babioch.de> Message-ID: Hi, Am 23.08.2016 um 10:36 schrieb Peter Lebbing: > If I'm mistaken, I'd like to know. But I suspect the system was > correctly designed to thwart such a thing. I'm pretty sure you are right, so this is not my concern. > So I don't think there is a need to ensure the correct key is used. However, it is annoying to be prompted for passphrases for each key in the keyring. This is even true for cases in which the public key of my smartcard is the first and only entry in authorized_keys on a SSH server. ssh-add -L lists the public key of my smartcard also first in the first place, so I'm not sure why I always get asked for other keys. On the other hand I do not want to have keys lying around unencrypted on disk. I could possibly get away with making a configuration using the Identity* directives from ssh_config(5), but this seems to be a PITA. Is it somehow possible for gpg-agent to _NOT_ ask for passphrases it does not need, e.g. to enforce that the smartcard is tried first for authentication? Best regards, Karol Babioch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Aug 23 11:17:33 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 23 Aug 2016 11:17:33 +0200 Subject: OpenPGP Smartcard recommendations In-Reply-To: <6a8a369f-cc0f-1443-2dfc-2e4557065053@babioch.de> References: <7aecb8fb-5682-c00f-7bb0-7f2770dc4fd9@cajuntechie.org> <6a8a369f-cc0f-1443-2dfc-2e4557065053@babioch.de> Message-ID: <1ec3c323-4346-43e1-14aa-da2afa439a3f@digitalbrains.com> On 23/08/16 02:54, Karol Babioch wrote: > P.S.: I should also mention that there is some debate about the open > source nature of the YubiKey 4, since its firmware is not open to > review any longer. Should this be a criterion for you, you have to > go with another solution. You'll find details on the story at [3]. I was quite surprised by this blog post, by one small but, in my eyes, significant part of it. A lot of the blog post seems not directly related to being able to review the source and verifying that the loaded firmware binary is indeed the reviewed source, which is what would interest me most in a security device. There's a lot of talk about field-updating firmware securely and related topics, which is only tangential to the source being /available/. But the really strange statement is this: > In this specific context (fault injection and side-channel > analysis), an open source strategy would provide little or no remedy > to a serious and growing industry problem. One could say it actually > works the other way. In fact, the attacker?s job becomes much easier > as the code to attack is fully known and the attacker owns the > hardware freely. I'm with him on the first sentence. The context is broadly that when your hardware is not secure, no amount of open sourcery would protect the data the hardware holds. At least if I understood the context. But then it gets iffy. The attacker's job becomes easier because he knows the inner workings? Alert! Alert! Security through obscurity! Prepare for battle stations! A secure system is secure by having the knowledge of a secret key. It is not secure because most people do not know how it works; because the method is secret. This is Cryptography 101. If you want to know more, I'd say just use your favourite search engine with the phrase "security through obscurity". I fully understand that stuff gets complicated when your hardware vendor forbids you to disclose your source code. That's a nasty problem. I'm less concerned about not meeting criteria for some certification because the source is open. Would you rather have a certification stating some party thinks you're secure, or would you rather actually be secure? I'd know. Stuff those Common Criteria ;). They're not the holy grail. But when you say "obscurity helps security", I'm seriously starting to doubt your reasoning. My 2 cents, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Tue Aug 23 11:29:07 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 23 Aug 2016 11:29:07 +0200 Subject: SSH agent prompts for all passphrases (was: Deleting SSH key(s) from agent) In-Reply-To: References: <3dea7fe6-1f23-781f-3e78-045bf9ed193f@digitalbrains.com> <7cc26deb-26fc-14b8-921c-4f2b002d5a87@babioch.de> Message-ID: <5afb974b-9fe7-1087-5aa0-d61081f43eda@digitalbrains.com> On 23/08/16 10:46, Karol Babioch wrote: > However, it is annoying to be prompted for passphrases for each key in > the keyring. This is even true for cases in which the public key of my > smartcard is the first and only entry in authorized_keys on a SSH server. Hmmmmm. I use both a smartcard and an encrypted on-disk key, and am never prompted for a passphrase for a key that isn't listed in authorized_keys. You can see a lot of the detail with: $ ssh -vvv user at host I can see how the client considers keys, offers them, and only when the server indicates acceptance will it access the private key and prompt for a passphrase. See here how it first asks the server whether it would accept the key the agent identifies by "/home/peter/.ssh/id_rsa", and the server declines (that's not very explicit in the messages). I'm not prompted for the passphrase for that key. The client then offers my smartcard, and the server accepts. Only then am I prompted for the PIN. --------------------8<----------------->8-------------------- [...] debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/peter/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Offering RSA public key: cardno:000500000241 debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp 27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1 debug3: sign_and_send_pubkey: RSA 27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1 [...] --------------------8<----------------->8-------------------- Are both the server and the client in your case OpenSSH? Do you have non-standard options set relating to auth perhaps? HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From karol at babioch.de Tue Aug 23 11:51:33 2016 From: karol at babioch.de (Karol Babioch) Date: Tue, 23 Aug 2016 11:51:33 +0200 Subject: SSH agent prompts for all passphrases In-Reply-To: <5afb974b-9fe7-1087-5aa0-d61081f43eda@digitalbrains.com> References: <3dea7fe6-1f23-781f-3e78-045bf9ed193f@digitalbrains.com> <7cc26deb-26fc-14b8-921c-4f2b002d5a87@babioch.de> <5afb974b-9fe7-1087-5aa0-d61081f43eda@digitalbrains.com> Message-ID: Hi again, Am 23.08.2016 um 11:29 schrieb Peter Lebbing: > Hmmmmm. I use both a smartcard and an encrypted on-disk key, and am > never prompted for a passphrase for a key that isn't listed in > authorized_keys. Ok, it was my mistake. Looking through the verbose output of the SSH client, I realized that I'm using a jump host, which still had my other public keys in authorized_keys, so I was being asked for the appropriate passphrase. Removing them fixed this. However, there is still something that bothers me. The client offers the disk-based keys first (id_rsa, id_ed25519, etc.). This is not a problem in case only the smartcard's key is stored in authorized_keys, but as soon as I put a fallback key there, it is being offered first and I'm asked for the passphrase. Can I somehow control the order in which the client presents its keys to the server? Is this something the agent controls, or the SSH client itself? Thanks again for your help, it is very much appreciated. Best regards, Karol Babioch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From nicole.faerber at kernelconcepts.de Tue Aug 23 10:53:03 2016 From: nicole.faerber at kernelconcepts.de (=?UTF-8?Q?Nicole_F=c3=a6rber?=) Date: Tue, 23 Aug 2016 10:53:03 +0200 Subject: OpenPGP Smartcard recommendations In-Reply-To: <7aecb8fb-5682-c00f-7bb0-7f2770dc4fd9@cajuntechie.org> References: <7aecb8fb-5682-c00f-7bb0-7f2770dc4fd9@cajuntechie.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, as one from kernel concepts I need to apologize for the inconvenience, we had some major reworks in our infrastrcuture these days. Now things start to get settled again, mail should work and the website should also be up again - but there might still be glitches, I am sorry. We still do supply the cards, worldwide. If you have any questions, please do not hesitate to contact me by personal email. Kind regards nicole Am 22.08.2016 um 23:22 schrieb Anthony Papillion: > Hello Everyone, > > I'm wanting to solidify my key security and I'm just not > comfortable with having my OpenPGP key on my computer all the time. > So I'd like to move to a smartcard solution. > > I've gone to the kernelconcepts.de page and tried to contact them > but it looks like the domain simply isn't accepting mail and the > site might just be a zombie. So I decided to come here and ask as > well. > > Can anyone recommend a solid OpenPGP smartcard solution that meets > the following criteria: > > 1) Supports up to 4096 bit RSA keys 2) Generates keys completely on > the card 3) Can sign, encrypt, decrypt 4) Preferably has some > tamper resistence 5) Can import an existing RSA key > > Also, since I'm pretty new to smartcard solutions, I'm also in the > market for a reader. If you have any suggestions for one of those, > I'd appreciate it too. If it makes a difference, I'm in the USA. > > Thanks, Anthony - -- kernel concepts Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ Gesch?ftsf?hrer: Nils Faerber, Ole Reinhardt HR Siegen, HR B 9613 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJXvA7uAAoJEEKL5ZUtJ7x4g3sL/3x88iU46MBf1yyrom3AQyB5 EOT4JTmXo+KgTf/g2COngnOMUU7fh6j6xKqb2UCx6J2CImP3tuUs2fTpqFGYOIb/ 3RJUg+332jA/shGMA3+NGyRPochy0Ls3PHV/iPemZ8eDZtv9fu5RwmNCyXParlNd BJ+Dj+fPUFf5snJED4VVXA0b75fcGYK4zr/3oOUGCaQv49RIduM4sS2Nd+H9ALuf btWlSrbYeyTdsGqbjA+ttTQ17wWG/Y/ZFI1aj3SLeINz2qc5PmtWoRr67RVpP5b9 Rh5PIWGzv+m12tFbUdLJwHF3Ruj1T3aX+XCR7Yyv0YSy/G2jFtT03cBGBQxj8N7q 3KaXJ0xbmO3v58nUsuD1o9j06z9awqC4W2qVcouA4BDuNCMLBCBEFkyP3jqf9D2l igKgGzn/izkD7oy1D3PRs7O2WOZPfPMIDjs++qcsj3YJ2phUX+NBGrUDCVE9geO9 iD6JFHipV1Jg6LXihZPDeS+Fe9wFisjLC8SHnUZrTA== =U4D7 -----END PGP SIGNATURE----- From peter at digitalbrains.com Tue Aug 23 12:03:35 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 23 Aug 2016 12:03:35 +0200 Subject: SSH agent prompts for all passphrases In-Reply-To: References: <3dea7fe6-1f23-781f-3e78-045bf9ed193f@digitalbrains.com> <7cc26deb-26fc-14b8-921c-4f2b002d5a87@babioch.de> <5afb974b-9fe7-1087-5aa0-d61081f43eda@digitalbrains.com> Message-ID: <8c4e1419-f5fd-e0c2-1ce3-6642e0ab95f9@digitalbrains.com> On 23/08/16 11:51, Karol Babioch wrote: > Can I somehow control the order in which the client presents its keys to > the server? Is this something the agent controls, or the SSH client itself? I don't know, but perhaps that's best asked on an SSH mailing list? If it turns out that the agent has influence (for example because the client parses the list of keys from the agent top to bottom), then it would again be something for the GnuPG SSH agent implementation. Perhaps the order can be influenced through the sshcontrol file, I don't know. Maybe something changes when you list the keygrip of the smartcard key in that file. Or maybe the "Identity*" options in ssh_config help. > Thanks again for your help, it is very much appreciated. You're welcome! HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From karol at babioch.de Tue Aug 23 12:51:20 2016 From: karol at babioch.de (Karol Babioch) Date: Tue, 23 Aug 2016 12:51:20 +0200 Subject: OpenPGP Smartcard recommendations In-Reply-To: <1ec3c323-4346-43e1-14aa-da2afa439a3f@digitalbrains.com> References: <7aecb8fb-5682-c00f-7bb0-7f2770dc4fd9@cajuntechie.org> <6a8a369f-cc0f-1443-2dfc-2e4557065053@babioch.de> <1ec3c323-4346-43e1-14aa-da2afa439a3f@digitalbrains.com> Message-ID: <5780669c-792a-8788-3594-dfa32f3df2ff@babioch.de> Hi, since we are commenting here, I want to put out my two cents also, as this is a topic I'm deeply interested in. Am 23.08.2016 um 11:17 schrieb Peter Lebbing: > I was quite surprised by this blog post, by one small but, in my > eyes, significant part of it. A lot of the blog post seems not > directly related to being able to review the source and verifying > that the loaded firmware binary is indeed the reviewed source, which > is what would interest me most in a security device. Yes, this is a problem, and to my knowledge there are no real solutions to it. Even with software alone its hard to verify that the binary you are running was indeed built from the correct source (i.e. reproducible builds), but with firmware and hardware devices it gets pretty much impossible. Open source is fine and dandy, but it doesn't solve this problem. And I'm saying this as a big open source enthusiast. > There's a lot of talk about field-updating firmware securely and > related topics, which is only tangential to the source being > /available/. Yes, you are absolutely right and I think the blog post is mixing things up here. Not making the source available has nothing to do with field-updatable firmware. > But the really strange statement is this: > > [...] > > A secure system is secure by having the knowledge of a secret key. > It is not secure because most people do not know how it works; > because the method is secret. This is Cryptography 101. If you want > to know more, I'd say just use your favourite search engine with the > phrase "security through obscurity". I'm playing a little bit of a devil's advocate here. In general I would agree with your statement. Security by obscurity is a bad idea. No one should come up with a new secret encryption standard and claim that it is secure. It has been shown time and again that these claims are mostly bullshit. These things should, as you said, be completely open, peer reviewd, pounded upon and only rely on a secret key. However for me this mostly applies to the cryptographic concepts itself and maybe software implementing them, not necessarily to physical devices that have to withstand various forms of physical attacks. When it comes to the real world, I'm not sure if this concepts holds completely true, though. If the revelations of Snowden taught us anything, than that it is hard to implement crypto correctly in the real world. Yes, RSA, AES and such are probably computationally secure enough, so that even the NSA cannot break it. However, they don't have to, because in the real world there are easier ways. For the most part, not attacking the crypto system itself is the weakness, but various side channels and other indirect vectors like that. I tend to think that hidden "traps" in a hardware design do actually improve security, and consider this to be kind of a defense-in-depth approach. We shouldn't rely too much on "secret sausage", but it definitely makes things harder for attackers when they do not know everything about a hardware design and have to reverse engineer it for themselves. This way key material can be wiped and hardware destroyed when tampering is detected. This costs them time and money, and hence reduces the potential revenue. I think a good analogy is the design of alarm systems and safes. Usually you won't find too much details about such things and they kind of rely on the fact that an attacker does not know too much about it. Obviously there are limits to this and I would like to be convinced otherwise, but in the end it always comes down to trust, e.g. in this case: Do you trust Yubico to have done everything that is reasonably possible to protect your keys. > Would you rather have a certification stating some > party thinks you're secure, or would you rather actually be secure? Once again I'm not sure if the real world is black-and-white like this. Just making something "open source" is not making it secure. Take the recent PRNG vulnerability in GnuPG as example (CVE-2016-6313). It was there for nearly two decades, and nobody spotted it. Obviously the same is true for all certifications and a hardware device is not secure, just because it is certified. Unfortunately these certifications (e.g. things like Common Criteria) are basically the only thing we have to make sure a product is designed with security in mind. It makes sure that there are clearly defined goals that can be met, tested and implemented. It makes sure that the people involved understand a thing or two about security and products tend to be better (i.e. more secure) with higher levels of certifications. Once again, I'm playing the devil's advocate here. I'm in no way, shape or form connected with Yubico and do not want to defend them, but I think arguments can be made for both sides here. Best regards, Karol Babioch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From alexandre at pujol.io Tue Aug 23 11:57:15 2016 From: alexandre at pujol.io (Alexandre Pujol) Date: Tue, 23 Aug 2016 10:57:15 +0100 Subject: OpenPGP Smartcard recommendations In-Reply-To: <6a8a369f-cc0f-1443-2dfc-2e4557065053@babioch.de> References: <7aecb8fb-5682-c00f-7bb0-7f2770dc4fd9@cajuntechie.org> <6a8a369f-cc0f-1443-2dfc-2e4557065053@babioch.de> Message-ID: <14fa3725-9966-4dd6-a071-5036a9cb8555@pujol.io> Hi all, There is also the Nitrokey [1] that like the Yubikey is a smart-card in a USB stick. However Nitrokey has both software and hardware open source [2]. Regards, Alex [1] https://www.nitrokey.com/ [2] https://github.com/nitrokey On 23/08/16 01:54, Karol Babioch wrote: > Personally I absolutely love the YubiKey (4 Nano) [2]. It meets all of > your criteria and can do a lot more (U2F, PIV, token, HOTP, TOTP, etc.). > It is also a lot smaller than a real smartcard and can be left in the > USB port all of the time. The Gemalto USB token (and/or real smartcards) > are rather unhandy - at least for me. > > P.S.: I should also mention that there is some debate about the open > source nature of the YubiKey 4, since its firmware is not open to review > any longer. Should this be a criterion for you, you have to go with > another solution. You'll find details on the story at [3]. > > [2]: https://www.yubico.com/products/yubikey-hardware/yubikey4/ > [3]: https://www.yubico.com/2016/05/secure-hardware-vs-open-source/ > From support at bytesinteractive.com Tue Aug 23 12:17:13 2016 From: support at bytesinteractive.com (David J) Date: Tue, 23 Aug 2016 06:17:13 -0400 Subject: Need Help decrypt HTML E-mail using OutlookPrivacyPlugin Message-ID: <1824cde24916523aaf8521aace2256e6.squirrel@forms.medclick24-7.com> Hi, I've installed dejavusecurity/OutlookPrivacyPlugin to decrypt e-mails from outlook. It works well with encrypted text email but under features its says it can decrypt HTML e-mail. I'm collecting data from an online form and I want to send the email as a form with the data filled in. I encrypt the HTML form using gpg then send as an e-mail. When the email arrives in Outlook it decrypts but displays at the top: ** Message decrypted. Message was unsigned. then the HTML code. Is there any specific way I need to prepare the HTML email then upon decryption it appears as an HTML email ready for printing. Any clue as to how I get this to work is welcome. Thank-you in advance! David j. From karol at babioch.de Tue Aug 23 14:03:07 2016 From: karol at babioch.de (Karol Babioch) Date: Tue, 23 Aug 2016 14:03:07 +0200 Subject: SSH agent prompts for all passphrases In-Reply-To: <8c4e1419-f5fd-e0c2-1ce3-6642e0ab95f9@digitalbrains.com> References: <3dea7fe6-1f23-781f-3e78-045bf9ed193f@digitalbrains.com> <7cc26deb-26fc-14b8-921c-4f2b002d5a87@babioch.de> <5afb974b-9fe7-1087-5aa0-d61081f43eda@digitalbrains.com> <8c4e1419-f5fd-e0c2-1ce3-6642e0ab95f9@digitalbrains.com> Message-ID: <3bb6eb8d-1e1a-d0a3-59cf-8a17ed1136fd@babioch.de> Hi, Am 23.08.2016 um 12:03 schrieb Peter Lebbing: > Or maybe the "Identity*" options in ssh_config help. After having played around with this for a while, I could solve this in the following way. I've created a pub file containing the public key of my smartcard and placed an appropriate IdentityFile directive within the ssh configuration file, so my smartcards gets now used by default. Seems to work fine, so I'm quite happy with my setup now. Thanks again. Best regards, Karol Babioch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Aug 23 14:36:23 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 23 Aug 2016 14:36:23 +0200 Subject: Security through obscurity (was: OpenPGP Smartcard recommendations) In-Reply-To: <5780669c-792a-8788-3594-dfa32f3df2ff@babioch.de> References: <7aecb8fb-5682-c00f-7bb0-7f2770dc4fd9@cajuntechie.org> <6a8a369f-cc0f-1443-2dfc-2e4557065053@babioch.de> <1ec3c323-4346-43e1-14aa-da2afa439a3f@digitalbrains.com> <5780669c-792a-8788-3594-dfa32f3df2ff@babioch.de> Message-ID: <547e7702-113d-6de5-118c-15432ec25a85@digitalbrains.com> On 23/08/16 12:51, Karol Babioch wrote: > However for me this mostly applies to the cryptographic concepts itself > and maybe software implementing them, not necessarily to physical > devices that have to withstand various forms of physical attacks. When > it comes to the real world, I'm not sure if this concepts holds > completely true, though. My main argument is this: white-hat security researchers would have a difficult time assessing your design when it is closed. But that /you/ can't just go and download the design from Yubico does not mean that nobody can access (steal) or reverse-engineer it. And the people who do this are often the people you least want to have the design. They're not the white-hats[1]. People might think that "not available == not available". I don't think that's accurate. Lastly, depending on where the company is situated, governments can play a nefarious role, looking at the design, mandating backdoors. An open design is better equiped against government mandates than a closed design. > If the revelations of Snowden taught us anything, than that it is hard > to implement crypto correctly in the real world. Yes, RSA, AES and such > are probably computationally secure enough, so that even the NSA cannot > break it. However, they don't have to, because in the real world there > are easier ways. > > For the most part, not attacking the crypto system itself is the > weakness, but various side channels and other indirect vectors like > that. So you don't just want to know "this device does RSA", and "RSA is open and secure". You want to know "it is correctly implemented". When you can get good security experts to just download your code and design, they can verify that. When you close the design, your only option is to approach a handful of researchers and have them look at it under contract. Bugs might still go unnoticed. Open access is not a panacea. But "security through obscurity" IMHO pretty much means there are much more bad guys looking into it than there are good guys. > This costs them time and > money, and hence reduces the potential revenue. But they can sell their knowledge and expertise on a black market... > [...], but in the end it always comes down to trust, e.g. in this > case: Do you trust Yubico to have done everything that is reasonably > possible to protect your keys. I think they did it to the best of their ability. But I'd like it independently verified that they actually didn't introduce a bad bug. All software has bugs. > Once again I'm not sure if the real world is black-and-white like this. > Just making something "open source" is not making it secure. Take the > recent PRNG vulnerability in GnuPG as example (CVE-2016-6313). It was > there for nearly two decades, and nobody spotted it. At least, none of the good guys did. I'm not trying to scare anyone. I'm just saying that if the source was closed, there would be a lot less good guys to ever do the spotting, and it would be harder to spot for them. It makes it harder for the bad guys to spot the bugs by not having the source, but it also makes it harder for the good guys. > Obviously the same is true for all certifications and a hardware device > is not secure, just because it is certified. Unfortunately these > certifications (e.g. things like Common Criteria) are basically the only > thing we have to make sure a product is designed with security in mind. This is what I was actually referring to by "a certification stating some party thinks you're secure"; I just put it a bit starkly for effect. I'm not convinced CC EAL-blah actually means much. I get this itchy "designed by committee" feeling, and a feeling of imposed bureaucracy. So if Common Criteria are actually promoting security through obscurity, which is what I think the blog post is alluding to... meh. Stuff your criteria. Just look at in what ways card payments are broken. Pick any recent Chaos Communication Congress, you'll find a talk about it, I think. These systems are Common Criteria certified, yet you can buy a second-hand payment terminal on eBay, enter a store indentifier that is printed on every receipt of a store, and start reimbursing payments to cards from that store, payments that were never done in the first place. It's the reverse of paying at the store: you put in your card and the store pays you, on your bank account. Methinks Common Criteria missed a criterium. > Once again, I'm playing the devil's advocate here. I'm in no way, shape > or form connected with Yubico and do not want to defend them, but I > think arguments can be made for both sides here. Oh, definitely. But I'm convinced that in security, both algorithms and implementations, an open design is always better than a closed design.[2] I don't see the algorithm and the implementation as completely disjoint in this respect. All of the stuff that protects the secret knowledge, whether it is algorithmic through multiplying the two secret primes of RSA or the implementation which must prevent leaking knowledge in random padding; all of this stuff is vital in keeping secrets secret. Any part failing is catastrophical. I've read about way too many goofs to still trust that something is "secure" when the manufacturer claims it is. I just grudgingly have to accept that there is quite a limit to what is openly available at the moment, or at what price in comfort and features. You always have to compromise, and everybody needs to decide for themselves where that compromise lies. It would be very preferable if that decision was based on an accurate understanding of the matter, though... :( (I'm quite worried about all these so-called "free" services on the internet. I mean the "gratis" ones). Peter. [1] White-hats do reverse-engineer. For instance with voting systems, which often turn out to have pretty lousy protection, even though the manufacturer claimed all kinds of features. [2] But I'm certainly not stating "any open design is better than a closed design". That would be silly. There are certainly worse open designs available than, say, a multiple-thousand-dollar Hardware Security Module ;). -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From johanw at vulcan.xs4all.nl Tue Aug 23 21:37:33 2016 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 23 Aug 2016 21:37:33 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe Message-ID: <57BCA5FD.50500@vulcan.xs4all.nl> In http://www.heise.de/newsticker/meldung/Justiz-soll-verschluesselte-Terror-Kommunikation-auswerten-koennen-3302594.html (German), the German and French government are attacking the right to encrypt communication of their serfs. Also because of their violent anti-encryption opinion I was glad to see the Brittish influence in the EU shrink but now we have this. I don't know what they will come up with, but as GnuPG community we should be prepared because development is in Germany (and we thought to be safe from the US there...). Also, Silence. the encrypted sms fork from Signal is developed partly in France. Both GnuPG and Silence have the advantage that they are open source and don't require central servers. Signal has the advantage it's open source and does not have a commercial presence here that can't be attacked. For WhatsApp things look not as well. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From SLinnebur at redrobin.com Tue Aug 23 17:38:54 2016 From: SLinnebur at redrobin.com (Scott Linnebur) Date: Tue, 23 Aug 2016 15:38:54 +0000 Subject: File Encrypted with Primary key In-Reply-To: <8116737E-EB5A-468A-80DC-BF1C8EBDD1B7@jabberwocky.com> References: <8116737E-EB5A-468A-80DC-BF1C8EBDD1B7@jabberwocky.com> Message-ID: Thanks everyone for your help on this. While I believe this is still an issue it wasn't the issue I was having. Apparently MoveIT was using the lowest level encryption algorithm allowed by my public key. I regenerated the key and removed the lower levels as options and all is fine. Thanks again. Scott Linnebur IT Solutions Architect (303) 846-6176 Desk (720) 334-5206 Cell slinnebur at redrobin.com -----Original Message----- From: David Shaw [mailto:dshaw at jabberwocky.com] Sent: Monday, August 22, 2016 4:13 PM To: Scott Linnebur Cc: gnupg-users at gnupg.org Subject: Re: File Encrypted with Primary key On Aug 19, 2016, at 11:56 AM, Scott Linnebur wrote: > > I have an issue that I just cannot figure out. What I?m trying to do is move a file between two organizations using two different transports while encrypting the file. On one side they use ipswitch movit to encrypt the file and post it to a sftp site. Then from my end I use camel to pick up the file, decrypt it and place it where it needs to go internally. What I have done is generate a key pair with GPG and have given the other company my public key to encrypt with as well as imported the key rings into Camel. > > Testing? > They post the encrypted file and when my camel process pull is down I get the error ?exception creating cipher?. > If I manually pull down the file I can decrypt it fine with GPG. > If I encrypt a test file with my own public key and feed it to Camel it decrypts fine. > > This is where I think the problem is but I can?t figure out a way to prove it. When I generated the key pair with GPG, it created a primary and secondary keys. Primary has usage set to SC and secondary set to E. When I look at the file they sent me, it?s encrypted with the primary key. That file fails in the camel process but is successful in a manual GPG decyption process. When I encrypt a file with GPG it uses the secondary key and I can decrypt it with Camel or manually with GPG. I have a suspicion that is the cause but I can?t test it. I can?t find anyway to force the primary key to encrypt and I can?t figure out how to generate a key pair without secondary keys in it. Any ideas how to troubleshoot this? The secondary party is not helpful and they are using their standard process with moveit to encrypt it and aren?t likely to change that, especially if I can?t prove that?s what?s wrong. I have seen this before - basically the Moveit code is using a buggy/older OpenPGP engine that does the wrong thing and ignores key flags. Your key has an RSA primary key, and their engine sees that and concludes that since it's RSA, it can encrypt to it. GPG properly respects key flags so uses the subkey. There is only one fix for this, but two workarounds: 1 (the true fix): Get Moveit to fix their OpenPGP engine. That's likely not an easy task since Moveit most likely purchased it from an upstream vendor (I'm going to guess Symantec - I have a vague recollection the previous time I saw this was with the Symantec code), so the actual fix would need to be from the upstream vendor, then Moveit would have to integrate it, and then whoever you're communicating with would have to update Moveit. Given that this problem still exists in 2016, I'm going to guess that a fix here is not going to happen any time soon! 2 (workaround A): You can generate a key that explicitly permits encrypting to the primary key. Then both GPG and Moveit will encrypt to the primary and everyone can interoperate. This is not ideal as it is best practice to split the signing and encryption capabilities, but should solve your immediate problem. 3 (workaround B): Don't use an RSA primary key. Instead of generating a RSA primary key with an RSA subkey, generate a DSA primary key with an Elgamal subkey (or for that matter, an RSA subkey - what matters here is the primary is DSA). This pretty much forces the Moveit code to encrypt to the subkey since there is no way to encrypt to a DSA primary key (it's a signature-only algorithm). My advice would be to try workaround B first. If they're using the same engine that I saw before, it was smart enough to handle that case and would properly use the subkey. David From rjh at sixdemonbag.org Wed Aug 24 04:26:17 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Aug 2016 22:26:17 -0400 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <57BCA5FD.50500@vulcan.xs4all.nl> References: <57BCA5FD.50500@vulcan.xs4all.nl> Message-ID: <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> > ... the German and French government are attacking the right to > encrypt communication of their serfs. I've got to ask a question. What would you have us do instead? For the last eight years I've worked in digital forensics. That's put me in a position to see the works of psychopaths up close and personal. They tend to love photographing or recording their exploits, and their "art" winds up crossing my desk. Evil exists and the worst thing I've ever heard is a wailed, "Daddy, no, please stop!" I believe that privacy is on balance a good thing and we need good tools to preserve it. But I've also seen enough victims and crimes to believe that we also need ways to detect, apprehend, and prosecute offenders, too. So long as you're a privacy absolutist -- which it appears you are -- then you're going to be on the losing side of your nation's privacy debate. As soon as people hear that your preferred answer to, "So how should investigators and forensics geeks deal with this Tor, GnuPG, and cgiproxy-using fiend?" is, "well, he shouldn't, because privacy!", they're going to write you off as not having anything useful to bring to the discussion. Some serious questions -- 1. Are you a privacy absolutist? 2. If yes, why should we listen to you? 3. If no, then how should we permit privacy tools to be circumvented? From fa-ml at ariis.it Wed Aug 24 07:45:29 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 24 Aug 2016 07:45:29 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> Message-ID: <20160824054529.GA6514@casa.casa> On Tue, Aug 23, 2016 at 10:26:17PM -0400, Robert J. Hansen wrote: > Some serious questions -- > > 1. Are you a privacy absolutist? > 2. If yes, why should we listen to you? Privacy and its boundaries are a well debated (and well worth to be debated) topic; keep in mind that any discussion that starts with framing ("privacy absolutist" is political framing 101 -- would you feel fairly treated if I described your views on the matter as, say, "government absolutist"?) is bound to get pretty flamish pretty soon. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From wk at gnupg.org Wed Aug 24 08:41:33 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Aug 2016 08:41:33 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <57BCA5FD.50500@vulcan.xs4all.nl> (Johan Wevers's message of "Tue, 23 Aug 2016 21:37:33 +0200") References: <57BCA5FD.50500@vulcan.xs4all.nl> Message-ID: <87mvk2y8gy.fsf@wheatstone.g10code.de> On Tue, 23 Aug 2016 21:37, johanw at vulcan.xs4all.nl said: > (German), the German and French government are attacking the right to > encrypt communication of their serfs. Also because of their violent Despite their common declaration to do something against the "evil" of encryption, the French and the German texts of that declaration differ! The German version does not ask for laws to introduced backdoors or key escrow. See the (German) article at Netzpolitik [1]. The German minister of the interior pushes for a federal agency as a central organization to develop and deploy the "federal trojan". What they want are _targeted_ attacks on confidential communication. They know very well that backdoors, as requested by the French, are a bad idea. Whether the current German rules on when and how constitutional rights on privacy can lawfully be suspended are still in compliance with the constitution is a different question. Shalom-Salam, Werner [1] -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed Aug 24 10:42:34 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Aug 2016 04:42:34 -0400 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <20160824054529.GA6514@casa.casa> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <20160824054529.GA6514@casa.casa> Message-ID: > ("privacy absolutist" is political framing 101 -- would you > feel fairly treated if I described your views on the matter as, say, > "government absolutist"?) I'd shrug and point to my many public statements where I've supported strong, non-backdoored privacy tools. If someone wants to accuse me of being a government absolutist, that's on them. > is bound to get pretty flamish pretty soon. Once it becomes such it'll be time to stop. Until then, the discussion can be quite useful. From johanw at vulcan.xs4all.nl Wed Aug 24 12:51:07 2016 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 24 Aug 2016 12:51:07 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> Message-ID: <57BD7C1B.6060700@vulcan.xs4all.nl> On 24-08-2016 4:26, Robert J. Hansen wrote: > 1. Are you a privacy absolutist? Yes. > 2. If yes, why should we listen to you? The child porn excuse is used too often. The terrorism card is also played often (not that it would help much against that as all known exmples show). And then comes the drugs excuse (where it might work but that's where a lot of people start to think "so what?"). And then come the tax evaders ("you pay more because he hides his administration"). Eventually you land in the situation you have in the USA, where people are being investigated because they have unwanted political opinions or oppose those in power like Clinton, or the situation in Turkey where people get jailed for supporting a competitor of the current sultan. Point is, the government can't be trusted. And even if you trusts today's one, tomorrows one might be another thing. > 3. If no, then how should we permit privacy tools to be > circumvented? You can try - someone might have used a weak password, wrote it down somewhere or made another mistake. Or can be pressured into telling it (the famous $5 wrench comes to mind here). But that's all you got. And the child pornographers will still use decent encryption because in any sane country the penalty for child abuse is higher than the penalty would be for refusing to decrypt. Unless you want to change that, the child abusers (or even those who only download other's pictures)will still use encryption, but everyone else is at risk. Not to mention terrorists who do use encryption: if you're going to die anyway, why would they care? -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From johanw at vulcan.xs4all.nl Wed Aug 24 12:55:18 2016 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 24 Aug 2016 12:55:18 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <87mvk2y8gy.fsf@wheatstone.g10code.de> References: <57BCA5FD.50500@vulcan.xs4all.nl> <87mvk2y8gy.fsf@wheatstone.g10code.de> Message-ID: <57BD7D16.1030400@vulcan.xs4all.nl> On 24-08-2016 8:41, Werner Koch wrote: > Whether the current German rules on when and how constitutional rights > on privacy can lawfully be suspended are still in compliance with the > constitution is a different question. They can try the French method: declare the state of emergency after some terrorist attack. German prime minister Merkel faces already stern opposition because of here views on immigration so it might suit her well. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From fa-ml at ariis.it Wed Aug 24 14:11:38 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 24 Aug 2016 14:11:38 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <20160824054529.GA6514@casa.casa> Message-ID: <20160824121138.GA13766@casa.casa> On Wed, Aug 24, 2016 at 04:42:34AM -0400, Robert J. Hansen wrote: > I'd shrug and point to my many public statements where I've supported > strong, non-backdoored privacy tools. If someone wants to accuse me of > being a government absolutist, that's on them. Then let me ask you how "I have supported strong, non-backdoored privacy tools" doesn't clash with: > 3. If no, then how should we permit privacy tools to be > circumvented? @Johan Wevers: you might or might not be aware, but what you describe is the "Four Horseman of the Infocalypse" [1]. [1] https://en.wikipedia.org/wiki/Four_Horsemen_of_the_Infocalypse From lynda.harlos at sympatico.ca Wed Aug 24 13:37:35 2016 From: lynda.harlos at sympatico.ca (lynda.harlos at sympatico.ca) Date: Wed, 24 Aug 2016 07:37:35 -0400 (Eastern Daylight Time) Subject: Please unsubscribe me form your mailing list. Thank you. Message-ID: <57BD86FE.00001F.30560@DESKTOP-NJQMPIA> ? ? ? Lynda Harlos Home based travel agent Orion Travelinx Home office: 905-433-4267 Text: 905-723-9210 www.facebook.com/TravelAgent.LyndaHarlos Referrals are the best compliment! Any price/s quoted not guaranteed until payment is made To unsubscribe please reply with unsubscribe in subject line -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndk.clanbo at gmail.com Wed Aug 24 14:58:21 2016 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 24 Aug 2016 14:58:21 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <20160824121138.GA13766@casa.casa> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <20160824054529.GA6514@casa.casa> <20160824121138.GA13766@casa.casa> Message-ID: Il 24/08/2016 14:11, Francesco Ariis ha scritto: > @Johan Wevers: you might or might not be aware, but what you describe > is the "Four Horseman of the Infocalypse" [1]. Instead of stupid backdoors, couldn't legislators simply say that if encryption is used to try to hide a crime (that still have to be proven by *other* means!) then it's like having used a gun in a robbery? That would simpli make something wrong even worst, but allow for rightful use of crypto. Sure, it's way easier to outlaw any non-approved crypto, but then outlaws will use strong crypto nevertheless... BYtE, Diego From rjh at sixdemonbag.org Wed Aug 24 15:11:23 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Aug 2016 09:11:23 -0400 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <20160824121138.GA13766@casa.casa> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <20160824054529.GA6514@casa.casa> <20160824121138.GA13766@casa.casa> Message-ID: > Then let me ask you how "I have supported strong, non-backdoored > privacy tools" doesn't clash with: > >> 3. If no, then how should we permit privacy tools to be >> circumvented? Simple: I wasn't presenting my own views, I was asking Johan for his. Where's the contradiction? From rjh at sixdemonbag.org Wed Aug 24 15:17:19 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Aug 2016 09:17:19 -0400 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <57BD7C1B.6060700@vulcan.xs4all.nl> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <57BD7C1B.6060700@vulcan.xs4all.nl> Message-ID: <2f0456fe-dce5-9db1-524e-e55eeebb4d55@sixdemonbag.org> >> 1. Are you a privacy absolutist? > > Yes. Thank you for being clear on that. >> 2. If yes, why should we listen to you? > > The child porn excuse is used too often... But this doesn't answer my question. Why should we listen to a privacy absolutist? > You can try - someone might have used a weak password, wrote it down > somewhere or made another mistake. Or can be pressured into telling it > (the famous $5 wrench comes to mind here). Wait, wait, wait. You're opposed to *any* kind of privacy circumvention... but you're okay with torture? You're seriously advocating "swing a wrench at this guy's knees and make him talk" as an alternative to any kind of circumvention of a privacy technology? Johan, your position is morally incoherent. From fa-ml at ariis.it Wed Aug 24 16:04:03 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 24 Aug 2016 16:04:03 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <2f0456fe-dce5-9db1-524e-e55eeebb4d55@sixdemonbag.org> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <57BD7C1B.6060700@vulcan.xs4all.nl> <2f0456fe-dce5-9db1-524e-e55eeebb4d55@sixdemonbag.org> Message-ID: <20160824140403.GA17526@casa.casa> On Wed, Aug 24, 2016 at 09:17:19AM -0400, Robert J. Hansen wrote: > > You can try - someone might have used a weak password, wrote it down > > somewhere or made another mistake. Or can be pressured into telling it > > (the famous $5 wrench comes to mind here). > > Wait, wait, wait. > > You're opposed to *any* kind of privacy circumvention... but you're okay > with torture? You're seriously advocating "swing a wrench at this guy's > knees and make him talk" as an alternative to any kind of circumvention > of a privacy technology? > > Johan, your position is morally incoherent. He is of course not advocating torture, he's merely listing possible exploits, referencing to xkcd #538. It's very difficult for me not to consider you a troll if you keep using these cheap rhetorical tricks. From johanw at vulcan.xs4all.nl Wed Aug 24 16:18:15 2016 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 24 Aug 2016 16:18:15 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <2f0456fe-dce5-9db1-524e-e55eeebb4d55@sixdemonbag.org> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <57BD7C1B.6060700@vulcan.xs4all.nl> <2f0456fe-dce5-9db1-524e-e55eeebb4d55@sixdemonbag.org> Message-ID: <57BDACA7.3000203@vulcan.xs4all.nl> On 24-08-2016 15:17, Robert J. Hansen wrote: >>> 2. If yes, why should we listen to you? >> >> The child porn excuse is used too often... > > But this doesn't answer my question. > > Why should we listen to a privacy absolutist? Why would we listen to anyone for that matter? >> You can try - someone might have used a weak password, wrote it down >> somewhere or made another mistake. Or can be pressured into telling it >> (the famous $5 wrench comes to mind here). > > Wait, wait, wait. > > You're opposed to *any* kind of privacy circumvention... but you're okay > with torture? No I'm not, it was only an example that current western governments are considering (however, they are applying the more moderate "lock him up until he talks"). In hindsight it was a bit ill-formatted to put it between the methods I did agree with. I'm OK with technical attacks, I am firmly against obligations to talk or pressuring people to talk with torture, prison terms or fines. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Wed Aug 24 16:23:43 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Aug 2016 10:23:43 -0400 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <20160824140403.GA17526@casa.casa> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <57BD7C1B.6060700@vulcan.xs4all.nl> <2f0456fe-dce5-9db1-524e-e55eeebb4d55@sixdemonbag.org> <20160824140403.GA17526@casa.casa> Message-ID: > He is of course not advocating torture, he's merely listing possible > exploits, referencing to xkcd #538. My question was, "How should we permit privacy tools to be circumvented?" His answer was, "You can try - someone might have used a weak password, wrote it down somewhere or made another mistake. Or can be pressured into telling it (the famous $5 wrench comes to mind here)." If I ask "how should we permit privacy tools to be circumvented?" and someone's answer is "Pressure them. A wrench comes to mind," well... I've received an answer to how the person believes governments should be permitted to obtain secrets. It's not a very good one. > It's very difficult for me not to consider you a troll if you keep > using these cheap rhetorical tricks. Consider me what you will. Couldn't care less, myself. From ben at adversary.org Wed Aug 24 16:23:59 2016 From: ben at adversary.org (Ben McGinnes) Date: Thu, 25 Aug 2016 00:23:59 +1000 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <87mvk2y8gy.fsf@wheatstone.g10code.de> References: <57BCA5FD.50500@vulcan.xs4all.nl> <87mvk2y8gy.fsf@wheatstone.g10code.de> Message-ID: <20160824142359.GC1607@adversary.org> On Wed, Aug 24, 2016 at 08:41:33AM +0200, Werner Koch wrote: > On Tue, 23 Aug 2016 21:37, johanw at vulcan.xs4all.nl said: > > > (German), the German and French government are attacking the right to > > encrypt communication of their serfs. Also because of their violent > > Despite their common declaration to do something against the "evil" of > encryption, the French and the German texts of that declaration differ! > The German version does not ask for laws to introduced backdoors or key > escrow. See the (German) article at Netzpolitik [1]. Ah-ha, I had wondered whether or not anything was being lost in translation here, with my main questions given the French focus being along the lines of, "when is the next election in France?" and, "how much does the current government have to claw their way back since the dreadful attacks recently?" There's an old maxim: all politics is local. With France and Germany together that's been effectively local since Dagobert got skewered in a darkened wood (i.e. approx. 12 or 13 centuries). > The German minister of the interior pushes for a federal agency as a > central organization to develop and deploy the "federal trojan". What > they want are _targeted_ attacks on confidential communication. They > know very well that backdoors, as requested by the French, are a bad > idea. Good, so that just leaves the French politicians to be convinced and that's easy. At least it is if they like having a banking and financial sector of their economy. They can have that *or* they can have backdoors in encryption, but not both. Here's another old maxim: money talks. Regards, Ben P.S. We may be in the Second Crypto Wars, but the genie is out of the bottle, so that sense of "oh noes, the governments is coming for my cryptoes" just isn't there so much. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed Aug 24 16:27:58 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Aug 2016 10:27:58 -0400 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <57BDACA7.3000203@vulcan.xs4all.nl> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <57BD7C1B.6060700@vulcan.xs4all.nl> <2f0456fe-dce5-9db1-524e-e55eeebb4d55@sixdemonbag.org> <57BDACA7.3000203@vulcan.xs4all.nl> Message-ID: <7ec5d320-ea37-25a8-c852-993df7a6d890@sixdemonbag.org> > Why would we listen to anyone for that matter? Ideally, because they present options that may work better than what we currently have. Privacy absolutism -- the position that there is *no* justification for infringing on individual privacy, even in the case of serious crimes -- doesn't offer anything better than what we currently have. In fact, many people would think it was a lot worse. > until he talks"). In hindsight it was a bit ill-formatted to put it > between the methods I did agree with. I'm OK with technical attacks, I > am firmly against obligations to talk or pressuring people to talk with > torture, prison terms or fines. Okay, I can understand speaking glibly: thank you for clarifying you're opposed to that. But if you're okay with technical attacks, you're not a privacy absolutist, either. If your solution is targeted malware, remote exploits, Trojans, and the like, then you're permitting the government to do an awful lot to subvert privacy. From rjh at sixdemonbag.org Wed Aug 24 16:37:35 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Aug 2016 10:37:35 -0400 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <20160824142359.GC1607@adversary.org> References: <57BCA5FD.50500@vulcan.xs4all.nl> <87mvk2y8gy.fsf@wheatstone.g10code.de> <20160824142359.GC1607@adversary.org> Message-ID: > P.S. We may be in the Second Crypto Wars, but the genie is out of the > bottle, so that sense of "oh noes, the governments is coming for > my cryptoes" just isn't there so much. Yeah, which is why I find both sides of the privacy absolutist debate to be ... pretty much comically missing the point. Tor, cgiproxy, GnuPG, Signal, and other such tools are out there and aren't going to go away. All proposals to require backdoors are silly, because so long as just one nation has no such requirement those tools will continue to exist and development will continue pretty much without interruption. So the "backdoor everything!" crowd is completely barmy. But so too are the privacy absolutists who believe that law-enforcement is doing something morally wrong when they try to break Tor's anonymity in the pursuit of awful people. I find the current state of detente to be pretty good, actually. We're allowed to design the best systems we can, and governments are allowed to discover where we're not as clever as we think we are. If there's a flaw in Tor and the FBI uses it to pierce anonymity and go after a bad guy, I can get behind that. Way to go, FBI, you did it right, now please hold on while we figure out how you did this and write a patch to keep you from doing it again. I guess you could say my preferred solution to the crypto wars is to encourage an ongoing escalating crypto arms race. It's crazy, but it seems to work. From 4got2ask at gmail.com Wed Aug 24 15:42:38 2016 From: 4got2ask at gmail.com (SUNNY) Date: Wed, 24 Aug 2016 09:42:38 -0400 Subject: Please unsubscribe me form your mailing list. Thank you. In-Reply-To: <57BD86FE.00001F.30560@DESKTOP-NJQMPIA> References: <57BD86FE.00001F.30560@DESKTOP-NJQMPIA> Message-ID: Can we refrain from people marketing on this forum , I guess this is not a marketing forum , and these need to be blocked Sunny > On Aug 24, 2016, at 07:37, "lynda.harlos at sympatico.ca" wrote: > > > > > ? ? ? > Lynda Harlos > Home based travel agent > Orion Travelinx > Home office: 905-433-4267 > Text: 905-723-9210 > www.facebook.com/TravelAgent.LyndaHarlos > > Referrals are the best compliment! > Any price/s quoted not guaranteed until payment is made > To unsubscribe please reply with unsubscribe in subject line > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From martini5468 at gmail.com Wed Aug 24 17:24:49 2016 From: martini5468 at gmail.com (martin) Date: Wed, 24 Aug 2016 16:24:49 +0100 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: References: <57BCA5FD.50500@vulcan.xs4all.nl> <87mvk2y8gy.fsf@wheatstone.g10code.de> <20160824142359.GC1607@adversary.org> Message-ID: <2e204c29-aed8-bd54-54a0-2b7da1ab78b2@gmail.com> On 24/08/16 15:37, Robert J. Hansen wrote: > I find the current state of detente to be pretty good, actually. We're > allowed to design the best systems we can, and governments are allowed > to discover where we're not as clever as we think we are. If there's a > flaw in Tor and the FBI uses it to pierce anonymity and go after a bad > guy, I can get behind that. Way to go, FBI, you did it right, now > please hold on while we figure out how you did this and write a patch to > keep you from doing it again. > > I guess you could say my preferred solution to the crypto wars is to > encourage an ongoing escalating crypto arms race. It's crazy, but it > seems to work. For my ?0.02 I think the above is mostly valid bar 2 small details: 1. Seldom we do find the FBI breaking security of anonymity tools. Only if a high profile case shows up or someone leaks it. I think it is even more rare for the FBI to outright disclose the vulnerability they used so it can be patched. I don't even know if the other 3 letter agencies do it. 2. Crypto arms race also implies stock piling vulnerabilities - something Bruce Schneier is very vocal about [1][2]. I think the answer here is to find a balance of some sort - i.e. keep vulnerabilities in rare cases for short periods of time and then disclose and patch them. However for that to work we need to trust the govt. to do the right thing. Which I think is pretty much the core issue that started this discussion. Regards, Martin [1] Hacking Team, Computer Vulnerabilities, and the NSA - https://www.schneier.com/blog/archives/2015/09/hacking_team_co.html [2] Disclosing vs. Hoarding Vulnerabilities - https://www.schneier.com/blog/archives/2014/05/disclosing_vs_h.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From lynda.harlos at sympatico.ca Wed Aug 24 18:44:06 2016 From: lynda.harlos at sympatico.ca (lynda.harlos at sympatico.ca) Date: Wed, 24 Aug 2016 12:44:06 -0400 (Eastern Daylight Time) Subject: Unsubscribe me please Message-ID: <57BDCED5.00016A.30560@DESKTOP-NJQMPIA> I have contacted you several times to unsubscribe me please. ? ? ? Lynda Harlos Home based travel agent Orion Travelinx Home office: 905-433-4267 Text: 905-723-9210 www.facebook.com/TravelAgent.LyndaHarlos Referrals are the best compliment! Any price/s quoted not guaranteed until payment is made To unsubscribe please reply with unsubscribe in subject line -------Original Message------- From: martin Date: 8/24/2016 12:32:12 PM To: gnupg-users at gnupg.org Subject: Re: Attacks on encrypted communicxatiopn rising in Europe On 24/08/16 15:37, Robert J. Hansen wrote: > I find the current state of detente to be pretty good, actually. We're > allowed to design the best systems we can, and governments are allowed > to discover where we're not as clever as we think we are. If there's a > flaw in Tor and the FBI uses it to pierce anonymity and go after a bad > guy, I can get behind that. Way to go, FBI, you did it right, now > please hold on while we figure out how you did this and write a patch to > keep you from doing it again. > > I guess you could say my preferred solution to the crypto wars is to > encourage an ongoing escalating crypto arms race. It's crazy, but it > seems to work. For my ?0.02 I think the above is mostly valid bar 2 small details: 1. Seldom we do find the FBI breaking security of anonymity tools. Only if a high profile case shows up or someone leaks it. I think it is even more rare for the FBI to outright disclose the vulnerability they used so it can be patched. I don't even know if the other 3 letter agencies do it. 2. Crypto arms race also implies stock piling vulnerabilities - something Bruce Schneier is very vocal about [1][2]. I think the answer here is to find a balance of some sort - i.e. keep vulnerabilities in rare cases for short periods of time and then disclose and patch them. However for that to work we need to trust the govt. to do the right thing. Which I think is pretty much the core issue that started this discussion. Regards, Martin [1] Hacking Team, Computer Vulnerabilities, and the NSA - https://www.schneier.com/blog/archives/2015/09/hacking_team_co.html [2] Disclosing vs. Hoarding Vulnerabilities - https://www.schneier.com/blog/archives/2014/05/disclosing_vs_h.html ____________________________________________________________ _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Wed Aug 24 19:00:39 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 24 Aug 2016 19:00:39 +0200 Subject: Unsubscribe me please In-Reply-To: <57BDCED5.00016A.30560@DESKTOP-NJQMPIA> References: <57BDCED5.00016A.30560@DESKTOP-NJQMPIA> Message-ID: On 24/08/16 18:44, lynda.harlos at sympatico.ca wrote: > I have contacted you several times to unsubscribe me please. Yet, the "you" you are contacting are not in the power to help you. It would be strange if the subscribers of a public mailing list could unsubscribe other subscribers. Please follow the link at the bottom of *every* post you receive through the list: > http://lists.gnupg.org/mailman/listinfo/gnupg-users If you ever find yourself in this situation again, please look for some pointers in the mail or on the web first, instead of posting such messages to the mailing list. It is a bit disruptive. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wolf at wolfsden.cz Wed Aug 24 19:56:58 2016 From: wolf at wolfsden.cz (Wolf) Date: Wed, 24 Aug 2016 19:56:58 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> Message-ID: <20160824175658.3q5aeffstd6yt4zc@wolfsden.cz> On , Robert J. Hansen wrote: > 3. If no, then how should we permit privacy tools to be > circumvented? Do you honestly believe that this is really possible? That government backdoor will stay available only to government and will not be misused? As an example I would raise issue of TSA accepted luggage locks. You know, those locks that only TSA is supposed to have master key to inspect for threats? The master key you can download from internet and print on your 3d printed and open any TSA accepted lock with it? ( https://en.wikipedia.org/wiki/Transportation_Security_Administration#Luggage_locks ) So in my eyes, when it comes to your question, we have only two options, no privacy or absolute privacy. Or do you know of any way to guarantee that government backdoor will not be made public and/or misused? Tomas Volf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed Aug 24 19:57:49 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Aug 2016 13:57:49 -0400 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <20160824175658.3q5aeffstd6yt4zc@wolfsden.cz> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <20160824175658.3q5aeffstd6yt4zc@wolfsden.cz> Message-ID: <2cddb851-0a46-8fd9-d61b-5311e46e9e1d@sixdemonbag.org> >> 3. If no, then how should we permit privacy tools to be >> circumvented? > > Do you honestly believe that this is really possible? That government > backdoor will stay available only to government and will not be > misused? I never said I believed backdoors were an appropriate way to circumvent privacy tools. I think backdoors are a terrible and inappropriate way to do it. I completely agree that backdoors are a lousy idea. From pete at heypete.com Wed Aug 24 19:07:41 2016 From: pete at heypete.com (Pete Stephenson) Date: Wed, 24 Aug 2016 19:07:41 +0200 Subject: Unsubscribe me please In-Reply-To: <57BDCED5.00016A.30560@DESKTOP-NJQMPIA> References: <57BDCED5.00016A.30560@DESKTOP-NJQMPIA> Message-ID: Hi Lynda, Unfortunately, that's not how it works. Essentially all of us are just users and can't unsubscribe you. Instead, your message was sent to the entire mailing list. Thankfully, the self-service process is straightforward: if you wish to unsubscribe, just click the link at the bottom of every message sent to the list and follow the directions to unsubscribe. Cheers! -Pete On Aug 24, 2016 18:51, "lynda.harlos at sympatico.ca" < lynda.harlos at sympatico.ca> wrote: > I have contacted you several times to unsubscribe me please. > > > > ? ? ? > *Lynda Harlos* > Home based travel agent > > Orion Travelinx > > Home office: 905-433-4267 > > Text: 905-723-9210 > > www.facebook.com/TravelAgent.LyndaHarlos > > > > Referrals are the best compliment! > > Any price/s quoted not guaranteed until payment is made > > To unsubscribe please reply with unsubscribe in subject line > *-------Original Message-------* > > *From:* martin > *Date:* 8/24/2016 12:32:12 PM > *To:* gnupg-users at gnupg.org > *Subject:* Re: Attacks on encrypted communicxatiopn rising in Europe > > On 24/08/16 15:37, Robert J. Hansen wrote: > > I find the current state of detente to be pretty good, actually. We're > > allowed to design the best systems we can, and governments are allowed > > to discover where we're not as clever as we think we are. If there's a > > flaw in Tor and the FBI uses it to pierce anonymity and go after a bad > > guy, I can get behind that. Way to go, FBI, you did it right, now > > please hold on while we figure out how you did this and write a patch to > > keep you from doing it again. > > > > I guess you could say my preferred solution to the crypto wars is to > > encourage an ongoing escalating crypto arms race. It's crazy, but it > > seems to work. > > For my ?0.02 I think the above is mostly valid bar 2 small details: > > 1. Seldom we do find the FBI breaking security of anonymity tools. Only > if a high profile case shows up or someone leaks it. I think it is even > more rare for the FBI to outright disclose the vulnerability they used > so it can be patched. I don't even know if the other 3 letter agencies > do it. > > 2. Crypto arms race also implies stock piling vulnerabilities - > something Bruce Schneier is very vocal about [1][2]. I think the answer > here is to find a balance of some sort - i.e. keep vulnerabilities in > rare cases for short periods of time and then disclose and patch them. > However for that to work we need to trust the govt. to do the right > thing. Which I think is pretty much the core issue that started this > discussion. > > Regards, > Martin > > [1] Hacking Team, Computer Vulnerabilities, and the NSA - > https://www.schneier.com/blog/archives/2015/09/hacking_team_co.html > [2] Disclosing vs. Hoarding Vulnerabilities - > https://www.schneier.com/blog/archives/2014/05/disclosing_vs_h.html > > > ____________________________________________________________ > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolf at wolfsden.cz Wed Aug 24 20:14:53 2016 From: wolf at wolfsden.cz (Wolf) Date: Wed, 24 Aug 2016 20:14:53 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <2cddb851-0a46-8fd9-d61b-5311e46e9e1d@sixdemonbag.org> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <20160824175658.3q5aeffstd6yt4zc@wolfsden.cz> <2cddb851-0a46-8fd9-d61b-5311e46e9e1d@sixdemonbag.org> Message-ID: <20160824181453.i2hdhl6amjh3ngvr@wolfsden.cz> On , Robert J. Hansen wrote: > >> 3. If no, then how should we permit privacy tools to be > >> circumvented? > > > > Do you honestly believe that this is really possible? That government > > backdoor will stay available only to government and will not be > > misused? > > I never said I believed backdoors were an appropriate way to circumvent > privacy tools. I think backdoors are a terrible and inappropriate way > to do it. > > I completely agree that backdoors are a lousy idea. Then I'm sorry, I've probably got you wrong. But I would be really interested to know what is you proposed solution to this issue. TV. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ben at adversary.org Wed Aug 24 20:35:23 2016 From: ben at adversary.org (Ben McGinnes) Date: Thu, 25 Aug 2016 04:35:23 +1000 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: References: <57BCA5FD.50500@vulcan.xs4all.nl> <87mvk2y8gy.fsf@wheatstone.g10code.de> <20160824142359.GC1607@adversary.org> Message-ID: <20160824183523.GD1607@adversary.org> On Wed, Aug 24, 2016 at 10:37:35AM -0400, Robert J. Hansen wrote: >> >> P.S. We may be in the Second Crypto Wars, but the genie is out of >> the bottle, so that sense of "oh noes, the governments is >> coming for my cryptoes" just isn't there so much. > > Yeah, which is why I find both sides of the privacy absolutist > debate to be ... pretty much comically missing the point. It's even more amusing if you've ever run the numbers on any country's direct economic benefit from Internet commerce (which usually doesn't count things like banking online). I did for a white paper released in 2009 during Australia's "clean feed" Internet censorship debate and the figures were massive and growing at a ridiculous rate. For any country with an equivalent GDP or larger (and most smaller), mandatory backdooring of encryption is economic suicide. > Tor, cgiproxy, GnuPG, Signal, and other such tools are out there and > aren't going to go away. All proposals to require backdoors are > silly, because so long as just one nation has no such requirement > those tools will continue to exist and development will continue > pretty much without interruption. So the "backdoor everything!" > crowd is completely barmy. Exactly. Sometimes governments will produce some ridiculous things which nearly become law, my own came precariously close to it a year or two ago ... which is why one of the first things I added to any of my commits for the GPGME stuff was a completed ITAR questionnaire. So much confusion and FUD simply because the term "public domain" means "no copyright/no license" to most civilians, but means "publicly available" to DoD. > But so too are the privacy absolutists who believe that law-enforcement > is doing something morally wrong when they try to break Tor's anonymity > in the pursuit of awful people. Ah, but if they were true absolutists then they wouldn't need these things because it would be absolutely sacrosanct. ;) > I find the current state of detente to be pretty good, actually. > We're allowed to design the best systems we can, and governments are > allowed to discover where we're not as clever as we think we are. > If there's a flaw in Tor and the FBI uses it to pierce anonymity and > go after a bad guy, I can get behind that. Way to go, FBI, you did > it right, now please hold on while we figure out how you did this > and write a patch to keep you from doing it again. Right. Then there's the recent-ish revelation that SSL/TLS was doing stupid things with sharing primes (maybe SSH was too), which was almost certainly why all the NSA docs we've seen so far from Ed Snowden kept referring to SSL as breakable and not so with GPG. > I guess you could say my preferred solution to the crypto wars is to > encourage an ongoing escalating crypto arms race. It's crazy, but > it seems to work. It works because it accepts the reality that one side will keep trying to take power and hoard it, while the rest of us instinctively reject it (no matter how much we may or may not agree with those attempting to seize that power). It starts becoming a problem, however, when I'm viewed as an evil bastard because I don't show enough loyalty to the United States by objecting to the NSA reading everything I write no matter what it is or who it is intended for. Even though I'm not an American citizen, or resident ... and the last time I was in America was 30 years ago (30 years, this month actually). Because really, that's just stupid, but I've lost count of the times I've heard it. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From Reid.Thompson at ateb.com Wed Aug 24 19:00:20 2016 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Wed, 24 Aug 2016 17:00:20 +0000 Subject: Unsubscribe me please In-Reply-To: <57BDCED5.00016A.30560@DESKTOP-NJQMPIA> References: <57BDCED5.00016A.30560@DESKTOP-NJQMPIA> Message-ID: <1472057970.4120.43.camel@ateb.com> you have to unsubscribe yourself.??the link to do so is at the bottom of every email from the list On Wed, 2016-08-24 at 12:44 -0400, lynda.harlos at sympatico.ca wrote: > ? > I have contacted you several times to unsubscribe me please. ? > ? > ? > ? > ? > ? ? ? > Lynda Harlos > Home based travel agent > Orion Travelinx > Home office: 905-433-4267 > Text: 905-723-9210 > www.facebook.com/TravelAgent.LyndaHarlos? > ? > Referrals are the best compliment! From johanw at vulcan.xs4all.nl Thu Aug 25 01:46:40 2016 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 25 Aug 2016 01:46:40 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: <7ec5d320-ea37-25a8-c852-993df7a6d890@sixdemonbag.org> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <57BD7C1B.6060700@vulcan.xs4all.nl> <2f0456fe-dce5-9db1-524e-e55eeebb4d55@sixdemonbag.org> <57BDACA7.3000203@vulcan.xs4all.nl> <7ec5d320-ea37-25a8-c852-993df7a6d890@sixdemonbag.org> Message-ID: <57BE31E0.6070700@vulcan.xs4all.nl> On 24-08-2016 16:27, Robert J. Hansen wrote: > Ideally, because they present options that may work better than what we > currently have. Privacy absolutism -- the position that there is *no* > justification for infringing on individual privacy, even in the case of > serious crimes -- doesn't offer anything better than what we currently > have. In fact, many people would think it was a lot worse. I probably misunderstood you. My position is that there is no compromise possible in the ability of people to protect their privacy. If it can be broken by passive technical means - bad implementation, weak password - that's OK with me. If it requires active hacking - keyloggers or so - that's not OK with me. If it requires pressuring people to give up their privacy - fines or jail time when not revealing their password - then I firmly oppose that. > But if you're okay with technical attacks, you're not a privacy > absolutist, either. If your solution is targeted malware, remote > exploits, Trojans, and the like, then you're permitting the government > to do an awful lot to subvert privacy. With technical attacks I meant more the like of cracking the crypto, not active hacking of computers or other devices. All said, I think our opinions are not that different. All I hope is that the current situation in Europe does not get used as an excuse to implement laws like the UK has, where not revealing passwords can get you jail time. Fortunately with perfect forward secrecy in messengers like Signal and Whatsapp even that becomes impossible, you can't even decipher intercepted chats from the past because the keys don't exist anymore. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From anthony at cajuntechie.org Thu Aug 25 02:05:08 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Wed, 24 Aug 2016 19:05:08 -0500 Subject: OpenPGP.conf streamed? Message-ID: <561ec722-7833-c1f1-a401-9d63619043c9@cajuntechie.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I just realized that OpenPGP.conf is coming up in less than a month. Unfortunately, I won't be able to attend. Will anyone be streaming it live? If not, will there be videos posted? Thanks, Anthony - -- OpenPGP Key: 4096R/0x028ADF7453B04B15 Other Key Info: http://www.cajuntechie.org/p/my-pgp-key.html XMPP?Jabber: cajuntech at dukgo.com VoIP/SIP: 17772471988101 at in.callcentric.com -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXvjY0AAoJEAKK33RTsEsVEhMP/AjV7gpCCRgO6AEfDg+vox4B dnHrdpRVw9SZgpWC033AexNW967h9dC/JrV51Go3ZHXTPs5diR/bBYOMhJUAype/ XFXlvLOxv4hPylVchkHGIjrRiQCtM/K7ux1ECm8mqB8LqFBO6Yl3ERTWeqO8Uu7Y SNqXwUSI0ptEroMs4XJrNXA3eaR2+5TWLANjblbQT5QwX021vbtRw8DMs44Xcd4R isAZ1oIDZJIGXMk5/w1qadvXVQ8hZ82TD1QqRzmdpKzyuTSliuBLkqiICW7qjmoN 1JvIPRD5Ru61GOKxkwPDhY7XeFvhSYqC3hkU3aQV8GpjtVR9NpNTFLqFaFuQnlKU Sth/GUffIIJBD8U0dhH30h7/kPkw6F40tWyS9U2NGcyl5hS9NCHvcuaD3xfRKzOe A+fjsMXcwnS7dTQNZaAJFvR5PjEsfFiPg3r9h0MtFrAH9A1Xv/IKPNK5mZVJEzNN BUzgNbXzNTfW0Vozj8QZFCTpeTq6y6ZNVTFrd7QokAAkxwPTMCl4H7DQ7vAsTNKo Kv8hyNombBFtAOz7H5ayNej8n1GziTzcRsakvsmPkSskIgVnimY5MQ9igrJ3ioNp DDbh3AylLo9GsN0DgcgGcQdZ1joLp1N7EsmwWi7HiPoMg7/P6fpTPrtguejXR3H5 ivK08QxkWDeWJVzf0s4P =VHOS -----END PGP SIGNATURE----- From ben at skyportsystems.com Thu Aug 25 02:31:33 2016 From: ben at skyportsystems.com (Ben Warren) Date: Wed, 24 Aug 2016 17:31:33 -0700 Subject: SSH hangs when using GPG2 + Yubikey on OS-X In-Reply-To: References: <3ba4e8c5-16dc-217f-b801-fac619360b6f@fsij.org> <2055D831-4693-4E5D-9A09-7634185B6300@skyportsystems.com> <83250957-75e0-dd26-b673-0c53f9622aea@fsij.org> Message-ID: <1D59D3E9-191B-4A42-A742-02E413506FF1@skyportsystems.com> Hi, Sorry it took so long to get back to you on this. Today I installed gpg 2.1.15, which contains your fix. I haven?t seen SSH connections hang yet, but haven?t been using it long. I did, however, see failure to use the card. I initiated an SSH session, and it immediately prompted for the remote user password, indicating that the Yubikey was not authenticating. I see this in the scdaemon log: 2016-08-24 16:29:29 scdaemon[67288] updating reader 0 (0) status: 0x0007->0x0000 (1->2) 2016-08-24 16:29:29 scdaemon[67288] DBG: Removal of a card: 0 2016-08-24 16:29:29 scdaemon[67288] DBG: application has been released 2016-08-24 16:29:29 scdaemon[67288] sending signal 31 to client 67281 2016-08-24 17:23:23 scdaemon[67288] handler for fd 9 started 2016-08-24 17:23:23 scdaemon[67288] DBG: enter: apdu_open_reader: portstr=(null) 2016-08-24 17:23:23 scdaemon[67288] detected reader 'Yubico Yubikey 4 OTP+U2F+CCID' 2016-08-24 17:23:23 scdaemon[67288] reader slot 1: not connected 2016-08-24 17:23:23 scdaemon[67288] DBG: leave: apdu_open_reader => slot=1 [pc/sc] 2016-08-24 17:23:23 scdaemon[67288] DBG: chan_9 -> OK GNU Privacy Guard's Smartcard server ready 2016-08-24 17:23:23 scdaemon[67288] DBG: chan_9 <- GETATTR $AUTHKEYID 2016-08-24 17:23:23 scdaemon[67288] DBG: enter: apdu_connect: slot=1 2016-08-24 17:23:23 scdaemon[67288] pcsc_connect failed: sharing violation (0x8010000b) 2016-08-24 17:23:23 scdaemon[67288] reader slot 1: not connected 2016-08-24 17:23:23 scdaemon[67288] DBG: leave: apdu_connect => sw=0x10006 2016-08-24 17:23:23 scdaemon[67288] DBG: Removal of a card: 0 2016-08-24 17:23:23 scdaemon[67288] DBG: chan_9 -> ERR 100696144 Operation not supported by device 2016-08-24 17:23:26 scdaemon[67288] DBG: chan_9 <- BYE 2016-08-24 17:23:26 scdaemon[67288] DBG: chan_9 -> OK closing connection 2016-08-24 17:23:26 scdaemon[67288] handler for fd 9 terminated Does the ?pcsc_connect_failed? message indicate that scdaemon is butting up against another smartcard handler running in OS-X? regards, Ben > On Jul 19, 2016, at 7:57 PM, NIIBE Yutaka wrote: > > On 07/19/2016 05:54 PM, NIIBE Yutaka wrote: >> On 07/19/2016 02:22 PM, Ben Warren wrote: >>> We don?t see this issue when using a file-based key for SSH, >>> although in that case we?re using ssh-agent, not gpg-agent. I?ll >>> try using a file-based GPG key, which will be closer to the failing >>> configuration. >> >> Are you using some other tools for Yubikey? >> >> People sometimes do or write a script with >> >> gpg-connect-agent "SCD RESET" /bye >> >> (to reset PIN auth state) but this only works well if we have a single >> connection from gpg-agent to scdaemon. Having ssh-sessions (with >> forwarding), we have multiple connections from gpg-agent to scdaemon. >> This could be a cause of troubles. > > I think that the problem occurs when we do "SCD RESET" above or > removal/insertion of token during the use of SSH. > > It seems for me that OpenSSH client (7.2p2, in my case) keeps the > connection to ssh-agent even if it doesn't use forwarding. So, it is > likely that we encounter this problem. > > Today, I fixed this issue by: > > commit 1598a4476466822e7e9c757ac471089d3db4b545 > > Please try it out. > -- > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3583 bytes Desc: not available URL: From ccogcj at gmail.com Thu Aug 25 04:15:26 2016 From: ccogcj at gmail.com (Caleb Coggeshall) Date: Wed, 24 Aug 2016 19:15:26 -0700 Subject: Please unsubscribe me form your mailing list. Thank you. In-Reply-To: References: <57BD86FE.00001F.30560@DESKTOP-NJQMPIA> Message-ID: this woman is not marketing, she is asking to be taken off the mailing list and simply happens to have a signature with her business information on it. On Wed, Aug 24, 2016 at 6:42 AM, SUNNY <4got2ask at gmail.com> wrote: > Can we refrain from people marketing on this forum , I guess this is not a > marketing forum , and these need to be blocked > > Sunny > > On Aug 24, 2016, at 07:37, "lynda.harlos at sympatico.ca" < > lynda.harlos at sympatico.ca> wrote: > > > > ? ? ? > *Lynda Harlos* > Home based travel agent > > Orion Travelinx > > Home office: 905-433-4267 > > Text: 905-723-9210 > > www.facebook.com/TravelAgent.LyndaHarlos > > > > Referrals are the best compliment! > > Any price/s quoted not guaranteed until payment is made > > To unsubscribe please reply with unsubscribe in subject line > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- Caleb Coggeshall UT http://www.facebook.com/caleb.membrane -------------- next part -------------- An HTML attachment was scrubbed... URL: From volf.tomas at gmail.com Thu Aug 25 14:01:35 2016 From: volf.tomas at gmail.com (Tomas Volf) Date: Thu, 25 Aug 2016 14:01:35 +0200 Subject: Please unsubscribe me form your mailing list. Thank you. In-Reply-To: References: <57BD86FE.00001F.30560@DESKTOP-NJQMPIA> Message-ID: <20160825120134.qmhykxbnutwg4ncc@wolfsden.cz> On , Caleb Coggeshall wrote: > this woman is not marketing, she is asking to be taken off the mailing list > and simply happens to have a signature with her business information on it. while true, the signature was like 70% of the mail... W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From paolo.bolzoni.brown at gmail.com Fri Aug 26 09:13:22 2016 From: paolo.bolzoni.brown at gmail.com (Paolo Bolzoni) Date: Fri, 26 Aug 2016 09:13:22 +0200 Subject: Please unsubscribe me form your mailing list. Thank you. In-Reply-To: <20160825120134.qmhykxbnutwg4ncc@wolfsden.cz> References: <57BD86FE.00001F.30560@DESKTOP-NJQMPIA> <20160825120134.qmhykxbnutwg4ncc@wolfsden.cz> Message-ID: The world would be a much better place if we could ban signatures and non pure-text emails. Alas... From paolo.bolzoni.brown at gmail.com Fri Aug 26 09:12:40 2016 From: paolo.bolzoni.brown at gmail.com (Paolo Bolzoni) Date: Fri, 26 Aug 2016 09:12:40 +0200 Subject: Attacks on encrypted communicxatiopn rising in Europe In-Reply-To: References: <57BCA5FD.50500@vulcan.xs4all.nl> <87mvk2y8gy.fsf@wheatstone.g10code.de> <20160824142359.GC1607@adversary.org> Message-ID: On Wed, Aug 24, 2016 at 4:37 PM, Robert J. Hansen wrote: > But so too are the privacy absolutists who believe that law-enforcement > is doing something morally wrong when they try to break Tor's anonymity > in the pursuit of awful people. I think you can say this sentence with the one that try break a Daesh hacker and the awful people being american soldiers. I personally think that's the point, to be in the safe side you have always to assume you are the awful people for someone. It does not matter how real, or absolute the thing is. Try to break is fine, forcing people to use broken products is bad. From jhs at berklix.com Fri Aug 26 13:22:48 2016 From: jhs at berklix.com (Julian H. Stacey) Date: Fri, 26 Aug 2016 13:22:48 +0200 Subject: Please unsubscribe me form your mailing list. Thank you. In-Reply-To: Your message "Fri, 26 Aug 2016 09:13:22 +0200." Message-ID: <201608261123.u7QBMmrh037156@fire.js.berklix.net> Paolo Bolzoni wrote: > The world would be a much better place if we could ban signatures and > non pure-text emails. Alas... The Net thrives on incompetence :-( UUCP '%' & '!' once excluded zombies. Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/#stolen_votes From rjh at sixdemonbag.org Fri Aug 26 16:12:53 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 26 Aug 2016 10:12:53 -0400 Subject: Please unsubscribe me form your mailing list. Thank you. In-Reply-To: <201608261123.u7QBMmrh037156@fire.js.berklix.net> References: <201608261123.u7QBMmrh037156@fire.js.berklix.net> Message-ID: <57f7aeac-f669-6c3a-fdb8-02a94dde8ec5@sixdemonbag.org> > Paolo Bolzoni wrote: >> The world would be a much better place if we could ban signatures and >> non pure-text emails. Alas... The world is a better place for it neither banning, nor trying to ban, such things. First, how do you ban signatures without banning people? Many people work in businesses which mandate signatures. If we attempted to ban signatures we'd be telling people, "unless you have a personal email account, you don't deserve to talk to people." Second, how do you ban signatures? That would be an interesting problem in AI, and would lead to false positives. Again, this would have the effect of barring some people from communicating. Third, define "non pure-text". If you're requiring 7-bit ASCII then you're telling people from non-English-speaking countries that they can't communicate. And once you open it up to Unicode, you've introduced a huge amount of attack surface -- I can't think of a coherent argument that says "we'll support arbitrary character sets including Unicode, but HTML is evil because of the attack surface it presents." Fourth, why is *forbidding a capability* considered a feature? Forbidding the misuse of a capability, sure, I can see that as a feature. But every now and again I try to present math in this mailing list, and I have two choices: (a) ASCII art, which doesn't render correctly on many platforms, or (b) Embed a LaTeX image into an HTML email We shouldn't be angry about capabilities -- we should be angry about people using them inappropriately. From paolo.bolzoni.brown at gmail.com Fri Aug 26 16:39:33 2016 From: paolo.bolzoni.brown at gmail.com (Paolo Bolzoni) Date: Fri, 26 Aug 2016 16:39:33 +0200 Subject: Please unsubscribe me form your mailing list. Thank you. In-Reply-To: <57f7aeac-f669-6c3a-fdb8-02a94dde8ec5@sixdemonbag.org> References: <201608261123.u7QBMmrh037156@fire.js.berklix.net> <57f7aeac-f669-6c3a-fdb8-02a94dde8ec5@sixdemonbag.org> Message-ID: (1) and (2) Did you read the word "alas"? Of course it's not possible. Secondly the fact business policy mandates something does not make it a good idea, in this case it does not at all. (3) Study the meaning of the word "Encoding." Plain-text has nothing to do with what characters you can represents. Nowadays UTF-8 is fairly popular for many reasons. (4) "*forbidding a capability* considered a feature" is something you said. I simply said the world would be better, because the disadvantages are more than the advantages. If the format is important for any reason, just write a .pdf or create few pictures and attach them. From andrewg at andrewg.com Fri Aug 26 16:56:05 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 26 Aug 2016 15:56:05 +0100 Subject: Please unsubscribe me form your mailing list. Thank you. In-Reply-To: References: <201608261123.u7QBMmrh037156@fire.js.berklix.net> <57f7aeac-f669-6c3a-fdb8-02a94dde8ec5@sixdemonbag.org> Message-ID: <0A8C1EF4-1DE4-458D-B0B7-AFB6CB3BA350@andrewg.com> On 26 Aug 2016, at 15:39, Paolo Bolzoni wrote: > just write a .pdf It's a sad day when pdf is considered preferable to html... ;-) A From listofactor at mail.ru Sat Aug 27 09:30:45 2016 From: listofactor at mail.ru (listo factor) Date: Sat, 27 Aug 2016 07:30:45 +0000 Subject: Torture and rights to privacy In-Reply-To: <7ec5d320-ea37-25a8-c852-993df7a6d890@sixdemonbag.org> References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <57BD7C1B.6060700@vulcan.xs4all.nl> <2f0456fe-dce5-9db1-524e-e55eeebb4d55@sixdemonbag.org> <57BDACA7.3000203@vulcan.xs4all.nl> <7ec5d320-ea37-25a8-c852-993df7a6d890@sixdemonbag.org> Message-ID: <322fc2f4-1c72-b124-56c0-022a03eeec0b@mail.ru> It would help if in similar discussions participants first find out what are the ethical fundamentals that they agree on. May I suggest the following: 1) Torture is absolutely unacceptable. It includes not only physical harm to the individual's body, bit also actions that instill pain or fear without leaving permanent marks on the body (water-boarding, mock executions...), mind-altering pharmaceuticals or keeping one locked up for refusing either a confession or self-incriminatory evidence. 2) No one can prevent an individual to keep his journals or ledgers in a language that only he understands, or any two individuals to communicate in such language. The fact that such language happens to be a stream of ones and zeros changes nothing, as does not the fact that a mechanical or electronic device - instead of pen and paper - may be used for reading and writing this language. Mere possession and use of such device can not be considered a transgression, any more than a possession of pen and paper. These two principles seem to me to be universal. After that, it becomes the matter of an individual jurisdiction law and the majority rule. Personally, I would not be much thrilled to live under a government that restricts the trade in the aforementioned devices, or worse, punishes someone for constructing them and making them available. I have lived long enough too see many different governments manipulate the public, typically using a mixture of fear-mongering and ideology, to accept various laws that are quite unpalatable to me. However, the discussion of one particular government's behavior is best left to it's citizens. From caro at nymph.paranoici.org Sun Aug 28 00:07:57 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sat, 27 Aug 2016 22:07:57 +0000 (UTC) Subject: Decryption with suppressed key ID (--throw-keyids) different in 2.1 Message-ID: <20160827220757.EB65610320E5@remailer.paranoici.org> Hi, the next problem with my 1.4 -> 2.1 (2.1.15) migration (Windows 7). Is there a reason why decryption of data with the recipient's key ID suppressed now requires the --try-all-secrets option? It took me some time to realize that difference. Kind regards, Caro From caro at nymph.paranoici.org Sat Aug 27 23:46:03 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sat, 27 Aug 2016 21:46:03 +0000 (UTC) Subject: Decryption with suppressed key ID (--throw-keyids) different in 2.1 Message-ID: <20160827214603.B271310320E5@remailer.paranoici.org> Hi, the next problem with my 1.4 -> 2.1 (2.1.15) migration (Windows 7). Is there a reason why decryption of data with the recipient's key ID suppressed now requires the --try-all-secrets option? It took me some time to realize that difference. Kind regards, Caro From 2014-667rhzu3dc-lists-groups at riseup.net Sun Aug 28 14:27:01 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 28 Aug 2016 13:27:01 +0100 Subject: Please unsubscribe me form your mailing list. Thank you. In-Reply-To: <20160825120134.qmhykxbnutwg4ncc@wolfsden.cz> References: <57BD86FE.00001F.30560@DESKTOP-NJQMPIA> <20160825120134.qmhykxbnutwg4ncc@wolfsden.cz> Message-ID: <243449375.20160828132701@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thursday 25 August 2016 at 1:01:35 PM, in , Tomas Volf wrote: > while true, the signature was like 70% of the mail... If you ignore the list footer, which gets added to all messages, her advert was 100% of her message content. - -- Best regards MFPA A picture is a poem without words -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJXwtiVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw8y4H/3GNwu1lVeXNlV3t5aTkgyht xiIFSmsEx8zGCLUUFrSnIgBBFyY1qpR/H8zZZzRRoxuDUJOZBvckvYudU/uVQd3w at3fhrDSV2tR6P7We+7frga4AIWwNC0e1zF1ZG6BfneF5IpnVbC/MrqYlSneqPCu 3Ofu7CESXC2KlLDXZUzZ2cDGFSYZYw4XLqi0lJ/sTarB4LVVY9BCJGlrWoNT25Lk 80ejOBuGLzsVJ2IHB7RaKK9vDj7xcczT4kQA/XFhkCx9Etrt2Z+F4zVQwCCCgjCd pI62Yix1acIkBgDtp5fWDD9+8yWMtqvqEIQGbVOjhymeKsWRW61ZuDuG4FQE3yqI vgQBFgoAZgUCV8LYlV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45DX9AP98PCugmdCZOPPybC2hwoA9JC7E VLXde8r7WCx6FuSWewD+Ijg5qrZvEXS3eDBimxBbrH9O/cL9pkND/B6ccBcMIAo= =38a0 -----END PGP SIGNATURE----- --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From jhs at berklix.com Sun Aug 28 15:05:44 2016 From: jhs at berklix.com (Julian H. Stacey) Date: Sun, 28 Aug 2016 15:05:44 +0200 Subject: Torture and rights to privacy In-Reply-To: Your message "Sat, 27 Aug 2016 07:30:45 -0000." <322fc2f4-1c72-b124-56c0-022a03eeec0b@mail.ru> Message-ID: <201608281305.u7SD5i5D066553@fire.js.berklix.net> listo factor wrote: > It would help if in similar discussions participants first find > out what are the ethical fundamentals that they agree on. May I > suggest the following: This is non technical, non gpg, & could be discussed anywhere, pref. not here. Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/#stolen_votes From wk at gnupg.org Sun Aug 28 17:26:22 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 28 Aug 2016 17:26:22 +0200 Subject: Decryption with suppressed key ID (--throw-keyids) different in 2.1 In-Reply-To: <20160827220757.EB65610320E5@remailer.paranoici.org> (Carola Grunwald's message of "Sat, 27 Aug 2016 22:07:57 +0000 (UTC)") References: <20160827220757.EB65610320E5@remailer.paranoici.org> Message-ID: <87h9a4kj8h.fsf@wheatstone.g10code.de> On Sun, 28 Aug 2016 00:07, caro at nymph.paranoici.org said: > Is there a reason why decryption of data with the recipient's key ID > suppressed now requires the --try-all-secrets option? It took me some No, this would be a bug. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From caro at nymph.paranoici.org Mon Aug 29 04:25:02 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Mon, 29 Aug 2016 02:25:02 +0000 (UTC) Subject: Decryption with suppressed key ID (--throw-keyids) different in 2.1 References: <20160827220757.EB65610320E5@remailer.paranoici.org> <87h9a4kj8h.fsf@wheatstone.g10code.de> Message-ID: <20160829022502.8994A100A7F3@remailer.paranoici.org> Hi Werner! On Sun, 28 Aug 2016 17:26:22 +0200, Werner Koch wrote: >On Sun, 28 Aug 2016 00:07, caro at nymph.paranoici.org said: > >> Is there a reason why decryption of data with the recipient's key ID >> suppressed now requires the --try-all-secrets option? It took me some > >No, this would be a bug. I get an error 0x02 in return: | [GNUPG:] ENC_TO 0000000000000000 1 0 | gpg: encrypted with RSA key, ID 00000000 | [GNUPG:] NO_SECKEY 0000000000000000 | [GNUPG:] BEGIN_DECRYPTION | [GNUPG:] DECRYPTION_FAILED | gpg: decryption failed: No secret key | [GNUPG:] END_DECRYPTION HTH Bye Caro From wk at gnupg.org Mon Aug 29 08:01:23 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Aug 2016 08:01:23 +0200 Subject: Decryption with suppressed key ID (--throw-keyids) different in 2.1 In-Reply-To: <20160829022502.8994A100A7F3@remailer.paranoici.org> (Carola Grunwald's message of "Mon, 29 Aug 2016 02:25:02 +0000 (UTC)") References: <20160827220757.EB65610320E5@remailer.paranoici.org> <87h9a4kj8h.fsf@wheatstone.g10code.de> <20160829022502.8994A100A7F3@remailer.paranoici.org> Message-ID: <87y43gf70s.fsf@wheatstone.g10code.de> On Mon, 29 Aug 2016 04:25, caro at nymph.paranoici.org said: >>No, this would be a bug. > > I get an error 0x02 in return: This is a regression in 2.1.14. Workaround is to either set --default-key or --try-secret-key. Patch attached. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Make-decryption-of-R-work-w-o-try-secret-key-or-.patch Type: text/x-diff Size: 1775 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From ben at adversary.org Mon Aug 29 08:46:52 2016 From: ben at adversary.org (Ben McGinnes) Date: Mon, 29 Aug 2016 16:46:52 +1000 Subject: Decryption with suppressed key ID (--throw-keyids) different in 2.1 In-Reply-To: <87y43gf70s.fsf@wheatstone.g10code.de> References: <20160827220757.EB65610320E5@remailer.paranoici.org> <87h9a4kj8h.fsf@wheatstone.g10code.de> <20160829022502.8994A100A7F3@remailer.paranoici.org> <87y43gf70s.fsf@wheatstone.g10code.de> Message-ID: <20160829064652.GC30931@adversary.org> On Mon, Aug 29, 2016 at 08:01:23AM +0200, Werner Koch wrote: > On Mon, 29 Aug 2016 04:25, caro at nymph.paranoici.org said: > >>>No, this would be a bug. >> >> I get an error 0x02 in return: > > This is a regression in 2.1.14. Workaround is to either set > --default-key or --try-secret-key. Patch attached. Which explains why a lot of people didn't notice it when so many people have "default-key" in their gpg.conf. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From dlx9pekuv at gmail.com Mon Aug 29 09:46:11 2016 From: dlx9pekuv at gmail.com (Dd Ll) Date: Mon, 29 Aug 2016 03:46:11 -0400 Subject: unable to find Sha1 checksums/ package announcements Message-ID: Hello, I have been trying to follow the advice given on your integrity web page below: https://www.gnupg.org/download/integrity_check.html "Comparing Checksums If you are not able to use an old version of GnuPG, you can still verfiy the file's SHA-1 checksum. This is less secure, because if someone modified the files as they were transferred to you, it would not be much more effort to modify the checksums that you see on this webpage. As such, if you use this method, you should compare the checksums with those in release announcement. This is sent to the gnupg-announce mailing list (among others), which is widely mirrored. Don't use the mailing list archive on this website, but find the announcement on several other websites and make sure the checksum is consistent. This makes it more difficult for an attacker to trick you into installing a modified version of the software." I have been trying to verify the checksums posted at the above listed web site by checking for the announce messages in the gnupg-announce mailing list. Unfortunately there doesn't seem to be any anouncements for the following tarballs: pinentry-0.9.7.tar.bz2 dirmngr-1.1.1.tar.bz2 npth-1.2.tar.bz2 libassuan-2.4.3.tar.bz2 libksba-1.3.4.tar.bz2 libgpg-error-1.24.tar.bz2 I am checking for the checksums at the web archive https://marc.info/. I have done a google search and can't seem to find any other site that archives messages from gnupg-announce. Have you stopped releasing announcements for certain tarballs or am I missing something? Dd -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Aug 29 12:26:51 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Aug 2016 12:26:51 +0200 Subject: unable to find Sha1 checksums/ package announcements In-Reply-To: (Dd Ll's message of "Mon, 29 Aug 2016 03:46:11 -0400") References: Message-ID: <87vayjdg5w.fsf@wheatstone.g10code.de> On Mon, 29 Aug 2016 09:46, dlx9pekuv at gmail.com said: > Have you stopped releasing announcements for certain tarballs or > am I missing something? I don't want to clutter the announcement list with these regular update notifications. I expected that only a few users have a need for these checksums, given that gpg is part of every Linux distribution and available in all *BSD ports. The files https://versions.gnupg.org/swdb.lst https://versions.gnupg.org/swdb.lst.sig have all the information including SHA-256 checksums. They are actually the source for the info at the website. I would suggest to download these files on a machine with gpg available, verify against the published fingerprints and then use the checksums. The tool gnupg/build-aux/getswdb.sh can be used to automate this task. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From listofactor at mail.ru Mon Aug 29 21:42:29 2016 From: listofactor at mail.ru (listo factor) Date: Mon, 29 Aug 2016 19:42:29 +0000 Subject: Servant of Two Masters In-Reply-To: References: <57BCA5FD.50500@vulcan.xs4all.nl> <1c22f206-8293-86f4-7aa6-48c33c494b17@sixdemonbag.org> <57BD7C1B.6060700@vulcan.xs4all.nl> <2f0456fe-dce5-9db1-524e-e55eeebb4d55@sixdemonbag.org> <20160824140403.GA17526@casa.casa> Message-ID: On 08/24/2016 02:23 PM, Robert J. Hansen wrote: > If I ask "how should we permit privacy tools to be circumvented?" and > someone's answer is "Pressure them. A wrench comes to mind," well... > I've received an answer to how the person believes governments should be > permitted to obtain secrets. It's not a very good one. How about we stop considering 'the government' to be an adversary in a class by itself? From a technical cryptographers' point of view, there is a user that wants to keep his stored or communicated data secret, and the adversary that wants to break the secrecy. It is perfectly normal for a technical professional to offer his or her services to one or the other, depending on either monetary consideration or on some ethical, political, or philosophical criteria. But attempts to be a servant of two masters have resulted in either catastrophe or a farce so often that not much can be said about that has been said or written already. From wk at gnupg.org Tue Aug 30 16:39:15 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Aug 2016 16:39:15 +0200 Subject: Key Discovery Made Simple Message-ID: <874m625njg.fsf@wheatstone.g10code.de> Hi, I just published a writeup on how to setup the Web Key Service at https://gnupg.org/blog/20160830-web-key-service.html A plain text copy is below. If you have comments, please send them as reply. Salam-Shalom, Werner ============================================ Table of Contents _________________ 1 Key Discovery Made Simple .. 1.1 Install GnuPG 2.1 .. 1.2 Prepare the mail and web servers .. 1.3 Create submission key .. 1.4 Install the WKS server tool .. 1.5 Test your installation .. 1.6 Future work 1 Key Discovery Made Simple =========================== A major hassle with sending encrypted mails is to find the key matching the recipients mail address. A na?ve method is to look for the key at a keyserver. In most cases this works surprisingly well. However, there is no guarantee that this key really matches the mail address --- anyone can create a key and put an arbitrary mail address there. It is quite disturbing to receive a mail which you can't decrypt because it was encrypted to another key. GnuPG 2.1 provides an simple but efficient solution to store a key under a well known URL and lookup it up via https. For practical deployment of this method (as well as for OpenPGP DANE) a method to publishing a key is required. The new [Web Key Service] protocol such a protocol and GnuPG 2.1.15 comes with the tools to implement this. Aside from GnuPG the other pre-requisites are: - A mail server for your domain with the full authority on the user mail addresses for this domain. - A Unix system where you have an account to receive mails to a dedicated mail address and to send mails via the sendmail tool. An account on the mail server will be the best choice. - A web server for the same domain to deliver static pages over TLS. Re-direction to a different server is possible - The ability to install the latest GnuPG version from source. Here is a first step by step description on how to install and test that service. [Web Key Service] https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-01.html 1.1 Install GnuPG 2.1 ~~~~~~~~~~~~~~~~~~~~~ Your system will already have a gpg version but we want the very latest one and we want to install it locally. First you should create a new account on the machine. Let's use `webkey'. Nothing special is required; thus a simple ,---- | # adduser --disabled-password webkey `---- as root will do. Add an `.ssh/authorized_keys' file to make it easy to access. Now download GnuPG (as of this writing version 2.1.15): ,---- | $ cd ~webkey | $ wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.15.tar.bz2 | $ wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.15.tar.bz2.sig | $ wget -O - https://gnupg.org/signature_key.html | gpg --import | $ gpg --verify gnupg-2.1.15.tar.bz2.sig gnupg-2.1.15.tar.bz2 `---- The last line uses the standard gpg to check that the integrity of the tarball. Then please verify that the displayed fingerprints match the desired ones; see [https://gnupg.org/download/integrity_check.html] for more on this. The easiest way to install the latest GnuPG version is to use Speedo, which downloads, verifies and builds all dependent packages. To do this first unpack the tarball: ,---- | $ tar xjf gnupg-2.1.5.tar.bz2 `---- On non GNU system you may need to use this instead: ,---- | $ zcat gnupg-2.1.5.tar.bz2 | tar xf - `---- Then run: ,---- | $ make -f ~/b-w32/speedo/gnupg-2.1.15/build-aux/speedo.mk \ | > INSTALL_PREFIX=. speedo_pkg_gnupg_configure='--enable-gpg2-is-gpg \ | > --disable-g13 --enable-wks-tools' native `---- If you run into errors you are probably missing some development tools; install them and try again. If all succeeds you will notice a bunch of new directories below webkey's home directory: ,---- | PLAY bin include lib libexec sbin share swdb.lst swdb.lst.sig `---- Optionally you may delete what is not anymore required: ,---- | $ rm -rf PLAY include lib swdb.* `---- To make use of your new GnuPG installation you need to run this first (you should add it to webkey's .profile or .bashrc): ,---- | PATH="$HOME/bin:$PATH" | LD_LIBRARY_PATH="$(pwd)/lib" | export LD_LIBRARY_PATH `---- 1.2 Prepare the mail and web servers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Web Key Service requires a working directory to store keys pending for publication. As root create a working directory: ,---- | # mkdir /var/lib/gnupg/wks | # chown webkey:webkey /var/lib/gnupg/wks | # chmod 2750 /var/lib/gnupg/wks `---- Then under your webkey account create directories for all your domains. Here we do it for ?example.org?: ,---- | $ mkdir /var/lib/gnupg/wks/example.org `---- Then run ,---- | $ gpg-wks-server --list-domains `---- to create the required sub-directories with the permission set correctly. In particular the `hu' directory (?hashed-userid?) to store pending keys most only be accessible by the webkey user. Running the above command will also remind you to create a file with the submission address for the domain. Let?s do that: ,---- | $ cd /var/lib/gnupg/wks/example.org | $ echo key-submission at example.org >submission-address `---- The submission address is the address the client uses to contact the Web Key Service. To make this actually work, that address needs to be redirected to the webkey user; use the alias file of your MTA to do this. To setup the web server there are at least two ways: If the web server is on the same machine it is possible to use symlinks to publish the working directories. For example: ,---- | $ cd /var/www/example.org/htdocs | $ mkdir -p .well-known/openpgpkey | $ cd .well-known/openpgpkey | $ ln -s /var/lib/gnupg/wks/example.org/hu . | $ ln -s /var/lib/gnupg/wks/example.org/submission-address . `---- The more flexible way is the use of rsync optionally using an ssh connection to a remote web server. This can be done with a cron job; run `crontab -e' and add this line (the backslashes below are used to indicate line wrapping here; do not enter them into the crontab but use a single long line): ,---- | */4 * * * * rsync -r -p --chmod=Fa+r --delete \ | /var/lib/gnupg/wks/example/hu/ \ | webserver:/var/www/all/example.org/.well-known/openpgpkey/hu/ `---- This job syncs every 4 minutes the local copy of the published keys to the server. The submission-address file does not change and thus it is sufficient to copy it once by hand to the server. 1.3 Create submission key ~~~~~~~~~~~~~~~~~~~~~~~~~ The protocol suggests that the key to be published is send with an encrypted mail to the service. Thus you need to create a key for the submission address: ,---- | $ gpg --batch --passphrase '' --quick-gen-key key-submission at example.org | $ gpg --with-wkd-hash -K key-submission at example.org `---- The output of the last command looks similar to this: ,---- | sec rsa2048 2016-08-30 [SC] | C0FCF8642D830C53246211400346653590B3795B | uid [ultimate] key-submission at example.org | bxzcxpxk8h87z1k7bzk86xn5aj47intu at example.org | ssb rsa2048 2016-08-30 [E] `---- Take the hash of the string ?key-submission?, which is `bxzcxpxk8h87z1k7bzk86xn5aj47intu' and manually publish that key: ,---- | $ gpg --export-options export-minimal --export key-submission at example.org | > -o /var/lib/gnupg/wks/example.org/hu/bxzcxpxk8h87z1k7bzk86xn5aj47intu `---- Make sure that the created file is world readable. We will eventually provide a tool to make that step easier. 1.4 Install the WKS server tool ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The tool gpg-wks-server implements the server part of the web key service protocol. There are several ways to install this tool, what I describe here is a setup which allows easy debugging. First install procmail and make sure that your MTA (Exim, Postfix, sendmail) can run procmail as delivery agent. In most cases it is sufficient to create the file `.procmailrc' in the home directory (e.g. `/home/webkey/.procmailrc'). Here is that file; you need to replace ?example.org? by your own domain name: ,---- | PATH=$HOME/bin:/usr/bin:/bin:/usr/local/bin | LD_LIBRARY_PATH=$HOME/lib | | MAILDIR=$HOME/Mail | LOGFILE=$HOME/Mail/from | LOCKFILE=$HOME/Mail/.lockmail | VERBOSE=yes | | :0 | * ^FROM_DAEMON | from-daemon/ | | :0 c | archive/ | | :0 | * !^From: webkey at example.org | * !^X-WKS-Loop: webkey.example.org | |$HOME/bin/gpg-wks-server -v --receive \ | --header X-WKS-Loop=webkey.example.org \ | --from webkey at example.org --send -o $HOME/send.log | | :0 | cruft/ `---- What it does: The first 6 lines set environment variables for use by this tool and programs invoked. In particular the setting of `PATH' and `LD_LIBRARY_PATH' is important so that gpg-wks-server can properly work. The first rule (rules are started with a colon line) detects mails sent from daemon processes. We don't want them and thus we save them to the Maildir style folder `Mail/from-daemon' for later inspection. For a production system it would be better to directly send those mails to the bit bucket by replacing the last line of that rule with `/dev/null'. The second rule stores a copy of all incoming mails to the folder `Mail/archive'. This is useful for debugging and to view the flow of mails. The 'c' after the ':0' means continue with the next rule after having processed this rule (i.e. storing to the archive folder). By the way, do not forget the trailing slash at folder names; without a slash a plain mbox style would be written (you can use an mbox too, but Maildir is considered a better way to store mails). The third rule is the heart of this procmail script (in procmail parlance ?recipe?). The two lines starting with an asterisk give two conditions on when this rule shall be skipped: If the mail comes from us or if the mail has our loop detection mail header. The command run on this mail is the wks server in a mode which uses the /usr/lib/sendmail tool for sending responses to the mail. The output of the tool is stored to the file `send.log' in the home directory; to append to a log file use `-o -' and redirect to a log file. The final rule stores all not processed mails to the `cruft/' folder. This can as well be replaced by =/dev/null=/ Finally add an entry to your crontab (run `crontab -e') to expire non confirmed publication requests: At the top of your crontab add: ,---- | PATH=/home/webkey/bin:/usr/local/bin:/usr/bin:/bin | LD_LIBRARY_PATH=/home/webkey/lib | | 42 3 * * * gpg-wks-server --cron `---- so that the server tool is run each night at, say, 3:42. 1.5 Test your installation ~~~~~~~~~~~~~~~~~~~~~~~~~~ To test the Web Key Service, you can create some test accounts for your domain and run the protocol. For a proper test, do not just use a different account on the server but use client box. Developers of [KMail] should already be able to use its brand new builtin support for the Web Key Service. Integration of the Web Key Service into the other mail clients has not yet been done. Thus you need to run the test manually. In this example we assume that on you own box a sendmail like tool is installed and you also installed GnuPG 2.1 along with the client part of Web Key Service (gpg-wks-client which may require that you pass --enable-wks-tools to the configure run). An easy way of testing the system exists for [Mutt] users: By adding the two lines ,---- | application/vnd.gnupg.wks; /usr/local/bin/gpg-wks-client \ | -v --read --send; needsterminal; description=WKS message `---- to `/etc/mailcap' Mutt will do the decryption job and then call the wks-client for the protocol handling. It can be expected that Mutt users have a /usr/lib/sendmail installed which is required here. Note that `--read' is used which tells the client that the input mail has already been decrypted. For all others the protocol can be run by hand. Let?s assume, you have the key ,---- | sub cv25519 2016-07-15 [E] | C444189BD549468C97992D7D3C79E8F960C69FCE | pub ed25519 2016-06-28 [SC] | 64944BC035493D929EF2A2B9D19D22B06EE78668 | uid [ultimate] dewey at test.gnupg.org | sub cv25519 2016-06-28 [E] | B3746B6927FF8021486561D83452DE414E0B5CCD `---- which in fact is a real key of our own test environment. To publish that key you send the key to the mail provider: ,---- | $ /usr/local/libexec/gpg-wks-client --create --send \ | > 64944BC035493D929EF2A2B9D19D22B06EE78668 dewey at test.gnupg.org `---- As already mention, `--send' invokes `/usr/lib/sendmail' and sends out the mail. If that option is not used, the mail is written to stdout (or to the file given with `--output') and the user is responsible to feed this to the mail system. If this all works a single message will be show: ,---- | gpg-wks-client: submitting request to 'key-submission at test.gnupg.org' `---- Now, wait until you receive a mail back from your provider. In this example that mail was received and stored in the file `new/1472561079.6352_1.foobar'. We feed this file to the wks-client: ,---- | $ /usr/local/libexec/gpg-wks-client --receive --send \ | > < new/1472561079.6352_1.foobar `---- which may respond like this: ,---- | gpg-wks-client: gpg: encrypted with 256-bit ECDH key, ID 3452DE414E[...] | gpg-wks-client: gpg: "dewey at test.gnupg.org" | gpg-wks-client: new 'application/vnd.gnupg.wks' message part | gpg-wks-client: gpg: automatically retrieved 'key-submission at test.g[...] `---- and has send the confirmation mail back to the provider. Over there the confirmation mail is matched to the pending key database and the key is then published. To check that the key has been published, use this: ,---- | $ gpg -v --auto-key-locate=clear,wkd,local --locate-key dewey at test.gnupg.org `---- you should see: ,---- | gpg: pub ed25519/D19D22B06EE78668 2016-06-28 dewey at test.gnupg.org | gpg: key D19D22B06EE78668: "dewey at test.gnupg.org" not changed | gpg: Total number processed: 1 | gpg: unchanged: 1 | gpg: auto-key-locate found fingerprint 64944BC035493D929EF2A2B9D19D22B06EE78668 | gpg: automatically retrieved 'dewey at test.gnupg.org' via WKD | pub ed25519 2016-06-28 [SC] | 64944BC035493D929EF2A2B9D19D22B06EE78668 | uid [ultimate] dewey at test.gnupg.org | sub cv25519 2016-06-28 [E] | B3746B6927FF8021486561D83452DE414E0B5CCD `---- Despite that it tells you that the key did not change (well, you asked the provider to publish this key), it also tells that the key was found using the Web Key Directory (WKD). You may also use this lower level test: ,---- | $ gpg-connect-agent --dirmngr --hex 'wkd_get dewey at test.gnupg.org' /bye `---- which results in a hex listing of the key [KMail] https://userbase.kde.org/KMail [Mutt] http://www.mutt.org 1.6 Future work ~~~~~~~~~~~~~~~ The tools are not yet finished and improvements can be expected over the next few GnuPG releases. For example the server should send a final mail back to announce that the key has been published. We are also considering slight changes to the protocol but the general procedure on how to drive the tools is unlikely to change. We still need to add manual pages to describe the server and client tools. For now `--help' and the [gnupg-devel] mailing list are your best friends. For those who want to integrate support for the Web Key Service into a MUA but do not want to fiddle with the server side of things, we are happy to provide mail addresses for testing. [gnupg-devel] https://lists.gnupg.org/mailman/listinfo/gnupg-devel -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From 3pfwunbu7j at snkmail.com Tue Aug 30 18:04:38 2016 From: 3pfwunbu7j at snkmail.com (John Hein) Date: Tue, 30 Aug 2016 10:04:38 -0600 Subject: Key Discovery Made Simple In-Reply-To: <874m625njg.fsf@wheatstone.g10code.de> References: <874m625njg.fsf@wheatstone.g10code.de> Message-ID: <12185-1472573142-158545@sneakemail.com> Werner Koch wrote at 16:39 +0200 on Aug 30, 2016: > Hi, > > I just published a writeup on how to setup the Web Key Service at > https://gnupg.org/blog/20160830-web-key-service.html > > A plain text copy is below. If you have comments, please send them as > reply. Nice writeup. Maybe add some _brief_ words about trust. We understand how keyservers can provide an "invalid" key. This is a tad bit more elaborate, but could still be abused. The thing about trust for the laymen is that it'd be nice if there was a short not overly technical presentation about how various methods can be compromised and how to be reasonably sure about safety. So that the user can decide about when and how they might want to do additional vetting. Someone could set up an https://wernerkoch.info with a bogus key, send out an email impersonating Werner and pointing to that web service, right? From rjh at sixdemonbag.org Tue Aug 30 20:12:15 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 30 Aug 2016 14:12:15 -0400 Subject: Key Discovery Made Simple In-Reply-To: <874m625njg.fsf@wheatstone.g10code.de> References: <874m625njg.fsf@wheatstone.g10code.de> Message-ID: <001e01d202ea$0a7a5d80$1f6f1880$@sixdemonbag.org> > A plain text copy is below. If you have comments, please send them as reply. I hate to be the one to rain on this parade, but this seems like a mistake. > GnuPG 2.1 provides an simple but efficient solution to store a key > under a well known URL and lookup it up via https. Most of our users don't run their own domains, don't have full authority over the mail server, and don't have webservers that can deliver static pages over TLS. A solution that depends on this trifecta of capabilities should not be called "simple". Just getting TLS running on a webserver can be a frustrating ordeal. IMO, GnuPG development should be guided by a concern for regular users, not power users. I'd like it if we could aim new features at regular users. From kloecker at kde.org Tue Aug 30 21:02:40 2016 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 30 Aug 2016 21:02:40 +0200 Subject: Key Discovery Made Simple In-Reply-To: <001e01d202ea$0a7a5d80$1f6f1880$@sixdemonbag.org> References: <874m625njg.fsf@wheatstone.g10code.de> <001e01d202ea$0a7a5d80$1f6f1880$@sixdemonbag.org> Message-ID: <1686962.DZCKTMMN1v@collossus.ingo-kloecker.de> On Tuesday 30 August 2016 14:12:15 Robert J. Hansen wrote: > > A plain text copy is below. If you have comments, please send them as > > reply. > I hate to be the one to rain on this parade, but this seems like a mistake. > > > GnuPG 2.1 provides an simple but efficient solution to store a key > > under a well known URL and lookup it up via https. > > Most of our users don't run their own domains, don't have full authority > over the mail server, and don't have webservers that can deliver static > pages over TLS. A solution that depends on this trifecta of capabilities > should not be called "simple". Just getting TLS running on a webserver can > be a frustrating ordeal. > > IMO, GnuPG development should be guided by a concern for regular users, not > power users. I'd like it if we could aim new features at regular users. The web key discovery _is_ aimed at regular users. Werner's message suggest that KMail's development version does already support this new key discovery protocol which makes key discovery for users of KMail much easier. Moreover, apparently, KMail also supports publishing the user's key this way. I'm sure enigmail will soon also support WKS. Devil's advocate: "Regular users don't use Thunderbird+Enigmail, let alone KMail. Regular users either use webmail or a corporate email client like Outlook. WKS is of no use for them." Of course, setting up WKS for a domain is non-trivial and nothing regular users will do. But, hopefully, some email providers of those regular users will do it. I'm pretty sure that sane email providers like posteo.de, etc. will implement it. Devil's advocate: "Regular users don't use email providers that are not gratis. They use gmail, gmx, yahoo, etc. And corporate users use the mail server of their corporation. WKS is of no use for them." Then again "regular users" don't care for encryption at all. "Regular users" use facebook and whatsapp and God knows what else. Ironically, users of whatsapp get end-to-end encryption even though they don't care. As long as email encryption is not as easy as with whatsapp and other chat apps that sport end-to-end encryption without requiring any additional user interaction whatsoever, email encryption will never be used by regular users. (Incidentally, I'm currently reading Greenwald's No Place to Hide. The first chapter clearly demonstrates that even regular users who know that they would better use encryption will not take the necessary steps unless they do not have to take any necessary steps in the first place.) Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From melvincarvalho at gmail.com Tue Aug 30 18:10:24 2016 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Tue, 30 Aug 2016 18:10:24 +0200 Subject: Key Discovery Made Simple In-Reply-To: <874m625njg.fsf@wheatstone.g10code.de> References: <874m625njg.fsf@wheatstone.g10code.de> Message-ID: On 30 August 2016 at 16:39, Werner Koch wrote: > Hi, > > I just published a writeup on how to setup the Web Key Service at > https://gnupg.org/blog/20160830-web-key-service.html > > A plain text copy is below. If you have comments, please send them as > reply. > Just regarding the web server part, and not the email part. Could the semantic web be leveraged to store your key on an HTTPS page? I've been doing this for many years: https://melvincarvalho.com *Human Version=============* "Universal Public Key (GPG + WebID) Modulus: d798758afd0844f3668f88e728e735b34e94706dbcdc7ab85831402bb043a88508a7d7c4eb462dafd917e6d3058f59597c54739f830bbff9ff5d740c906ac480efe3e1c9d0a8e57de81a987a7fd0c1b68b4b4ca1e434aec07c4f43cd048a86e085d28f69b3e97c844d3aedb749c273639f0abfef3d5829fe85677b34364701132e4459b95acc334704f80c4de3e0e79f21acf282c401e73e7e577fbbc195a91132e215c411191bae3c67ed1c3d12934a9a8513bbe8aafc6e024701a1595b848c1fe5b5f6ac93891e339e3d181d48b3a57ae862b50096a40570dde7b3fa9f149a72f5bc7d5dc20099cd26015e20f7f3dc611b66f2c784997d993b9899c7afd25f Exponent: 65537 GPG Fingerprint: 5B8F 3CDF 0A25 BADE 4F29 190F 114E F7BC 9460 4583 GPG Hex ID: 15f3dd63505f3160 curl http://melvincarvalho.com/melvincarvalho.asc | gpg --import " *Machine version=============* http://melvincarvalho.com/#key1 ? rdf:type ? cert:RSAPublicKey ? cert:modulus ? "d798758afd0844f3668f88e728e735b34e94706dbcdc7ab85831402bb043a88508a7d7c4eb462dafd917e6d3058f59597c54739f830bbff9ff5d740c906ac480efe3e1c9d0a8e57de81a987a7fd0c1b68b4b4ca1e434aec07c4f43cd048a86e085d28f69b3e97c844d3aedb749c273639f0abfef3d5829fe85677b34364701132e4459b95acc334704f80c4de3e0e79f21acf282c401e73e7e577fbbc195a91132e215c411191bae3c67ed1c3d12934a9a8513bbe8aafc6e024701a1595b848c1fe5b5f6ac93891e339e3d181d48b3a57ae862b50096a40570dde7b3fa9f149a72f5bc7d5dc20099cd26015e20f7f3dc611b66f2c784997d993b9899c7afd25f"^^xsd:hexBinary ? cert:exponent ? "65537"^^xsd:integer ? wot:fingerprint ? "5B8F 3CDF 0A25 BADE 4F29??190F 114E F7BC 9460 4583" ? wot:hex_id ? "15f3dd63505f3160" ? wot:pubkeyAddress ? http://melvincarvalho.com/melvincarvalho.asc ? is cert:key of ? Melvin Carvalho ... ? foaf:mbox ? "mailto:melvincarvalho at gmail.com" There exist web standards to do this. Would it be helpful at all for this use case? > > Salam-Shalom, > > Werner > > ============================================ > Table of Contents > _________________ > > 1 Key Discovery Made Simple > .. 1.1 Install GnuPG 2.1 > .. 1.2 Prepare the mail and web servers > .. 1.3 Create submission key > .. 1.4 Install the WKS server tool > .. 1.5 Test your installation > .. 1.6 Future work > > > > 1 Key Discovery Made Simple > =========================== > > A major hassle with sending encrypted mails is to find the key > matching the recipients mail address. A na?ve method is to look for > the key at a keyserver. In most cases this works surprisingly well. > However, there is no guarantee that this key really matches the mail > address --- anyone can create a key and put an arbitrary mail address > there. It is quite disturbing to receive a mail which you can't > decrypt because it was encrypted to another key. > > GnuPG 2.1 provides an simple but efficient solution to store a key > under a well known URL and lookup it up via https. For practical > deployment of this method (as well as for OpenPGP DANE) a method to > publishing a key is required. The new [Web Key Service] protocol such > a protocol and GnuPG 2.1.15 comes with the tools to implement this. > Aside from GnuPG the other pre-requisites are: > > - A mail server for your domain with the full authority on the user > mail addresses for this domain. > > - A Unix system where you have an account to receive mails to a > dedicated mail address and to send mails via the sendmail tool. An > account on the mail server will be the best choice. > > - A web server for the same domain to deliver static pages over TLS. > Re-direction to a different server is possible > > - The ability to install the latest GnuPG version from source. > > Here is a first step by step description on how to install and test > that service. > > > [Web Key Service] > https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-01.html > > > 1.1 Install GnuPG 2.1 > ~~~~~~~~~~~~~~~~~~~~~ > > Your system will already have a gpg version but we want the very > latest one and we want to install it locally. > > First you should create a new account on the machine. Let's use > `webkey'. Nothing special is required; thus a simple > > ,---- > | # adduser --disabled-password webkey > `---- > > as root will do. Add an `.ssh/authorized_keys' file to make it easy > to access. Now download GnuPG (as of this writing version 2.1.15): > > ,---- > | $ cd ~webkey > | $ wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.15.tar.bz2 > | $ wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.15.tar.bz2.sig > | $ wget -O - https://gnupg.org/signature_key.html | gpg --import > | $ gpg --verify gnupg-2.1.15.tar.bz2.sig gnupg-2.1.15.tar.bz2 > `---- > > The last line uses the standard gpg to check that the integrity of the > tarball. Then please verify that the displayed fingerprints match the > desired ones; see [https://gnupg.org/download/integrity_check.html] > for more on this. > > The easiest way to install the latest GnuPG version is to use Speedo, > which downloads, verifies and builds all dependent packages. To do > this first unpack the tarball: > > ,---- > | $ tar xjf gnupg-2.1.5.tar.bz2 > `---- > > On non GNU system you may need to use this instead: > > ,---- > | $ zcat gnupg-2.1.5.tar.bz2 | tar xf - > `---- > > Then run: > > ,---- > | $ make -f ~/b-w32/speedo/gnupg-2.1.15/build-aux/speedo.mk \ > | > INSTALL_PREFIX=. speedo_pkg_gnupg_configure='--enable-gpg2-is-gpg \ > | > --disable-g13 --enable-wks-tools' native > `---- > > If you run into errors you are probably missing some development > tools; install them and try again. If all succeeds you will notice a > bunch of new directories below webkey's home directory: > > ,---- > | PLAY bin include lib libexec sbin share swdb.lst swdb.lst.sig > `---- > > Optionally you may delete what is not anymore required: > > ,---- > | $ rm -rf PLAY include lib swdb.* > `---- > > To make use of your new GnuPG installation you need to run this first > (you should add it to webkey's .profile or .bashrc): > > ,---- > | PATH="$HOME/bin:$PATH" > | LD_LIBRARY_PATH="$(pwd)/lib" > | export LD_LIBRARY_PATH > `---- > > > 1.2 Prepare the mail and web servers > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The Web Key Service requires a working directory to store keys pending > for publication. As root create a working directory: > > ,---- > | # mkdir /var/lib/gnupg/wks > | # chown webkey:webkey /var/lib/gnupg/wks > | # chmod 2750 /var/lib/gnupg/wks > `---- > > Then under your webkey account create directories for all your > domains. Here we do it for ?example.org?: > > ,---- > | $ mkdir /var/lib/gnupg/wks/example.org > `---- > > Then run > > ,---- > | $ gpg-wks-server --list-domains > `---- > > to create the required sub-directories with the permission set > correctly. In particular the `hu' directory (?hashed-userid?) to > store pending keys most only be accessible by the webkey user. > Running the above command will also remind you to create a file with > the submission address for the domain. Let?s do that: > > ,---- > | $ cd /var/lib/gnupg/wks/example.org > | $ echo key-submission at example.org >submission-address > `---- > > The submission address is the address the client uses to contact the > Web Key Service. To make this actually work, that address needs to be > redirected to the webkey user; use the alias file of your MTA to do > this. > > To setup the web server there are at least two ways: If the web server > is on the same machine it is possible to use symlinks to publish the > working directories. For example: > > ,---- > | $ cd /var/www/example.org/htdocs > | $ mkdir -p .well-known/openpgpkey > | $ cd .well-known/openpgpkey > | $ ln -s /var/lib/gnupg/wks/example.org/hu . > | $ ln -s /var/lib/gnupg/wks/example.org/submission-address . > `---- > > The more flexible way is the use of rsync optionally using an ssh > connection to a remote web server. This can be done with a cron job; > run `crontab -e' and add this line (the backslashes below are used to > indicate line wrapping here; do not enter them into the crontab but > use a single long line): > > ,---- > | */4 * * * * rsync -r -p --chmod=Fa+r --delete \ > | /var/lib/gnupg/wks/example/hu/ \ > | webserver:/var/www/all/example.org/.well-known/openpgpkey/hu/ > `---- > > This job syncs every 4 minutes the local copy of the published keys to > the server. The submission-address file does not change and thus it > is sufficient to copy it once by hand to the server. > > > 1.3 Create submission key > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > The protocol suggests that the key to be published is send with an > encrypted mail to the service. Thus you need to create a key for the > submission address: > > ,---- > | $ gpg --batch --passphrase '' --quick-gen-key > key-submission at example.org > | $ gpg --with-wkd-hash -K key-submission at example.org > `---- > > The output of the last command looks similar to this: > > ,---- > | sec rsa2048 2016-08-30 [SC] > | C0FCF8642D830C53246211400346653590B3795B > | uid [ultimate] key-submission at example.org > | bxzcxpxk8h87z1k7bzk86xn5aj47intu at example.org > | ssb rsa2048 2016-08-30 [E] > `---- > > Take the hash of the string ?key-submission?, which is > `bxzcxpxk8h87z1k7bzk86xn5aj47intu' and manually publish that key: > > ,---- > | $ gpg --export-options export-minimal --export > key-submission at example.org > | > -o /var/lib/gnupg/wks/example.org/hu/bxzcxpxk8h87z1k7bzk86xn5aj47in > tu > `---- > > Make sure that the created file is world readable. We will eventually > provide a tool to make that step easier. > > > 1.4 Install the WKS server tool > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The tool gpg-wks-server implements the server part of the web key > service protocol. There are several ways to install this tool, what I > describe here is a setup which allows easy debugging. > > First install procmail and make sure that your MTA (Exim, Postfix, > sendmail) can run procmail as delivery agent. In most cases it is > sufficient to create the file `.procmailrc' in the home directory > (e.g. `/home/webkey/.procmailrc'). Here is that file; you need to > replace ?example.org? by your own domain name: > > ,---- > | PATH=$HOME/bin:/usr/bin:/bin:/usr/local/bin > | LD_LIBRARY_PATH=$HOME/lib > | > | MAILDIR=$HOME/Mail > | LOGFILE=$HOME/Mail/from > | LOCKFILE=$HOME/Mail/.lockmail > | VERBOSE=yes > | > | :0 > | * ^FROM_DAEMON > | from-daemon/ > | > | :0 c > | archive/ > | > | :0 > | * !^From: webkey at example.org > | * !^X-WKS-Loop: webkey.example.org > | |$HOME/bin/gpg-wks-server -v --receive \ > | --header X-WKS-Loop=webkey.example.org \ > | --from webkey at example.org --send -o $HOME/send.log > | > | :0 > | cruft/ > `---- > > What it does: The first 6 lines set environment variables for use by > this tool and programs invoked. In particular the setting of `PATH' > and `LD_LIBRARY_PATH' is important so that gpg-wks-server can properly > work. > > The first rule (rules are started with a colon line) detects mails > sent from daemon processes. We don't want them and thus we save them > to the Maildir style folder `Mail/from-daemon' for later inspection. > For a production system it would be better to directly send those > mails to the bit bucket by replacing the last line of that rule with > `/dev/null'. > > The second rule stores a copy of all incoming mails to the folder > `Mail/archive'. This is useful for debugging and to view the flow of > mails. The 'c' after the ':0' means continue with the next rule after > having processed this rule (i.e. storing to the archive folder). By > the way, do not forget the trailing slash at folder names; without a > slash a plain mbox style would be written (you can use an mbox too, > but Maildir is considered a better way to store mails). > > The third rule is the heart of this procmail script (in procmail > parlance ?recipe?). The two lines starting with an asterisk give two > conditions on when this rule shall be skipped: If the mail comes from > us or if the mail has our loop detection mail header. The command run > on this mail is the wks server in a mode which uses the > /usr/lib/sendmail tool for sending responses to the mail. The output > of the tool is stored to the file `send.log' in the home directory; to > append to a log file use `-o -' and redirect to a log file. > > The final rule stores all not processed mails to the `cruft/' folder. > This can as well be replaced by =/dev/null=/ > > Finally add an entry to your crontab (run `crontab -e') to expire non > confirmed publication requests: At the top of your crontab add: > > ,---- > | PATH=/home/webkey/bin:/usr/local/bin:/usr/bin:/bin > | LD_LIBRARY_PATH=/home/webkey/lib > | > | 42 3 * * * gpg-wks-server --cron > `---- > > so that the server tool is run each night at, say, 3:42. > > > 1.5 Test your installation > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > > To test the Web Key Service, you can create some test accounts for > your domain and run the protocol. For a proper test, do not just use > a different account on the server but use client box. > > Developers of [KMail] should already be able to use its brand new > builtin support for the Web Key Service. > > Integration of the Web Key Service into the other mail clients has not > yet been done. Thus you need to run the test manually. In this > example we assume that on you own box a sendmail like tool is > installed and you also installed GnuPG 2.1 along with the client part > of Web Key Service (gpg-wks-client which may require that you pass > --enable-wks-tools to the configure run). > > An easy way of testing the system exists for [Mutt] users: By adding > the two lines > > ,---- > | application/vnd.gnupg.wks; /usr/local/bin/gpg-wks-client \ > | -v --read --send; needsterminal; description=WKS message > `---- > > to `/etc/mailcap' Mutt will do the decryption job and then call the > wks-client for the protocol handling. It can be expected that Mutt > users have a /usr/lib/sendmail installed which is required here. Note > that `--read' is used which tells the client that the input mail has > already been decrypted. > > For all others the protocol can be run by hand. Let?s assume, you > have the key > > ,---- > | sub cv25519 2016-07-15 [E] > | C444189BD549468C97992D7D3C79E8F960C69FCE > | pub ed25519 2016-06-28 [SC] > | 64944BC035493D929EF2A2B9D19D22B06EE78668 > | uid [ultimate] dewey at test.gnupg.org > | sub cv25519 2016-06-28 [E] > | B3746B6927FF8021486561D83452DE414E0B5CCD > `---- > > which in fact is a real key of our own test environment. To publish > that key you send the key to the mail provider: > > ,---- > | $ /usr/local/libexec/gpg-wks-client --create --send \ > | > 64944BC035493D929EF2A2B9D19D22B06EE78668 dewey at test.gnupg.org > `---- > > > As already mention, `--send' invokes `/usr/lib/sendmail' and sends out > the mail. If that option is not used, the mail is written to stdout > (or to the file given with `--output') and the user is responsible to > feed this to the mail system. If this all works a single message will > be show: > > ,---- > | gpg-wks-client: submitting request to 'key-submission at test.gnupg.org' > `---- > > Now, wait until you receive a mail back from your provider. In this > example that mail was received and stored in the file > `new/1472561079.6352_1.foobar'. We feed this file to the wks-client: > > ,---- > | $ /usr/local/libexec/gpg-wks-client --receive --send \ > | > < new/1472561079.6352_1.foobar > `---- > > which may respond like this: > > ,---- > | gpg-wks-client: gpg: encrypted with 256-bit ECDH key, ID > 3452DE414E[...] > | gpg-wks-client: gpg: "dewey at test.gnupg.org" > | gpg-wks-client: new 'application/vnd.gnupg.wks' message part > | gpg-wks-client: gpg: automatically retrieved 'key-submission at test.g > [...] > `---- > > and has send the confirmation mail back to the provider. Over there > the confirmation mail is matched to the pending key database and the > key is then published. > > To check that the key has been published, use this: > > ,---- > | $ gpg -v --auto-key-locate=clear,wkd,local --locate-key > dewey at test.gnupg.org > `---- > > you should see: > > ,---- > | gpg: pub ed25519/D19D22B06EE78668 2016-06-28 dewey at test.gnupg.org > | gpg: key D19D22B06EE78668: "dewey at test.gnupg.org" not changed > | gpg: Total number processed: 1 > | gpg: unchanged: 1 > | gpg: auto-key-locate found fingerprint 64944BC035493D929EF2A2B9D19D22 > B06EE78668 > | gpg: automatically retrieved 'dewey at test.gnupg.org' via WKD > | pub ed25519 2016-06-28 [SC] > | 64944BC035493D929EF2A2B9D19D22B06EE78668 > | uid [ultimate] dewey at test.gnupg.org > | sub cv25519 2016-06-28 [E] > | B3746B6927FF8021486561D83452DE414E0B5CCD > `---- > > Despite that it tells you that the key did not change (well, you asked > the provider to publish this key), it also tells that the key was > found using the Web Key Directory (WKD). > > You may also use this lower level test: > > ,---- > | $ gpg-connect-agent --dirmngr --hex 'wkd_get dewey at test.gnupg.org' > /bye > `---- > > which results in a hex listing of the key > > > [KMail] https://userbase.kde.org/KMail > > [Mutt] http://www.mutt.org > > > 1.6 Future work > ~~~~~~~~~~~~~~~ > > The tools are not yet finished and improvements can be expected over > the next few GnuPG releases. For example the server should send a > final mail back to announce that the key has been published. We are > also considering slight changes to the protocol but the general > procedure on how to drive the tools is unlikely to change. > > We still need to add manual pages to describe the server and client > tools. For now `--help' and the [gnupg-devel] mailing list are your > best friends. For those who want to integrate support for the Web Key > Service into a MUA but do not want to fiddle with the server side of > things, we are happy to provide mail addresses for testing. > > > [gnupg-devel] https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > /* Join us at OpenPGP.conf */ > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg at raf.org Wed Aug 31 01:47:46 2016 From: gnupg at raf.org (gnupg at raf.org) Date: Wed, 31 Aug 2016 09:47:46 +1000 Subject: Key Discovery Made Simple In-Reply-To: <874m625njg.fsf@wheatstone.g10code.de> References: <874m625njg.fsf@wheatstone.g10code.de> Message-ID: <20160830234746.GA20856@raf.org> Werner Koch wrote: > Hi, > > I just published a writeup on how to setup the Web Key Service at > https://gnupg.org/blog/20160830-web-key-service.html > > A plain text copy is below. If you have comments, please send them as > reply. > > > Salam-Shalom, > > Werner > > [snip] "most only be accessible" should be "must only be accessible". In the cronjob, "*/4" is invalid on systemd systems (or at least Debian8) and will cause the entire crontab to be ignored. Use "0-56/4" instead. "key to be published is send with" should be "key to be published is sent with". "on you own box" should be "on your own box". "sendmail like" should probably be "sendmail-like". "As already mention" should be "As already mentioned". "the user is responsible to feed" should be "the user is responsible for feeding". "will be show" should be "will be shown". "and has send the confirmation" should be "and has sent the confirmation". cheers, raf From mirimir at riseup.net Wed Aug 31 04:27:31 2016 From: mirimir at riseup.net (Mirimir) Date: Tue, 30 Aug 2016 20:27:31 -0600 Subject: Key Discovery Made Simple In-Reply-To: <12185-1472573142-158545@sneakemail.com> References: <874m625njg.fsf@wheatstone.g10code.de> <12185-1472573142-158545@sneakemail.com> Message-ID: <47ec0875-5cb9-927a-4fc1-02d841182aea@riseup.net> On 08/30/2016 10:04 AM, John Hein wrote: > Werner Koch wrote at 16:39 +0200 on Aug 30, 2016: > > Hi, > > > > I just published a writeup on how to setup the Web Key Service at > > https://gnupg.org/blog/20160830-web-key-service.html > > > > A plain text copy is below. If you have comments, please send them as > > reply. > > Nice writeup. > > Maybe add some _brief_ words about trust. We understand how > keyservers can provide an "invalid" key. This is a tad bit more > elaborate, but could still be abused. > > The thing about trust for the laymen is that it'd be nice if there was > a short not overly technical presentation about how various methods > can be compromised and how to be reasonably sure about safety. So > that the user can decide about when and how they might want to do > additional vetting. > > Someone could set up an https://wernerkoch.info with a bogus key, send > out an email impersonating Werner and pointing to that web service, > right? What are the defects in ? From wk at gnupg.org Wed Aug 31 09:05:33 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 09:05:33 +0200 Subject: Key Discovery Made Simple In-Reply-To: <20160830234746.GA20856@raf.org> (gnupg@raf.org's message of "Wed, 31 Aug 2016 09:47:46 +1000") References: <874m625njg.fsf@wheatstone.g10code.de> <20160830234746.GA20856@raf.org> Message-ID: <87k2ex1kqq.fsf@wheatstone.g10code.de> On Wed, 31 Aug 2016 01:47, gnupg at raf.org said: > In the cronjob, "*/4" is invalid on > systemd systems (or at least Debian8) > and will cause the entire crontab to > be ignored. Use "0-56/4" instead. man 5 crontab says: Steps are also permitted after an asterisk, so if you want to say ``every two hours'', just use ``*/2''. [Yet another systemd bug^Wimprovement.] Thanks for the grammar fixes. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Wed Aug 31 09:42:18 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 09:42:18 +0200 Subject: Key Discovery Made Simple In-Reply-To: <12185-1472573142-158545@sneakemail.com> (John Hein's message of "Tue, 30 Aug 2016 10:04:38 -0600") References: <874m625njg.fsf@wheatstone.g10code.de> <12185-1472573142-158545@sneakemail.com> Message-ID: <87fupl1j1h.fsf@wheatstone.g10code.de> On Tue, 30 Aug 2016 18:04, 3pfwunbu7j at snkmail.com said: > Maybe add some _brief_ words about trust. We understand how Well, I should have explained what I mean by Key Discovery: We do key discovery to get a key for a given mail address the first time we want to write to that address. At that point we don't have a relationship with the recipient and thus it doesn't matter whether we trust the key or the mail address. If we would have had a former in-person communication we also had a chance to exchange fingerprints. It is more important to assure that you are always talking to the same person/mail address after the first contact. This builds up trust to the mail address. This is the concept of trust-on-first-use (TOFU) which we are soon going to use as default trust model for GnuPG. Actually it will be a combination of TOFU and the Web-of-Trust (---trust-model=tofu+pgp). > Someone could set up an https://wernerkoch.info with a bogus key, send > out an email impersonating Werner and pointing to that web service, The key would not be bogus, unless it also has my mail address, which should be unique. Given that I sign my mails (granted, too rarely on MLs), a TOFU system can easily detect a conflict for those who are reading GnuPG mailing lists. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Aug 31 09:45:53 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 09:45:53 +0200 Subject: keybase.io (was: Key Discovery Made Simple) In-Reply-To: <47ec0875-5cb9-927a-4fc1-02d841182aea@riseup.net> (mirimir@riseup.net's message of "Tue, 30 Aug 2016 20:27:31 -0600") References: <874m625njg.fsf@wheatstone.g10code.de> <12185-1472573142-158545@sneakemail.com> <47ec0875-5cb9-927a-4fc1-02d841182aea@riseup.net> Message-ID: <87bn091ivi.fsf_-_@wheatstone.g10code.de> On Wed, 31 Aug 2016 04:27, mirimir at riseup.net said: > What are the defects in ? They not even try to minimize the use of meta data but use privacy invading services (Facebook, Twitter, etc) to connect the key into a way larger network than what we have with the Web of Trust. Kind of key signing party for the Twitter generation. I am not sure, but I heard that keybase.io is moving towards a centralized system for encrypted message exchange. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Wed Aug 31 09:55:46 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 09:55:46 +0200 Subject: Key Discovery Made Simple In-Reply-To: <001e01d202ea$0a7a5d80$1f6f1880$@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 30 Aug 2016 14:12:15 -0400") References: <874m625njg.fsf@wheatstone.g10code.de> <001e01d202ea$0a7a5d80$1f6f1880$@sixdemonbag.org> Message-ID: <877fax1if1.fsf@wheatstone.g10code.de> On Tue, 30 Aug 2016 20:12, rjh at sixdemonbag.org said: > Most of our users don't run their own domains, don't have full > authority over the mail server, and don't have webservers that can "Most of our users" are not the target audience for the description on how to setup the Web Key Service. Obviously this is for sysadmins and geeks running their own mail servers. Larger mail providers will probably have their own idea on whether and how to setup this service - for all their users. There will be a lot of lobbying necessary to convince the large providers to install this system. We can only get end to end encryption in mass use if we are able to solve the problem of getting the right key (initially). I hope that the more privacy aware providers will step forward to show the larger ones that it is possible to make encryption really easy. > IMO, GnuPG development should be guided by a concern for regular > users, not power users. I'd like it if we could aim new features at Right. The article should help early adopters to setup the system for experimentation and private use and to help us to make it well working. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From tehpeh-gnupg at tty1.net Wed Aug 31 10:31:31 2016 From: tehpeh-gnupg at tty1.net (Thomas Pircher) Date: Wed, 31 Aug 2016 09:31:31 +0100 Subject: Key Discovery Made Simple In-Reply-To: <874m625njg.fsf@wheatstone.g10code.de> References: <874m625njg.fsf@wheatstone.g10code.de> Message-ID: <44f5624b80f787e291bfc042a66fd600@wusel.tty1.net> On 2016-08-30 15:39, Werner Koch wrote: > .. 1.1 Install GnuPG 2.1 The option --with-wkd-hash is not implemented in gnupg 2.1.11 (on Debian testing). Maybe change this to "Install GnuPG 2.1.15 or later". > ,---- > | $ tar xjf gnupg-2.1.5.tar.bz2 > `---- change to "tar xjf gnupg-2.1.15.tar.bz2" > ,---- > | $ zcat gnupg-2.1.5.tar.bz2 | tar xf - > `---- idem. Thanks, Thomas From wk at gnupg.org Wed Aug 31 12:32:23 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 12:32:23 +0200 Subject: Key Discovery Made Simple In-Reply-To: (Melvin Carvalho's message of "Tue, 30 Aug 2016 18:10:24 +0200") References: <874m625njg.fsf@wheatstone.g10code.de> Message-ID: <87zintw7ns.fsf@wheatstone.g10code.de> On Tue, 30 Aug 2016 18:10, melvincarvalho at gmail.com said: > Just regarding the web server part, and not the email part. > > Could the semantic web be leveraged to store your key on an HTTPS page? No. The whole point is that there is an authoritativea mapping from mail address to key. You can't do that with an arbitrary web site. But see the description for the old PKA system how this can be done with a DNS entry. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Aug 31 12:42:19 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 12:42:19 +0200 Subject: Key Discovery Made Simple In-Reply-To: <1686962.DZCKTMMN1v@collossus.ingo-kloecker.de> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22's?= message of "Tue, 30 Aug 2016 21:02:40 +0200") References: <874m625njg.fsf@wheatstone.g10code.de> <001e01d202ea$0a7a5d80$1f6f1880$@sixdemonbag.org> <1686962.DZCKTMMN1v@collossus.ingo-kloecker.de> Message-ID: <87vayhw777.fsf@wheatstone.g10code.de> On Tue, 30 Aug 2016 21:02, kloecker at kde.org said: > The web key discovery _is_ aimed at regular users. Werner's message suggest > that KMail's development version does already support this new key discovery Actually this has been introduced with GnuPG 2.1.13 and you can make use of it by adding this option auto-key-locate local,wkd,dane to gpg.conf. This looks up missing keys using WKD and if it can't be found using the OpenPGP DANE method. Thus it works for all clients which invoke gpg with the mail address as recipient. However, most mailers first get a list of keys and then figure the keys out by themselves and pass the fingerprint. This is what needs to be changed. We will soon add appropriate support for this to GPGME. > protocol which makes key discovery for users of KMail much easier. Moreover, > apparently, KMail also supports publishing the user's key this way. I'm sure > enigmail will soon also support WKS. Devil's advocate: "Regular users don't Right, Andre implemented this but I am not 100% sure whether he already pushed that. > use Thunderbird+Enigmail, let alone KMail. Regular users either use webmail or > a corporate email client like Outlook. WKS is of no use for them." We will add this to GpgOL of course. So users could in theory make use of it. > Of course, setting up WKS for a domain is non-trivial and nothing regular > users will do. But, hopefully, some email providers of those regular users > will do it. I'm pretty sure that sane email providers like posteo.de, etc. I noticed that posteo.de (but only .de) supports WKD in addition to DANE. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From peter at digitalbrains.com Wed Aug 31 12:58:29 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 31 Aug 2016 12:58:29 +0200 Subject: Key Discovery Made Simple In-Reply-To: <874m625njg.fsf@wheatstone.g10code.de> References: <874m625njg.fsf@wheatstone.g10code.de> Message-ID: <578e51d0-c3a4-7b71-9326-7e55ddf1c9a6@digitalbrains.com> Well, as long as we are submitting minor corrections to the blog post, I wondered about the directory name in this command: > $ make -f ~/b-w32/speedo/gnupg-2.1.15/build-aux/speedo.mk \ > > INSTALL_PREFIX=. speedo_pkg_gnupg_configure='--enable-gpg2-is-gpg \ > > --disable-g13 --enable-wks-tools' native Specifically, the -f argument to make. It's clear you need to invoke this command and others in the home directory of the user (and not a subdirectory of the home directory). Perhaps it's better to put some emphasis on this aspect, and I think the command could then be: > $ make -f gnupg-2.1.15/build-aux/speedo.mk \ > > INSTALL_PREFIX=. speedo_pkg_gnupg_configure='--enable-gpg2-is-gpg \ > > --disable-g13 --enable-wks-tools' native HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Aug 31 12:44:06 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 31 Aug 2016 12:44:06 +0200 Subject: Key Discovery Made Simple In-Reply-To: <20160830234746.GA20856@raf.org> References: <874m625njg.fsf@wheatstone.g10code.de> <20160830234746.GA20856@raf.org> Message-ID: <688b1822-52e0-ef97-8e36-d76b546f7ee1@digitalbrains.com> On 31/08/16 01:47, gnupg at raf.org wrote: > In the cronjob, "*/4" is invalid on > systemd systems (or at least Debian8) In Debian 8, the default cron daemon seems to come from the package 'cron'. I don't think you get the 'systemd-cron' package by default: you need to explicitly install it, and uninstall the 'Prio: important' package 'cron'. Either way, I was unable to reproduce this. I installed systemd-cron, and it accepted my "*/4" happily (and did indeed run the command every four minutes). Though I no longer was able to edit my crontab as a regular user, I needed root to do it with "crontab -u peter". Do you have a Debian bug reference for this? I don't see it. The snippet Werner quoted from the man page is also in the man page from 'systemd-cron', by the way. I get the feeling systemd-cron is for supporting "legacy" stuff, and people who go all-out systemd will use systemd facilities such as timers to implement stuff "legacy people" ;-) do with crontabs. Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dimitrova at lec.mavt.ethz.ch Wed Aug 31 11:49:26 2016 From: dimitrova at lec.mavt.ethz.ch (Dimitrova Elena) Date: Wed, 31 Aug 2016 09:49:26 +0000 Subject: GPL license responsibility Message-ID: Dear GnuPG mailing list, I have just downloaded GnuPG and I intend to use it for signing private metadata files. The signing process will happen through calling: gpg --clearsign < ~/?./?./name_of_file.txt > name_of_file_signed.txt from the command window directly and the verification process will happen in a standalone script which will pipe the command: gpg --verify < name_of_file_signed.txt I will not alter any part of the source code. In this case what are my obligations under the GPL license? I would appreciate your response as I am new to using GnuPG and GPL licenced software. Regards, Elena -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Aug 31 13:14:11 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 13:14:11 +0200 Subject: Key Discovery Made Simple In-Reply-To: <44f5624b80f787e291bfc042a66fd600@wusel.tty1.net> (Thomas Pircher's message of "Wed, 31 Aug 2016 09:31:31 +0100") References: <874m625njg.fsf@wheatstone.g10code.de> <44f5624b80f787e291bfc042a66fd600@wusel.tty1.net> Message-ID: <87wpixur5o.fsf@wheatstone.g10code.de> On Wed, 31 Aug 2016 10:31, tehpeh-gnupg at tty1.net said: > The option --with-wkd-hash is not implemented in gnupg 2.1.11 (on > Debian testing). Maybe change this to "Install GnuPG 2.1.15 or later". Yeah, that was a typo. Gniibe already remarked that on Jabber and it has been fixed now. Thanks for telling. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Aug 31 13:11:38 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 13:11:38 +0200 Subject: GPL license responsibility In-Reply-To: (Dimitrova Elena's message of "Wed, 31 Aug 2016 09:49:26 +0000") References: Message-ID: <871t15w5ud.fsf@wheatstone.g10code.de> On Wed, 31 Aug 2016 11:49, dimitrova at lec.mavt.ethz.ch said: > I will not alter any part of the source code. In this case what are my obligations under the GPL license? As long as you only use the software, there are no restrictions. If you convey the software to others you have to make the source code available for them. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Wed Aug 31 13:15:34 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 13:15:34 +0200 Subject: Key Discovery Made Simple In-Reply-To: <578e51d0-c3a4-7b71-9326-7e55ddf1c9a6@digitalbrains.com> (Peter Lebbing's message of "Wed, 31 Aug 2016 12:58:29 +0200") References: <874m625njg.fsf@wheatstone.g10code.de> <578e51d0-c3a4-7b71-9326-7e55ddf1c9a6@digitalbrains.com> Message-ID: <87shtlur3d.fsf@wheatstone.g10code.de> On Wed, 31 Aug 2016 12:58, peter at digitalbrains.com said: > Specifically, the -f argument to make. It's clear you need to invoke this > command and others in the home directory of the user (and not a Oh yeah I copied it from my command line history ;-) Will fix it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From andrewg at andrewg.com Wed Aug 31 13:25:45 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 31 Aug 2016 12:25:45 +0100 Subject: GPL license responsibility In-Reply-To: References: Message-ID: On 31/08/16 10:49, Dimitrova Elena wrote: > > I will not alter any part of the source code. In this case what are my > obligations under the GPL license? In this case you have no obligations. Fly, and be free. ;-) The only time when the GPL becomes significant is when you are distributing modified code to other people or companies. In that instance, you usually(*) are required to make freely available any modifications you have made to that code. In this case you are neither distributing nor modifying the GnuPG code, so the GPL is not applicable. * If you don't change the source code, you don't have to do anything. * If you change the source code, but only use it yourself, you don't have to do anything. * If you use an LGPL library in your own code, but don't change the source code of the library itself, you don't have to do anything. A (*) Most of the complicated details of the GPL are concerned with pinning down the exact scope of "usually". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From fa-ml at ariis.it Wed Aug 31 13:07:26 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 31 Aug 2016 13:07:26 +0200 Subject: GPL license responsibility In-Reply-To: References: Message-ID: <20160831110726.GA11284@casa.casa> On Wed, Aug 31, 2016 at 09:49:26AM +0000, Dimitrova Elena wrote: > I will not alter any part of the source code. In this case what are > my obligations under the GPL license? Hello, GPL obligations happen when you *distribute* software. In this case you are not (re)distributing GPG or any derivative from it, so no restriction/obligation applies to you! -F From guanx.bac at gmail.com Wed Aug 31 13:09:32 2016 From: guanx.bac at gmail.com (Guan Xin) Date: Wed, 31 Aug 2016 13:09:32 +0200 Subject: GPL license responsibility In-Reply-To: References: Message-ID: On Wed, Aug 31, 2016 at 11:49 AM, Dimitrova Elena wrote: > Dear GnuPG mailing list, > > I have just downloaded GnuPG and I intend to use it for signing private > metadata files. The signing process will happen through calling: > > gpg --clearsign < ~/?./?./name_of_file.txt > name_of_file_signed.txt > Read: https://www.gnu.org/licenses/gpl-faq.en.html#WhatCaseIsOutputGPL Guan From rjh at sixdemonbag.org Wed Aug 31 15:32:30 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 31 Aug 2016 09:32:30 -0400 Subject: Key Discovery Made Simple In-Reply-To: <877fax1if1.fsf@wheatstone.g10code.de> References: <874m625njg.fsf@wheatstone.g10code.de> <001e01d202ea$0a7a5d80$1f6f1880$@sixdemonbag.org> <877fax1if1.fsf@wheatstone.g10code.de> Message-ID: <006101d2038c$20349f30$609ddd90$@sixdemonbag.org> > "Most of our users" are not the target audience for the description on how > to setup the Web Key Service. Obviously this is for sysadmins and geeks > running their own mail servers. I want to be careful about my criticism here, because it's really easy to sound like I'm telling someone else what they should have volunteered to work on for free instead. That annoys me when other people do it to me, and I want to be careful I'm not doing it to you. I'm having a hard time imagining why a mail provider would adopt WKD when probably less than 1% of their userbase uses OpenPGP in the first place. Sure, I can see it for the geek elite who run their own domains, mailservers, and webservers with TLS. I can imagine a couple of fringe players in the mail space might adopt it. But I can't imagine adoption beyond a small niche of the GnuPG community, which is *already* a really small niche. Carving out niches of niches does not strike me as a productive way to expand the userbase. The big players have already chimed in on OpenPGP. Last year there was talk from Google and Yahoo on the IETF WG list about how they were going to introduce OpenPGP support to their mail clients, but they've been conspicuously silent lately. I know Cistercians who make more noise. Does Gmail even have one project member subscribed to this list and following the conversations? From wk at gnupg.org Wed Aug 31 16:56:31 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 16:56:31 +0200 Subject: Key Discovery Made Simple In-Reply-To: <006101d2038c$20349f30$609ddd90$@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 31 Aug 2016 09:32:30 -0400") References: <874m625njg.fsf@wheatstone.g10code.de> <001e01d202ea$0a7a5d80$1f6f1880$@sixdemonbag.org> <877fax1if1.fsf@wheatstone.g10code.de> <006101d2038c$20349f30$609ddd90$@sixdemonbag.org> Message-ID: <87mvjtt2ao.fsf@wheatstone.g10code.de> On Wed, 31 Aug 2016 15:32, rjh at sixdemonbag.org said: > I'm having a hard time imagining why a mail provider would adopt WKD when > probably less than 1% of their userbase uses OpenPGP in the first place. In Germany they are proud of their Email Made in Germany label which is merely the use of TLS between MTAs. So things are moving a bit. The larges one, United Internet (e.g. gmx) deploy their own solution based on Mailvelope and recently announced their "validating" keyserver. These are all island solution for key discovery, though. This is what needs to be changed. > introduce OpenPGP support to their mail clients, but they've been > conspicuously silent lately. I know Cistercians who make more noise. Does > Gmail even have one project member subscribed to this list and following the Indeed this is very unfortunate. At least one of their main developer is still subscribed to the gnupg-devel list. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed Aug 31 19:05:44 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 31 Aug 2016 13:05:44 -0400 Subject: Key Discovery Made Simple In-Reply-To: <87mvjtt2ao.fsf@wheatstone.g10code.de> References: <874m625njg.fsf@wheatstone.g10code.de> <001e01d202ea$0a7a5d80$1f6f1880$@sixdemonbag.org> <877fax1if1.fsf@wheatstone.g10code.de> <006101d2038c$20349f30$609ddd90$@sixdemonbag.org> <87mvjtt2ao.fsf@wheatstone.g10code.de> Message-ID: <00ec01d203a9$ea057bf0$be1073d0$@sixdemonbag.org> > In Germany they are proud of their Email Made in Germany label which is > merely the use of TLS between MTAs. So things are moving a bit... I hope they accelerate their movement. :) I've never learned how to politely say, "all right, then I think this wraps up the conversation" without sounding rude. I promise, it's not my intent. I've spoken my thoughts on the matter, they've been heard and responded to, and I don't think anyone's entitled to more than that. Thanks for answering, even if we see this differently. I appreciate it, and all the work you do on GnuPG, an awful lot. From capella.devera at qlx.com Wed Aug 31 18:04:17 2016 From: capella.devera at qlx.com (Capella De Vera) Date: Wed, 31 Aug 2016 12:04:17 -0400 Subject: Decryption Key Compatibility between GNUPG V 2.030 and GnUPG 2.0.27 Message-ID: <413ed35d0d20c383b4bbc969253fa0ff@mail.gmail.com> Hi, We have GPG v 2.0.27 installed on our Windows X64 Development Server. In this server, we are able to successfully decrypt our gpg files using a private key imported through kleopatra. We have another Windows X64 Server (Our PROD Server) where we installed GPG 2.030. We imported the gpg keys from DEV server using kleopatra. When we try to decrypt a gpg file on this server, we get the ?decryption failed: No secret key? error. I checked the list of keys in both servers. Both servers have the same list of keys. Could this issue be due to the difference in GPG version between the 2 servers? Thanks and Best Regards, *Ella* This message is for the intended recipient only and may contain confidential and privileged information. If you are not the intended recipient, please return this message to the sender and delete this message and any attachments from your computer. The use, distribution, transmittal or re-transmittal by an unintended recipient of this communication is strictly prohibited without my expressed approval in writing or by e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Wed Aug 31 19:34:02 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 31 Aug 2016 13:34:02 -0400 Subject: Decryption Key Compatibility between GNUPG V 2.030 and GnUPG 2.0.27 In-Reply-To: <413ed35d0d20c383b4bbc969253fa0ff@mail.gmail.com> References: <413ed35d0d20c383b4bbc969253fa0ff@mail.gmail.com> Message-ID: <012b01d203ad$de07e2d0$9a17a870$@sixdemonbag.org> > Could this issue be due to the difference in GPG version between the 2 servers? Unlikely. It's much more likely that you only imported the public key on the Production box. On the Production box, try this: C:\> \path\to\gpg.exe --list-secret-keys If the key isn't listed there, then you forgot to import the private key. If that's the case, give a smile and move on -- it's a common mistake, and one pretty much everyone here has made at least once. :)