From wk at gnupg.org Fri Nov 4 15:04:27 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Nov 2016 15:04:27 +0100 Subject: gpgsm --verify back to back gpgsm --gen-key In-Reply-To: <1AF3736E-0199-4BD6-93A4-062F1A1C9517@adviser.com> (Meno Abels's message of "Tue, 18 Oct 2016 15:09:57 +0200") References: <1AF3736E-0199-4BD6-93A4-062F1A1C9517@adviser.com> Message-ID: <87pombwdck.fsf@wheatstone.g10code.de> On Tue, 18 Oct 2016 15:09, meno.abels at adviser.com said: > # gpgsm --batch --gen-key < gpgsm-keygen | gpgsm ?verify gpgsm create a certificate signing request (CSR) but "gpgsm --verify: verifies CMS signed data - these are entirely different things. The CSR must be given to a CA so that the CA can generate a certificate for you. With that certificate you can signed data (using "gpgsm --sign") which anyone can later verify with "gpgsm --verify" Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From antlists at youngman.org.uk Sat Nov 5 01:58:10 2016 From: antlists at youngman.org.uk (Wols Lists) Date: Sat, 5 Nov 2016 00:58:10 +0000 Subject: gpg is destroying my messages ... Message-ID: <581D2EA2.5060500@youngman.org.uk> (Note I'm not subscribed, please cc me on replies) Basically, I'm very frustrated that gpg is losing random emails of mine. The problem is I am NOT using it by default, but every now and then it will "grab" a message I send. I then can only access it by typing in my pass-phrase. (And, iirc, the menu bar displays and says DON'T sign, DON'T encrypt!!!) Why on earth - HOW on earth - is it encrypting messages without needing my key? And why is it doing it? I need gpg for the odd message, but it's a right royal pain when it does this as messages refuse to save in sent, and I can't access emails I've sent without a load of grief. I can't even find out how to strip this blasted encryption from my own messages so I can see them without problem! I'm using the gpg plug-in for thunderbird ... Cheers, Wol From gnupg-ml at seichter.de Mon Nov 7 13:28:08 2016 From: gnupg-ml at seichter.de (Ralph Seichter) Date: Mon, 7 Nov 2016 13:28:08 +0100 Subject: gpg is destroying my messages ... In-Reply-To: <581D2EA2.5060500@youngman.org.uk> References: <581D2EA2.5060500@youngman.org.uk> Message-ID: <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> > (Note I'm not subscribed, please cc me on replies) If you are not subscribed, how did you post on this mailing list? > Why on earth - HOW on earth - is it encrypting messages without > needing my key? GPG does not initiate encryption, your MUA (Thunderbird) does. Also, GPG does not require your own key, but the recipient's key for encryption. Unless you Bcc yourself or add a default encrypt-to-key in GPG settings, you won't even be able to read the encrypted message. > I'm using the gpg plug-in for thunderbird ... What is "the" plugin? Enigmail? In any case, check the plugin settings, GPG is not the root cause for your problems, the Thunderbird plugin calling GPG is. Change the plugin settings, or disable it. -Ralph P.S.: Please keep replies on-list. From dkg at fifthhorseman.net Mon Nov 7 17:54:41 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 07 Nov 2016 11:54:41 -0500 Subject: gpg is destroying my messages ... In-Reply-To: <581D2EA2.5060500@youngman.org.uk> References: <581D2EA2.5060500@youngman.org.uk> Message-ID: <8760nzw7qm.fsf@alice.fifthhorseman.net> On Fri 2016-11-04 20:58:10 -0400, Wols Lists wrote: > Basically, I'm very frustrated that gpg is losing random emails of mine. > The problem is I am NOT using it by default, but every now and then it > will "grab" a message I send. I then can only access it by typing in my > pass-phrase. (And, iirc, the menu bar displays and says DON'T sign, > DON'T encrypt!!!) > > Why on earth - HOW on earth - is it encrypting messages without needing > my key? And why is it doing it? I need gpg for the odd message, but it's > a right royal pain when it does this as messages refuse to save in sent, > and I can't access emails I've sent without a load of grief. > > I can't even find out how to strip this blasted encryption from my own > messages so I can see them without problem! > > I'm using the gpg plug-in for thunderbird ... You probably want to ask this question on the enigmail mailing list: Enigmail user discussion list Enigmail is responsible for integrating GnuPG with Thunderbird. Regards, --dkg From wk at gnupg.org Mon Nov 7 19:06:10 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Nov 2016 19:06:10 +0100 Subject: [admin] postings from non-subscribers (was: gpg is destroying my messages) In-Reply-To: <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> (Ralph Seichter's message of "Mon, 7 Nov 2016 13:28:08 +0100") References: <581D2EA2.5060500@youngman.org.uk> <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> Message-ID: <87d1i7np0t.fsf_-_@wheatstone.g10code.de> On Mon, 7 Nov 2016 13:28, gnupg-ml at seichter.de said: > If you are not subscribed, how did you post on this mailing list? That is easy. Our mailing list admins are moderating posts from non-subscribed posters. For many years they are doing this without getting much attention - time for a big KUDOS to them. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From gnupg-ml at seichter.de Mon Nov 7 21:47:13 2016 From: gnupg-ml at seichter.de (Ralph Seichter) Date: Mon, 7 Nov 2016 21:47:13 +0100 Subject: [admin] postings from non-subscribers In-Reply-To: <87d1i7np0t.fsf_-_@wheatstone.g10code.de> References: <581D2EA2.5060500@youngman.org.uk> <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> <87d1i7np0t.fsf_-_@wheatstone.g10code.de> Message-ID: <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> On 07.11.16 19:06, Werner Koch wrote: > Our mailing list admins are moderating posts from non-subscribed > posters. For many years they are doing this without getting much > attention - time for a big KUDOS to them. That's quite unusual. Thanks to the list admins for their work. Still, I personally (!) don't think there is any need to accommodate non- subscribers. The whole notion of "I want information but cannot be bothered to subscribe" rubs me the wrong way. -Ralph From gnupg-ml at seichter.de Mon Nov 7 22:22:41 2016 From: gnupg-ml at seichter.de (Ralph Seichter) Date: Mon, 7 Nov 2016 22:22:41 +0100 Subject: [admin] postings from non-subscribers In-Reply-To: References: <581D2EA2.5060500@youngman.org.uk> <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> <87d1i7np0t.fsf_-_@wheatstone.g10code.de> <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> Message-ID: On 07.11.16 21:59, Schlacta, Christ wrote: > What's annoying is when you're subscribed to a list and receiving > posts, but for some reason when you try to post, it says you're not > subscribed and getting moderated. Used the wrong address to post? Anyway, speaking of annoying things: top-posting and full quotes come to mind. :-) -Ralph From anthony at cajuntechie.org Mon Nov 7 22:32:16 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Mon, 7 Nov 2016 15:32:16 -0600 Subject: Question about using GnuPG on Windows 10 Message-ID: <9145795e-f92e-79a2-811a-e834b601beb1@cajuntechie.org> I know Windows 10 sends a lot of telemetry data back to Microsoft for analysis. The data sent to Microsoft, in some circumstances, also seems to be keystroke data to help make certain features of Windows 10 better. How does GnuPG play into this? Is there any evidence that GnuPG password entry is not part of the keystroke data sent to Microsoft? Does GnuPG take any steps to avoid this? Can it? Thanks, Anthony -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From gnupg-ml at seichter.de Mon Nov 7 23:06:24 2016 From: gnupg-ml at seichter.de (Ralph Seichter) Date: Mon, 7 Nov 2016 23:06:24 +0100 Subject: [admin] postings from non-subscribers In-Reply-To: References: <581D2EA2.5060500@youngman.org.uk> <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> <87d1i7np0t.fsf_-_@wheatstone.g10code.de> <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> Message-ID: <027737c1-e334-0a0f-a74a-745132cb1412@seichter.de> On 07.11.16 22:52, Schlacta, Christ wrote: > Top posting is easier for some, bottom posting for others. It is not about what is "easier for some", but I am not going to spend more time discussing Netiquette with you. We have been doing things in a certain way in mailing lists - since the 1980s - for good reasons. -Ralph From anthony at cajuntechie.org Mon Nov 7 22:19:41 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Mon, 7 Nov 2016 15:19:41 -0600 Subject: [admin] postings from non-subscribers In-Reply-To: <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> References: <581D2EA2.5060500@youngman.org.uk> <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> <87d1i7np0t.fsf_-_@wheatstone.g10code.de> <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> Message-ID: <478fe468-9249-7c2c-b419-95aec241bf05@cajuntechie.org> On 11/7/2016 2:47 PM, Ralph Seichter wrote: > On 07.11.16 19:06, Werner Koch wrote: > >> Our mailing list admins are moderating posts from non-subscribed >> posters. For many years they are doing this without getting much >> attention - time for a big KUDOS to them. > > That's quite unusual. Thanks to the list admins for their work. Still, > I personally (!) don't think there is any need to accommodate non- > subscribers. The whole notion of "I want information but cannot be > bothered to subscribe" rubs me the wrong way. I tend to feel the same way. I've never understood that mentality. I mean, it literally takes less than a minute to subscribe then less than another to unsubscribe. You really want information but it's not worth two-minutes of your time to get it? Must not be really important to you then. Still, their willingness to moderate non-subscribers shows how much our moderators rock. Most mailing list I belong to would never do this. This sets our mods apart! Great job guys. Anthony From piotr at chmielnicki.com Mon Nov 7 20:59:33 2016 From: piotr at chmielnicki.com (Piotr Chmielnicki) Date: Mon, 7 Nov 2016 20:59:33 +0100 Subject: Defense strategy against basic DoS on key servers Message-ID: <597c81d9-0327-b0ea-72c0-3f06463d2154@chmielnicki.com> Hello, The pool of key servers looks like a central element of the OpenPGP global WoT and key synchronization across people. I wonder what is the defense strategy of this pool against 2 very basic DoS attacks. The first attack would be to just upload several To of keys to fulfill the available storage of these servers. The second attack scenario would target a specific key by attaching to it a huge number of signatures that would make it very hard for anyone to download or refresh the targeted key. Thank for helping me to understand how those scenarios are managed. Piotr Chmielnicki @piotrcki From aarcane at aarcane.org Mon Nov 7 21:59:16 2016 From: aarcane at aarcane.org (Schlacta, Christ) Date: Mon, 7 Nov 2016 12:59:16 -0800 Subject: [admin] postings from non-subscribers In-Reply-To: <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> References: <581D2EA2.5060500@youngman.org.uk> <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> <87d1i7np0t.fsf_-_@wheatstone.g10code.de> <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> Message-ID: What's annoying is when you're subscribed to a list and receiving posts, but for some reason when you try to post, it says you're not subscribed and getting moderated. I've had that happen, but I don't think it's happened here yet. On Nov 7, 2016 12:48 PM, "Ralph Seichter" wrote: > On 07.11.16 19:06, Werner Koch wrote: > > > Our mailing list admins are moderating posts from non-subscribed > > posters. For many years they are doing this without getting much > > attention - time for a big KUDOS to them. > > That's quite unusual. Thanks to the list admins for their work. Still, > I personally (!) don't think there is any need to accommodate non- > subscribers. The whole notion of "I want information but cannot be > bothered to subscribe" rubs me the wrong way. > > -Ralph > > _______________________________________________ > 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 aarcane at aarcane.org Mon Nov 7 22:52:45 2016 From: aarcane at aarcane.org (Schlacta, Christ) Date: Mon, 7 Nov 2016 13:52:45 -0800 Subject: [admin] postings from non-subscribers In-Reply-To: References: <581D2EA2.5060500@youngman.org.uk> <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> <87d1i7np0t.fsf_-_@wheatstone.g10code.de> <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> Message-ID: Top posting is easier for some, bottom posting for others. Also, a sane mda will show all new messages at the bottom, meaning you see the previous messages above the current message. Leaving the full quote in for those who aren't using a sane mda to be able to read through and find previous messages, indented to show threading, is a matter of courtesy. The only time inline responses make any sense at all is when there are multiple separate points to respond to, and the only time a bottom post makes sense is when you want your recipients to have to scroll through the previous context *twice*, and get annoyed. On Nov 7, 2016 1:24 PM, "Ralph Seichter" wrote: > On 07.11.16 21:59, Schlacta, Christ wrote: > > > What's annoying is when you're subscribed to a list and receiving > > posts, but for some reason when you try to post, it says you're not > > subscribed and getting moderated. > > Used the wrong address to post? Anyway, speaking of annoying things: > top-posting and full quotes come to mind. :-) > > -Ralph > > > _______________________________________________ > 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 rjh at sixdemonbag.org Tue Nov 8 01:49:31 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 7 Nov 2016 19:49:31 -0500 Subject: [admin] postings from non-subscribers In-Reply-To: References: <581D2EA2.5060500@youngman.org.uk> <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> <87d1i7np0t.fsf_-_@wheatstone.g10code.de> <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> Message-ID: > The only time inline responses make any sense at all is when there are > multiple separate points to respond to... Or when the list owners have specifically requested it be done, as is the case here. http://www.gossamer-threads.com/lists/gnupg/users/75846 (Although my comment is first in that thread, I'm not the list owner. wk chimes in a few comments into the thread: his opinion is the authoritative one.) From maorlando at gmail.com Tue Nov 8 06:01:40 2016 From: maorlando at gmail.com (Matthew Orlando) Date: Mon, 7 Nov 2016 21:01:40 -0800 Subject: [admin] postings from non-subscribers In-Reply-To: <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> References: <581D2EA2.5060500@youngman.org.uk> <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> <87d1i7np0t.fsf_-_@wheatstone.g10code.de> <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> Message-ID: <74de0d57-7a24-4e37-59b3-ed23ad3d62b2@gmail.com> The flip side is someone who wants a quick answer to a limited issue but otherwise has no interest in participating in (or using email rules to filter out) every single conversation on a given topic. Personally, I clicked one of the reply-to addresses in the archive from a google search, wrote a message, got a notice that it was being moderated, and then decided to sign up. If I had been told my message was rejected because I wasn't a subscriber, I might not have bothered going any further. Barriers to entry should be reduced not reinforced imo. More kudos to the admins! - Cog On 11/7/2016 12:47 PM, Ralph Seichter wrote: > On 07.11.16 19:06, Werner Koch wrote: > >> Our mailing list admins are moderating posts from non-subscribed >> posters. For many years they are doing this without getting much >> attention - time for a big KUDOS to them. > That's quite unusual. Thanks to the list admins for their work. Still, > I personally (!) don't think there is any need to accommodate non- > subscribers. The whole notion of "I want information but cannot be > bothered to subscribe" rubs me the wrong way. > > -Ralph > > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From alec at alec.pl Tue Nov 8 08:39:42 2016 From: alec at alec.pl (A.L.E.C) Date: Tue, 8 Nov 2016 08:39:42 +0100 Subject: User ID format Message-ID: When to use quotes in user identifiers if at all? According to RFC4880 and RFC2822 quotes should be used in some cases, but it looks that gpg does not use them when expected. https://github.com/mailvelope/mailvelope/issues/448 -- Aleksander 'A.L.E.C' Machniak Kolab Groupware Developer [http://kolab.org] Roundcube Webmail Developer [http://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com From ineiev at gnu.org Tue Nov 8 12:01:34 2016 From: ineiev at gnu.org (Ineiev) Date: Tue, 8 Nov 2016 06:01:34 -0500 Subject: [admin] postings from non-subscribers In-Reply-To: <478fe468-9249-7c2c-b419-95aec241bf05@cajuntechie.org> References: <581D2EA2.5060500@youngman.org.uk> <2428de8c-cf17-9c22-2fce-1928e0e60ea1@seichter.de> <87d1i7np0t.fsf_-_@wheatstone.g10code.de> <69206870-b9ad-3679-c496-b427e3d60334@seichter.de> <478fe468-9249-7c2c-b419-95aec241bf05@cajuntechie.org> Message-ID: <20161108110134.GB10490@gnu.org> On Mon, Nov 07, 2016 at 03:19:41PM -0600, Anthony Papillion wrote: > > Most mailing list I belong to would never do this. Just for the record: English-speaking Savannah mailing lists do this unless the owners explicitly request otherwise. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Nov 8 17:02:45 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Nov 2016 17:02:45 +0100 Subject: User ID format In-Reply-To: (A. L. E. C.'s message of "Tue, 8 Nov 2016 08:39:42 +0100") References: Message-ID: <8737j2m02i.fsf@wheatstone.g10code.de> On Tue, 8 Nov 2016 08:39, alec at alec.pl said: > According to RFC4880 and RFC2822 quotes should be used in some cases, By convention, it [the OpenPGP user id packet] includes an RFC 2822 mail name-addr, but there are no restrictions on its content. thus you should not assume that the same rules apply. In fact OpenPGP requires UTF-8 which is not allowed by RFC-5322. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From gnupg at tim.thechases.com Tue Nov 8 20:24:05 2016 From: gnupg at tim.thechases.com (Tim Chase) Date: Tue, 8 Nov 2016 13:24:05 -0600 Subject: Specifying different pinentry based on caller? Message-ID: <20161108132405.2596836d@bigbox.christie.dr> Is there a way to specify which pinentry program should be used based on the calling context? When using a GUI program like Claws Mail, I'd like to use the graphical pinentry, but I'd prefer to default to the terminal pinentry for everything else. Poking around, I've found ways of changing this globally, but am unsure how to go about specifying it on a per-application basis. I imagine that it would take some combined effort between gpg (to allow the pinentry program to be specified via the command-line or environment) and the calling program (to specify arguments). Any tips to get me headed in the right direction would be appreciated. Thanks, -tkc From peter at digitalbrains.com Wed Nov 9 12:14:30 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 9 Nov 2016 12:14:30 +0100 Subject: Specifying different pinentry based on caller? In-Reply-To: <20161108132405.2596836d@bigbox.christie.dr> References: <20161108132405.2596836d@bigbox.christie.dr> Message-ID: <30f125f3-ff0b-6675-43bc-71719c17658e@digitalbrains.com> On 08/11/16 20:24, Tim Chase wrote: > When using a GUI program like Claws Mail, I'd > like to use the graphical pinentry, but I'd prefer to default to the > terminal pinentry for everything else. One step in the right direction is unsetting the DISPLAY environment variable when gpg is invoked. Ensuring that gpg never gets to see a usable DISPLAY var might be all that is needed (or it might not, depending on Desktop Environment, I don't know :-). It works for me on a terminal just invoking: $ DISPLAY= gpg2 -s test.txt (Actually, that's not unsetting it, just setting it to an empty value. But it works.) 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 theodoros.n at gmail.com Wed Nov 9 11:14:30 2016 From: theodoros.n at gmail.com (Theodoros) Date: Wed, 9 Nov 2016 12:14:30 +0200 Subject: Question about using GnuPG on Windows 10 In-Reply-To: <9145795e-f92e-79a2-811a-e834b601beb1@cajuntechie.org> References: <9145795e-f92e-79a2-811a-e834b601beb1@cajuntechie.org> Message-ID: I believe telemetry can be disabled. It all comes down to trusting the host OS at the end (...) On 7 November 2016 at 23:32, Anthony Papillion wrote: > I know Windows 10 sends a lot of telemetry data back to Microsoft for > analysis. The data sent to Microsoft, in some circumstances, also seems > to be keystroke data to help make certain features of Windows 10 better. > How does GnuPG play into this? > > Is there any evidence that GnuPG password entry is not part of the > keystroke data sent to Microsoft? Does GnuPG take any steps to avoid > this? Can it? > > Thanks, > Anthony > > > _______________________________________________ > 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 mike at mdsresource.net Wed Nov 9 17:16:09 2016 From: mike at mdsresource.net (Mike Schleif) Date: Wed, 9 Nov 2016 10:16:09 -0600 Subject: PCI DSS compliance Message-ID: During our current annual PCI DSS audit, our auditor complains that a human being can access the company's private key and, thus, a human being can decrypt sales files containing credit card information. All production processes are fully automated and run as non-privileged user. We use GPG encryption for all file exchanges between this company and banks, and between vendors/clients and this company. The latter is the issue. What can be done about this? Please, advise. Thank you. ~ Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Nov 9 17:44:24 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 09 Nov 2016 10:44:24 -0600 Subject: Specifying different pinentry based on caller? In-Reply-To: <30f125f3-ff0b-6675-43bc-71719c17658e@digitalbrains.com> References: <20161108132405.2596836d@bigbox.christie.dr> <30f125f3-ff0b-6675-43bc-71719c17658e@digitalbrains.com> Message-ID: <87lgwseh7b.fsf@alice.fifthhorseman.net> On Wed 2016-11-09 05:14:30 -0600, Peter Lebbing wrote: > On 08/11/16 20:24, Tim Chase wrote: >> When using a GUI program like Claws Mail, I'd >> like to use the graphical pinentry, but I'd prefer to default to the >> terminal pinentry for everything else. > > One step in the right direction is unsetting the DISPLAY environment > variable when gpg is invoked. Ensuring that gpg never gets to see a > usable DISPLAY var might be all that is needed (or it might not, > depending on Desktop Environment, I don't know :-). > > It works for me on a terminal just invoking: > > $ DISPLAY= gpg2 -s test.txt > > (Actually, that's not unsetting it, just setting it to an empty value. > But it works.) fwiw, this is taking advantage of the "curses fallback" in whatever pinentry you're using -- it is not using a different pinentry. But in general, i think it's better to let the agent do its thing independent of gpg. why do you want a terminal-based pinentry in other contexts? secret key isolation is one of the big advantages of the 2.1.x gpg-agent, and trying to mix the agent's interactions with the process that's using the agent makes that isolation less effective. If you really want to do this, though, i note that unsetting DISPLAY won't work for all graphical pientry programs. In particular, the development branch of pinentry-gnome3 (and the versions in debian testing and unstable) use d-bus to talk to the GNOME system prompter, and don't interact directly with the X11 session. I don't know what pinentry you're using, but if your goal is to force the curses-fallback, you might want to also explicitly point DBUS_SESSION_BUS_ADDRESS at something that isn't a dbus socket; this will cause anything that tries to talk to d-bus to fail, which should result in a curses fallback. At the same time, you also need to ensure that GPG_TTY is explicitly set, otherwise the curses fallback will fail if the tool that ultimately invokes gpg has no access to a tty directly (or if you invoke gpg with stdin and stdout bound to non-pty pipes). So i think you want: DISPLAY= DBUS_SESSION_BUS_ADDRESS=/dev/null GPG_TTY=$(tty) gpg2 [?] If you know that gpg is going to be in a position to prompt the user directly, and you're running 2.1.15 or later, you can also try adding the --pinentry-mode=loopback argument to your gpg command. But again, i recommend *not* trying to do this. let the agent be effectively isolated! Hope this helps, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From mike at mdsresource.net Wed Nov 9 16:08:56 2016 From: mike at mdsresource.net (Mike Schleif) Date: Wed, 9 Nov 2016 09:08:56 -0600 Subject: PCI DSS compliance Message-ID: During our current annual PCI DSS audit, our auditor complains that a human being can access the company's private key and, thus, a human being can decrypt sales files containing credit card information. All production processes are fully automated and run as non-privileged user. We use GPG encryption for all file exchanges between this company and banks, and between vendors/clients and this company. The latter is the issue. What can be done about this? Please, advise. Thank you. ~ Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From cross at appsecconsulting.com Wed Nov 9 20:12:31 2016 From: cross at appsecconsulting.com (Chip Ross) Date: Wed, 9 Nov 2016 13:12:31 -0600 Subject: GPG and PCI requirement 3.6.6 Message-ID: <004101d23abd$384e9630$a8ebc290$@appsecconsulting.com> Does anyone have any suggestions on how to handle split knowledge and dual control for PCI 3.6.6, using GPG? Here is the PCI requirement and guidance: PCI DSS Requirements Testing Procedures Guidance 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control. Note: Examples of manual key-management operations include, but are not limited to: key generation, transmission, loading, storage and destruction. 3.6.6.a Verify that manual clear-text key-management procedures specify processes for the use of the following: ? Split knowledge of keys, such that key components are under the control of at least two people who only have knowledge of their own key components; AND ? Dual control of keys, such that at least two people are required to perform any key-management operations and no one person has access to the authentication materials (for example, passwords or keys) of another. Split knowledge and dual control of keys are used to eliminate the possibility of one person having access to the whole key. This control is applicable for manual key-management operations, or where key management is not implemented by the encryption product. Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of the original cryptographic key. Dual control requires two or more people to perform a function, and no single person can access or use the authentication materials of another. 3.6.6 b Interview personnel and/or observe processes to verify that manual clear-text keys are managed with: ? Split knowledge, AND ? Dual control Any help is appreciated. Thanks. _chip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5048 bytes Desc: not available URL: From farhanible at gmail.com Wed Nov 9 21:54:28 2016 From: farhanible at gmail.com (F Rafi) Date: Wed, 9 Nov 2016 15:54:28 -0500 Subject: PCI DSS compliance In-Reply-To: References: Message-ID: Probably out-of-scope for this list but, if the process is automated you'd want to reduce the number of people with access to the keys to only staff with need-to-know. Usually that translates to IT support / administrators. Beyond that safeguards against people (specifically administrators) cannot be technical controls. They have to be policies, procedures, and monitoring/audit. You should demonstrate that: - You are doing background checks against employees with access to the keys - Those background checks look at issues like debt - You have security policies and procedures that dictate use of well-known security best practices - You have a security awareness program that ensures that employees are reminded of best practices - You keep a log of whoever is logging into the system to access the key You just have to trust your employees at some point. None of this mitigates a rogue insider with access to the keys. -Farhan On Wed, Nov 9, 2016 at 11:16 AM, Mike Schleif wrote: > During our current annual PCI DSS audit, our auditor complains that a > human being can access the company's private key and, thus, a human being > can decrypt sales files containing credit card information. > > All production processes are fully automated and run as non-privileged > user. > > We use GPG encryption for all file exchanges between this company and > banks, and between vendors/clients and this company. The latter is the > issue. > > What can be done about this? > > Please, advise. Thank you. > > ~ Mike > > > > > _______________________________________________ > 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 mike at mdsresource.net Thu Nov 10 15:13:49 2016 From: mike at mdsresource.net (Mike Schleif) Date: Thu, 10 Nov 2016 08:13:49 -0600 Subject: PCI DSS compliance In-Reply-To: References: Message-ID: Yes, our company has been doing all four of your suggestions for years, including written policies and procedures, and we passed all prior years of PCI DSS auditing without incident. Near as I can tell, nothing has changed in this regard in PCI DSS standards in the last twelve months, to which our auditor agrees. You can find his non-member post here: https://lists.gnupg.org/pipermail/gnupg-users/2016-November/057009.html He says that PGP has some mechanism that satisfies this requirement. I haven't touched PGP in more than four years. Do they have something new? ~ Mike On Wed, Nov 9, 2016 at 2:54 PM, F Rafi wrote: > Probably out-of-scope for this list but, if the process is automated you'd > want to reduce the number of people with access to the keys to only staff > with need-to-know. Usually that translates to IT support / administrators. > Beyond that safeguards against people (specifically administrators) cannot > be technical controls. They have to be policies, procedures, and > monitoring/audit. You should demonstrate that: > > - You are doing background checks against employees with access to the > keys > - Those background checks look at issues like debt > - You have security policies and procedures that dictate use of > well-known security best practices > - You have a security awareness program that ensures that employees > are reminded of best practices > - You keep a log of whoever is logging into the system to access the > key > > You just have to trust your employees at some point. None of this > mitigates a rogue insider with access to the keys. > > -Farhan > > > On Wed, Nov 9, 2016 at 11:16 AM, Mike Schleif > wrote: > >> During our current annual PCI DSS audit, our auditor complains that a >> human being can access the company's private key and, thus, a human being >> can decrypt sales files containing credit card information. >> >> All production processes are fully automated and run as non-privileged >> user. >> >> We use GPG encryption for all file exchanges between this company and >> banks, and between vendors/clients and this company. The latter is the >> issue. >> >> What can be done about this? >> >> Please, advise. Thank you. >> >> ~ Mike >> >> >> >> >> _______________________________________________ >> 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 mwood at IUPUI.Edu Thu Nov 10 15:27:43 2016 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 10 Nov 2016 09:27:43 -0500 Subject: PCI DSS compliance In-Reply-To: References: Message-ID: <20161110142743.GA8975@IUPUI.Edu> I would be interested to hear this auditor's explanation of how *any* completely automated software system can protect private keys from a human with access to the system. -- 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: 163 bytes Desc: not available URL: From gpg at mdsresource.net Thu Nov 10 15:50:42 2016 From: gpg at mdsresource.net (helices) Date: Thu, 10 Nov 2016 08:50:42 -0600 Subject: PCI DSS compliance In-Reply-To: <20161110142743.GA8975@IUPUI.Edu> References: <20161110142743.GA8975@IUPUI.Edu> Message-ID: So would I! At this point, our company must achieve PCI DSS compliance before year end, and the road to that necessity leads through this auditor, who insists that PGP satisfies all requirements. There is no explanation that he shares with us. ~ Mike On Thu, Nov 10, 2016 at 8:27 AM, Mark H. Wood wrote: > I would be interested to hear this auditor's explanation of how *any* > completely automated software system can protect private keys from a > human with access to the system. > > -- > 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 > > _______________________________________________ > 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 kristian.fiskerstrand at sumptuouscapital.com Thu Nov 10 16:07:10 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 10 Nov 2016 16:07:10 +0100 Subject: PCI DSS compliance In-Reply-To: References: <20161110142743.GA8975@IUPUI.Edu> Message-ID: On 11/10/2016 03:50 PM, helices wrote: > So would I! > > At this point, our company must achieve PCI DSS compliance before year end, > and the road to that necessity leads through this auditor, who insists that > PGP satisfies all requirements. > > There is no explanation that he shares with us. I'd expect it being reference to shamir secret sharing scheme that I believe formed part of PGP at some point, but haven't really looked into PGP for a while. This would allow e.g split key in 5 parts and require 2 or 3 at the same time to access it. For the automated system, presumably would require two administrators to set it up, and expectation that nobody willfully modify the application or read the full private key in memory for the regular operation, but at that point would hinder any one admin to have access to the full key to use outside of the system. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Aut disce aut discede Either learn or leave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From gpg at mdsresource.net Thu Nov 10 16:24:29 2016 From: gpg at mdsresource.net (helices) Date: Thu, 10 Nov 2016 09:24:29 -0600 Subject: PCI DSS compliance In-Reply-To: References: <20161110142743.GA8975@IUPUI.Edu> Message-ID: O, yes! I forgot about that :-( I understand SSSS as far as this goes. Our company must decrypt ~100 files 7x24 in near real time. How can SSSS work - or any reasonable alternative - in such a production environment? ~ Mike On Thu, Nov 10, 2016 at 9:07 AM, Kristian Fiskerstrand < kristian.fiskerstrand at sumptuouscapital.com> wrote: > On 11/10/2016 03:50 PM, helices wrote: > > So would I! > > > > At this point, our company must achieve PCI DSS compliance before year > end, > > and the road to that necessity leads through this auditor, who insists > that > > PGP satisfies all requirements. > > > > There is no explanation that he shares with us. > > I'd expect it being reference to shamir secret sharing scheme that I > believe formed part of PGP at some point, but haven't really looked into > PGP for a while. This would allow e.g split key in 5 parts and require 2 > or 3 at the same time to access it. For the automated system, presumably > would require two administrators to set it up, and expectation that > nobody willfully modify the application or read the full private key in > memory for the regular operation, but at that point would hinder any one > admin to have access to the full key to use outside of the system. > > -- > ---------------------------- > Kristian Fiskerstrand > Blog: https://blog.sumptuouscapital.com > Twitter: @krifisk > ---------------------------- > Public OpenPGP keyblock at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 > ---------------------------- > Aut disce aut discede > Either learn or leave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndk.clanbo at gmail.com Thu Nov 10 18:42:52 2016 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 10 Nov 2016 18:42:52 +0100 Subject: PCI DSS compliance In-Reply-To: References: <20161110142743.GA8975@IUPUI.Edu> Message-ID: <26422943-7fb9-b883-ea91-3bcdfe277e98@gmail.com> Il 10/11/2016 16:24, helices ha scritto: > Our company must decrypt ~100 files 7x24 in near real time. How can SSSS > work - or any reasonable alternative - in such a production environment? Wouldn't a smartcard solve (at least partially) the issue? Insert it in a pinpad reader and have the PIN shared between two administrators. Both are required at system boot to unlock the card. If the card gets removed, no single admin can unlock it. Sure, an admin could just use it while connected to the server to decrypt files (or simply read stored files) but as others said there's no way to prevent that if the attacker have physical access to the system. BYtE, Diego From glenn at rempe.us Thu Nov 10 21:06:56 2016 From: glenn at rempe.us (Glenn Rempe) Date: Thu, 10 Nov 2016 20:06:56 +0000 Subject: PCI DSS compliance In-Reply-To: <26422943-7fb9-b883-ea91-3bcdfe277e98@gmail.com> References: <20161110142743.GA8975@IUPUI.Edu> <26422943-7fb9-b883-ea91-3bcdfe277e98@gmail.com> Message-ID: I think this is where you want to look into a Hardware Security Module (HSM) or a solution like Hashicorp's Vault server. The split secret would be used to initialize either of those solutions (Vault uses split keys to unseal the server out of the box, and can even encrypt those shares to several different GPG keys when the root key is created, this way the shares are never exposed in plaintext form to anyone, not even the original admin that creates the key) https://en.wikipedia.org/wiki/Hardware_security_module https://www.yubico.com/products/yubihsm/ https://www.vaultproject.io I don't know if any HSM's support hardware based protected GnuPG encryption or not. If you want to experiment with a Shamir Secret Sharing key split you can look at an implementation in Ruby that I have created which also has a simple command line interface for splitting and recombining secrets. https://github.com/grempe/tss-rb In any case I think you would have those trusted admins, with shares of a private key passphrase, unlock the key in memory at boot time of your application and this server would be the only one that is capable of automated decryption using that unlocked private key. They would need to repeat this process at each reboot or if the process that contains the key crashes. I am not aware of GnuPG ever supporting Shamir Secret Sharing style encryption key splitting. They may exist, I just don't know. Cheers, Glenn On Thu, Nov 10, 2016 at 11:10 AM NdK wrote: > Il 10/11/2016 16:24, helices ha scritto: > > > Our company must decrypt ~100 files 7x24 in near real time. How can SSSS > > work - or any reasonable alternative - in such a production environment? > Wouldn't a smartcard solve (at least partially) the issue? > Insert it in a pinpad reader and have the PIN shared between two > administrators. Both are required at system boot to unlock the card. If > the card gets removed, no single admin can unlock it. > Sure, an admin could just use it while connected to the server to > decrypt files (or simply read stored files) but as others said there's > no way to prevent that if the attacker have physical access to the system. > > BYtE, > Diego > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Fri Nov 11 12:12:38 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 11 Nov 2016 12:12:38 +0100 Subject: PCI DSS compliance In-Reply-To: References: <20161110142743.GA8975@IUPUI.Edu> Message-ID: Disclaimer: I know nothing about these compliance issues. > Our company must decrypt ~100 files 7x24 in near real time. How can SSSS > work - or any reasonable alternative - in such a production environment? Couldn't you simply password protect the key and unlock it when the server boots, with several admins entering a part of the password? Alternatively, to use SSSS, you could wire up an SSSS implementation to a pinentry, so you don't need specific admins but use any X of Y of them. In this case, I suggest you use a randomly generated "passphrase" for the GnuPG key. If you want to make your implementation real shiny, you could store the actual shares encrypted, with each admin having the possibility of choosing their own decryption password, so they don't have to learn a seemingly random number. To clarify, I mean you write the pinentry implementation and use an already written SSSS implementation. This pinentry is then invoked when you gpg-preset-passphrase the passphrase during boot of the server. Just an idea, 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 Fri Nov 11 12:29:21 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 11 Nov 2016 12:29:21 +0100 Subject: PCI DSS compliance In-Reply-To: References: <20161110142743.GA8975@IUPUI.Edu> Message-ID: <61de7741-0cc2-76fa-2714-1ae55ebe1c97@digitalbrains.com> On 10/11/16 16:24, helices wrote: > Our company must decrypt ~100 files 7x24 in near real time. Upon reflection, isn't this complaince issue for key management, like subkey creation, setting of expiry, stuff like that, rather than decryption? It seems like stuff you need the primary key for, whereas for decryption, you only need the encryption subkey. They can be separately managed. 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 andreas.schwier.ml at cardcontact.de Fri Nov 11 13:36:26 2016 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Fri, 11 Nov 2016 13:36:26 +0100 Subject: PCI DSS compliance In-Reply-To: References: <20161110142743.GA8975@IUPUI.Edu> Message-ID: <5a8dd638-83e7-ecdd-50f7-939b82186b37@cardcontact.de> The SmartCard-HSM supports n-of-m authentication using n out of m "other" SmartCard-HSM cards/token to authenticate towards the device with the private key. You need at least n authentication steps to enable key access. Authentication is done using a public key based challenge-response protocol, so that it also works remotely. The scheme was specifically designed to provide shared control for sensitive keys (like Root-CA keys). The SmartCard-HSM is supported by gpgsm, however there is currently no support for n-of-m build into scdaemon. Andreas On 11/11/2016 12:12 PM, Peter Lebbing wrote: > Disclaimer: I know nothing about these compliance issues. > >> Our company must decrypt ~100 files 7x24 in near real time. How can SSSS >> work - or any reasonable alternative - in such a production environment? > > Couldn't you simply password protect the key and unlock it when the > server boots, with several admins entering a part of the password? > > Alternatively, to use SSSS, you could wire up an SSSS implementation to > a pinentry, so you don't need specific admins but use any X of Y of > them. In this case, I suggest you use a randomly generated "passphrase" > for the GnuPG key. If you want to make your implementation real shiny, > you could store the actual shares encrypted, with each admin having the > possibility of choosing their own decryption password, so they don't > have to learn a seemingly random number. > > To clarify, I mean you write the pinentry implementation and use an > already written SSSS implementation. This pinentry is then invoked when > you gpg-preset-passphrase the passphrase during boot of the server. > > Just an idea, > > Peter. > -- --------- CardContact Systems GmbH |.##> <##.| Sch?lerweg 38 |# #| D-32429 Minden, Germany |# #| Phone +49 571 56149 |'##> <##'| http://www.cardcontact.de --------- Registergericht Bad Oeynhausen HRB 14880 Gesch?ftsf?hrer Andreas Schwier From listofactor at mail.ru Sun Nov 13 09:30:24 2016 From: listofactor at mail.ru (listo factor) Date: Sun, 13 Nov 2016 08:30:24 +0000 Subject: No "evidence" is possible In-Reply-To: <9145795e-f92e-79a2-811a-e834b601beb1@cajuntechie.org> References: <9145795e-f92e-79a2-811a-e834b601beb1@cajuntechie.org> Message-ID: <8a1347fc-b935-36ff-99d4-c44307238ece@mail.ru> On 11/07/2016 09:32 PM, Anthony Papillion wrote: ... > Is there any evidence that GnuPG password entry is not part of the > keystroke data sent to Microsoft? Does GnuPG take any steps to avoid > this? Can it? It can not. Even if it was possible to obtain conclusive evidence that currently installed OS components on some computer do not send some particular segment of user's data back to the OS vendor, any new update of the operating system, done automatically, without continued exhaustive examination of its internals by the user, could change things and invalidate the "evidence". Even on Linux systems, there is not much security that can be guaranteed by any program running on a network-connected computer. Even if GnuPG encryption and decryption is performed on a stand-alone computer and transfered for communication to a networked computer via a memory device, only the content of the message would be protected. All other data, specifically a complete network of who communicates with whom, when and where, is completely open to an adversary. In almost all real-life threat models, this data is just as sensitive as is the content of the message. All of the above is not explained sufficiently well to a non-technical users. This hardly matters to those that use GnuPG simply because they believe all e-mail should be encrypted for philosophical reasons, but can have dire consequences for those that use the program when they have a real need for robust protection of their communication. From gnupg.thegrue at spamgourmet.com Sun Nov 13 13:20:49 2016 From: gnupg.thegrue at spamgourmet.com (gnupg.thegrue at spamgourmet.com) Date: Sun, 13 Nov 2016 13:20:49 +0100 Subject: gpg password and/or agend messed up Message-ID: <20161113132049.7b709545@haktar.galaxy.home> Dear GnuPG List, It seems the password handling and/or gnupg-agent use of my setup is messed up somehow. I suspect that these two might be related, that's why put both issues in one mail. I wanted to change the password of of my gpg key. So I did this: gpg --edit-key 79D7E890 gpg> passwd The pinentry agent pops up, I enter the new password gpg> save gpg> quit I didn't use gpg for a few days, then wanted to sign a mail. Pinentry pops up, I enter the new password - which is rejected :( I try again, rejected. I try the old password: success. Strange. "Hmm, something went wrong when changing the password", I thought, and repeated the aforementioned procedure. When I'm prompted to enter the old password, I enter the old one, and it is /rejected/. I enter the new one, successfully. Then I'm prompted to enter the new password. I enter the new one (same as last time) and it seems to work. When I type "save" to save my changes, I get this message: "Key not changed so no update needed." Hmmm. I want to be sure that my mail program (claws) doesn't make problems, so I try this: % gpg --sign test.txt Pinentry comes up and only the OLD password is accepted :( :( Ok, maybe pinentry's fault? I comment the line # use-agent in ~/.gnupg/options , try signing again and pinentry comes up again. Wtf? So now I have a gnupg where I can't change my password, allthough I /changed/ it, it just doesn't work and where I can't disable pinentry... I don't really mind pinentry, but I do want to be able to change my password! Could you help me, please? (Not signed, because, you know...) -- Markus Grunwald From dkg at fifthhorseman.net Mon Nov 14 03:18:24 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 14 Nov 2016 11:18:24 +0900 Subject: gpg password and/or agend messed up In-Reply-To: <20161113132049.7b709545@haktar.galaxy.home> References: <20161113132049.7b709545@haktar.galaxy.home> Message-ID: <87k2c6erdb.fsf@alice.fifthhorseman.net> On Sun 2016-11-13 21:20:49 +0900, gnupg.thegrue at spamgourmet.com wrote: > So now I have a gnupg where I can't change my password, allthough I > /changed/ it, it just doesn't work and where I can't disable > pinentry... What platform are you using? What version of GnuPG? do you have multiple versions of gpg installed ? (e.g. "gpg" and "gpg2")? --dkg From gnupg.thegrue at spamgourmet.com Mon Nov 14 19:42:00 2016 From: gnupg.thegrue at spamgourmet.com (gnupg.thegrue at spamgourmet.com) Date: Mon, 14 Nov 2016 19:42:00 +0100 Subject: gpg password and/or agend messed up (gnupg: message 2 of 20) In-Reply-To: <20161113132049.7b709545@haktar.galaxy.home> References: <20161113132049.7b709545@haktar.galaxy.home> Message-ID: <20161114194200.229283aa@haktar.galaxy.home> Hello, Well, I forgot a few important things: > What platform are you using? What version of GnuPG? do you have > multiple versions of gpg installed ? (e.g. "gpg" and "gpg2")? My machine is a debian/jessie linux. % dpkg -l \*gpg\* | egrep '^ii' ii gpgsm 2.1.15-4 amd64 GNU privacy guard - S/MIME version ii gpgv 2.1.15-4 amd64 GNU privacy guard - signature verification tool ii libgpg-error0:amd64 1.24-1 amd64 library for common error values and messages in GnuPG components ii libgpg-error0:i386 1.24-1 i386 library for common error values and messages in GnuPG components ii libgpgme++2v5 4:4.14.10-7 amd64 C++ wrapper library for GPGME ii libgpgme11:amd64 1.7.0-1 amd64 GPGME - GnuPG Made Easy (library) ii libkf5gpgmepp5:amd64 16.04.3-1 amd64 c++ wrapper library for gpgme ii python-gpgme 0.3-1.1+b1 amd64 python wrapper for the GPGME library % dpkg -l \*gnupg\* | egrep '^ii' ii gnupg 2.1.15-4 amd64 GNU privacy guard - a free PGP replacement ii gnupg-agent 2.1.15-4 amd64 GNU privacy guard - cryptographic agent ii gnupg-l10n 2.1.15-4 all GNU privacy guard - localization files ii gnupg2 2.1.15-4 all GNU privacy guard - a free PGP replacement (dummy transitional package) ii libgnupg-interface-perl 0.52-5 all Perl interface to GnuPG -- Markus Grunwald http://www.the-grue.de Fragen zur Mail? http://www.the-grue.de/mail_und_co http://www.the-grue.de/~markus/markus_grunwald.gpg From aafanasyev at os3.nl Tue Nov 15 11:57:18 2016 From: aafanasyev at os3.nl (aafanasyev at os3.nl) Date: Tue, 15 Nov 2016 11:57:18 +0100 Subject: Specifying entropy source Message-ID: <5ab987825892d804e722ccbd869d9a1d.squirrel@webmail.os3.nl> Hi, I know that during generation of the key will be asked for moving mouse or some other actions to create enough entropy. However could I use a specific source to create entropy for key generation? Like only mouse or keyboard. If yes how it can be done? Thank you. With kind regards, Andrey From duane at nofroth.com Tue Nov 15 16:54:58 2016 From: duane at nofroth.com (Duane Whitty) Date: Tue, 15 Nov 2016 11:54:58 -0400 Subject: gnupg over Internet Message-ID: Hi, I can no longer use my laptop where I had gnupg, Thunderbird, and Enigmail installed. I do have my keys backed-up on an accessible medium. Now I am thinking I might like to avoid from now on being dependent on local hardware. Any ideas, tips, random thoughts on how I could use gnupg from any random Internet cafe or library computer? Has anyone gotten around the problem of USB HDs being so easily compromised? It would be convenient to run gnupg from a USB stick with a card reader plugged into another USB port but I don't believe that is safe. For instance, I am currently using a computer (a Mac) at a local university for which I have a temporary login account. I have shell access but no administrative privileges. Even if I could install software on my account I would not want to. There's also no DVD installed. Excuse the cliche but I am trying to describe being a "road warrior" without the laptop. Let's say no hardware at all except my card reader and pin pad and maybe a near field radio id device and of course an android phone :-) which I have gnupg on but haven't figured out yet how to effectively use it. Any help is appreciated. -- Best Regards, Duane Duane Whitty duane at nofroth.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wachs at net.in.tum.de Tue Nov 15 17:19:51 2016 From: wachs at net.in.tum.de (Matthias Wachs) Date: Tue, 15 Nov 2016 17:19:51 +0100 Subject: gpg-agent crashes on Windows 10 Message-ID: <1479226791.3050.16.camel@net.in.tum.de> Hi, after updating to Windows 10 on one of colleagues system gpg-agent crashes: When trying to e.g. decrypt an email ("gpg testmail.eml") and entering the passphrase, gpg-agent crashes with: C:\Program Files (x86)\GnuPG\bin>gpg-agent --daemon --verbose gpg-agent[6704]: Es wird auf Socket `C:\Users\gi26get\AppData\Roaming\gnupg\S.gpg-agent' geh?rt gpg-agent[6704]: gpg-agent (GnuPG) 2.1.12 started gpg-agent[6704]: Handhabungsroutine 0x2 f?r fd 144 gestartet gpg-agent[6704]: starting a new PIN Entry gpg-agent[6704]: S2K calibration: 4485120 -> 109ms Assertion failed! Program: C:\Program Files (x86)\GnuPG\bin\gpg-agent.exe File: /home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/PLAY/src/libgpg- error/src/estream.c, Line 1873 Expression: stream->flags.writing This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. In the application eventlog, the following event is logged ?gpg-agent.exe ???2.1.12.223 ???00000000 ???libgpg-error-0.dll ???1.22.0.39429 ???3c993c92 ???40000015 ???000125e8 ???1a30 ???01d23f553c95d446 ???C:\Program Files (x86)\GnuPG\bin\gpg-agent.exe ???C:\Program Files (x86)\GnuPG\bin\libgpg-error-0.dll ???510f1373-e598-4a78-91d8-5a02d6f42ab8 Did anyone notice this before? Is there a solution around? I did not find anything in the bugtracker, so if not I am happy to file a bug and provide more information if required. Cheers Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From swehack at gmail.com Wed Nov 16 09:52:49 2016 From: swehack at gmail.com (Stefan Midjich) Date: Wed, 16 Nov 2016 09:52:49 +0100 Subject: Specifying entropy source In-Reply-To: <5ab987825892d804e722ccbd869d9a1d.squirrel@webmail.os3.nl> References: <5ab987825892d804e722ccbd869d9a1d.squirrel@webmail.os3.nl> Message-ID: I'm a novice user but since nobody else has replied. Have you tried installing haveged and starting the service? It generates entropy. First link on Google. https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged 2016-11-15 11:57 GMT+01:00 : > Hi, > > > I know that during generation of the key will be asked for moving mouse or > some other actions to create enough entropy. However could I use a > specific source to create entropy for key generation? Like only mouse or > keyboard. > If yes how it can be done? > > Thank you. > > With kind regards, > > Andrey > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- V?nliga H?lsningar / Sincerely Stefan M From jc.gnupg at unser.net Wed Nov 16 15:55:22 2016 From: jc.gnupg at unser.net (Juergen Christoffel) Date: Wed, 16 Nov 2016 15:55:22 +0100 Subject: Specifying entropy source In-Reply-To: <5ab987825892d804e722ccbd869d9a1d.squirrel@webmail.os3.nl> References: <5ab987825892d804e722ccbd869d9a1d.squirrel@webmail.os3.nl> Message-ID: <20161116145522.GA9493@unser.net> On Tue, Nov 15, 2016 at 11:57:18AM +0100, aafanasyev at os3.nl wrote: > >I know that during generation of the key will be asked for moving mouse or >some other actions to create enough entropy. However could I use a >specific source to create entropy for key generation? Like only mouse or >keyboard. As Stefan wrote, try haveged. Or: if your CPU has "RDRAND" (i.e. grep rdrand /proc/cpuinfo) it contains Intel's hardware RNG. Which you have to trust, as it's a proprietary feature of a big player. But Linux's entropy gathering mixes its output with other sources of randomness, Then there are http://www.bitbabbler.org and http://ubld.it/products/truerng-hardware-random-number-generator/ as hardware random number generators. Both are worth their money IMO. --jc -- Doctorow's Law: Anytime someone puts a lock on something you own, against your wishes, and doesn't give you the key, they're not doing it for your benefit. From ndk.clanbo at gmail.com Wed Nov 16 19:12:11 2016 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 16 Nov 2016 19:12:11 +0100 Subject: Specifying entropy source In-Reply-To: <20161116145522.GA9493@unser.net> References: <5ab987825892d804e722ccbd869d9a1d.squirrel@webmail.os3.nl> <20161116145522.GA9493@unser.net> Message-ID: <03dbe304-5d01-18de-f19b-6964d7561527@gmail.com> Il 16/11/2016 15:55, Juergen Christoffel ha scritto: > Then there are http://www.bitbabbler.org and > http://ubld.it/products/truerng-hardware-random-number-generator/ as > hardware random number generators. Both are worth their money IMO. Why not GnuK, that incorporates a TRNG too? There's even a version that only includes the TRNG, and it's completely open. BYtE, Diego From lukas.troebinger at gmail.com Wed Nov 16 20:39:51 2016 From: lukas.troebinger at gmail.com (=?UTF-8?Q?Lukas_Tr=C3=B6binger?=) Date: Wed, 16 Nov 2016 20:39:51 +0100 Subject: Specifying entropy source In-Reply-To: <03dbe304-5d01-18de-f19b-6964d7561527@gmail.com> References: <5ab987825892d804e722ccbd869d9a1d.squirrel@webmail.os3.nl> <20161116145522.GA9493@unser.net> <03dbe304-5d01-18de-f19b-6964d7561527@gmail.com> Message-ID: Hi, i run also into the same problem. At the end, it seems the rng-tools are not so recommended. So i went with haveged because of the algorithm it uses. Haveged runs as a background daemon and won't bother you in the future. I know a good hosting provider where it is preinstalled and a good linux admin who uses it as a standard repertoir tool. Greetings 2016-11-16 19:12 GMT+01:00 NdK : > Il 16/11/2016 15:55, Juergen Christoffel ha scritto: > > > Then there are http://www.bitbabbler.org and > > http://ubld.it/products/truerng-hardware-random-number-generator/ as > > hardware random number generators. Both are worth their money IMO. > Why not GnuK, that incorporates a TRNG too? > There's even a version that only includes the TRNG, and it's completely > open. > > BYtE, > Diego > > > _______________________________________________ > 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 gniibe at fsij.org Thu Nov 17 01:37:44 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 17 Nov 2016 09:37:44 +0900 Subject: TRNG (was: Specifying entropy source) In-Reply-To: <03dbe304-5d01-18de-f19b-6964d7561527@gmail.com> References: <5ab987825892d804e722ccbd869d9a1d.squirrel@webmail.os3.nl> <20161116145522.GA9493@unser.net> <03dbe304-5d01-18de-f19b-6964d7561527@gmail.com> Message-ID: Hello, I work for my own TRNG implementation. I realized that the point is: We should collectively control things so that none can control a sequence of random bytes. --- (*) Second "control" in (*) includes guessing, predicting, or knowing, not only manipulating directly/indirectly. Things include software, hardware, and the process of making software, hardware, etc. I observed that people have tendency to prefer an exotic noise source, but it is not that important matter for me. Rather, if a TRNG device depends on some exotic technology, I count it as a weakness because it makes it difficult to be reproducible and transparent. On 11/17/2016 03:12 AM, NdK wrote: > Il 16/11/2016 15:55, Juergen Christoffel ha scritto: > >> Then there are http://www.bitbabbler.org and >> http://ubld.it/products/truerng-hardware-random-number-generator/ as >> hardware random number generators. Both are worth their money IMO. > Why not GnuK, that incorporates a TRNG too? In general, OpenPGP card implementations have a random number generator. I mean, it's not only the feature of Gnuk. It is accessible by gpg-connect-agent. Here is an example. ==================== $ gpg-connect-agent --hex "SCD RANDOM 32" /bye D[0000] F8 04 49 F3 BA D9 85 44 47 54 F5 89 B5 49 EA E7 ..I....DGT...I.. D[0010] 46 20 1E 09 15 AC 38 7E 9E 50 0E D7 28 19 64 15 F ....8~.P..(.d. OK ==================== I think that this is useful when a person installs an OS into a new machine, or when people use machines for clean boot with fixed media like CD. Feeding those random bytes to /dev/random can make the barrier higher (against guessing, predicting, or knowing). > There's even a version that only includes the TRNG, and it's completely > open. Thank you, Diego, for the introduction. The device is available at: https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator I think that "completely open" is not achieved, yet. Although I tried my best making it free, reproducible and transparent (I use the tube on purpose to demonstrate its transparency), it's not perfect; While firmware is Free Software assuming Free Software development environment only, and the PCB design is free and the design assumes Free Software development environment only, it still depends on the MCU chip (manufacturer and its distribution channel) and the manufacturer of PCB assembly. Suppose that there were a proprietary TRNG device by some alien (I mean, an external entity). As a gift, the alien deliberately left the TRNG which generation of randomness cannot be controlled by anyone in this planet. In this case, this TRNG is useful for us, perhaps. Given no such a gift on earth, I believe that we need free, reproducible and transparent one even not perfect. Well, I think that the TRNG device is very good for a gift to hackers. :-) Enjoy, -- -------------- 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 Thu Nov 17 08:53:51 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Nov 2016 08:53:51 +0100 Subject: gpg-agent crashes on Windows 10 In-Reply-To: <1479226791.3050.16.camel@net.in.tum.de> (Matthias Wachs's message of "Tue, 15 Nov 2016 17:19:51 +0100") References: <1479226791.3050.16.camel@net.in.tum.de> Message-ID: <87polutucw.fsf@wheatstone.g10code.de> On Tue, 15 Nov 2016 17:19, wachs at net.in.tum.de said: > ???2.1.12.223 gnupg 2.1.12 is not current. > ???libgpg-error-0.dll > ???1.22.0.39429 IRRC, we fixes some Windows things in libgpg after 1.22. I'd suggest until we have release 2.1.16 along with a new windows installer. Very likely this week. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From anton at marchukov.com Thu Nov 17 15:02:07 2016 From: anton at marchukov.com (Anton Marchukov) Date: Thu, 17 Nov 2016 15:02:07 +0100 Subject: Primary and Signing Key on Different Smart Cards Message-ID: Hello. I did some research myself and came to conclusion that this is not supported. Was about to submit a feature request, but it is better to ask for help here first. The use case that I want to implement is the following: 1. I have an OpenPGP v2 smart card (regular plastic card) where I want to store my primary key with keys enabled for certification, encryption, signing and authentication. This is physical smart card that I am going to connect and use only when I certify other keys and if I get encrypted mail. This happens not that often, so it is ok to keep the card disconnected till it is needed. 2. But contrary to most smart card manual recommendations, I do not want any of my secret keys to be ever copied anywhere off the card. This is because this way I can be relatively sure that the only way to use the key is by physical presence of the smartcard. I understand that I will loose my key if I loose smartcard, but since those certification and encryption operations are not that often made I accept this risk as rather low. 3. Now, the most often operation done for me is signing. And for that I want to have a signing only subkey stored on my Yubikey nano - a tiny device that permanently seats in the usb port of my computer and that implements OpenPGP v2 card inside. Since it supports presence check (you need to touch it to confirm cryptographic operation) I find it secure enough to be always connected for signing purposes. This is because if my computer is tampered with I will not be sure about the content of what I sign anyway as it might be forged when I look onto it. So I assume that it is secure and then care only that physical presence is required and that it is not possible to copy the secret key out. The only problem is that it is possible to hijack the PIN first and then the device, but I will revoke this subkey using the primary smartcard if that happens. Good enough for me. Now based on my review I have found the situation in gpg2 to be the following: 1. Using multiple smartcards at the same time is not properly supported. As I have found using homedir hacks you can essentially have two gpg profiles each of them using different cards, but 2. it will not be possible to use keys on two cards together and thus I will not be able to generate subkey for card in [3] using key stored on card in [1] 3. unless I temporarily copy the secret key from [1] to the file at the time of generation, but this will violate requirement [2] and also if I delete secret key copy I will not be able to generate other subkeys for other smartcards in future. Anything that I have missed or thoughts? Does this request make sense? Also as I see that with currently supported features, the best way to proceed is to give up using a smartcard for the primary key [1] and use airgapped machine with file based key instead. This is basically what I have now. Anton. From swehack at gmail.com Thu Nov 17 12:47:05 2016 From: swehack at gmail.com (Stefan Midjich) Date: Thu, 17 Nov 2016 12:47:05 +0100 Subject: TRNG (was: Specifying entropy source) In-Reply-To: References: <5ab987825892d804e722ccbd869d9a1d.squirrel@webmail.os3.nl> <20161116145522.GA9493@unser.net> <03dbe304-5d01-18de-f19b-6964d7561527@gmail.com> Message-ID: On the topic of open source RNG, I own the OneRNG and have attempted to use it with gpg but failed in the past. I never made another attempt. OneRNG was a kickstarter crowd funding campaign and is now available from their webshop. It's supposed to be an open source RNG but I'm not qualified to speak on its quality as a TRNG. It instructed users to use rngd, and at the time I was not aware of haveged. I was able to use it for entropy but never for GPG. The OneRNG has a LED that is supposed to dim when entropy is being drawn from it, but gpg use never triggered this. My goal would be to make another attempt at using my OneRNG over USB with haveged as entropy source. A quick web search shows others have attempted this already. For example https://lwn.net/Articles/648550/ 2016-11-17 1:37 GMT+01:00 NIIBE Yutaka : > Hello, > > I work for my own TRNG implementation. I realized that the point is: > > We should collectively control things so that none can control a > sequence of random bytes. --- (*) > > Second "control" in (*) includes guessing, predicting, or knowing, not > only manipulating directly/indirectly. > > Things include software, hardware, and the process of making software, > hardware, etc. > > I observed that people have tendency to prefer an exotic noise source, > but it is not that important matter for me. Rather, if a TRNG device > depends on some exotic technology, I count it as a weakness because it > makes it difficult to be reproducible and transparent. > > > On 11/17/2016 03:12 AM, NdK wrote: >> Il 16/11/2016 15:55, Juergen Christoffel ha scritto: >> >>> Then there are http://www.bitbabbler.org and >>> http://ubld.it/products/truerng-hardware-random-number-generator/ as >>> hardware random number generators. Both are worth their money IMO. >> Why not GnuK, that incorporates a TRNG too? > > In general, OpenPGP card implementations have a random number > generator. I mean, it's not only the feature of Gnuk. It is > accessible by gpg-connect-agent. Here is an example. > > ==================== > $ gpg-connect-agent --hex "SCD RANDOM 32" /bye > D[0000] F8 04 49 F3 BA D9 85 44 47 54 F5 89 B5 49 EA E7 ..I....DGT...I.. > D[0010] 46 20 1E 09 15 AC 38 7E 9E 50 0E D7 28 19 64 15 F ....8~.P..(.d. > OK > ==================== > > I think that this is useful when a person installs an OS into a new > machine, or when people use machines for clean boot with fixed media > like CD. Feeding those random bytes to /dev/random can make the > barrier higher (against guessing, predicting, or knowing). > >> There's even a version that only includes the TRNG, and it's completely >> open. > > Thank you, Diego, for the introduction. The device is available at: > > > https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator > > I think that "completely open" is not achieved, yet. > > Although I tried my best making it free, reproducible and transparent > (I use the tube on purpose to demonstrate its transparency), it's not > perfect; While firmware is Free Software assuming Free Software > development environment only, and the PCB design is free and the > design assumes Free Software development environment only, it still > depends on the MCU chip (manufacturer and its distribution channel) > and the manufacturer of PCB assembly. > > Suppose that there were a proprietary TRNG device by some alien (I > mean, an external entity). As a gift, the alien deliberately left the > TRNG which generation of randomness cannot be controlled by anyone in > this planet. In this case, this TRNG is useful for us, perhaps. > > Given no such a gift on earth, I believe that we need free, > reproducible and transparent one even not perfect. > > Well, I think that the TRNG device is very good for a gift to hackers. > :-) > > Enjoy, > -- > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- V?nliga H?lsningar / Sincerely Stefan M From wk at gnupg.org Thu Nov 17 16:49:26 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Nov 2016 16:49:26 +0100 Subject: TRNG In-Reply-To: (Stefan Midjich's message of "Thu, 17 Nov 2016 12:47:05 +0100") References: <5ab987825892d804e722ccbd869d9a1d.squirrel@webmail.os3.nl> <20161116145522.GA9493@unser.net> <03dbe304-5d01-18de-f19b-6964d7561527@gmail.com> Message-ID: <87r36artrt.fsf@wheatstone.g10code.de> On Thu, 17 Nov 2016 12:47, swehack at gmail.com said: > On the topic of open source RNG, I own the OneRNG and have attempted > to use it with gpg but failed in the past. I used it for half a year until it started to fail which fortunately was detected by its selftest. I really liked it due its physical nature of entropy. > My goal would be to make another attempt at using my OneRNG over USB > with haveged as entropy source. A quick web search shows others have Take care with haveged and read the design paper. It needs to be tuned to a specific CPU model to work reliable. I would always prefer a hardware based entropy source. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From peter at digitalbrains.com Thu Nov 17 17:13:45 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 17 Nov 2016 17:13:45 +0100 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: References: Message-ID: On 17/11/16 15:02, Anton Marchukov wrote: > Now based on my review I have found the situation in gpg2 to be the following: Which version, GnuPG 2.0 or 2.1? I think you can use 2.1 to reach the desired outcome without difficulty, even if it might be a bit non-standard. > 1. Using multiple smartcards at the same time is not properly > supported. As I have found using homedir hacks you can essentially > have two gpg profiles each of them using different cards, but Separate homedirs is not necessary for 2.0 either. But you need to do some "packet surgery" on the private key files as GnuPG 2.0 cannot update private keys. It has been described before at least in this[1] and this[2] thread. > Anything that I have missed or thoughts? Can we first get out of the way which exact version of GnuPG you're using? If you're using 2.0, start with the threads linked above, and feel free to report back if you're unclear about something. For 2.1, if time permits, I can outline the steps for you. You will need to have the private key on-disk for both versions, I'm afraid. Then again, by doing the alternative, on-card key generation, you're forced to use the on-card random number generator. I'd much rather trust GnuPG's random number generator than the one on a cheap smartcard (or any smartcard for that matter). So I would recommend to not use the on-card key generation feature anyway. I think I worked with the on-disk keys by pulling all hard drives from my computer, booting Knoppix from USB stick and using the DVD writer to save backups. I verified Knoppix had only opened stuff from the stick in read-only mode, and decided to trust Knoppix in not saving any persistent stuff. However, since you don't want backups, you could simply burn Knoppix to DVD and do away with writable media altogether (ignoring writing DVD's for a moment; that's not something you accidentally leave on). Unless you don't have a DVD writer, of course :-). > Does this request make sense? Yes, I've used a key with the primary key on one smartcard and the subkeys on another for 7 years. HTH, Peter. [1] https://lists.gnupg.org/pipermail/gnupg-users/2013-June/046784.html [2] https://lists.gnupg.org/pipermail/gnupg-users/2013-September/047412.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 lukas.troebinger at gmail.com Thu Nov 17 20:25:15 2016 From: lukas.troebinger at gmail.com (=?UTF-8?Q?Lukas_Tr=C3=B6binger?=) Date: Thu, 17 Nov 2016 20:25:15 +0100 Subject: gpg4win HKPS in gpg.conf correct slash Message-ID: Hey, when using the sks keyserver you can choose to use the HKPS version. In the gpg.conf file you need to specify the path to the CA cert "keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem". In Windows, what is the correct slash to use? Is it / or \? Thank you guys -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Thu Nov 17 20:26:55 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 17 Nov 2016 20:26:55 +0100 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: References: Message-ID: On 17/11/16 17:13, Peter Lebbing wrote: > You will need to have the private key on-disk for both versions, I'm > afraid. You will need the private key on-disk *temporarily* while setting up the smartcards. But with Knoppix, that "disk" can be a RAM disk in the main memory of your computer, obliterated once you power it off. I reread part of my own message in the reply by Arthur Ulfeldt, and noticed how unclear I had worded it :-). 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 arthur at ulfeldt.com Thu Nov 17 19:45:25 2016 From: arthur at ulfeldt.com (Arthur Ulfeldt) Date: Thu, 17 Nov 2016 10:45:25 -0800 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: References: Message-ID: I have a similar setup and have been doing it successfully. I have two yubikey neos with signing keys. I found that because of bugs in gpg 2.1 I had to put the same signing key onto both neos. Once I did that it worked smoothly. It would be preferable to use different keys and I'll do that if these problems are fixed (and I haven't checked in a while, perhaps they have been) PS: the bug is that gpg will only use the newest signing key, rather than the newest signing key that is available now. Den 17. nov. 2016 11.14 AM skrev "Peter Lebbing" : > On 17/11/16 15:02, Anton Marchukov wrote: > > Now based on my review I have found the situation in gpg2 to be the > following: > > Which version, GnuPG 2.0 or 2.1? I think you can use 2.1 to reach the > desired > outcome without difficulty, even if it might be a bit non-standard. > > > 1. Using multiple smartcards at the same time is not properly > > supported. As I have found using homedir hacks you can essentially > > have two gpg profiles each of them using different cards, but > > Separate homedirs is not necessary for 2.0 either. But you need to do some > "packet surgery" on the private key files as GnuPG 2.0 cannot update > private > keys. It has been described before at least in this[1] and this[2] thread. > > > Anything that I have missed or thoughts? > > Can we first get out of the way which exact version of GnuPG you're using? > If > you're using 2.0, start with the threads linked above, and feel free to > report > back if you're unclear about something. For 2.1, if time permits, I can > outline > the steps for you. You will need to have the private key on-disk for both > versions, I'm afraid. Then again, by doing the alternative, on-card key > generation, you're forced to use the on-card random number generator. I'd > much > rather trust GnuPG's random number generator than the one on a cheap > smartcard > (or any smartcard for that matter). So I would recommend to not use the > on-card > key generation feature anyway. > > I think I worked with the on-disk keys by pulling all hard drives from my > computer, booting Knoppix from USB stick and using the DVD writer to save > backups. I verified Knoppix had only opened stuff from the stick in > read-only > mode, and decided to trust Knoppix in not saving any persistent stuff. > However, > since you don't want backups, you could simply burn Knoppix to DVD and do > away > with writable media altogether (ignoring writing DVD's for a moment; > that's not > something you accidentally leave on). Unless you don't have a DVD writer, > of > course :-). > > > Does this request make sense? > > Yes, I've used a key with the primary key on one smartcard and the subkeys > on > another for 7 years. > > HTH, > > Peter. > > [1] https://lists.gnupg.org/pipermail/gnupg-users/2013-June/046784.html > [2] https://lists.gnupg.org/pipermail/gnupg-users/2013- > September/047412.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 > > _______________________________________________ > 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 tokktokk at riseup.net Thu Nov 17 20:34:19 2016 From: tokktokk at riseup.net (unknown) Date: Thu, 17 Nov 2016 20:34:19 +0100 Subject: Fresh OS installation Message-ID: <980b9088-96d4-627e-d065-c6b0494b5da6@riseup.net> Hi, I'd like to make a fresh linux installation. What is the best way to use my keys and settings I've already configured on my old OS? Do I back things up, or make a copy from the config. file? I've just started using Gnupg (and Linux). Thank you. From rjh at sixdemonbag.org Thu Nov 17 22:28:28 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 17 Nov 2016 16:28:28 -0500 Subject: Fresh OS installation In-Reply-To: <980b9088-96d4-627e-d065-c6b0494b5da6@riseup.net> References: <980b9088-96d4-627e-d065-c6b0494b5da6@riseup.net> Message-ID: <020001d24119$8a7d6ff0$9f784fd0$@sixdemonbag.org> > What is the best way to use my keys and settings I've already configured on > my old OS? Do I back things up, or make a copy from the config. file? Good question: there really isn't a good, standardized way to do this. There are three different branches of GnuPG that are in common use (1.4, 2.0, 2.1), and it's possible that your old keys were set up on 1.4, your new machine will be a 2.1 install, and so on. The easiest way will not necessarily be the best way. It will probably be good enough for your purposes. On your old machine: $ cd ~ $ tar cf gnupg-backup.tar .gnupg/ Copy the tarfile to your new installation. Place it in your home directory. Then, on your new machine: $ cd ~ $ rm -rf .gnupg $ tar xf ./gnupg-backup.tar $ rm -f .gnupg/random_seed $ gpg --list-secret-keys $ gpg --list-keys If you can list your secret keys and public keys OK, then you're probably good to go. Let us know if you have any problems. From wk at gnupg.org Fri Nov 18 08:22:09 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Nov 2016 08:22:09 +0100 Subject: gpg4win HKPS in gpg.conf correct slash In-Reply-To: ("Lukas =?utf-8?Q?Tr=C3=B6binger=22's?= message of "Thu, 17 Nov 2016 20:25:15 +0100") References: Message-ID: <87lgwhqmla.fsf@wheatstone.g10code.de> On Thu, 17 Nov 2016 20:25, lukas.troebinger at gmail.com said: > ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem". In Windows, what is the > correct slash to use? > Is it / or \? Windows officially supports a forward slash in its core APIs but not in the shell. We do not use the shell and thus the use of a forward slash in GnuPG configuration files is okay. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From lukas.troebinger at gmail.com Fri Nov 18 08:55:42 2016 From: lukas.troebinger at gmail.com (=?UTF-8?Q?Lukas_Tr=C3=B6binger?=) Date: Fri, 18 Nov 2016 08:55:42 +0100 Subject: gpg4win HKPS in gpg.conf correct slash In-Reply-To: References: <87lgwhqmla.fsf@wheatstone.g10code.de> Message-ID: Hey Werner, thank you for your reply. So it works with both? It would be useful to write this in the gpg4win documentation. I could do this. Greetings Am 18.11.2016 8:27 AM schrieb "Werner Koch" : On Thu, 17 Nov 2016 20:25, lukas.troebinger at gmail.com said: > ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem". In Windows, what is the > correct slash to use? > Is it / or \? Windows officially supports a forward slash in its core APIs but not in the shell. We do not use the shell and thus the use of a forward slash in GnuPG configuration files is okay. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wachs at net.in.tum.de Fri Nov 18 09:45:36 2016 From: wachs at net.in.tum.de (Matthias Wachs) Date: Fri, 18 Nov 2016 09:45:36 +0100 Subject: gpg-agent crashes on Windows 10 In-Reply-To: <87polutucw.fsf@wheatstone.g10code.de> References: <1479226791.3050.16.camel@net.in.tum.de> <87polutucw.fsf@wheatstone.g10code.de> Message-ID: <1479458736.5366.31.camel@net.in.tum.de> Hi Werner, hi all, 2.1.12 may be outdated but is the latest version for Windows (available on Heise): https://www.heise.de/download/product/gnu-privacy-guard-gnupg-1677/download The version included in gpg4win is even older: https://www.gpg4win.org/download.html -> GnuPG 2.0.30 Best, -M On Thu, 2016-11-17 at 08:53 +0100, Werner Koch wrote: > On Tue, 15 Nov 2016 17:19, wachs at net.in.tum.de said: > > > > > ???2.1.12.223 > > gnupg 2.1.12 is not current. > > > > > ???libgpg-error-0.dll > > ???1.22.0.39429 > > IRRC, we fixes some Windows things in libgpg after 1.22. > > I'd suggest until we have release 2.1.16 along with a new windows > installer.??Very likely this week. > > > Shalom-Salam, > > ???Werner > -- Dr. rer. nat. Matthias Wachs Researcher Technical University of Munich Department of Informatics Chair of Network Architectures and Services Boltzmannstr. 3? 85748 Garching, Germany Tel. + 49 89 289 18037 Fax + 49 89 289 18030 wachs at net.in.tum.de https://net.in.tum.de/members/wachs/ OpenPGP fingerprint 4594 6915 BA9B 3886 A7A5??91E0 271E D86D 6F53 AD12 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From peter at digitalbrains.com Fri Nov 18 12:20:42 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 18 Nov 2016 12:20:42 +0100 Subject: gpg-agent crashes on Windows 10 In-Reply-To: <1479458736.5366.31.camel@net.in.tum.de> References: <1479226791.3050.16.camel@net.in.tum.de> <87polutucw.fsf@wheatstone.g10code.de> <1479458736.5366.31.camel@net.in.tum.de> Message-ID: On 18/11/16 09:45, Matthias Wachs wrote: > 2.1.12 may be outdated but is the latest version for Windows (available on > Heise): That's not the official place to get your GnuPG downloads. 2.1.15 for Windows is available from . > The version included in gpg4win is even older: > https://www.gpg4win.org/download.html > -> GnuPG 2.0.30 While technically correct[1], 2.0.30 is the latest 2.0 release, and thus the current version. Remember there are three parallel branches, 1.4, 2.0 and 2.1. HTH, Peter. [1] The best kind of correct! -- 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 Fri Nov 18 20:24:20 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 18 Nov 2016 14:24:20 -0500 Subject: gpgme 1.8 build failure In-Reply-To: <7590557.nRbBky8x1B@esus> References: <908b8300-797c-88d4-bc79-0213203f0980@sixdemonbag.org> <7590557.nRbBky8x1B@esus> Message-ID: <7070591d-990f-38e8-6b3d-1b934ca7ab76@sixdemonbag.org> > Sorry, I don't understand the problem. In line 35 keygenerationresult.cpp > includes so strdup should be available. Is string.h not the right > header for strdup on macOS? It is, but it's in an #ifdef guard. A small test program is able to use strdup: ===== quorra:~ rjh$ more test.cxx #include int main() { const char* foo = "Foo"; const char* bar = strdup(foo); return 0; } quorra:~ rjh$ clang++ -W -Wextra -std=c++11 test.cxx -o t ===== So given that a dummy program can see strdup, but a default ./configure gpgme-1.8.0 can't, I suspect somewhere the configure script is setting a custom #define which is causing the build to fail. From wk at gnupg.org Fri Nov 18 22:19:54 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Nov 2016 22:19:54 +0100 Subject: [Announce] GnuPG 2.1.16 released Message-ID: <87twb4pjt1.fsf@wheatstone.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.16. 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.16 ==================================== * gpg: New algorithm for selecting the best ranked public key when using a mail address with -r, -R, or --locate-key. * gpg: New option --with-tofu-info to print a new "tfs" record in colon formatted key listings. * gpg: New option --compliance as an alternative way to specify options like --rfc2440, --rfc4880, et al. * gpg: Many changes to the TOFU implementation. * gpg: Improve usability of --quick-gen-key. * gpg: In --verbose mode print a diagnostic when a pinentry is launched. * gpg: Remove code which warns for old versions of gnome-keyring. * gpg: New option --override-session-key-fd. * gpg: Option --output does now work with --verify. * gpgv: New option --output to allow saving the verified data. * gpgv: New option --enable-special-filenames. * agent, dirmngr: New --supervised mode for use by systemd and alike. * agent: By default listen on all available sockets using standard names. * agent: Invoke scdaemon with --homedir. * dirmngr: On Linux now detects the removal of its own socket and terminates. * scd: Support ECC key generation. * scd: Support more card readers. * dirmngr: New option --allow-version-check to download a software version database in the background. * dirmngr: Use system provided CAs if no --hkp-cacert is given. * dirmngr: Use a default keyserver if none is explicitly set * gpgconf: New command --query-swdb to check software versions against an copy of an online database. * gpgconf: Print the socket directory with --list-dirs. * tools: The WKS tools now support draft version -02. * tools: Always build gpg-wks-client and install under libexec. * tools: New option --supported for gpg-wks-client. * The log-file option now accepts a value "socket://" to log to the socket named "S.log" in the standard socket directory. * Provide fake pinentries for use by tests cases of downstream developers. * Fixed many bugs and regressions. * Many changes and improvements for the test suite. 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.16 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.16.tar.bz2 (5704k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.16.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.16.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.16.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.16_20161118.exe (3684k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.16_20161118.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.16_20161118.exe https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.16_20161118.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 and Web Key Directory support, though. 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.16.tar.bz2 you would use this command: gpg --verify gnupg-2.1.16.tar.bz2.sig gnupg-2.1.16.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.16.tar.bz2, you run the command like this: sha1sum gnupg-2.1.16.tar.bz2 and check that the output matches the next line: 67540161c9fe289153c4a5ea60f7cdce0ef48897 gnupg-2.1.16.tar.bz2 50b0bd286faa90e5c71417b5f2f36cf5de964084 gnupg-w32-2.1.16_20161118.exe dd7d33a941c47574830df2e35503cd8ba0788eda gnupg-w32-2.1.16_20161118.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. Due to expected changes in the next release some strings pertaining to the TOFU code are not translated in this version. 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, GPGME, and GPA. Please consider to donate via: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, 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: 2020-10-30] 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. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 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 davidadamson.md at gmail.com Sat Nov 19 00:24:41 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Fri, 18 Nov 2016 18:24:41 -0500 Subject: gpg2 --version gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.3) Message-ID: Hello, I'm running a debian Jessie v8 kernel release 3.16.0-4-amd64 on my personal laptop. It came pre-installed with GnuPG 1.4.18. Rightly or not I thought having the latest version was a good idea for no other reason than wanting to have the latest and greatest. So from gnupg.org download page I downloaded and installed Gnupg Modern 2.1.15 along with the required libraries: nPth v1.2, Libgpg-error v1.25, Libgcrypt v1.7.3, Libksba v1.3.5 and Libassuan v2.4.3. Integrity checked them all. After installation completed I ran gpg --version from the command line and was presented with: gpg (GnuPG) 1.4.18 but then saw reference online somewhere to gpg2 and figured that I should be checking the version to that and so I ran gpg2 --version and was presented with: gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.3). I would like to have either version at this point that works. I don't like the idea of having misconfigured or improperly installed software trashing up my system. If you can help me clean up my system and have either version operational, I'd appreciate it. I intend to use Gnupg just to encrypt and sign text and files. Thanks in advance! From dkg at fifthhorseman.net Fri Nov 18 22:16:43 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 18 Nov 2016 16:16:43 -0500 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: References: Message-ID: <877f80h4jo.fsf@alice.fifthhorseman.net> On Thu 2016-11-17 13:45:25 -0500, Arthur Ulfeldt wrote: > PS: the bug is that gpg will only use the newest signing key, rather than > the newest signing key that is available now. I believe this bug is tracked upstream at https://bugs.gnupg.org/gnupg/issue1983 -- it would be great if someone wanted to propose a patch to fix it. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 962 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Nov 18 22:04:41 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 18 Nov 2016 16:04:41 -0500 Subject: Fresh OS installation In-Reply-To: <020001d24119$8a7d6ff0$9f784fd0$@sixdemonbag.org> References: <980b9088-96d4-627e-d065-c6b0494b5da6@riseup.net> <020001d24119$8a7d6ff0$9f784fd0$@sixdemonbag.org> Message-ID: <87d1hsh53q.fsf@alice.fifthhorseman.net> On Thu 2016-11-17 16:28:28 -0500, Robert J. Hansen wrote: >> What is the best way to use my keys and settings I've already configured > on >> my old OS? Do I back things up, or make a copy from the config. file? > > Good question: there really isn't a good, standardized way to do this. > There are three different branches of GnuPG that are in common use (1.4, > 2.0, 2.1), and it's possible that your old keys were set up on 1.4, your new > machine will be a 2.1 install, and so on. > > The easiest way will not necessarily be the best way. It will probably be > good enough for your purposes. > > On your old machine: > > $ cd ~ > $ tar cf gnupg-backup.tar .gnupg/ > > Copy the tarfile to your new installation. Place it in your home directory. > Then, on your new machine: > > $ cd ~ > $ rm -rf .gnupg > $ tar xf ./gnupg-backup.tar > $ rm -f .gnupg/random_seed > $ gpg --list-secret-keys > $ gpg --list-keys > > If you can list your secret keys and public keys OK, then you're probably > good to go. Let us know if you have any problems. Please be aware that if you take Robert's advice above, and your home directory is world-readable, then other accounts on the system will be able to read gnupg-backup.tar, which means they'll be able to get a copy of any secret information happens to be there. If that's a problem for you, you might want to set the umask to 077 ("umask 077") before the initial "tar cf", and ensure that the permissions on the file in your new directory are similarly restricted (theehy should not be readable by "group" or "other". --dkg From dkg at fifthhorseman.net Fri Nov 18 23:54:02 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 18 Nov 2016 17:54:02 -0500 Subject: gpg password and/or agend messed up (gnupg: message 2 of 20) In-Reply-To: <20161114194200.229283aa@haktar.galaxy.home> References: <20161113132049.7b709545@haktar.galaxy.home> <20161114194200.229283aa@haktar.galaxy.home> Message-ID: <87k2c0flh1.fsf@alice.fifthhorseman.net> On Mon 2016-11-14 13:42:00 -0500, gnupg.thegrue at spamgourmet.com wrote: >> What platform are you using? What version of GnuPG? do you have >> multiple versions of gpg installed ? (e.g. "gpg" and "gpg2")? > > My machine is a debian/jessie linux. > > % dpkg -l \*gpg\* | egrep '^ii' > ii gpgsm 2.1.15-4 amd64 GNU privacy guard - S/MIME version > ii gpgv 2.1.15-4 amd64 GNU privacy guard - signature verification tool > ii libgpg-error0:amd64 1.24-1 amd64 library for common error values and messages in GnuPG components > ii libgpg-error0:i386 1.24-1 i386 library for common error values and messages in GnuPG components > ii libgpgme++2v5 4:4.14.10-7 amd64 C++ wrapper library for GPGME > ii libgpgme11:amd64 1.7.0-1 amd64 GPGME - GnuPG Made Easy (library) > ii libkf5gpgmepp5:amd64 16.04.3-1 amd64 c++ wrapper library for gpgme > ii python-gpgme 0.3-1.1+b1 amd64 python wrapper for the GPGME library > > % dpkg -l \*gnupg\* | egrep '^ii' > ii gnupg 2.1.15-4 amd64 GNU privacy guard - a free PGP replacement > ii gnupg-agent 2.1.15-4 amd64 GNU privacy guard - cryptographic agent > ii gnupg-l10n 2.1.15-4 all GNU privacy guard - localization files > ii gnupg2 2.1.15-4 all GNU privacy guard - a free PGP replacement (dummy transitional package) > ii libgnupg-interface-perl 0.52-5 all Perl interface to GnuPG These versions are not the versions that are part of Debian jessie. are you running a mixed environment, or are you actually running Debian stretch? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 962 bytes Desc: not available URL: From wk at gnupg.org Sat Nov 19 11:27:26 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 19 Nov 2016 11:27:26 +0100 Subject: gpg2 --version gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.3) In-Reply-To: (David Adamson's message of "Fri, 18 Nov 2016 18:24:41 -0500") References: Message-ID: <87lgwfpxwx.fsf@wheatstone.g10code.de> On Sat, 19 Nov 2016 00:24, davidadamson.md at gmail.com said: > gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.3). You built gpg2 against Libgcrypt 1.7 but the system can't find that library at runtime and uses the system provided version (1.6.3). Quick workaround (assuming gpg was built with defaults): $ LD_LIBRARY_PATH=/usr/local/lib $ export LD_LIBRARY_PATH Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From davidadamson.md at gmail.com Sat Nov 19 15:13:14 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Sat, 19 Nov 2016 09:13:14 -0500 Subject: gpg2 --version gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.3) In-Reply-To: <87lgwfpxwx.fsf@wheatstone.g10code.de> References: <87lgwfpxwx.fsf@wheatstone.g10code.de> Message-ID: That worked thank you but only for that session and I read that it's generally not good practice to make that path permanent. Are you proposing I do this every time I wish to use gpg2? Is this behavior expected in a successful installation or what did I do wrong and can I fix it? Thanks again. P.S. I am prepared to do fresh install of OS if that would be smart. From peter at digitalbrains.com Sat Nov 19 16:36:47 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 19 Nov 2016 16:36:47 +0100 Subject: gpg2 --version gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.3) In-Reply-To: References: <87lgwfpxwx.fsf@wheatstone.g10code.de> Message-ID: <9417e3b3-c137-759c-b2c8-84f9126bb8d4@digitalbrains.com> On 19/11/16 15:13, David Adamson wrote: > Are you proposing I do this every time I wish to use gpg2? > Is this behavior expected in a successful installation or what did I > do wrong and can I fix it? Did you issue a # ldconfig as root after you installed the libraries? Because you say you run Debian jessie, and that has the file: :::::::::::::: /etc/ld.so.conf.d/libc.conf :::::::::::::: # libc default configuration /usr/local/lib So unless you manually changed the settings for ld.so, this directory should already be in the system search path. However, invoking ldconfig as root is a necessary step to scan these directories for new additions, AFAIK. Possibly this is only necessary if you put the first library in one of the dirs, I don't have the details ready. But in a normal Debian jessie system, libraries in this directory should "Just Work"(TM). Or is this a problem with the 1.6.3 receiving priority over 1.7.3? I don't know off the top of my head how to fix that, so let's try ldconfig first... 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 nix at esperi.org.uk Sat Nov 19 18:27:20 2016 From: nix at esperi.org.uk (Nix) Date: Sat, 19 Nov 2016 17:27:20 +0000 Subject: smartcard reader In-Reply-To: <53ad93a4-1ede-b8fd-9193-a973aa6fe37f@bjoern-kahl.de> (Bjoern Kahl's message of "Sun, 23 Oct 2016 00:16:57 +0200") References: <20161017205021.GA3273@localhost> <87vawomwkn.fsf@wheatstone.g10code.de> <57F6B1EC-02E1-4496-B0B8-E8C0EE939484@michel-messerschmidt.de> <53ad93a4-1ede-b8fd-9193-a973aa6fe37f@bjoern-kahl.de> Message-ID: <87eg27v0qv.fsf@esperi.org.uk> On 22 Oct 2016, Bjoern Kahl spake thusly: > I /think/ it worked exactly once. But then I played a bit with the > PIV applet on the YubiKey (using yubico's piv-tool), and since then > I can not get to the OpenPGP applet on the YubiKey. Only the PIV > works (I see my x509 certificates in there in Keychain and can used > in Safari to authenticate to for example StartSSL.com) If you're using pcscd, there's no way this will work without at least OpenSC 0.16.0, which was released quite recently (due to spec violations in the Yubikey Neo and 4's PIV applet which have exactly the effects you see). The master branch is more likely yet to work. Getting both PIV and GPG to work simultaneously is an even bigger kettle of pain :/ -- NULL && (void) From davidadamson.md at gmail.com Sat Nov 19 20:44:37 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Sat, 19 Nov 2016 14:44:37 -0500 Subject: gpg2 --version gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.3) In-Reply-To: <9417e3b3-c137-759c-b2c8-84f9126bb8d4@digitalbrains.com> References: <87lgwfpxwx.fsf@wheatstone.g10code.de> <9417e3b3-c137-759c-b2c8-84f9126bb8d4@digitalbrains.com> Message-ID: Running ldconfig as root resolved the issue I was having! Now when I type gpg2 --version in a new shell it reports the following: gpg (GnuPG) 2.1.15 libgcrypt 1.7.3 Thanks for the help. From mac3iii at gmail.com Sat Nov 19 20:26:05 2016 From: mac3iii at gmail.com (murphy) Date: Sat, 19 Nov 2016 14:26:05 -0500 Subject: gpg2 --version gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.3) Message-ID: <7c687009-9f8e-8f09-d381-1e46cd309d13@gmail.com> Hi David - I have run into this exact issue on various 32 bit machines or OS that run as 32 bit, like raspberry pi. I am certainly no expert but this seems to consistently solve the problem. sudo nano /etc/ld.so.conf Then place the following as the first line: include /etc/ld.so.conf.d/libc.conf save and then: sudo ldconfig Best of luck! Murphy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From davidadamson.md at gmail.com Sat Nov 19 21:51:19 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Sat, 19 Nov 2016 15:51:19 -0500 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 Message-ID: Hello, I'm running a debian Jessie v8 kernel release 3.16.0-4-amd64 on my personal laptop. It came pre-installed with GnuPG 1.4.18. I went to generate keys for myself by typing: gpg2 --gen-key But then during the process got this error: gpg: agent_genkey failed: No pinentry Key generation failed: No pinentry So I assumed I needed to install Pinentry and downloaded it from gnupg.org. I tried running ./configure as root and towards the end I got the following warnings and errors. I'm not sure how many issues I'm dealing with here or how to fix them. checking for gpg-error-config... /usr/local/bin/gpg-error-config checking for GPG Error - version >= 1.16... yes (1.25) configure: WARNING: *** *** The config script /usr/local/bin/gpg-error-config was *** built for x86_64-pc-linux-gnu and thus may not match the *** used host x86_64-unknown-linux-gnu. *** You may want to use the configure option --with-gpg-error-prefix *** to specify a matching config script or use $SYSROOT. *** checking for libassuan-config... /usr/local/bin/libassuan-config checking for LIBASSUAN - version >= 2.1.0... yes (2.4.3) checking LIBASSUAN API version... okay configure: WARNING: *** *** The config script /usr/local/bin/libassuan-config was *** built for x86_64-pc-linux-gnu and thus may not match the *** used host x86_64-unknown-linux-gnu. *** You may want to use the configure option --with-libassuan-prefix *** to specify a matching config script or use $SYSROOT. *** checking for byte typedef... no checking for ulong typedef... yes checking for setcap... /sbin/setcap checking for cap_set_proc in -lcap... no checking for pkg-config... no checking for ncursesw... checking for ncurses... checking for initscr in -lncursesw... no checking for initscr in -lncurses... no checking for tgetent in -lcurses... no checking for tgetent in -ltermcap... no checking for tgetent in -ltermlib... no checking for initscr in -lcurses... no checking if Unix domain socket is supported... yes checking for pkg-config... no checking for pkg-config... (cached) no checking for Qt5Core >= 5.0.0 Qt5Gui >= 5.0.0 Qt5Widgets >= 5.0.0... ./configure: line 9744: no: command not found ./configure: line 9752: no: command not found no ./configure: line 9770: no: command not found checking for QtCore >= 4.4.0 QtGui >= 4.4.0... ./configure: line 10123: no: command not found ./configure: line 10131: no: command not found no configure: error: No pinentry enabled. I appreciate any help, thanks. From davidadamson.md at gmail.com Sun Nov 20 09:04:59 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Sun, 20 Nov 2016 03:04:59 -0500 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: <5830e7e4.524d2e0a.c238a.e67a@mx.google.com> References: <5830e7e4.524d2e0a.c238a.e67a@mx.google.com> Message-ID: Thanks Krzysztof. I did apt-get install pinentry-qt4 although it was an older (0.8.3-2) version than what is on gnupg . org. It installed without any errors but when I run gpg2 --gen-key I'm still getting: We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: agent_genkey failed: No pinentry Key generation failed: No pinentry There is no delay in the error - it occurs at the same time the text above is displayed. From caro at nymph.paranoici.org Sun Nov 20 21:37:40 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sun, 20 Nov 2016 20:37:40 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> Message-ID: <20161120203740.CAB33100A200@remailer.paranoici.org> On Sun, 16 Oct 2016 01:22:50 +0000 (UTC), I wrote: >Hi, > >my next problem with 2.1.15 on Windows 7. > >I add a pub/sec keypair to two different keyrings > '--import ... --keyring a.kbx', then '--import ... --keyring b.kbx'. >Following this I delete that key from one of the keyrings > '--delete-secret-and-public-key ... --keyring a.kbx', >which unfortunately as a side effect also removes the secret key >associated with the other public keyring (b.kbx), as for both public key >items there's only one single secret key file stored in the common >private-keys-v1.d directory. > >Is there any chance to get that disentangled, maybe by defining a >separate secret key directory for each public .kbx keyring in use? The silence makes me believe that what I described is intended behavior, not a 2.1 design flaw. I'd like to know whether that's correct. Any response would still be appreciated. Kind regards, Caro From caro at nymph.paranoici.org Sun Nov 20 22:11:50 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sun, 20 Nov 2016 21:11:50 +0000 (UTC) Subject: How to prevent passphrase caching in 2.1 Message-ID: <20161120211150.C440C100A216@remailer.paranoici.org> Hi, is adding | default-cache-ttl 0 and/or | max-cache-ttl 0 to gpg-agent.conf the official way to deactivate passphrase caching completely and make GnuPG only use the term transferred with the --passphrase option? Thanks Caro From caro at nymph.paranoici.org Sun Nov 20 22:18:14 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sun, 20 Nov 2016 21:18:14 +0000 (UTC) Subject: How to prevent passphrase caching in 2.1 Message-ID: <20161120211814.CDD7C100A216@remailer.paranoici.org> Hi, is adding | default-cache-ttl 0 and/or | max-cache-ttl 0 to gpg-agent.conf the official way to deactivate passphrase caching completely and make GnuPG only use the term transferred with the --passphrase option? Thanks Caro From anton at marchukov.com Sun Nov 20 22:48:12 2016 From: anton at marchukov.com (Anton Marchukov) Date: Sun, 20 Nov 2016 22:48:12 +0100 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: References: Message-ID: > Which version, GnuPG 2.0 or 2.1? I think you can use 2.1 to reach the desired > outcome without difficulty, even if it might be a bit non-standard. I have 2.1.11 > Can we first get out of the way which exact version of GnuPG you're using? If > you're using 2.0, start with the threads linked above, and feel free to report > back if you're unclear about something. For 2.1, if time permits, I can outline > the steps for you. You will need to have the private key on-disk for both Ok. So I am using 2.1 and I have read the referenced threads and the both options assume that you either generate key of the card or maintain a copy of that. Anybody was able to do that with generating keys on the card always and not extracting them from the card as the copy either? > rather trust GnuPG's random number generator than the one on a cheap smartcard > (or any smartcard for that matter). So I would recommend to not use the on-card > key generation feature anyway. That's quite an interesting point that I have not thought about. Do you have any references to the papers that I can read on this subject? > with writable media altogether (ignoring writing DVD's for a moment; that's not > something you accidentally leave on). Unless you don't have a DVD writer, of > course :-). Do not have DVD writer anymore, but managed to buy USB flashcard with write protection switch. As I understand the protection switch there is hardware one, so should be good enough replacement for DVD-Rs. Key generation on air gaped machine is ok for me and I think I have enough information now to try to do that. But same time I find it a kind of overkill over key generation on the card for my use cases. E.g. I am not looking for security stronger than government issued eID cards have and they are usually key on card generated with card random number generator. Anton. From anton at marchukov.com Sun Nov 20 22:50:57 2016 From: anton at marchukov.com (Anton Marchukov) Date: Sun, 20 Nov 2016 22:50:57 +0100 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: References: Message-ID: > You will need the private key on-disk *temporarily* while setting up the > smartcards. But with Knoppix, that "disk" can be a RAM disk in the main > memory of your computer, obliterated once you power it off. I think you will have to keep it as backup too in case you will want to add another smartcard with a new subkey to an existing key or not? Although if air gaped machine is secure then encrypting backup using the smartcard itself and removing the unencrypted copy will do the trick as well. From jernej at kos.mx Sun Nov 20 20:47:25 2016 From: jernej at kos.mx (Jernej Kos) Date: Sun, 20 Nov 2016 20:47:25 +0100 Subject: GPGSM detached signature without auth attributes Message-ID: Hello! I would like to use GPGSM to sign a Linux kernel module with a private key stored on an OpenPGP smartcard. The original signing tool uses OpenSSL to sign the kernel module using a detached CMS signature. The kernel requires that the CMS does not contain any authenticated attributes and it refuses to validate the signature otherwise [1]. In the original signing tool [2] the CMS_add1_signer call uses the CMS_NOATTR and CMS_NOSMIMECAP flags (the same can be achieved by using the -noattr flag of the openssl command-line utility). Is there anything like this available in GPGSM? I've looked at the source code of both GPGSM and libksba and it looks like there is currently no easy way to omit these attributes from CMS with GPGSM? Thanks! [1] - https://lkml.org/lkml/2015/8/5/469 [2] - https://github.com/torvalds/linux/blob/master/scripts/sign-file.c#L311 Jernej -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From anton at marchukov.com Sun Nov 20 22:53:13 2016 From: anton at marchukov.com (Anton Marchukov) Date: Sun, 20 Nov 2016 22:53:13 +0100 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: References: Message-ID: On Thu, Nov 17, 2016 at 7:45 PM, Arthur Ulfeldt wrote: > I have a similar setup and have been doing it successfully. I have two > yubikey neos with signing keys. I found that because of bugs in gpg 2.1 I That's interesting as I want exactly that - two yubikeys for signing. Will be bale to try that once my second Yubikey arrives. Did you generated the primary key on the card or you had to maintain it on a disk somewhere? Anton. From wk at gnupg.org Mon Nov 21 10:16:52 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Nov 2016 10:16:52 +0100 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: (David Adamson's message of "Sat, 19 Nov 2016 15:51:19 -0500") References: Message-ID: <87oa19nqez.fsf@wheatstone.g10code.de> On Sat, 19 Nov 2016 21:51, davidadamson.md at gmail.com said: > *** The config script /usr/local/bin/gpg-error-config was > *** built for x86_64-pc-linux-gnu and thus may not match the > *** used host x86_64-unknown-linux-gnu. This warning is a bit unfortunate but it is harmless. Both platform triplets indicate the same platform. The names of these triplets are sometimes changed and when you are using an older version of a library you may see such a warning. The reason why we print this warning is to be able to figure out build problems in case of non properly installed systems where a native library and a library used for cross-compiling are mixed up. > checking for Qt5Core >= 5.0.0 Qt5Gui >= 5.0.0 Qt5Widgets >= 5.0.0... > ./configure: line 9744: no: command not found The "no" is a minor bug in the configure script - it is mostly harmless. > configure: error: No pinentry enabled. You need to install the appropriate development package for the GUI platform. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Mon Nov 21 10:28:47 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Nov 2016 10:28:47 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161120203740.CAB33100A200@remailer.paranoici.org> (Carola Grunwald's message of "Sun, 20 Nov 2016 20:37:40 +0000 (UTC)") References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> Message-ID: <87k2bxnpv4.fsf@wheatstone.g10code.de> On Sun, 20 Nov 2016 21:37, caro at nymph.paranoici.org said: >>Is there any chance to get that disentangled, maybe by defining a >>separate secret key directory for each public .kbx keyring in use? No. > The silence makes me believe that what I described is intended behavior, > not a 2.1 design flaw. I'd like to know whether that's correct. Any Correct. The gpg-agent takes care of private keys and does not know about gpg or gpgsm. Deleting a private key is not easy because it may be used by several protocols. This is the reason you see an extra confirmation message when trying to delete a private key. BTW, the use of the --keyring option is in general not a good idea. We would very much like to entirely get rid of them due to the problems assocciated with that kludge (or well, that upward compatibility with PGP). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Mon Nov 21 10:30:51 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Nov 2016 10:30:51 +0100 Subject: How to prevent passphrase caching in 2.1 In-Reply-To: <20161120211814.CDD7C100A216@remailer.paranoici.org> (Carola Grunwald's message of "Sun, 20 Nov 2016 21:18:14 +0000 (UTC)") References: <20161120211814.CDD7C100A216@remailer.paranoici.org> Message-ID: <87fumlnpro.fsf@wheatstone.g10code.de> On Sun, 20 Nov 2016 22:18, caro at nymph.paranoici.org said: > to gpg-agent.conf the official way to deactivate passphrase caching > completely and make GnuPG only use the term transferred with the Please describe what you want to achieve. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From peter at digitalbrains.com Mon Nov 21 12:04:51 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 21 Nov 2016 12:04:51 +0100 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: References: Message-ID: <543a356c-5014-94d0-c96b-b31c74e4c7a4@digitalbrains.com> On 20/11/16 22:48, Anton Marchukov wrote: >> Which version, GnuPG 2.0 or 2.1? I think you can use 2.1 to reach the desired >> outcome without difficulty, even if it might be a bit non-standard. > > I have 2.1.11 Ah! I don't have time right now, but once I do, I'll try to see to write up some instructions... > Ok. So I am using 2.1 and I have read the referenced threads and the > both options assume that you either generate key of the card or > maintain a copy of that. Anybody was able to do that with generating > keys on the card always and not extracting them from the card as the > copy either? With 2.1, maybe it's possible. I'm curious to try it out. It might work. It might not. >> rather trust GnuPG's random number generator than the one on a cheap smartcard >> (or any smartcard for that matter). So I would recommend to not use the on-card >> key generation feature anyway. > > That's quite an interesting point that I have not thought about. Do > you have any references to the papers that I can read on this subject? No, but I remember Werner Koch saying he'd rather not use the on-card RNG. I tried to find this, but the best I could find was his statement that you don't want regular DSA on smartcard[1]. As I understand it, that is because of the risk of a failing RNG. Signature generation in DSA requires a good quality random number, otherwise it might be possible to reconstruct the private key through signatures. In the time since that post, GnuPG gained deterministic DSA, which no longer requires randomness for signature generation. > But same time I find it a > kind of overkill over key generation on the card for my use cases. That is of course your choice. However, people have done analysis of large amounts of public keys on keyservers before. If someone discovers a way to exploit a weakness in the OpenPGP Card on-card RNG, they might be able to analyse massive amounts of public keys and put the results on the internet for everyone to see. Just to show they can, and win the internets. Even if you don't suspect adversaries who target you specifically, you might be caught in a massive untargeted sweep. I'm just thinking out loud here, it's just something that came to mind. It's your decision, I'm just trying to help you make it an informed decision. Maybe you think I'm being overly paranoid. I'd rather have you consider it and then dismiss it than not think of it at all. HTH, Peter. [1] https://lists.gnupg.org/pipermail/gnupg-users/2013-October/047841.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 peter at digitalbrains.com Mon Nov 21 12:08:29 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 21 Nov 2016 12:08:29 +0100 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: References: Message-ID: On 20/11/16 22:50, Anton Marchukov wrote: > I think you will have to keep it as backup too in case you will want > to add another smartcard with a new subkey to an existing key or not? Oh, good point! Maybe it's possible without on-disk keys, I'll try it out later. Otherwise: yes, it would be impossible to add new subkeys. > Although if air gaped machine is secure then encrypting backup using > the smartcard itself and removing the unencrypted copy will do the > trick as well. I'm not too sure about "removing the unencrypted copy", though. I'd much rather not have the key hit the disk anyway. By using a Linux Live CD and physically removing the cable from the hard disk. 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 andrewg at andrewg.com Mon Nov 21 12:24:50 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 21 Nov 2016 11:24:50 +0000 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: <543a356c-5014-94d0-c96b-b31c74e4c7a4@digitalbrains.com> References: <543a356c-5014-94d0-c96b-b31c74e4c7a4@digitalbrains.com> Message-ID: <4ec5bf17-dc23-e23a-d2db-98ae32e6ebc2@andrewg.com> On 21/11/16 11:04, Peter Lebbing wrote: >>> >> rather trust GnuPG's random number generator than the one on a cheap smartcard >>> >> (or any smartcard for that matter). So I would recommend to not use the on-card >>> >> key generation feature anyway. >> > >> > That's quite an interesting point that I have not thought about. Do >> > you have any references to the papers that I can read on this subject? > No, but I remember Werner Koch saying he'd rather not use the on-card > RNG. I tried to find this, but the best I could find was his statement > that you don't want regular DSA on smartcard[1]. As I understand it, > that is because of the risk of a failing RNG. Have a look at the graphs on page 7 of this PDF: https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_svenda.pdf tl;dr: Some smart cards have *shockingly* poor RNG implementations. 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 davidadamson.md at gmail.com Mon Nov 21 15:13:20 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Mon, 21 Nov 2016 09:13:20 -0500 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: <87oa19nqez.fsf@wheatstone.g10code.de> References: <87oa19nqez.fsf@wheatstone.g10code.de> Message-ID: On Mon, Nov 21, 2016 at 4:16 AM, Werner Koch wrote: >> configure: error: No pinentry enabled. > > You need to install the appropriate development package for the GUI > platform. I looked for a GUI platform but had no idea what it's called where to find it and why I need a GUI if I plan on using purely command line interface. Would It be: "GPA is a graphical frontend to GnuPG" Thanks for your help! From caro at nymph.paranoici.org Mon Nov 21 15:20:04 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Mon, 21 Nov 2016 14:20:04 +0000 (UTC) Subject: How to prevent passphrase caching in 2.1 References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> Message-ID: <20161121142004.416101032265@remailer.paranoici.org> Hello Werner, thanks for your fast reply. On Mon, 21 Nov 2016 10:30:51 +0100, you wrote: >On Sun, 20 Nov 2016 22:18, caro at nymph.paranoici.org said: > >> to gpg-agent.conf the official way to deactivate passphrase caching >> completely and make GnuPG only use the term transferred with the > >Please describe what you want to achieve. It's about a multi-user mail/news server, where multithreaded message processing for all user accounts is done by a single gpg agent. As for each single decryption task only a defined passphrase is allowed to be used it's essential to have caching, which implicates the risk of unauthorized passphrase usage, strictly deactivated. Kind regards Caro From juanmi.3000 at gmail.com Mon Nov 21 16:22:01 2016 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Mon, 21 Nov 2016 16:22:01 +0100 Subject: gpg-agent crashes on Windows 10 In-Reply-To: <1479458736.5366.31.camel@net.in.tum.de> References: <1479226791.3050.16.camel@net.in.tum.de> <87polutucw.fsf@wheatstone.g10code.de> <1479458736.5366.31.camel@net.in.tum.de> Message-ID: <07fdd855-0f38-e942-4504-e1726c77a2ca@gmail.com> On 2016-11-18 at 09:45, Matthias Wachs wrote: > Hi Werner, hi all, > > 2.1.12 may be outdated but is the latest version for Windows (available on > Heise): > https://www.heise.de/download/product/gnu-privacy-guard-gnupg-1677/download > > The version included in gpg4win is even older: > https://www.gpg4win.org/download.html > -> GnuPG 2.0.30 I can't tell about heise.de version but as Peter Lebbing has said, GnuPG 2.0.30 is the latest stable branch version. For GnuPG 2.1.16 download it from www.gnupg.org[1] or if you like Gpg4Win you can install the Gpg4Win 3.0.0 Beta[2] which contains 2.1.15 (it could have been 2.1.16 but the last beta version was released a few days earlier to the 2.1.16 release) [1]: https://www.gnupg.org/download/index.html#binary (Second download link on Windows row) [2]: https://files.gpg4win.org/Beta/ -- 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 stebe at mailbox.org Mon Nov 21 18:33:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Mon, 21 Nov 2016 17:33:00 +0000 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: References: <87oa19nqez.fsf@wheatstone.g10code.de> Message-ID: <7d2dd74e-3dab-5e8a-dacd-2d8585d288be@mailbox.org> Hi, David Adamson: > On Mon, Nov 21, 2016 at 4:16 AM, Werner Koch wrote: > >>> configure: error: No pinentry enabled. >> >> You need to install the appropriate development package for the GUI >> platform. > > I looked for a GUI platform but had no idea what it's called where to > find it and why I need a GUI if I plan on using purely command line > interface. > > Would It be: > "GPA is a graphical frontend to GnuPG" > > Thanks for your help! If you only want to use the command line (i.e. text mode) and do not need a GUI, you'll probably need the pinentry-curses package. Install it by typing: sudo apt-get install pinentry-curses There's one thing I don't really understand: In your first mail you talked about your laptop with Debian Jessie, and that it has gnupg 1.4.18 pre-installed. I think the whole info should be: Debian Jessie (standard install) has gnupg 1.4.18 AND gnupg 2.0.26 pre-installed. Or how would you be able to issue a command gpg2 at all? Or do you have a text-mode only pre-installed Debian Jessie with both gnupg versions? HTH Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From davidadamson.md at gmail.com Mon Nov 21 19:51:14 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Mon, 21 Nov 2016 13:51:14 -0500 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: <7d2dd74e-3dab-5e8a-dacd-2d8585d288be@mailbox.org> References: <87oa19nqez.fsf@wheatstone.g10code.de> <7d2dd74e-3dab-5e8a-dacd-2d8585d288be@mailbox.org> Message-ID: On Mon, Nov 21, 2016 at 12:33 PM, Stephan Beck wrote: > Hi, > > David Adamson: > > If you only want to use the command line (i.e. text mode) and do not > need a GUI, you'll probably need the pinentry-curses package. Install it > by typing: sudo apt-get install pinentry-curses Thanks for the tip. I just tried your suggestion, installed pinentry-curses, which installed without error but I am getting the same error when trying generate keys, just as before. > There's one thing I don't really understand: > In your first mail you talked about your laptop with Debian Jessie, and > that it has gnupg 1.4.18 pre-installed. I think the whole info should > be: Debian Jessie (standard install) has gnupg 1.4.18 AND gnupg 2.0.26 > pre-installed. Or how would you be able to issue a command gpg2 at all? > Or do you have a text-mode only pre-installed Debian Jessie with both > gnupg versions? You're right there's some information I accidentally left out. I have a standard debian 8 jessie install which included gnupg v 1.4.18. I then downloaded and installed from gnupg.org the source code for version GnuPG modern 2.1.16 and needed libraries. With that said you can pick up with the opening line of this thread. I hope I didn't leave anything out this time. I'm really starting to feel I missed a step along the way and messed up the install. I suppose I could do a fresh install of the OS and just use the 1.4.18 version otherwise I'm not aware of what to do differently on my second attempt. I feel as though I followed the instructions. It probably some basic linux config that I'm too new to know about, LOL. Thanks. From stebe at mailbox.org Tue Nov 22 01:58:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Tue, 22 Nov 2016 00:58:00 +0000 Subject: GPGSM detached signature without auth attributes In-Reply-To: References: Message-ID: <901bceb3-c7bc-76fa-c034-0e01149f9fce@mailbox.org> Hi Jerney, Jernej Kos: > Hello! > > I would like to use GPGSM to sign a Linux kernel module with a private > key stored on an OpenPGP smartcard. As to the OpenPGP card 2.1 [1] specification, you can store the private key of an X.509 certificate on card (Data Object Cardholder Certificate, TAG 7F21) ONLY for using it for authentication purposes in a client/server environment, not for signing. In version 3.0 of the OpenPGP card specification the decipher and sign capabilities for use with an PKIX/X.509 certificate have been introduced. Unfortunately I don't know of any existing OpenPGP smart card that implements version 3.0 [2]. So, I guess, without even discussing the possibility (and further details) of using a "smartcard-based" X.509 certificate's private key with gpgsm for digitally signing a file skipping/overriding/ignoring CMS's auth attributes for signing a kernel module, it is not (yet) feasible (in practice). My 2 cent Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Tue Nov 22 02:15:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Tue, 22 Nov 2016 01:15:00 +0000 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: References: <87oa19nqez.fsf@wheatstone.g10code.de> <7d2dd74e-3dab-5e8a-dacd-2d8585d288be@mailbox.org> Message-ID: <0e0236c3-3fde-0395-3b50-8ebba8c14ca8@mailbox.org> Hi, David Adamson: > On Mon, Nov 21, 2016 at 12:33 PM, Stephan Beck wrote: >> Hi, >> >> David Adamson: >> >> If you only want to use the command line (i.e. text mode) and do not >> need a GUI, you'll probably need the pinentry-curses package. Install it >> by typing: sudo apt-get install pinentry-curses > > Thanks for the tip. I just tried your suggestion, installed > pinentry-curses, which installed without error but I am getting the > same error when trying generate keys, just as before. Ah, I forgot one thing: you have to add the following to your ~/.bashrc file: GPG_TTY=$(tty) export GPG_TTY Does it work now? HTH Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From caro at nymph.paranoici.org Tue Nov 22 02:54:22 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Tue, 22 Nov 2016 01:54:22 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <87k2bxnpv4.fsf@wheatstone.g10code.de> Message-ID: <20161122015422.D560F103215E@remailer.paranoici.org> Hello Werner! On Mon, 21 Nov 2016 10:28:47 +0100, you wrote: >On Sun, 20 Nov 2016 21:37, caro at nymph.paranoici.org said: > >>>Is there any chance to get that disentangled, maybe by defining a >>>separate secret key directory for each public .kbx keyring in use? > >No. > >> The silence makes me believe that what I described is intended behavior, >> not a 2.1 design flaw. I'd like to know whether that's correct. Any > >Correct. The gpg-agent takes care of private keys and does not know >about gpg or gpgsm. Deleting a private key is not easy because it may >be used by several protocols. This is the reason you see an extra >confirmation message when trying to delete a private key. > >BTW, the use of the --keyring option is in general not a good idea. We >would very much like to entirely get rid of them due to the problems >assocciated with that kludge (or well, that upward compatibility with >PGP). IMHO for several reasons there has to be some method to structure larger key depositories. Just to name a few ... - Performance drops with the number of available keys, especially when data lacking a key-ID (--throw-keyids) have to be decrypted. - In a multi-user environment the key owning recipient has to be granted access to the private key with some sender being restricted to only use the public key no matter whether there's any chance s/he guesses the correct passphrase. - There's no reason to have keys used for different tasks together on a single keyring, as key management gets chaotic with such a hodgepodge. And confusion would increase even more trying to mimic v1.4 by running multiple GPG Agents dedicated to tasks which have to be separated. Even if there's no chance to return to completely separated keyrings, which without doubt have stood the test of time in GnuPG 1.4, I think there at least has to be a method to group public as well as private keys in some way to allow the selection of only one or a few of these subsets to take part in processing. Currently for example apart from the accidental deletion of private keys I earlier described I don't see any concept of dealing with orphaned files in the private-keys and openpgp-revocs directory. An Agent managing all lists of key subsets would gain the information needed to solve all these problems, for example delete the private key file when all list entries associated with that privat key are removed. Though not very familiar with GnuPG internals I hope I made my concerns somewhat clearer. Good night, and good luck Caro From stebe at mailbox.org Tue Nov 22 08:22:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Tue, 22 Nov 2016 07:22:00 +0000 Subject: GPGSM detached signature without auth attributes In-Reply-To: <901bceb3-c7bc-76fa-c034-0e01149f9fce@mailbox.org> References: <901bceb3-c7bc-76fa-c034-0e01149f9fce@mailbox.org> Message-ID: <92a24b20-a573-1c0c-0e09-88aa1ff3ffb6@mailbox.org> Hi, I forgot to include the links to the docs. [1] http://g10code.com/docs/openpgp-card-2.1.pdf [2] http://g10code.com/docs/openpgp-card-3.0.pdf Stephan Beck: > Hi Jerney, > > Jernej Kos: >> Hello! >> >> I would like to use GPGSM to sign a Linux kernel module with a private >> key stored on an OpenPGP smartcard. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jernej at kos.mx Tue Nov 22 09:18:21 2016 From: jernej at kos.mx (Jernej Kos) Date: Tue, 22 Nov 2016 09:18:21 +0100 Subject: GPGSM detached signature without auth attributes In-Reply-To: <901bceb3-c7bc-76fa-c034-0e01149f9fce@mailbox.org> References: <901bceb3-c7bc-76fa-c034-0e01149f9fce@mailbox.org> Message-ID: <999f4964-734b-8cdf-76af-b7c72cb3ed4a@kos.mx> Hello! Not sure about what you mean with the OpenPGP card not supporting signing? I have set gpgsm to use the signing key on the OpenPGP card (in key slot 1) for generating X509 certificates and CMS (S/MIME) signatures by doing: gpgsm --learn-card gpgsm --gen-key And selecting an existing key on the OpenPGP card in the key slot for signing. This is using GnuPG 2.1.15. I can successfully use gpgsm to sign an arbitrary file in detached mode and can validate the signature using "openssl cms -verify". So the signing part seems to work. The only problem is that such a signature is rejected by the kernel due to containing signedAttrs (the CMS structure can be inspected by running "openssl cms -cmsout -inform DER -print -in signature.der"). I've tried removing the signed attributes from the CMS by hacking the source of libksba and the resulting file doesn't have signedAttrs, but for some reason the signature is then wrong. So I have to look into this more. Thanks! Jernej On 22. 11. 2016 01:58, Stephan Beck wrote: > Hi Jerney, > > Jernej Kos: >> Hello! >> >> I would like to use GPGSM to sign a Linux kernel module with a private >> key stored on an OpenPGP smartcard. > > As to the OpenPGP card 2.1 [1] specification, you can store the private > key of an X.509 certificate on card (Data Object Cardholder Certificate, > TAG 7F21) ONLY for using it for authentication purposes in a > client/server environment, not for signing. > In version 3.0 of the OpenPGP card specification the decipher and sign > capabilities for use with an PKIX/X.509 certificate have been > introduced. Unfortunately I don't know of any existing OpenPGP smart > card that implements version 3.0 [2]. > So, I guess, without even discussing the possibility (and further > details) of using a "smartcard-based" X.509 certificate's private key > with gpgsm for digitally signing a file skipping/overriding/ignoring > CMS's auth attributes for signing a kernel module, it is not (yet) > feasible (in practice). > > My 2 cent > > Stephan > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Nov 22 08:06:31 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Nov 2016 08:06:31 +0100 Subject: GPGSM detached signature without auth attributes In-Reply-To: (Jernej Kos's message of "Sun, 20 Nov 2016 20:47:25 +0100") References: Message-ID: <87r364j8nc.fsf@wheatstone.g10code.de> On Sun, 20 Nov 2016 20:47, jernej at kos.mx said: > detached CMS signature. The kernel requires that the CMS does not > contain any authenticated attributes and it refuses to validate the > signature otherwise [1]. That is unfortunate because all modern implementations use the indirect signing method (using the attribute 1.2.840.113549.1.9.4). GPGSM is able to verify the old direct signing method but it can't create such an old signature. To change this we need to extend libksba, which I believe can be done without updating the API. Also we need to add an option to gpgsm (easy) and implement the old method (a few hours). Instead of doing that I would suggest to extend Linux and implement verification of the indirect signature. An update to gpgsm would then be simple by adding an option to not emit any of the other signed attributes, Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From stebe at mailbox.org Tue Nov 22 11:02:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Tue, 22 Nov 2016 10:02:00 +0000 Subject: GPGSM detached signature without auth attributes In-Reply-To: <999f4964-734b-8cdf-76af-b7c72cb3ed4a@kos.mx> References: <901bceb3-c7bc-76fa-c034-0e01149f9fce@mailbox.org> <999f4964-734b-8cdf-76af-b7c72cb3ed4a@kos.mx> Message-ID: <89e4de71-6fdb-54da-ca8c-c1c8c6cdd092@mailbox.org> Hi, Jernej Kos: > Hello! > > Not sure about what you mean with the OpenPGP card not supporting > signing? I have set gpgsm to use the signing key on the OpenPGP card (in > key slot 1) for generating X509 certificates and CMS (S/MIME) signatures > by doing: > > gpgsm --learn-card > gpgsm --gen-key > > And selecting an existing key on the OpenPGP card in the key slot for > signing. This is using GnuPG 2.1.15. > [...] sorry, I obviously got this wrong. I'll have to take a deeper look into gpgsm and its use with smart cards. Thanks for your answer. Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jernej at kos.mx Tue Nov 22 11:08:50 2016 From: jernej at kos.mx (Jernej Kos) Date: Tue, 22 Nov 2016 11:08:50 +0100 Subject: GPGSM detached signature without auth attributes In-Reply-To: <87r364j8nc.fsf@wheatstone.g10code.de> References: <87r364j8nc.fsf@wheatstone.g10code.de> Message-ID: <27e02a60-331e-1731-6dd1-cbb4ef3e09bd@kos.mx> Hello! On 22. 11. 2016 08:06, Werner Koch wrote: > That is unfortunate because all modern implementations use the > indirect signing method (using the attribute 1.2.840.113549.1.9.4). > GPGSM is able to verify the old direct signing method but it can't > create such an old signature. This explains why my quick hack with just removing the signed attributes didn't work (I could remove everything but the messageDigest). The indirect method uses the messageDigest that is part of the signed attributes, right? I've also looked into how OpenSSL does it and noticed that the signing part is done differently when the CMS_NOATTR flag is passed. I've quickly looked at the CMS RFCs, but they seem quite heavy. I would be grateful for any quick pointers you might have. > Instead of doing that I would suggest to extend Linux and implement > verification of the indirect signature. An update to gpgsm would then > be simple by adding an option to not emit any of the other signed > attributes, Yes, that would probably be the best option and I am not sure why they didn't do it this way. I also don't like that the default way to sign things in the Linux kernel assumes that the private key is available in a local file, as this is way less secure than storing it in a HSM. Had they used gpgsm from the start, they would also find the need to support indirect signatures. Unfortunately I need this in a current system, so I might just look around libksba when I find some more time. Thanks for making things more clear! Jernej -------------- 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 Nov 22 11:41:27 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 22 Nov 2016 11:41:27 +0100 Subject: How to prevent passphrase caching in 2.1 In-Reply-To: <20161121142004.416101032265@remailer.paranoici.org> References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161121142004.416101032265@remailer.paranoici.org> Message-ID: On 21/11/16 15:20, Carola Grunwald wrote: > As for each single decryption task only a defined passphrase is > allowed to be used it's essential to have caching, which implicates > the risk of unauthorized passphrase usage, strictly deactivated. Why do you lump these users together? At a first glance it seems more logical that they have separate system accounts, or at the least separate GnuPG homedirs (and hence agents). They shouldn't even have access to the encrypted private key in the first place. 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 Tue Nov 22 11:44:57 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 22 Nov 2016 11:44:57 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161122015422.D560F103215E@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <87k2bxnpv4.fsf@wheatstone.g10code.de> <20161122015422.D560F103215E@remailer.paranoici.org> Message-ID: On 22/11/16 02:54, Carola Grunwald wrote: > - In a multi-user environment the key owning recipient has to be granted > access to the private key with some sender being restricted to only use > the public key no matter whether there's any chance s/he guesses the > correct passphrase. That's what filesystem permissions are for? Like I just said in the other mail, if each user has their own system account, they can't access the files containing the encrypted private keys of other users. 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 caro at nymph.paranoici.org Tue Nov 22 17:20:26 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Tue, 22 Nov 2016 16:20:26 +0000 (UTC) Subject: How to prevent passphrase caching in 2.1 References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161121142004.416101032265@remailer.paranoici.org> Message-ID: <20161122162026.CF0C2100B129@remailer.paranoici.org> Peter Lebbing wrote: >On 21/11/16 15:20, Carola Grunwald wrote: >> As for each single decryption task only a defined passphrase is >> allowed to be used it's essential to have caching, which implicates >> the risk of unauthorized passphrase usage, strictly deactivated. > >Why do you lump these users together? At a first glance it seems more >logical that they have separate system accounts, or at the least >separate GnuPG homedirs (and hence agents). They don't have any system account at all. These are users of a messaging system, only allowed to access its POP3, SMTP and NNTP service. > >They shouldn't even have access to the encrypted private key in the >first place. They don't have direct access to any key. Nevertheless by using someone else's cached passphrase with 2.1 and its all-embracing keyring they may succeed in decoding data not meant for them. Kind regards Caro From caro at nymph.paranoici.org Tue Nov 22 19:17:10 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Tue, 22 Nov 2016 18:17:10 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <87k2bxnpv4.fsf@wheatstone.g10code.de> <20161122015422.D560F103215E@remailer.paranoici.org> Message-ID: <20161122181710.2923D103215E@remailer.paranoici.org> Peter Lebbing wrote: >On 22/11/16 02:54, Carola Grunwald wrote: >> - In a multi-user environment the key owning recipient has to be granted >> access to the private key with some sender being restricted to only use >> the public key no matter whether there's any chance s/he guesses the >> correct passphrase. > >That's what filesystem permissions are for? Like I just said in the >other mail, if each user has their own system account, they can't access >the files containing the encrypted private keys of other users. You seriously recommend to run a dedicated gpg-agent instance for each of dozens if not hundreds of mail service users? You have to consider that these gpg-agent services are meant to persistent beyond the initial data processing call. Compared with my current single-agent approach with task-queuing not really resource-efficient, is it? Kind regards Caro From andrewg at andrewg.com Tue Nov 22 19:25:29 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 22 Nov 2016 18:25:29 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161122181710.2923D103215E@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <87k2bxnpv4.fsf@wheatstone.g10code.de> <20161122015422.D560F103215E@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> Message-ID: <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> On 22/11/16 18:17, Carola Grunwald wrote: > You seriously recommend to run a dedicated gpg-agent instance for each > of dozens if not hundreds of mail service users? gpg is intended to run on the client, not the server. A mail service operator should not hold the private keys of its users, never mind perform encryption operations on their behalf. I would question the design of your architecture if you feel this is necessary. 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 peter at digitalbrains.com Tue Nov 22 19:44:20 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 22 Nov 2016 19:44:20 +0100 Subject: How to prevent passphrase caching in 2.1 In-Reply-To: <20161122162026.CF0C2100B129@remailer.paranoici.org> References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161121142004.416101032265@remailer.paranoici.org> <20161122162026.CF0C2100B129@remailer.paranoici.org> Message-ID: <915f84a9-2b95-75eb-3ffa-d79f8ae5d000@digitalbrains.com> On 22/11/16 17:20, Carola Grunwald wrote: > They don't have any system account at all. These are users of a > messaging system, only allowed to access its POP3, SMTP and NNTP > service. Perhaps 1.4 is the best release for you... you'll miss out on Elliptic Curve, but other than that, it's still a supported release. > They don't have direct access to any key. Nevertheless by using someone > else's cached passphrase with 2.1 and its all-embracing keyring they may > succeed in decoding data not meant for them. Perhaps you should implement access control in your frontend, instead of asking the agent to perform access control, for which it was not intended, AFAIK. It sounds like you just want the ability to work with OpenPGP material, rather than the user-centric model the agent seems to correspond to. When GnuPG gives you a square peg, you'll have to build your own adapter before it fits in a round hole ;). By the way, I'm not recommending anything (this in response to your "do you seriously recommend..."). I know nothing about your application or what you demand of it. I'm merely trying to give you directions to look in, while you search for the correct architecture of your application. 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 rjh at sixdemonbag.org Tue Nov 22 20:52:04 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 22 Nov 2016 14:52:04 -0500 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <87k2bxnpv4.fsf@wheatstone.g10code.de> <20161122015422.D560F103215E@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> Message-ID: <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> > gpg is intended to run on the client, not the server. A mail service operator > should not hold the private keys of its users, never mind perform encryption > operations on their behalf. I would question the design of your architecture if > you feel this is necessary. I concur. This post is agreement, not dissent. A user ID on a key makes an assertion: "The person named X is in control of this certificate." But in this architecture the end-user *isn't* in control. You remain in complete control of the private certificate. You have the power to completely undermine the system. So for that reason, it seems strange to me that your users would have their own private certificates -- what, precisely, *could* they certify? Likewise, a signature on a message makes an assertion: "This message went through the hands of the person who controlled this certificate, and has not been altered since then." (Signatures do not prove authorship: that's a common misconception. If Alice sends Bob a signed message saying "I love you", and Bob strips off the signature, places his own on it, and sends it on to Charlene, Charlene will have a message Alice authored but which Bob signed. Charlene can prove the message went through Bob's hands, but she cannot prove who wrote it.) But if I'm on your system, and you're the one doing signatures for me, then what does a signature which claims to be from me really attest? Your scheme appears to deeply subvert the meaning of signatures and certificate ownership. This is crazy. Maybe it's crazy enough to be a breakthrough, but so far I'm not seeing it. From dkg at fifthhorseman.net Tue Nov 22 21:09:46 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 22 Nov 2016 15:09:46 -0500 Subject: How to prevent passphrase caching in 2.1 In-Reply-To: <20161122162026.CF0C2100B129@remailer.paranoici.org> References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161121142004.416101032265@remailer.paranoici.org> <20161122162026.CF0C2100B129@remailer.paranoici.org> Message-ID: <87k2bvi8dx.fsf@alice.fifthhorseman.net> On Tue 2016-11-22 11:20:26 -0500, Carola Grunwald wrote: > They don't have direct access to any key. Nevertheless by using someone > else's cached passphrase with 2.1 and its all-embracing keyring they may > succeed in decoding data not meant for them. fwiw, the same concerns hold for a shared gpg-agent passphrase-cache from pre-2.1 versions of gpg as well, right? your model sounds like it needs to use a separate agent per user, regardless of which version of the agent you're using. --dkg From caro at nymph.paranoici.org Wed Nov 23 03:28:36 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Wed, 23 Nov 2016 02:28:36 +0000 (UTC) Subject: How to prevent passphrase caching in 2.1 References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161121142004.416101032265@remailer.paranoici.org> <20161122162026.CF0C2100B129@remailer.paranoici.org> <915f84a9-2b95-75eb-3ffa-d79f8ae5d000@digitalbrains.com> Message-ID: <20161123022836.845501032265@remailer.paranoici.org> Peter Lebbing wrote: >On 22/11/16 17:20, Carola Grunwald wrote: >> They don't have any system account at all. These are users of a >> messaging system, only allowed to access its POP3, SMTP and NNTP >> service. > >Perhaps 1.4 is the best release for you... you'll miss out on Elliptic >Curve, but other than that, it's still a supported release. Sure, I like v1.4's small footprint and its reliability. But as the --faked-system-time option, important in my application for privacy reasons, wasn't backported to v1.4, I had to migrate to v2.1. I'm still not very confident in EC cryptography's strength nor am I interested in dealing with just another background service, which freezes every now and then and actively has to be stopped with my application to keep it portable. > >> They don't have direct access to any key. Nevertheless by using someone >> else's cached passphrase with 2.1 and its all-embracing keyring they may >> succeed in decoding data not meant for them. > >Perhaps you should implement access control in your frontend, instead of >asking the agent to perform access control, for which it was not >intended, AFAIK. There's server access control through a username/password combination, access to the corresponding PGP key is given by a usually unique base64 encoded 256-bit random number dedicated to the account. But if for decryption a cloud of unpredictable valid passphrases is used ... > It sounds like you just want the ability to work with >OpenPGP material, rather than the user-centric model the agent seems to >correspond to. When GnuPG gives you a square peg, you'll have to build >your own adapter before it fits in a round hole ;). Well, I didn't know that GnuPG follows a single-user strategy. Now I do. > >By the way, I'm not recommending anything (this in response to your "do >you seriously recommend..."). I know nothing about your application or >what you demand of it. I'm merely trying to give you directions to look >in, while you search for the correct architecture of your application. I'm truly sorry, no harm intended. Kind regards Caro From caro at nymph.paranoici.org Wed Nov 23 04:48:19 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Wed, 23 Nov 2016 03:48:19 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122015422.D560F103215E@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> Message-ID: <20161123034819.AD17F1032265@remailer.paranoici.org> "Robert J. Hansen" wrote: >> gpg is intended to run on the client, not the server. A mail service >operator >> should not hold the private keys of its users, never mind perform >encryption >> operations on their behalf. I would question the design of your >architecture if >> you feel this is necessary. > >I concur. This post is agreement, not dissent. > >A user ID on a key makes an assertion: "The person named X is in control of >this certificate." But in this architecture the end-user *isn't* in >control. You remain in complete control of the private certificate. You >have the power to completely undermine the system. So for that reason, it >seems strange to me that your users would have their own private >certificates -- what, precisely, *could* they certify? >But if I'm on your system, and you're the one doing signatures for me, then >what does a signature which claims to be from me really attest? > >Your scheme appears to deeply subvert the meaning of signatures and >certificate ownership. This is crazy. Maybe it's crazy enough to be a >breakthrough, but so far I'm not seeing it. Hi Andrew, hi Robert, many thanks for your replies. But why does a person have to be in control of a signature key? Why not a server in the name of a company resp. its employees. Talking about mail, when transmitting messages we currently have two encryption principles in common use. There's server-to-server security provided usually by SSL/TLS, where nevertheless the communication partners can't influence the all-knowing servers building the route. And there's true end-to-end cryptography done by PGP/SMIME at the client applications, which also leaks valid (envelope) information thinking of message size and structure and the enormously talkative header section. Now let there be a corporate server, which 'cleans' the header of outgoing mail, adds some nonsense data of random size and encrypts the result into a single PGP message block, which it finally forwards after adding the recipients' mail addresses as the only header line. The message block's signature only documents the identity of the sender who logged into the server, and, btw, with --faked-system-time doesn't even leak whether it was processed at business hours or at midnight. At the recipient's corporate server that mail is decrypted using the recipient's key, the original mail structure restored, a line representing the signature status added to the header and the result delivered to the POP3 client. This concept of an enhanced transport security layer offers external adversaries least possible information while it doesn't preclude the sender from adding another inner encryption/signature layer created with a key she herself controls. Hope that helps to understand what I'm aiming at. Kind regards Caro From davidadamson.md at gmail.com Wed Nov 23 06:29:10 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Wed, 23 Nov 2016 00:29:10 -0500 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: <0e0236c3-3fde-0395-3b50-8ebba8c14ca8@mailbox.org> References: <87oa19nqez.fsf@wheatstone.g10code.de> <7d2dd74e-3dab-5e8a-dacd-2d8585d288be@mailbox.org> <0e0236c3-3fde-0395-3b50-8ebba8c14ca8@mailbox.org> Message-ID: On Mon, Nov 21, 2016 at 8:15 PM, Stephan Beck wrote: > Ah, I forgot one thing: you have to add the following to your ~/.bashrc > file: > GPG_TTY=$(tty) > export GPG_TTY > > Does it work now? > > HTH > > Stephan Stephan I updated the .bashrc file in my home directory, still got the same error, so I restarted the system but unfortunately the error remains. Thanks for the assistance. From davidadamson.md at gmail.com Wed Nov 23 07:44:51 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Wed, 23 Nov 2016 01:44:51 -0500 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: <87oa19nqez.fsf@wheatstone.g10code.de> References: <87oa19nqez.fsf@wheatstone.g10code.de> Message-ID: On Mon, Nov 21, 2016 at 4:16 AM, Werner Koch wrote: > >> configure: error: No pinentry enabled. > > You need to install the appropriate development package for the GUI > platform. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. Werner was GTK+-2.0 a potential option for an appropriate development package for the GUI platform? After installing GTK+-2.0 I was successfully able to complete the install of pinentry, However during the --gen-key process while generating entropy I got the following errors: We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: lookup_hashtable failed: Unknown system error gpg: trustdb: searching trust record failed: Unknown system error gpg: Error: The trustdb is corrupted. gpg: You may try to re-create the trustdb using the commands: gpg: cd ~/.gnupg gpg: gpg --export-ownertrust > otrust.tmp gpg: rm trustdb.gpg gpg: gpg --import-ownertrust < otrust.tmp gpg: If that does not work, please consult the manual So with one issue solved now on to the next. I'm sorry but this can't be right. Anyone know why I am running into so many issues? From caro at nymph.paranoici.org Wed Nov 23 09:46:57 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Wed, 23 Nov 2016 08:46:57 +0000 (UTC) Subject: How to prevent passphrase caching in 2.1 References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161121142004.416101032265@remailer.paranoici.org> <20161122162026.CF0C2100B129@remailer.paranoici.org> <87k2bvi8dx.fsf@alice.fifthhorseman.net> Message-ID: <20161123084657.9513410320F5@remailer.paranoici.org> Daniel Kahn Gillmor wrote: >On Tue 2016-11-22 11:20:26 -0500, Carola Grunwald wrote: >> They don't have direct access to any key. Nevertheless by using someone >> else's cached passphrase with 2.1 and its all-embracing keyring they may >> succeed in decoding data not meant for them. > >fwiw, the same concerns hold for a shared gpg-agent passphrase-cache >from pre-2.1 versions of gpg as well, right? Of course. > >your model sounds like it needs to use a separate agent per user, >regardless of which version of the agent you're using. With GnuPG 1.4 I had no agent. And, in case it is, I've no idea why with 2.x such a passphrase cache with all its risks has to be mandatory. Kind regards Caro From andrewg at andrewg.com Wed Nov 23 10:53:45 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 23 Nov 2016 09:53:45 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161123034819.AD17F1032265@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122015422.D560F103215E@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> Message-ID: <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> > On 23 Nov 2016, at 03:48, Carola Grunwald wrote: > > But why does a person have to be in control of a signature key? Why not > a server in the name of a company resp. its employees. There is no problem having a server in control of a key. Just so long as we understand that the key is now the *server's* key, not the user's. And there's no point in the server having multiple keys when the same information can be conveyed using a standardised header that's signed by a shared key. All you're saying with the signature is "the sender of this email appears to have authenticated to this server using X credentials", where the credentials in this case are equivalent to username/password. It sounds to me like you're trying to reinvent DKIM. > There's server-to-server security > provided usually by SSL/TLS, where nevertheless the communication > partners can't influence the all-knowing servers building the route. True. But this appears to be unrelated to your proposal. > And > there's true end-to-end cryptography done by PGP/SMIME at the client > applications, which also leaks valid (envelope) information thinking of > message size and structure and the enormously talkative header section. There are ways around this, such as attaching the real message as a PGP encrypted attachment to a generic form letter (as per Facebook), or alternatively encrypting the header values individually (as per memoryhole). > and, btw, with --faked-system-time doesn't even > leak whether it was processed at business hours or at midnight. But the received: headers of the message will leak this anyway. Unless you configure your mail queue to only run once a day. If you are worried about an attacker on the wire doing statistical analysis of your message sizes and patterns of use, you will probably have to go the whole hog and transport over Tor. And even that is no panacea. > At the > recipient's corporate server that mail is decrypted using the > recipient's key If the message is being automatically decrypted at the MTA then it provides no more security than TLS. And if we are only encrypting the content of the mail, then it provides less security than TLS, which encrypts everything from the handshake onwards. > a line > representing the signature status added to the header How does this provide the user with any more assurance than DKIM verification? > This concept of an enhanced transport security layer You have not described a transport security layer, but an MTA-to-MTA message encapsulation protocol. I don't see how this improves upon TLS+DKIM. A From peter at digitalbrains.com Wed Nov 23 11:19:06 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Nov 2016 11:19:06 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122015422.D560F103215E@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> Message-ID: On 23/11/16 10:53, Andrew Gallagher wrote: > If the message is being automatically decrypted at the MTA then it > provides no more security than TLS. I could concur with this statement if we amend it a little: when two MTA's are explicitly configured as TLS peers. They have to abort the mail exchange when TLS can't be negotiated and when the certificate is not as expected. "Expected" can mean: DN checking, issuer checking, fingerprint checking, perhaps CRL checking. There are many problems preventing succesful TLS on SMTP. It's trivial to downgrade, and certificates are only checked whether they are valid in the general sense, not even the DN is checked. I could MITM a connection to mail.example.org, present a valid certificate for mail.digitalbrains.com, and the peer would accept it even though it isn't valid *for mail.example.org*. Basically, it only works for passive adversaries. But since the OpenPGP-protected mail payload would also require explicit configuration, I don't think it is actually a disadvantage of TLS in this case... I'm not completely sure the "explicitly configured TLS" doesn't have a snag somewhere that complicates stuff more, though... I vaguely remember something like that from a presentation... 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 stebe at mailbox.org Wed Nov 23 11:14:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Wed, 23 Nov 2016 10:14:00 +0000 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: References: <87oa19nqez.fsf@wheatstone.g10code.de> <7d2dd74e-3dab-5e8a-dacd-2d8585d288be@mailbox.org> <0e0236c3-3fde-0395-3b50-8ebba8c14ca8@mailbox.org> Message-ID: Hi, David Adamson: > On Mon, Nov 21, 2016 at 8:15 PM, Stephan Beck wrote: >> Ah, I forgot one thing: you have to add the following to your ~/.bashrc >> file: >> GPG_TTY=$(tty) >> export GPG_TTY >> >> Does it work now? >> >> HTH >> >> Stephan > > Stephan I updated the .bashrc file in my home directory, still got the > same error, so I restarted the system but unfortunately the error > remains. > > Thanks for the assistance. You haven't answered the question if you only want to use text-mode. If you only use text-mode, add those lines mentioned to ~/.bashrc (or whatever may be your shell initialization file) and properly symlink /usr/bin/pinentry to the pinentry-curses you actually would like to use if you are using text-mode only, I don't know why it should not work. I refer you to the info gnupg manual and its appropriate section 10.3 Commonly Seen Problems. * The Curses based Pinentry does not work Maybe it's helpful for you and for all willing to help if you properly document the output of gen-key with the debug flag set to expert or guru level. gpg2 --gen-key --debug-level [expert|guru] Just a suggestion. Cheers, Stephan P.S. I now see that you have installed gtk-pinentry, so maybe I was wrong and you don't want to use text-mode. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Nov 23 11:38:32 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Nov 2016 11:38:32 +0100 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: References: <87oa19nqez.fsf@wheatstone.g10code.de> <7d2dd74e-3dab-5e8a-dacd-2d8585d288be@mailbox.org> <0e0236c3-3fde-0395-3b50-8ebba8c14ca8@mailbox.org> Message-ID: On 23/11/16 11:14, Stephan Beck wrote: > [...] and properly symlink > /usr/bin/pinentry to the pinentry-curses you actually would like to use > if you are using text-mode only, I don't know why it should not work. Good one, the symlink. It makes me wonder: is the agent looking in the right place for the pinentry? Perhaps if you compile your own GnuPG and install it in /usr/local/*, it will look for /usr/local/bin/pinentry only? The Debian jessie pinentry-curses package uses the alternatives system, which means that /usr/bin/pinentry will be a symlink to /etc/alternatives/pinentry, and if the only pinentry alternative is pinentry-curses, that will in turn be a symlink to /usr/bin/pinentry-curses. So by installing the Debian pinentry-curses package, David should already have a /usr/bin/pinentry. 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 Nov 23 11:44:34 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Nov 2016 11:44:34 +0100 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: References: <87oa19nqez.fsf@wheatstone.g10code.de> Message-ID: <8d192840-847a-a9cb-a122-ea170f13c203@digitalbrains.com> On 23/11/16 07:44, David Adamson wrote: > Werner was GTK+-2.0 a potential option for an appropriate development > package for the GUI platform? (I'm not Werner :) Yes, GTK+-2 is one of the pinentries. It's the one I use, on my XFCE Debian jessie. > gpg: lookup_hashtable failed: Unknown system error > gpg: trustdb: searching trust record failed: Unknown system error > gpg: Error: The trustdb is corrupted. > gpg: You may try to re-create the trustdb using the commands: > gpg: cd ~/.gnupg > gpg: gpg --export-ownertrust > otrust.tmp > gpg: rm trustdb.gpg > gpg: gpg --import-ownertrust < otrust.tmp > gpg: If that does not work, please consult the manual Argh. Just do the "rm trustdb.gpg", it contains the ownertrust values you have assigned to other people's keys (well, okay, as well as your own). I'm under the impression you're starting out cleanly, without keys, so the file would have been empty anyway. > So with one issue solved now on to the next. I'm sorry but this can't > be right. Anyone know why I am running into so many issues? Murphy, probably :-). I think it's just bad luck. 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 andrewg at andrewg.com Wed Nov 23 11:54:13 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 23 Nov 2016 10:54:13 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122015422.D560F103215E@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> Message-ID: <558edfd9-7f7c-9655-a5da-72224c0efe89@andrewg.com> On 23/11/16 10:19, Peter Lebbing wrote: > I could concur with this statement if we amend it a little: when two > MTA's are explicitly configured as TLS peers. Absolutely. But if you're using a non-standard protocol, then you also need to explicitly configure both sides. So in practical terms there is little advantage. Andrew. -------------- 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 Wed Nov 23 13:17:08 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Nov 2016 13:17:08 +0100 Subject: Primary and Signing Key on Different Smart Cards In-Reply-To: <543a356c-5014-94d0-c96b-b31c74e4c7a4@digitalbrains.com> References: <543a356c-5014-94d0-c96b-b31c74e4c7a4@digitalbrains.com> Message-ID: <78ed0c7b-ac5e-cd02-95e8-27264ab638f8@digitalbrains.com> On 21/11/16 12:04, Peter Lebbing wrote: > Ah! I don't have time right now, but once I do, I'll try to see to write > up some instructions... Here are instructions for doing this on 2.1. First let me point out: On 20/11/16 22:50, Anton Marchukov wrote: > I think you will have to keep it as backup too in case you will want > to add another smartcard with a new subkey to an existing key or not? With 2.1, everything goes fine and you can later add new subkeys without a backup! There are two ways to go about this. If you don't mind that the primary key will have Certify and Sign abilities, you can do everything on-card and no RSA private key material ever leaves the card. Note that you do use the on-card RNG in this case! We've discussed this. If you're being very strict and really only want the Certify ability on your primary key, I think you're forced to do a regular on-disk keygen for the primary key first. I don't think a Sign ability on your primary key will hurt in the usual case. It means you can use either smartcard to issue signatures on data. Signatures on subkeys or other people's keys are limited to the smartcard with the primary key, since only the primary key has the Certify ability. So let's start out with both Sign and Certify abilities on your primary key. I'm simply copying my terminal output here, with some omissions where I thought it was getting too verbose. I also don't mention when it prompts me to enter the PIN on the card reader. And note I'm not suggesting you set your key expiration to one week. I do that for my test keys. I also edited these "ultimately trusted" keys to "NOT trust", but I omitted that part. I do not trust my test keys :-). For one thing, they have password "test" or PIN 123456. ---------------------------8<--------------->8--------------------------- $ gpg2 --card-edit Reader ...........: 04E6:E003:60200D5E:0 Application ID ...: D27600012401020000050000106D0000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 0000106D Name of cardholder: [not set] Language prefs ...: de Sex ..............: unspecified URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Key attributes ...: rsa2048 rsa2048 rsa2048 Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none] gpg/card> admin Admin commands are allowed gpg/card> forcesig gpg/card> generate Make off-card backup of encryption key? (Y/n) n Please note that the factory settings of the PINs are PIN = '123456' Admin PIN = '12345678' You should change them using the command --change-pin What keysize do you want for the Signature key? (2048) What keysize do you want for the Encryption key? (2048) What keysize do you want for the Authentication key? (2048) Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 1w Key expires at Wed 30 Nov 2016 12:36:53 CET Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: Test card gen 3 Email address: Comment: You selected this USER-ID: "Test card gen 3" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o gpg: key 367D1BCF marked as ultimately trusted gpg: revocation certificate stored as '/home/peter/.gnupg/openpgp-revocs.d/777A48F5311A426503AEA845A7AB3198367D1BCF.rev' public and secret key created and signed. gpg: checking the trustdb [...] gpg: next trustdb check due at 2016-11-26 gpg/card> pub rsa2048/367D1BCF 2016-11-23 [S] [expires: 2016-11-30] Key fingerprint = 777A 48F5 311A 4265 03AE A845 A7AB 3198 367D 1BCF uid [ultimate] Test card gen 3 sub rsa2048/B8F0E89B 2016-11-23 [] [expires: 2016-11-30] sub rsa2048/7DB4FF6C 2016-11-23 [] [expires: 2016-11-30] $ gpg2 -K 367D1BCF sec> rsa2048/367D1BCF 2016-11-23 [SC] [expires: 2016-11-30] Card serial no. = 0005 0000106D uid [ultimate] Test card gen 3 ssb> rsa2048/B8F0E89B 2016-11-23 [A] [expires: 2016-11-30] ssb> rsa2048/7DB4FF6C 2016-11-23 [E] [expires: 2016-11-30] ---------------------------8<--------------->8--------------------------- I toggled off the signature force flag because I find it annoying and not useful. Keysigning parties really wear out your PIN-typing fingers with a reader with its own PIN-pad :-). These things aren't that ergonomical... Anyway. I used the normal procedure to generate an on-card OpenPGP key. The output at the end is somewhat malformed, the abilities are nonsense. So I did "gpg2 -K 367D1BCF" at the end to show them. We don't want those Enc and Auth keys! ---------------------------8<--------------->8--------------------------- $ gpg2 --edit-key 367D1BCF gpg (GnuPG) 2.1.11; Copyright (C) 2016 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. sec rsa2048/367D1BCF created: 2016-11-23 expires: 2016-11-30 usage: SC card-no: 0005 0000106D trust: ultimate validity: ultimate ssb rsa2048/B8F0E89B created: 2016-11-23 expires: 2016-11-30 usage: A card-no: 0005 0000106D ssb rsa2048/7DB4FF6C created: 2016-11-23 expires: 2016-11-30 usage: E card-no: 0005 0000106D [ultimate] (1). Test card gen 3 gpg> key 1 sec rsa2048/367D1BCF created: 2016-11-23 expires: 2016-11-30 usage: SC card-no: 0005 0000106D trust: ultimate validity: ultimate ssb* rsa2048/B8F0E89B created: 2016-11-23 expires: 2016-11-30 usage: A card-no: 0005 0000106D ssb rsa2048/7DB4FF6C created: 2016-11-23 expires: 2016-11-30 usage: E card-no: 0005 0000106D [ultimate] (1). Test card gen 3 gpg> key 2 sec rsa2048/367D1BCF created: 2016-11-23 expires: 2016-11-30 usage: SC card-no: 0005 0000106D trust: ultimate validity: ultimate ssb* rsa2048/B8F0E89B created: 2016-11-23 expires: 2016-11-30 usage: A card-no: 0005 0000106D ssb* rsa2048/7DB4FF6C created: 2016-11-23 expires: 2016-11-30 usage: E card-no: 0005 0000106D [ultimate] (1). Test card gen 3 gpg> delkey Do you really want to delete the selected keys? (y/N) y sec rsa2048/367D1BCF created: 2016-11-23 expires: 2016-11-30 usage: SC card-no: 0005 0000106D trust: ultimate validity: ultimate [ultimate] (1). Test card gen 3 gpg> save ---------------------------8<--------------->8--------------------------- Now let's add subkeys on the other card. GnuPG 2.1 totally does the right thing here! Insert a new blank smartcard and do: ---------------------------8<--------------->8--------------------------- $ gpg2 --edit-key 367D1BCF gpg (GnuPG) 2.1.11; Copyright (C) 2016 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. sec rsa2048/367D1BCF created: 2016-11-23 expires: 2016-11-30 usage: SC card-no: 0005 0000106D trust: ultimate validity: ultimate [ultimate] (1). Test card gen 3 gpg> addcardkey Signature key ....: [none] Encryption key....: [none] Authentication key: [none] Please select the type of key to generate: (1) Signature key (2) Encryption key (3) Authentication key Your selection? 1 What keysize do you want for the Signature key? (2048) Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y ---------------------------8<--------------->8--------------------------- At this point the pinentry will prompt: ---------------------------8<--------------->8--------------------------- Please remove the current card and insert the one with serial number: "D27600012401020000050000106D0000" ---------------------------8<--------------->8--------------------------- Note that that is our card with the primary key. And then: ---------------------------8<--------------->8--------------------------- Please remove the current card and insert the one with serial number: "D27600012401020000050000106E0000" ---------------------------8<--------------->8--------------------------- At this point the terminal will continue ---------------------------8<--------------->8--------------------------- sec rsa2048/367D1BCF created: 2016-11-23 expires: 2016-11-30 usage: SC card-no: 0005 0000106D trust: ultimate validity: ultimate ssb rsa2048/52201D0D created: 2016-11-23 expires: never usage: S card-no: 0005 0000106E [ultimate] (1). Test card gen 3 gpg> addcardkey Signature key ....: 93D8 BEE5 0F02 ABDE 3256 74D0 FC3D 5484 5220 1D0D Encryption key....: [none] Authentication key: [none] Please select the type of key to generate: (1) Signature key (2) Encryption key (3) Authentication key Your selection? 2 What keysize do you want for the Encryption key? (2048) Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y ---------------------------8<--------------->8--------------------------- At this point it will prompt: ---------------------------8<--------------->8--------------------------- Please remove the current card and insert the one with serial number: "D27600012401020000050000106D0000" ---------------------------8<--------------->8--------------------------- And the terminal will continue ---------------------------8<--------------->8--------------------------- sec rsa2048/367D1BCF created: 2016-11-23 expires: 2016-11-30 usage: SC card-no: 0005 0000106D trust: ultimate validity: ultimate ssb rsa2048/52201D0D created: 2016-11-23 expires: never usage: S card-no: 0005 0000106E ssb rsa2048/D6F8E666 created: 2016-11-23 expires: never usage: E card-no: 0005 0000106E [ultimate] (1). Test card gen 3 gpg> Save changes? (y/N) y $ ---------------------------8<--------------->8--------------------------- Done, succes! I tested the key, I could do all operations and it will prompt for the correct smartcard. If you just want the Certify ability on the primary key, replace the first part with: ---------------------------8<--------------->8--------------------------- $ gpg2 --expert --full-gen-key gpg (GnuPG) 2.1.11; Copyright (C) 2016 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. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECC and ECC (10) ECC (sign only) (11) ECC (set your own capabilities) Your selection? 8 Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? e Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? s Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Certify (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? q RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 1w Key expires at Wed 30 Nov 2016 12:14:09 CET Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: Test card gen 2 Email address: Comment: You selected this USER-ID: "Test card gen 2" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: key A401B81E marked as ultimately trusted gpg: revocation certificate stored as '/home/peter/.gnupg/openpgp-revocs.d/3ACA3357AFEE FD74E43065B1D65C1BCEA401B81E.rev' public and secret key created and signed. gpg: checking the trustdb [...] gpg: next trustdb check due at 2016-11-26 pub rsa2048/A401B81E 2016-11-23 [] [expires: 2016-11-30] Key fingerprint = 3ACA 3357 AFEE FD74 E430 65B1 D65C 1BCE A401 B81E uid [ultimate] Test card gen 2 $ gpg2 --edit-key A401B81E gpg (GnuPG) 2.1.11; Copyright (C) 2016 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. sec rsa2048/A401B81E created: 2016-11-23 expires: 2016-11-30 usage: C trust: ultimate validity: ultimate [ultimate] (1). Test card gen 2 gpg> keytocard Really move the primary key? (y/N) y Please select where to store the key: (1) Signature key Your selection? 1 sec rsa2048/A401B81E created: 2016-11-23 expires: 2016-11-30 usage: C trust: ultimate validity: ultimate [ultimate] (1). Test card gen 2 gpg> save $ gpg2 --card-status Reader ...........: 04E6:E003:60200D5E:0 Application ID ...: D27600012401020000050000106D0000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 0000106D Name of cardholder: [not set] Language prefs ...: de Sex ..............: unspecified URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Key attributes ...: rsa2048 rsa2048 rsa2048 Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: 3ACA 3357 AFEE FD74 E430 65B1 D65C 1BCE A401 B81E created ....: 2016-11-23 11:14:21 Encryption key....: [none] Authentication key: [none] General key info..: pub rsa2048/A401B81E 2016-11-23 Test card gen 2 sec> rsa2048/A401B81E created: 2016-11-23 expires: 2016-11-30 card-no: 0005 0000106D ---------------------------8<--------------->8--------------------------- And continue with adding subkeys as per above. 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 stebe at mailbox.org Wed Nov 23 17:13:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Wed, 23 Nov 2016 16:13:00 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122015422.D560F103215E@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> Message-ID: <3b09469b-5bd3-0e82-4c2e-2092bdfcdf82@mailbox.org> Peter Lebbing: > On 23/11/16 10:53, Andrew Gallagher wrote: >> If the message is being automatically decrypted at the MTA then it >> provides no more security than TLS. > > I could concur with this statement if we amend it a little: when two > MTA's are explicitly configured as TLS peers. They have to abort the > mail exchange when TLS can't be negotiated and when the certificate is > not as expected. "Expected" can mean: DN checking, issuer checking, > fingerprint checking, perhaps CRL checking. > > There are many problems preventing succesful TLS on SMTP. It's trivial > to downgrade, and certificates are only checked whether they are valid > in the general sense, not even the DN is checked. I could MITM a > connection to mail.example.org, present a valid certificate for > mail.digitalbrains.com, and the peer would accept it even though it > isn't valid *for mail.example.org*. Basically, it only works for passive > adversaries. Looking at it from the Postfix SMTP client side (as an example), with the smtp_tls_security_level (default: empty) main.cf configuration parameter there are the following levels with increasing security from left to right: none, may, encrypt, dane, dane-only, fingerprint, verify, secure From dane-only upwards no MITM is possible. With mere "dane" there are 2 fallbacks: if DNSSEC lookup does not present any result (-->fallback to may), if there are result, but they are not usable (--> fallback to encrypt). Even if the "verify" level seems to open the door once again to unauthenticated DNS MX lookups (and possibly, MITM), the name verification parameter smtp_tls_verify_cert_match keeps it locked. But that's theoretical, as it is not considered to be appropriate for systems that deliver mail to the Internet. I have a spontaneous sympathy for the "fingerprint" level as it suppresses (the need to rely on) any (CA) authorities :-) Cheers, Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Wed Nov 23 17:39:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Wed, 23 Nov 2016 16:39:00 +0000 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: References: <87oa19nqez.fsf@wheatstone.g10code.de> <7d2dd74e-3dab-5e8a-dacd-2d8585d288be@mailbox.org> <0e0236c3-3fde-0395-3b50-8ebba8c14ca8@mailbox.org> Message-ID: <57b4d858-3d20-2043-f604-f5e2bc232920@mailbox.org> Peter Lebbing: > On 23/11/16 11:14, Stephan Beck wrote: >> [...] and properly symlink >> /usr/bin/pinentry to the pinentry-curses you actually would like to use >> if you are using text-mode only, I don't know why it should not work. > [...]So by installing the Debian pinentry-curses > package, David should already have a /usr/bin/pinentry. > Yes, it has helped, thanks. But I looked at one of the OP's previous mail and was confirmed. > I looked for a GUI platform but had no idea what it's called where to > find it and why I need a GUI if I plan on using purely command line > interface. So, I am puzzled by the fact that he switched to GUI pinentry that quickly, without providing more info on the error, so I proposed to get the maximum amount of info possible using the debug-level flag. Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From anthony at cajuntechie.org Wed Nov 23 17:19:03 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Wed, 23 Nov 2016 10:19:03 -0600 Subject: Trying to figure out what's going on with a key update failure... Message-ID: <9bb32ac3-c823-ff3c-8202-cd2511c1d726@cajuntechie.org> Hello Everyone, When I run gpg2 --keyserver --refresh-keys I get a list of all of the keys in my keyring with the message that they have not been changed (this is expected). At the bottom of the output, I see the following message: gpg: Total number processed: 31 gpg: unchanged: 31 gpg: keyserver communications error: Not found gpg: keyserver communications error: Bad public key gpg: keyserver refresh failed: Bad public key I assumed that I was getting this message because a key lookup failed because it wasn't on a keyserver but someone on another list said this is not the case. When I look at all of the output from the session, nothing indicates any problems with any of the 31 keys in my keyring. Can someone tell me what this error means and how can I fix it? Thanks, Anthony -- VoIP/SIP: 1259010 at localphone.com Skype: cajuntechie XMPP/Jabber: papillion at dukgo.com PGP Key: 0xCC9D1E072AC97369 Other Info: http://www.cajuntechie.org/p/my-pgp-key.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 caro at nymph.paranoici.org Wed Nov 23 18:26:28 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Wed, 23 Nov 2016 17:26:28 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122015422.D560F103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> Message-ID: <20161123172628.743C710320FE@remailer.paranoici.org> Peter Lebbing wrote: >On 23/11/16 10:53, Andrew Gallagher wrote: >> If the message is being automatically decrypted at the MTA then it >> provides no more security than TLS. > >I could concur with this statement if we amend it a little: when two >MTA's are explicitly configured as TLS peers. They have to abort the >mail exchange when TLS can't be negotiated and when the certificate is >not as expected. "Expected" can mean: DN checking, issuer checking, >fingerprint checking, perhaps CRL checking. > >There are many problems preventing succesful TLS on SMTP. It's trivial >to downgrade, and certificates are only checked whether they are valid >in the general sense, not even the DN is checked. I could MITM a >connection to mail.example.org, present a valid certificate for >mail.digitalbrains.com, and the peer would accept it even though it >isn't valid *for mail.example.org*. Basically, it only works for passive >adversaries. > >But since the OpenPGP-protected mail payload would also require explicit >configuration, I don't think it is actually a disadvantage of TLS in >this case... > >I'm not completely sure the "explicitly configured TLS" doesn't have a >snag somewhere that complicates stuff more, though... I vaguely remember >something like that from a presentation... Pardon me when I disgress too much from the original problem, but my system carries a TLS certificate database of all external servers it ever contacted, and, based on the certificate's fingerprint, you can choose from that list which host connections you allow. Kind regards Caro From dkg at fifthhorseman.net Wed Nov 23 18:24:13 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 23 Nov 2016 12:24:13 -0500 Subject: How to prevent passphrase caching in 2.1 In-Reply-To: <20161123084657.9513410320F5@remailer.paranoici.org> References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161121142004.416101032265@remailer.paranoici.org> <20161122162026.CF0C2100B129@remailer.paranoici.org> <87k2bvi8dx.fsf@alice.fifthhorseman.net> <20161123084657.9513410320F5@remailer.paranoici.org> Message-ID: <87h96ygldu.fsf@alice.fifthhorseman.net> On Wed 2016-11-23 03:46:57 -0500, Carola Grunwald wrote: > With GnuPG 1.4 I had no agent. And, in case it is, I've no idea why with > 2.x such a passphrase cache with all its risks has to be mandatory. in 2.0, the agent is a passphrase cache. in 2.1, the agent is a proper cryptographic agent, which does not release any secret key material to the calling process. This isolation is actually offers reduced risks in the contexts in which gpg is expected to be invoked (by a single user, who is managing their own keys). that said, i understand why it doesn't meet your needs. unfortunately, you're using these tools in a framework that they generally weren't expected to be used. You've said already that you don't want to run a different gpg-agent for each user account that is currently authenticated to your server. can i ask why not? the agent is a pretty lightweight process, and setting one up on login and tearing it down on shutdown seems like it could be a fairly convenient approach. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 962 bytes Desc: not available URL: From caro at nymph.paranoici.org Wed Nov 23 18:54:27 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Wed, 23 Nov 2016 17:54:27 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> Message-ID: <20161123175427.86C0310320FF@remailer.paranoici.org> Andrew Gallagher wrote: > >> On 23 Nov 2016, at 03:48, Carola Grunwald wrote: >> >> But why does a person have to be in control of a signature key? Why not >> a server in the name of a company resp. its employees. > >There is no problem having a server in control of a key. Just so long as we understand that the key is now the *server's* key, not the user's. And there's no point in the server having multiple keys when the same information can be conveyed using a standardised header that's signed by a shared key. All you're saying with the signature is "the sender of this email appears to have authenticated to this server using X credentials", where the credentials in this case are equivalent to username/password. > >It sounds to me like you're trying to reinvent DKIM. Nope. > >> There's server-to-server security >> provided usually by SSL/TLS, where nevertheless the communication >> partners can't influence the all-knowing servers building the route. > >True. But this appears to be unrelated to your proposal. > >> And >> there's true end-to-end cryptography done by PGP/SMIME at the client >> applications, which also leaks valid (envelope) information thinking of >> message size and structure and the enormously talkative header section. > >There are ways around this, such as attaching the real message as a PGP encrypted attachment to a generic form letter (as per Facebook), or alternatively encrypting the header values individually (as per memoryhole). I implemented Whole Message Encryption in 2006, the year when Facebook went public beyond students. And how old is Memory Hole? > >> and, btw, with --faked-system-time doesn't even >> leak whether it was processed at business hours or at midnight. > >But the received: headers of the message will leak this anyway. Unless you configure your mail queue to only run once a day. Which relevant information does the single Received: header, describing the recipient MTA's interaction with the exit remailer, leak? > >If you are worried about an attacker on the wire doing statistical analysis of your message sizes and patterns of use, you will probably have to go the whole hog and transport over Tor. And even that is no panacea. Not real-time Tor but remailers providing latency. You got it. > >> At the >> recipient's corporate server that mail is decrypted using the >> recipient's key > >If the message is being automatically decrypted at the MTA then it provides no more security than TLS. TLS is a real-time server-to-server connection protocol, which PGP isn't. You can send your PGP message to and fro around the world through as many servers as you like hiding all your traces thus removing sender metadata. With TLS you can't. > And if we are only encrypting the content of the mail, then it provides less security than TLS, which encrypts everything from the handshake onwards. I'm talking about Whole Message Encryption including the complete header section. > >> a line >> representing the signature status added to the header > >How does this provide the user with any more assurance than DKIM verification? DKIM doesn't hide the sender's identity from external adversaries who try to analyse message flow. > >> This concept of an enhanced transport security layer > >You have not described a transport security layer, but an MTA-to-MTA message encapsulation protocol. Sounds great. > I don't see how this improves upon TLS+DKIM. - In a TLS session the communication partners' IP addresses are public, moreover the sender domain is published by the receiving MTA by retrieving its public key from the DNS in order to verify the DKIM signature. OTOH with my kind of Whole Message Encryption combined with an asynchronous message transfer providing latency e.g. through remailers adversaries have no chance at all to link sender with recipient(s). - A DKIM signature isn't as robust as an ASCII PGP block. A tiny in-transit MIME recoding and it's invalid. - A DKIM signature doesn't take care of the complete message including all header fields, which WME does. - The TLS+DKIM combination taken by itself can't fake the size of a message, WME with random dummy load can. And so on. Kind regards Caro From andrewg at andrewg.com Wed Nov 23 19:51:25 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 23 Nov 2016 18:51:25 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161123175427.86C0310320FF@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> <20161123175427.86C0310320FF@remailer.paranoici.org> Message-ID: On 23/11/16 17:54, Carola Grunwald wrote: > Andrew Gallagher wrote: > >> If you are worried about an attacker on the wire doing statistical >> analysis of your message sizes and patterns of use, you will >> probably have to go the whole hog and transport over Tor. And even >> that is no panacea. > > Not real-time Tor but remailers providing latency. You got it. Aha, this is the subtlety I was missing. Yes, this sounds like an interesting project. I still don't understand what you gain from per-user keys though. >> And if we are only encrypting the content of the mail, then it >> provides less security than TLS, which encrypts everything from >> the handshake onwards. > > I'm talking about Whole Message Encryption including the complete > header section. But the SMTP envelope contains plaintext addressing info. TLS protects this on the wire, while PGP encryption of the message (even the headers) does not. >> How does this provide the user with any more assurance than DKIM >> verification? > > DKIM doesn't hide the sender's identity from external adversaries > who try to analyse message flow. That wasn't my question. I was asking what advantage a per-user signature gives you compared to a server signature over a custom header. > - In a TLS session the communication partners' IP addresses are > public, moreover the sender domain is published by the receiving MTA > by retrieving its public key from the DNS in order to verify the > DKIM signature. OTOH with my kind of Whole Message Encryption > combined with an asynchronous message transfer providing latency > e.g. through remailers adversaries have no chance at all to link > sender with recipient(s). But if you have a per-user signature on the message content, surely the sender can still be deduced? At least on the last hop... 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 peter at digitalbrains.com Wed Nov 23 19:59:09 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Nov 2016 19:59:09 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161123175427.86C0310320FF@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> <20161123175427.86C0310320FF@remailer.paranoici.org> Message-ID: <929ae0b0-cc7c-ee5e-8951-05d701cbd7c5@digitalbrains.com> On 23/11/16 18:54, Carola Grunwald wrote: > Which relevant information does the single Received: header, describing > the recipient MTA's interaction with the exit remailer, leak? If you sign the data just before the interaction, the signature time and the time noted in the Received:-header are virtually identical, so the signature time doesn't leak data. > Not real-time Tor but remailers providing latency. You got it. > [...] > You can send your PGP message to and fro around the world through > as many servers as you like hiding all your traces thus removing sender > metadata. With TLS you can't. I think other people were thinking you wanted to use regular mail transports in combination with your OpenPGP layer. Thus, only very few MTA's would be involved and they would all be under the administration of either the sending, or the receiving party. That is, the exact two parties who have access to the private keys in the scheme you proposed. Hence the noted similarity. 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 stebe at mailbox.org Wed Nov 23 22:10:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Wed, 23 Nov 2016 21:10:00 +0000 Subject: Trying to figure out what's going on with a key update failure... In-Reply-To: <9bb32ac3-c823-ff3c-8202-cd2511c1d726@cajuntechie.org> References: <9bb32ac3-c823-ff3c-8202-cd2511c1d726@cajuntechie.org> Message-ID: Anthony Papillion: > Hello Everyone, > > When I run > > gpg2 --keyserver --refresh-keys > > I get a list of all of the keys in my keyring with the message that they > have not been changed (this is expected). At the bottom of the output, I > see the following message: > > gpg: Total number processed: 31 > gpg: unchanged: 31 > gpg: keyserver communications error: Not found > gpg: keyserver communications error: Bad public key > gpg: keyserver refresh failed: Bad public key > > I assumed that I was getting this message because a key lookup failed > because it wasn't on a keyserver but someone on another list said this > is not the case. When I look at all of the output from the session, > nothing indicates any problems with any of the 31 keys in my keyring. > > Can someone tell me what this error means and how can I fix it? Which gpg2 version are you running? 2.0x or 2.1x? If it's the former, gpg makes use of the "keyserver helper programs" to connect to keyservers, whereas using the latter implies Dirmngr being in charge of it. Depending on that, the ways to get the required information needed to analyze and (possibly) resolve your problem differ. Or do you already have all that information when you say > When I look at all of the output from the session Cheers Stephan Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From caro at nymph.paranoici.org Thu Nov 24 00:09:16 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Wed, 23 Nov 2016 23:09:16 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> <20161123175427.86C0310320FF@remailer.paranoici.org> Message-ID: <20161123230916.5960A10320FB@remailer.paranoici.org> Andrew Gallagher wrote: >On 23/11/16 17:54, Carola Grunwald wrote: >> Andrew Gallagher wrote: >> >>> If you are worried about an attacker on the wire doing statistical >>> analysis of your message sizes and patterns of use, you will >>> probably have to go the whole hog and transport over Tor. And even >>> that is no panacea. >> >> Not real-time Tor but remailers providing latency. You got it. > >Aha, this is the subtlety I was missing. Yes, this sounds like an >interesting project. > >I still don't understand what you gain from per-user keys though. When you deal with pseudonymity you have to avoid similarities of your aliases. So the WME keys they use to secure their messages have to be different. Going into details there are several scenarios where WME can help protect privacy. One of them is easy to explain. Think of two partners who strive for absolutely hidden communication though they know about their identity. Alice's ordinary mail client sends a standard mail message to her proxy server, where it gets PGP encoded, which makes up the body of the WME message, with only a To: header containing the destination's pure address and possibly a hashcash token and further dummy headers to surpass spam filters added. This message is now converted into a remailer message and sent through Tor to the entry remailer. When Bob's counterpart receives the message it decrypts it, checks the signature and adds a header about its status on top of the net message, and forwards it to his mail client. With Tor involved for an adversary it's very hard if not impossible to detect that Alice sent mail. Concerning Bob he can only see that a remailer message with a single PGP block including no key-ID arrives from nowhere. In case Bob also has to hide that he receives any messages he has to use a pseudonymous remailer through Tor. If now both only know their addresses at pseudonymous remailers individual anonymity is secured in all directions. And that's where you really need individual WME keys, each reflecting the holder's address at the respective nym server. > >>> And if we are only encrypting the content of the mail, then it >>> provides less security than TLS, which encrypts everything from >>> the handshake onwards. >> >> I'm talking about Whole Message Encryption including the complete >> header section. > >But the SMTP envelope contains plaintext addressing info. TLS protects >this on the wire, while PGP encryption of the message (even the >headers) does not. First of all I see no reason to do without TLS. Then with remailing only the address of the next hop is visible, the final destination is protected by multilayer encryption up to the exit remailer. Another advantage of WME compared with MIME acrobatics is that the recipient even without running a proxy server can easily decrypt the WME layer to get a complete RFC compliant message ready for manual import into his client software. > >>> How does this provide the user with any more assurance than DKIM >>> verification? >> >> DKIM doesn't hide the sender's identity from external adversaries >> who try to analyse message flow. > >That wasn't my question. I was asking what advantage a per-user >signature gives you compared to a server signature over a custom header. I anyway have to encrypt the message. So for me it seems natural to simply add a signature here instead of thinking of something completely new. > >> - In a TLS session the communication partners' IP addresses are >> public, moreover the sender domain is published by the receiving MTA >> by retrieving its public key from the DNS in order to verify the >> DKIM signature. OTOH with my kind of Whole Message Encryption >> combined with an asynchronous message transfer providing latency >> e.g. through remailers adversaries have no chance at all to link >> sender with recipient(s). > >But if you have a per-user signature on the message content, surely the >sender can still be deduced? At least on the last hop... With PGP the encryption layer protects the signature, which is why only the final recipient with his key/passphrase combination gets hold of it. Kind regards Caro From caro at nymph.paranoici.org Thu Nov 24 00:25:52 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Wed, 23 Nov 2016 23:25:52 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> <20161123175427.86C0310320FF@remailer.paranoici.org> <929ae0b0-cc7c-ee5e-8951-05d701cbd7c5@digitalbrains.com> Message-ID: <20161123232552.89D9410320F5@remailer.paranoici.org> Peter Lebbing wrote: >On 23/11/16 18:54, Carola Grunwald wrote: >> Which relevant information does the single Received: header, describing >> the recipient MTA's interaction with the exit remailer, leak? > >If you sign the data just before the interaction, the signature time and >the time noted in the Received:-header are virtually identical, so the >signature time doesn't leak data. No, that isn't correct. Dependent on the length of the remailer chain and the individual latency of the involved hops there may be hours, even days between the signing process at the sender and the final message transfer from the exit remailer to the recipient's MTA. And you have to be aware that at each hop the message envelope (including some Received: header line) is completely removed and replaced by nothing but the next hop's address. > >> Not real-time Tor but remailers providing latency. You got it. >> [...] >> You can send your PGP message to and fro around the world through >> as many servers as you like hiding all your traces thus removing sender >> metadata. With TLS you can't. > >I think other people were thinking you wanted to use regular mail >transports in combination with your OpenPGP layer. Thus, only very few >MTA's would be involved and they would all be under the administration >of either the sending, or the receiving party. That is, the exact two >parties who have access to the private keys in the scheme you proposed. >Hence the noted similarity. Different from TLS with my PGP layer solution it doesn't matter how many MTAs are involved in the delivery process and how long that takes. Kind regards Caro From anthony at cajuntechie.org Thu Nov 24 00:29:15 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Wed, 23 Nov 2016 17:29:15 -0600 Subject: Trying to figure out what's going on with a key update failure... In-Reply-To: References: <9bb32ac3-c823-ff3c-8202-cd2511c1d726@cajuntechie.org> Message-ID: <79292c8d-a5f3-bbda-94f9-1c7c744c4c22@cajuntechie.org> On 11/23/2016 3:10 PM, Stephan Beck wrote: > > > Anthony Papillion: >> Hello Everyone, >> >> When I run >> >> gpg2 --keyserver --refresh-keys >> >> I get a list of all of the keys in my keyring with the message that they >> have not been changed (this is expected). At the bottom of the output, I >> see the following message: >> >> gpg: Total number processed: 31 >> gpg: unchanged: 31 >> gpg: keyserver communications error: Not found >> gpg: keyserver communications error: Bad public key >> gpg: keyserver refresh failed: Bad public key >> >> I assumed that I was getting this message because a key lookup failed >> because it wasn't on a keyserver but someone on another list said this >> is not the case. When I look at all of the output from the session, >> nothing indicates any problems with any of the 31 keys in my keyring. >> >> Can someone tell me what this error means and how can I fix it? > > Which gpg2 version are you running? 2.0x or 2.1x? If it's the former, > gpg makes use of the "keyserver helper programs" to connect to > keyservers, whereas using the latter implies Dirmngr being in charge of > it. Depending on that, the ways to get the required information needed > to analyze and (possibly) resolve your problem differ. > Or do you already have all that information when you say >> When I look at all of the output from the session I don't have anything besides what's displayed when I try to refresh the keys so I probably will need to tease more information out of the process. I'm running the 2.0 branch (specifically, 2.0.30). Are there commands I can use to extract the information you mentioned? Thanks, Anthony -- VoIP/SIP: 1259010 at localphone.com Skype: cajuntechie XMPP/Jabber: papillion at dukgo.com PGP Key: 0xCC9D1E072AC97369 Other Info: http://www.cajuntechie.org/p/my-pgp-key.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 caro at nymph.paranoici.org Thu Nov 24 01:18:30 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Thu, 24 Nov 2016 00:18:30 +0000 (UTC) Subject: How to prevent passphrase caching in 2.1 References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161122162026.CF0C2100B129@remailer.paranoici.org> <87k2bvi8dx.fsf@alice.fifthhorseman.net> <20161123084657.9513410320F5@remailer.paranoici.org> <87h96ygldu.fsf@alice.fifthhorseman.net> Message-ID: <20161124001830.5704D10320FB@remailer.paranoici.org> Daniel Kahn Gillmor wrote: >On Wed 2016-11-23 03:46:57 -0500, Carola Grunwald wrote: >> With GnuPG 1.4 I had no agent. And, in case it is, I've no idea why with >> 2.x such a passphrase cache with all its risks has to be mandatory. > >in 2.0, the agent is a passphrase cache. in 2.1, the agent is a proper >cryptographic agent, which does not release any secret key material to >the calling process. This isolation is actually offers reduced risks in >the contexts in which gpg is expected to be invoked (by a single user, >who is managing their own keys). What are your objections to an option to deactivate that caching feature, which, as I explained, under certain circumstances may turn into a severe security risk? Are there any technical reasons why GnuPG absolutely can't do without a cache? Or is it merely user convenience you trade security for? Think of a single-user configuration, where that guy enters a (wrong) passphrase, GPG uses a different one from a cache of unknown contents and decrypts his data, at worst without telling him about that substitution required to complete the task. The user tries to memorize his allegedly valid passphrase. And next time, same key, same passphrase, but the cache no longer in favour of him - hard luck! Is that correct? Or is there any chance for the user to get knowledge of that passphrase substitution? > >that said, i understand why it doesn't meet your needs. unfortunately, >you're using these tools in a framework that they generally weren't >expected to be used. And which Open Source OpenPGP engine have you in mind that suits my needs? > >You've said already that you don't want to run a different gpg-agent for >each user account that is currently authenticated to your server. can i >ask why not? the agent is a pretty lightweight process, and setting one >up on login and tearing it down on shutdown seems like it could be a >fairly convenient approach. Please don't underestimate the complexity of your proposal. It isn't only about starting and shutting down a service with every single mail server connection, which by itself would be bad enough. You also have to deal with the creation and manipulation of lots of keyrings, one for every private key, with multiple public key copies of potential recipients added and removed. And each instance has to have its own home directory. What would that mean for my test environment, where I currently manage way more than a hundred identities. Horrible! Kind regards Caro From 2014-667rhzu3dc-lists-groups at riseup.net Thu Nov 24 02:31:49 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 24 Nov 2016 01:31:49 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161123034819.AD17F1032265@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122015422.D560F103215E@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> Message-ID: <107592031.20161124013149@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wednesday 23 November 2016 at 3:48:19 AM, in , Carola Grunwald wrote:- > This concept of an enhanced transport security layer > offers external > adversaries least possible information while it > doesn't preclude the > sender from adding another inner encryption/signature > layer created with > a key she herself controls. > Hope that helps to understand what I'm aiming at. Have you looked at all at Mike Ingle's "Confidant Mail" (CM) ? Maybe your signing/encryption servers at each end could incorporate a CM-to-SMTP gateway; CM could be awesome it were possible to compose and read messages on an ordinary mail client. - -- Best regards MFPA Penguins are not to be trusted, especially those who listen to organ music. -----BEGIN PGP SIGNATURE----- iL4EARYKAGYFAlg2QwhfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3 MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOQhvgD/SyXI12SgjS9bVae97JKHwLN+ mTkMa3GcjH9HAzGAvtoBAOSVCVVDqm4E+5jMNdVu/1hUv+4u8JgNFigYelRbRjYD iQF8BAEBCgBmBQJYNkMYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwBqsH/2/8hhIUVFbFI2JkOkWl4ooN DLJJMfKAbpnzbiUE8z0FztzTU7DM6TmwIhwubmuUaryL4ng/7Dx+MXQq1jbpLeLd T6iH71C8ybl88kwI+QT6vmjXZMngm+HXDv1LXbjscpSufv1JQm9t3gF5IEoF0awo 1Lbgofwzn++WNSL+PHX2022BA1k14EMUjEJ4kJpzc91uuSVOy3USlvrgH2ix1e81 elUYqvmmspDVMOqyCXicu7qVMv1yPBVO0aE1wUb+7RXLN1iuepjeLS3FIdcEfxUd vV1rnRELFXFDjVyVnEPW6IwNyD6l9Fn2kxisvyYwBwm0xRxUIBzNezWVg17CoWU= =biB1 -----END PGP SIGNATURE----- From davidadamson.md at gmail.com Thu Nov 24 09:40:42 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Thu, 24 Nov 2016 03:40:42 -0500 Subject: configure warnings and errors upon ./configure for Pinentry v0.9.7 In-Reply-To: <57b4d858-3d20-2043-f604-f5e2bc232920@mailbox.org> References: <87oa19nqez.fsf@wheatstone.g10code.de> <7d2dd74e-3dab-5e8a-dacd-2d8585d288be@mailbox.org> <0e0236c3-3fde-0395-3b50-8ebba8c14ca8@mailbox.org> <57b4d858-3d20-2043-f604-f5e2bc232920@mailbox.org> Message-ID: I wasn't exactly methodical in my approach to resolve the issue but I "think" what resolved my issue preventing me from generating keys was following Stephan's suggestion of adding to .bashrc, which I had done and was still getting the issue but tonight I added the lines to .bashrc of root. Or it could have been Peter's suggestion of rm trustdb.gpg. Anyhow I have successfully generated pub and secret key. I am getting a gui pop up requesting I enter a passphrase when generating a key which was not my initial goal but I'm glad to have something working than nothing. I have a feeling I'm not out of the woods quite yet but that's ok. I appreciate you guys helping me work through this gpg software. I still have lots of questions about what kind of questions I should have but that will come. David From peter at digitalbrains.com Thu Nov 24 11:17:03 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 24 Nov 2016 11:17:03 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161123230916.5960A10320FB@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> <20161123175427.86C0310320FF@remailer.paranoici.org> <20161123230916.5960A10320FB@remailer.paranoici.org> Message-ID: <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> On 24/11/16 00:09, Carola Grunwald wrote: > When you deal with pseudonymity you have to avoid similarities of > your aliases. So the WME keys they use to secure their messages have > to be different. I still don't see why you need per-user keys. OpenPGP, or at least as produced by GnuPG, is Sign-Then-Encrypt. If each Message Submission Agent and each post office (POP3, IMAP) server had their own key (you could use --throw-keyids or --hidden-recipient), it could be as follows: User sends from . Intended recipient is . Message Submission Agent for example.org adds a header indicating it was alice who succesfully authenticated, and other interesting stuff. MSA then signs and encrypts the whole message. Encryption recipient is the nowhere-special.org post office server (but --throw-keyids). MSA creates a new shell RFC822 e-mail message with everything removed but the SMTP recipient (this is a special address I'm inventing for the protocol). We now have a message that only leaks the fact that nowhere-special.org is the receiving domain. The OpenPGP thingy itself leaks nothing. The signature has a correct, normal timestamp, but this data is encrypted. The recipient of the encryption is unknown (but can be inferred to be nowhere-special.org, so it's not that useful to use --throw-keyids perhaps). It's just an encrypted blob. This goes through all the remailers, is beamed into space, buried for some time on the dark side of the moon, etcetera. Once it reaches nowhere-special.org, the process listening on decrypts the message using its own private key. It checks the signature is indeed from its established peer server at example.org. It knows when example.org signed the message. Then again, in your proposed scheme, the receiving server also has all data like when alice wrote it, and what she wrote. The timestamp from the signature adds nothing substantial. The post office server then delivers the message in the recipient mailbox, with some status headers. As I said, I don't see what different keys for different accounts add here. And I don't see why the intended recipient can't know of the signature timestamp, so you don't need --faked-system-time. You could use GnuPG 1.4, or you could use 2.1 with a gpg-agent daemon holding just the private key for the server doing the crypto. Oh, by the way, in reply to a bit from another mail: On 24/11/16 00:25, Carola Grunwald wrote: > Peter Lebbing wrote: >> If you sign the data just before the interaction, the signature >> time and the time noted in the Received:-header are virtually >> identical, so the signature time doesn't leak data. > > No, that isn't correct. Dependent on the length of the remailer > chain and the individual latency of the involved hops there may be > hours, even days between the signing process at the sender and the > final message transfer from the exit remailer to the recipient's > MTA. It's not really that relevant, but anyway: as I said in the next paragraph, this was all assuming you were using a regular mail transport, not remailers. 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 caro at nymph.paranoici.org Thu Nov 24 14:16:36 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Thu, 24 Nov 2016 13:16:36 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> <20161123175427.86C0310320FF@remailer.paranoici.org> <20161123230916.5960A10320FB@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> Message-ID: <20161124131636.82DF810320FB@remailer.paranoici.org> Peter Lebbing wrote: >On 24/11/16 00:09, Carola Grunwald wrote: >> When you deal with pseudonymity you have to avoid similarities of >> your aliases. So the WME keys they use to secure their messages have >> to be different. > >I still don't see why you need per-user keys. > >OpenPGP, or at least as produced by GnuPG, is Sign-Then-Encrypt. If each >Message Submission Agent and each post office (POP3, IMAP) server had >their own key (you could use --throw-keyids or --hidden-recipient), it >could be as follows: > >User sends from . Intended recipient is >. > >Message Submission Agent for example.org adds a header indicating it was >alice who succesfully authenticated, and other interesting stuff. MSA >then signs and encrypts the whole message. Encryption recipient is the >nowhere-special.org post office server (but --throw-keyids). MSA creates >a new shell RFC822 e-mail message with everything removed but the SMTP >recipient (this is a special address I'm >inventing for the protocol). > >We now have a message that only leaks the fact that nowhere-special.org >is the receiving domain. The OpenPGP thingy itself leaks nothing. The >signature has a correct, normal timestamp, but this data is encrypted. >The recipient of the encryption is unknown (but can be inferred to be >nowhere-special.org, so it's not that useful to use --throw-keyids >perhaps). It's just an encrypted blob. > >This goes through all the remailers, is beamed into space, buried for >some time on the dark side of the moon, etcetera. > >Once it reaches nowhere-special.org, the process listening on > decrypts the message using its own private >key. It checks the signature is indeed from its established peer server >at example.org. It knows when example.org signed the message. Then >again, in your proposed scheme, the receiving server also has all data >like when alice wrote it, and what she wrote. The timestamp from the >signature adds nothing substantial. The post office server then delivers >the message in the recipient mailbox, with some status headers. > > > >As I said, I don't see what different keys for different accounts add >here. And I don't see why the intended recipient can't know of the >signature timestamp, so you don't need --faked-system-time. You could >use GnuPG 1.4, or you could use 2.1 with a gpg-agent daemon holding just >the private key for the server doing the crypto. WME combined with nym server usage for example requires an individual WME key for each account, as otherwise at least the recipient, who may communicate with different aliases is able to link them based on their common signature key-ID. Concerning faked timestamps you have to imagine that an adversary may observe your Tor connections. When he sees high activity shortly after the signature's timestamp you may have transmitted the respective message. And with each positive correlation on follow up messages the connection between you and the anonymous sender becomes more and more certain. That's just one example. > >Oh, by the way, in reply to a bit from another mail: > >On 24/11/16 00:25, Carola Grunwald wrote: >> Peter Lebbing wrote: >>> If you sign the data just before the interaction, the signature >>> time and the time noted in the Received:-header are virtually >>> identical, so the signature time doesn't leak data. >> >> No, that isn't correct. Dependent on the length of the remailer >> chain and the individual latency of the involved hops there may be >> hours, even days between the signing process at the sender and the >> final message transfer from the exit remailer to the recipient's >> MTA. > >It's not really that relevant, but anyway: as I said in the next >paragraph, this was all assuming you were using a regular mail >transport, not remailers. I know, but unfortunately this thread became more and more a discussion about my project, which I didn't intend, and not the problem why I started it. Kind regards Caro From peter at digitalbrains.com Thu Nov 24 14:32:53 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 24 Nov 2016 14:32:53 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161124131636.82DF810320FB@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <9E80FA1A-CD8D-4941-85FE-D1FB533E3C5A@andrewg.com> <20161123175427.86C0310320FF@remailer.paranoici.org> <20161123230916.5960A10320FB@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> Message-ID: On 24/11/16 14:16, Carola Grunwald wrote: > WME combined with nym server usage for example requires an individual > WME key for each account, as otherwise at least the recipient, who may > communicate with different aliases is able to link them based on their > common signature key-ID. I don't understand this. Could you give an example or something, to help me understand? AFAICS, the recipient needs a way to send mail back to the sender, and hence, a domain name for the sender. Having the signature tell them which domain name the sender used, tells them nothing. Unless of course you don't want pseudonymous, but anonymous mail. In the latter case, a signature is meaningless and should just be omitted altogether. > Concerning faked timestamps you have to imagine that an adversary may > observe your Tor connections. When he sees high activity shortly after > the signature's timestamp you may have transmitted the respective > message. And how will the adversary see this timestamp? It's encrypted to the recipient! Surely, if he has the timestamp, he has the plaintext of the mail and the timestamp is probably the least of your problems. I'm really not getting this concern! Huh?! 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 caro at nymph.paranoici.org Thu Nov 24 14:34:12 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Thu, 24 Nov 2016 13:34:12 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161122181710.2923D103215E@remailer.paranoici.org> <6fcf75b9-50ad-ce73-e7ae-b0d75e9e303f@andrewg.com> <00f401d244f9$e94def30$bbe9cd90$@sixdemonbag.org> <20161123034819.AD17F1032265@remailer.paranoici.org> <107592031.20161124013149@riseup.net> Message-ID: <20161124133412.54AA810320FE@remailer.paranoici.org> MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote: >Have you looked at all at Mike Ingle's "Confidant Mail" (CM) >? Maybe your signing/encryption servers >at each end could incorporate a CM-to-SMTP gateway; CM could be >awesome it were possible to compose and read messages on an ordinary >mail client. No, I wasn't aware of Confidant Mail. I have a different approach to transmit bulk data anonymously. Sending a larger mail message through the remailer network is a lengthy process, as it is transferred in uniform 4 kB mail packets, from which the exit remailer reconstructs the original message. But as my system incorporates Tor, it offers another solution to that problem. Apart from hidden services, which allow to contact the integrated POP3, SMTP and NNTP proxy from all over the world without having to deal with DDNS services you can also set up HTTP hidden services to allow others to download files anonymously. Send the recipient anonymously the .onion address of the file you offer and after installing a Tor Browser he's able to download it through the Tor network. You yourself remain anonymous, which is why that's a tool whistleblowers can use to forward larger documents. Compared with standard Tor communication a custom made protocol may stand out and be easily detectable by an adversary. So I'm not sure how CM can help to improve my system. But I'm always open to suggestions. Kind regards Caro From tlikonen at iki.fi Thu Nov 24 15:27:49 2016 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 24 Nov 2016 16:27:49 +0200 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? Message-ID: <87lgw9neai.fsf@iki.fi> Keys with authentication capability can be used with ssh, and GnuPG 2.1's command --export-ssh-key will export the ssh public key. Right? Unfortunately I have GnuPG 2.0.26 (as packaged in Debian 8). Can it be told to export ssh public keys? -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From peter at digitalbrains.com Thu Nov 24 16:04:42 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 24 Nov 2016 16:04:42 +0100 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: <87lgw9neai.fsf@iki.fi> References: <87lgw9neai.fsf@iki.fi> Message-ID: On 24/11/16 15:27, Teemu Likonen wrote: > Unfortunately I have GnuPG 2.0.26 (as packaged in Debian 8). Can it be > told to export ssh public keys? I think 2.0 also supported: $ ssh-add -L to list all SSH keys known to the agent. ssh-add is part of the openssh-client package. 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 tlikonen at iki.fi Thu Nov 24 16:59:41 2016 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 24 Nov 2016 17:59:41 +0200 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: (Peter Lebbing's message of "Thu, 24 Nov 2016 16:04:42 +0100") References: <87lgw9neai.fsf@iki.fi> Message-ID: <87h96woolu.fsf@iki.fi> Peter Lebbing [2016-11-24 16:04:42+01] wrote: > On 24/11/16 15:27, Teemu Likonen wrote: >> Unfortunately I have GnuPG 2.0.26 (as packaged in Debian 8). Can it be >> told to export ssh public keys? > > I think 2.0 also supported: > > $ ssh-add -L > > to list all SSH keys known to the agent. ssh-add is part of the > openssh-client package. That works if the key is already known to the gpg-agent but it seems that gpg 2.0 has also a problem in making A-capable keys known to ssh agent protocol. I believe that file ~/.gnupg/sshcontrol should contain key's keygrip but how do I get the keygrip when there's no --with-keygrip option in 2.0? -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From stebe at mailbox.org Thu Nov 24 17:51:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Thu, 24 Nov 2016 16:51:00 +0000 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: <87lgw9neai.fsf@iki.fi> References: <87lgw9neai.fsf@iki.fi> Message-ID: <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> Hi Teemu, Teemu Likonen: > Keys with authentication capability can be used with ssh, and GnuPG > 2.1's command --export-ssh-key will export the ssh public key. Right? Yes, --export-ssh-key has been introduced in gpg with release of version 2.1.11. To set the whole thing up, a few more steps are necessary (--enable-ssh-support in gpg.conf still is necessary AFAIK, but this is the "new" export command. > > Unfortunately I have GnuPG 2.0.26 (as packaged in Debian 8). Can it be > told to export ssh public keys? Yes, but it's a bit more laborious in comparison to gpg >= 2.1.11 A) You do not use a smart card --> B) you use a smart card A1) Install the monkeysphere package (1) that includes openpgp2ssh tool A2) Export the secret subkey you'd like to use for ssh authentication purposes and pipe it through openpgp2ssh gpg2 --export-secret-subkeys \ --export-options export-reset-subkey-passwd [keyID!] | \ openpgp2ssh [keyID] > gpg-auth-keyfile A3) Set correct permissions chmod 0600 gpg-auth-keyfile A4) Add the key to the agent ssh-add gpg-auth-key-file A4) Check that the key effectively is loaded ssh-add -l A5) Extract the *public* key for use in the ~/.ssh/authorized_keys file ssh-add -L OR gpgkey2ssh [keyID] B) You use a smart card and have it inserted Transfer your secret authentication subkey to the smart card by typing first B1) gpg2 --edit-key [keyID] Toggle and select the correct subkey B2) gpg> toggle B3) key [N] N depends on the number of subkeys and describes the position of the key in the listing B4) Transfer the authentication subkey to the card gpg> keytocard Select the correct slot of the card for the auth subkey to be stored Usually, it's "3" B5) Enter passphrase B6) Enter your card ADMIN PIN B7) gpg> save Cheers Stephan List member Damien Goute-Gattat has an excellent write-up to be found at: https://incenp.org/notes/2014/index.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Nov 24 18:36:59 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 24 Nov 2016 18:36:59 +0100 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: <87h96woolu.fsf@iki.fi> References: <87lgw9neai.fsf@iki.fi> <87h96woolu.fsf@iki.fi> Message-ID: On 2016-11-24 16:59, Teemu Likonen wrote: > I believe that file ~/.gnupg/sshcontrol should contain > key's keygrip but how do I get the keygrip when there's no > --with-keygrip option in 2.0? I think the following: $ gpg-connect-agent > help keyinfo # KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] # # Return information about the key specified by the KEYGRIP. If the # key is not available GPG_ERR_NOT_FOUND is returned. If the option # --list is given the keygrip is ignored and information about all # available keys are returned. If --ssh-list is given information # about all keys listed in the sshcontrol are returned. With --with-ssh # information from sshcontrol is always added to the info. Unless --data # is given, the information is returned as a status line using the format: # # KEYINFO - - # # KEYGRIP is the keygrip. # # TYPE describes the type of the key: # 'D' - Regular key stored on disk, # 'T' - Key is stored on a smartcard (token), # 'X' - Unknown type, # '-' - Key is missing. # # SERIALNO is an ASCII string with the serial number of the # smartcard. If the serial number is not known a single # dash '-' is used instead. # # IDSTR is the IDSTR used to distinguish keys on a smartcard. If it # is not known a dash is used instead. # # FPR returns the formatted ssh-style fingerprint of the key. It is only # printed if the option --ssh-fpr has been used. It defaults to '-'. # # TTL is the TTL in seconds for that key or '-' if n/a. # # FLAGS is a word consisting of one-letter flags: # 'D' - The key has been disabled, # 'S' - The key is listed in sshcontrol (requires --with-ssh), # 'c' - Use of the key needs to be confirmed, # '-' - No flags given. # # More information may be added in the future. OK > keyinfo --list [...] I just can't think of how to pick out the right key now... What little detail is eluding me? 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 Thu Nov 24 18:46:17 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 24 Nov 2016 18:46:17 +0100 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: References: <87lgw9neai.fsf@iki.fi> <87h96woolu.fsf@iki.fi> Message-ID: <58b3f812ee87ea25b0a8524afc7a5008@butters.digitalbrains.com> On 2016-11-24 18:36, Peter Lebbing wrote: >> keyinfo --list No, that's wrong, scratch that. That will not work for OpenPGP keys because those aren't handled by the agent in 2.0. Silly me. I'm not sure you can add an OpenPGP auth subkey to the agent's SSH support without resorting to external tools, i.e., follow the method Stephan gave. 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 Thu Nov 24 20:56:20 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 24 Nov 2016 20:56:20 +0100 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> References: <87lgw9neai.fsf@iki.fi> <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> Message-ID: <4e25256d-e658-19f8-a9db-e7cbd4fbad69@digitalbrains.com> Stephan, thanks for helping out! I think I can improve a bit on one part of it, though. On 24/11/16 17:51, Stephan Beck wrote: > A2) Export the secret subkey you'd like to use for ssh authentication > purposes and pipe it through openpgp2ssh > gpg2 --export-secret-subkeys \ > --export-options export-reset-subkey-passwd [keyID!] | \ > openpgp2ssh [keyID] > gpg-auth-keyfile > > A3) Set correct permissions > > chmod 0600 gpg-auth-keyfile This leaves open a window where the file with your private key might be world-readable. The thing I usually do is this: $ mkdir safe $ chmod 700 safe $ cd safe $ [... do your stuff ...] $ cd .. $ rm -rf safe The directory permissions prevent anyone from getting a handle for your file. Even if the file is world-readable, nobody can get towards the file. This is not true if you are on an NFS share, though! The thing I would expect to actually be in the textbooks is a variation of: $ OLD_UMASK=$(umask) $ umask 0077 $ [... do your stuff ...] $ umask $OLD_UMASK The umask 0077 will create any new files with all access rights cleared for group and world. This is your A2 and A3 folded into one, safely, without a gap. 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 Thu Nov 24 21:17:23 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 24 Nov 2016 21:17:23 +0100 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: <4e25256d-e658-19f8-a9db-e7cbd4fbad69@digitalbrains.com> References: <87lgw9neai.fsf@iki.fi> <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> <4e25256d-e658-19f8-a9db-e7cbd4fbad69@digitalbrains.com> Message-ID: <183c2180-f425-1255-f68d-4d7dfc420b90@digitalbrains.com> On 24/11/16 20:56, Peter Lebbing wrote: > This is not true if you are on an NFS share, though! I mean: if you're on an NFS share, or an a disk partition from which things are shared over NFS. So if you're sharing /srv/export and you're on /srv/somewhere/else, it's still not safe. 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 caro at nymph.paranoici.org Fri Nov 25 00:03:01 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Thu, 24 Nov 2016 23:03:01 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161123230916.5960A10320FB@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> Message-ID: <20161124230301.3055810320F5@remailer.paranoici.org> Peter Lebbing wrote: >On 24/11/16 14:16, Carola Grunwald wrote: >> WME combined with nym server usage for example requires an individual >> WME key for each account, as otherwise at least the recipient, who may >> communicate with different aliases is able to link them based on their >> common signature key-ID. > >I don't understand this. Could you give an example or something, to help >me understand? Let's just say I hold two nym accounts at different nym servers https://en.wikipedia.org/wiki/Pseudononymous_remailer#Contemporary_nym_servers and send WME encapsulated mail through both of them to a single recipient making him believe he talks to two different persons. In this case the From: address of the message sent by my mail client tells the proxy that it's nym mail. In addition to that the From: and the To: address can be found in the WME participants list with 'Sign' activated for the From: entry. That's why the proxy clears the message header section, WME encrypts the whole message for the recipient signing it with its individual WME key (which can be the nym server account key), encrypts it for the nym server signed with the nym server account's key and sends the result through the remailer network to the nym server, which removes the nym server encoding layer checking the account signature and sends the resulting WME message to the recipient. If now both of your nym accounts alice at nymserva.net and bob at nymservb.org sign with the same WME key the recipient, to whom that similarity becomes apparent, may wonder whether the obviously single author of these messages suffers from dissociative identity disorder. > >AFAICS, the recipient needs a way to send mail back to the sender, and >hence, a domain name for the sender. Having the signature tell them >which domain name the sender used, tells them nothing. Unless of course >you don't want pseudonymous, but anonymous mail. In the latter case, a >signature is meaningless and should just be omitted altogether. > >> Concerning faked timestamps you have to imagine that an adversary may >> observe your Tor connections. When he sees high activity shortly after >> the signature's timestamp you may have transmitted the respective >> message. > >And how will the adversary see this timestamp? It's encrypted to the >recipient! Surely, if he has the timestamp, he has the plaintext of the >mail and the timestamp is probably the least of your problems. I'm >really not getting this concern! Huh?! Simple answer: You never know who your opponents are. How can you be sure the recipient of your mail isn't one of them? Or his network infiltrated and his computer compromised? Footnote: A pinch of paranoia helps develop solid anonymity software. Act as if there's no one out there you can trust. Kind regards Caro From stebe at mailbox.org Fri Nov 25 10:14:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Fri, 25 Nov 2016 09:14:00 +0000 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: References: <87lgw9neai.fsf@iki.fi> <87h96woolu.fsf@iki.fi> Message-ID: <313eb6ea-7053-87ec-d9f4-0c88f26611ba@mailbox.org> Hi, Peter Lebbing: > On 2016-11-24 16:59, Teemu Likonen wrote: >> I believe that file ~/.gnupg/sshcontrol should contain >> key's keygrip but how do I get the keygrip when there's no >> --with-keygrip option in 2.0? > > I think the following: > > $ gpg-connect-agent >> help keyinfo > # KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] > # > # Return information about the key specified by the KEYGRIP. If the > # key is not available GPG_ERR_NOT_FOUND is returned. If the option > # --list is given the keygrip is ignored and information about all > # available keys are returned. If --ssh-list is given information > # about all keys listed in the sshcontrol are returned. With --with-ssh > # information from sshcontrol is always added to the info. Unless --data > # is given, the information is returned as a status line using the format: > # > # KEYINFO - - > # > # KEYGRIP is the keygrip. > # > # TYPE describes the type of the key: > # 'D' - Regular key stored on disk, > # 'T' - Key is stored on a smartcard (token), > # 'X' - Unknown type, > # '-' - Key is missing. > # > # SERIALNO is an ASCII string with the serial number of the > # smartcard. If the serial number is not known a single > # dash '-' is used instead. > # > # IDSTR is the IDSTR used to distinguish keys on a smartcard. If it > # is not known a dash is used instead. > # > # FPR returns the formatted ssh-style fingerprint of the key. It is only > # printed if the option --ssh-fpr has been used. It defaults to '-'. > # > # TTL is the TTL in seconds for that key or '-' if n/a. > # > # FLAGS is a word consisting of one-letter flags: > # 'D' - The key has been disabled, > # 'S' - The key is listed in sshcontrol (requires --with-ssh), > # 'c' - Use of the key needs to be confirmed, > # '-' - No flags given. > # > # More information may be added in the future. > OK >> keyinfo --list > [...] > > I just can't think of how to pick out the right key now... What little > detail is eluding me? I'm not sure. This is the Agent's ASSUAN protocol. I had a look into the gcrypt manual, as (AFAIK).gpg 2.0 as such lacks a specific command line option, as Teemu indicated. ----------------------------------------------------------------------- This manual is for Libgcrypt (version 1.4.4-svn1342, 20 October 2008), which is GNU's library of cryptographic building blocks. Copyright (C) 2000, 2002, 2003, 2004, 2006, 2007, 2008 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The text of the license can be found in the section entitled "GNU General Public License". 6.5 General public-key related Functions A couple of utility functions are available to retrieve the length of the key, map algorithm identifiers and perform sanity checks: -- Function: unsigned char * gcry_pk_get_keygrip (gcry_sexp_t KEY, unsigned char *ARRAY) Return the so called "keygrip" which is the SHA-1 hash of the public key parameters expressed in a way depended on the algorithm. ---------------------------------------------------------------------- Relevant section in the Info gnupg File: gnupg.info, Node: Top, Next: Installation, Up: (dir) Using the GNU Privacy Guard *************************** This is the 'The GNU Privacy Guard Manual' (version 2.0.26, August 2014). Copyright (C) 2002, 2004, 2005, 2006, 2007, 2010 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. The text of the license can be found in the section entitled "Copying". 2.6 Agent's Assuan Protocol =========================== 2.6.10 Check whether a key is available --------------------------------------- This can be used to see whether a secret key is available. It does not return any information on whether the key is somehow protected. HAVEKEY KEYGRIPS The agent answers either with OK or 'No_Secret_Key' (208). The caller may want to check for other error codes as well. More than one keygrip may be given. In this case the command returns success if at least one of the keygrips corresponds to an available secret key. Cheers Stephan From stebe at mailbox.org Fri Nov 25 11:02:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Fri, 25 Nov 2016 10:02:00 +0000 Subject: Trying to figure out what's going on with a key update failure... In-Reply-To: References: <9bb32ac3-c823-ff3c-8202-cd2511c1d726@cajuntechie.org> Message-ID: Hi Anthony, Stephan Beck: > > > Anthony Papillion: >> Hello Everyone, >> >> When I run >> >> gpg2 --keyserver --refresh-keys >> >> Can someone tell me what this error means and how can I fix it? > > Which gpg2 version are you running? 2.0x or 2.1x? sorry for the delay in getting back to you on-list. [Could you please send me the error output you get when decrypting the encrypted message I sent you yesterday, telling you that I had problems in checking keyserver's connection as well, it's just that I'm eager to know and I want to exclude key compromise]. In order to get the details of the communication of keyserver helper programs with the keyserver you should use the --use-temp-files and --keep-temp-files --keyserver options. For example, I tried (a hundred times, with variations) to refresh your key attempting to log keyserver<->helpers communication to check it myself before giving advice gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --refresh-keys 4F765425380A9BBA5F0E0892CC9D1E072AC97369 --no-emit-version --display-charset utf-8 --keyserver-options ca-cert-file=~/sks-keyservers.netCA.pem,use-temp-files=/tmp/tempfile.txt,keep-temp-files,verbose --debug-level 2 But tempin.txt tempout.txt are nowhere. I made a search in the gnupg's pipermail list archive and I consistently found surely authoritative indication of David Shaw that adding --debug 1024 --keyserver-options "use-temp-files keep-temp-files" do result in tempin.txt tempout.txt being logged somewhere. I successfully generated those files in the past when checking communication with keyservers, but I haven't wrote it down and I can't integrate David Shaw's instructions into the above mentioned command-line I used. I'm giving up on this now, eager to hear once for all times HOW to successfully create them. Cheers Stephan From stebe at mailbox.org Fri Nov 25 11:28:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Fri, 25 Nov 2016 10:28:00 +0000 Subject: PM from David Adamson -please ask on-list Message-ID: <7106d356-f1ed-456a-166f-2bfa132e6b23@mailbox.org> Hi David, I kindly invite you to post your PM on-list. It might be of interest for other people as well. Thanks and regards Stephan From stebe at mailbox.org Fri Nov 25 12:01:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Fri, 25 Nov 2016 11:01:00 +0000 Subject: Trying to figure out what's going on with a key update failure... In-Reply-To: References: <9bb32ac3-c823-ff3c-8202-cd2511c1d726@cajuntechie.org> Message-ID: Update: I actually tried gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --refresh-keys 4F765425380A9BBA5F0E0892CC9D1E072AC97369 --no-emit-version --display-charset utf-8 --keyserver-options ca-cert-file=~/sks-keyservers.netCA.pem use-temp-files keep-temp-files verbose as well (with variations), the use-temp-files=/tmp/tempfile.txt is I used in my example below is plainly wrong. Cheers Stephan Stephan Beck: > Hi Anthony, > > Stephan Beck: >> >> >> Anthony Papillion: >>> Hello Everyone, >>> >>> When I run >>> >>> gpg2 --keyserver --refresh-keys > >>> >>> Can someone tell me what this error means and how can I fix it? >> >> Which gpg2 version are you running? 2.0x or 2.1x? > > sorry for the delay in getting back to you on-list. > [Could you please send me the error output you get when decrypting the > encrypted message I sent you yesterday, telling you that I had problems > in checking keyserver's connection as well, it's just that I'm eager to > know and I want to exclude key compromise]. > > > In order to get the details of the communication of keyserver helper > programs with the keyserver you should use the --use-temp-files and > --keep-temp-files --keyserver options. > > For example, I tried (a hundred times, with variations) to refresh your > key attempting to log keyserver<->helpers communication to check it > myself before giving advice > > gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --refresh-keys > 4F765425380A9BBA5F0E0892CC9D1E072AC97369 --no-emit-version > --display-charset utf-8 --keyserver-options > ca-cert-file=~/sks-keyservers.netCA.pem,use-temp-files=/tmp/tempfile.txt,keep-temp-files,verbose > --debug-level 2 > > But tempin.txt tempout.txt are nowhere. > I made a search in the gnupg's pipermail list archive and I consistently > found surely authoritative indication of David Shaw > that adding > --debug 1024 --keyserver-options "use-temp-files keep-temp-files" > > do result in tempin.txt tempout.txt being logged somewhere. > > I successfully generated those files in the past when checking > communication with keyservers, but I haven't wrote it down and I can't > integrate David Shaw's instructions into the above mentioned > command-line I used. > I'm giving up on this now, eager to hear once for all times HOW to > successfully create them. > > Cheers > > Stephan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From davidadamson.md at gmail.com Fri Nov 25 14:12:35 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Fri, 25 Nov 2016 08:12:35 -0500 Subject: What are those attachments you have on your email? Message-ID: On Fri, Nov 25, 2016 at 5:28 AM, Stephan Beck wrote: > Hi David, > > I kindly invite you to post your PM on-list. It might be of interest for > other people as well. > > Thanks and regards > > Stephan > Certainly that sounds like a good idea. Stephan, Thanks again for your help. I am playing around with generating my keys, importing others and encrypting and decrypting. I was thinking of ways to get my key out to people without using the keyservers and instead attaching my public key to my email seemed like a good idea. I noticed you have two, one called 0x4218732B.asc and another called signature.asc. Am I correct in assuming your first one is your public key? The second one I'm not sure what it is for. I thought maybe you were signing your public key so I ran the following but got a BAD signature message so I thought maybe it's for something else - david at system:~/Downloads$ gpg2 --verify signature.asc 0x4218732B.asc gpg: Signature made Wed 23 Nov 2016 11:41:22 AM EST gpg: using RSA key 5E77973C5ED0E692 gpg: Can't check signature: No public key david at system:~/Downloads$ gpg2 --import 0x4218732B.asc gpg: key 1CA0EF5E4218732B: public key "Stephan Beck " imported gpg: Total number processed: 1 gpg: imported: 1 david at system:~/Downloads$ gpg2 --verify signature.asc 0x4218732B.asc gpg: Signature made Wed 23 Nov 2016 11:41:22 AM EST gpg: using RSA key 5E77973C5ED0E692 gpg: BAD signature from "Stephan Beck " [unknown] Thanks! From andrewg at andrewg.com Fri Nov 25 14:18:19 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 25 Nov 2016 13:18:19 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161124230301.3055810320F5@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161123230916.5960A10320FB@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> Message-ID: <7ce9e30b-0c13-215c-b94b-a1a43d4fc87a@andrewg.com> On 24/11/16 23:03, Carola Grunwald wrote: > > Let's just say I hold two nym accounts at different nym servers > > https://en.wikipedia.org/wiki/Pseudononymous_remailer#Contemporary_nym_servers > > and send WME encapsulated mail through both of them to a single > recipient making him believe he talks to two different persons. In this case, you must have already created a separate PGP keypair on your local machine for each nym username. > WME encrypts the > whole message for the recipient signing it with its individual WME key > (which can be the nym server account key) So the server can sign the WME encapsulation with it's own key. It doesn't add anything for the server to use a per-userid key, because the user must already have a per-userid key locally in order to use nym, and so can sign the original message in the MUA. > encrypts it for the nym > server signed with the nym server account's key and sends the result > through the remailer network to the nym server, which removes the nym > server encoding layer checking the account signature and sends the > resulting WME message to the recipient. The same applies at the receiving end. The recipient must have a per-userid PGP key, and therefore can decrypt messages in their own MUA. Encryption to the receiving nym server's common key is sufficient for confidentiality as far as the mailbox - at which point it gets converted back to a standard PGP message. So I can see why you want per-userid PGP keys. And I can see why you want an encryption/signing layer at the MTA. What I don't get is how implementing per-userid keys *at the MTA* gives you anything but grief. Sorry if I'm diverting the subject of the thread, but my initial suspicion was that your scalability issues are the inescapable result of an over-egged design, and I haven't read anything since to change my mind. 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 stebe at mailbox.org Fri Nov 25 14:36:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Fri, 25 Nov 2016 13:36:00 +0000 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: <4e25256d-e658-19f8-a9db-e7cbd4fbad69@digitalbrains.com> References: <87lgw9neai.fsf@iki.fi> <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> <4e25256d-e658-19f8-a9db-e7cbd4fbad69@digitalbrains.com> Message-ID: <88beb5b3-46b2-f99e-84c6-b4f1c21739be@mailbox.org> Thanks, Peter. [no irony] Wherever you shed your light, I'm a bit more enlightened. Peter Lebbing: > Stephan, thanks for helping out! I think I can improve a bit on one part > of it, though. > > On 24/11/16 17:51, Stephan Beck wrote: >> A2) Export the secret subkey you'd like to use for ssh authentication >> purposes and pipe it through openpgp2ssh >> gpg2 --export-secret-subkeys \ >> --export-options export-reset-subkey-passwd [keyID!] | \ >> openpgp2ssh [keyID] > gpg-auth-keyfile >> >> A3) Set correct permissions >> >> chmod 0600 gpg-auth-keyfile > > This leaves open a window where the file with your private key might be > world-readable. Well, one could and should immediately delete this file. I should have mentioned it. Would you please describe more in detail where (or in which way, in which use case) the window is left open? AFAIK, more secure than 0600 is not available within (secure) GNU/Linux (Unix) file permissions. I'm really interested. I'm facing adversaries like the local Jobcenter mafia with all the allies they have and I need to be better than them. > > The thing I usually do is this: > > $ mkdir safe > $ chmod 700 safe > $ cd safe > $ [... do your stuff ...] > $ cd .. > $ rm -rf safe I see. Yes, even better. A directory as another barrier. > > The directory permissions prevent anyone from getting a handle for your > file. Even if the file is world-readable, nobody can get towards the > file. This is not true if you are on an NFS share, though! > > The thing I would expect to actually be in the textbooks is a variation of: > > $ OLD_UMASK=$(umask) > $ umask 0077 > $ [... do your stuff ...] > $ umask $OLD_UMASK > > The umask 0077 will create any new files with all access rights cleared > for group and world. This is your A2 and A3 folded into one, safely, > without a gap. Yes, that sounds good. Nice trick putting the OLD_UMASK into a variable for later recovery. Cheers Stephan From juanmi.3000 at gmail.com Fri Nov 25 14:31:37 2016 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Fri, 25 Nov 2016 14:31:37 +0100 Subject: What are those attachments you have on your email? In-Reply-To: References: Message-ID: <9762f0bf-ea75-8c8e-01c5-aa861ac13b84@gmail.com> On 2016-11-25 at 14:12, David Adamson wrote: > I noticed you have two, one called 0x4218732B.asc and another > called signature.asc. Am I correct in assuming your first one is your > public key? The second one I'm not sure what it is for. I thought > maybe you were signing your public key so I ran the following but got > a BAD signature message so I thought maybe it's for something else The first one is indeed the public key, the second one most likely is the signature for the email using PGP/MIME. If you have PGP-supported email client (like Claws) or the email client have a PGP pluging (like Thunderbird+Enigmail) it should be able to verify it. Otherwise, it looks like a normal message (or empty if PGP/MIME encrypted) with a signature.asc file (sometimes called differently) as an attachment. -- 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 tlikonen at iki.fi Fri Nov 25 15:45:35 2016 From: tlikonen at iki.fi (Teemu Likonen) Date: Fri, 25 Nov 2016 16:45:35 +0200 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> (Stephan Beck's message of "Thu, 24 Nov 2016 16:51:00 +0000") References: <87lgw9neai.fsf@iki.fi> <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> Message-ID: <87a8cnobxs.fsf@iki.fi> Stephan Beck [2016-11-24 16:51:00Z] wrote: > A1) Install the monkeysphere package (1) that includes openpgp2ssh tool > A2) Export the secret subkey you'd like to use for ssh authentication > purposes and pipe it through openpgp2ssh > gpg2 --export-secret-subkeys \ > --export-options export-reset-subkey-passwd [keyID!] | \ > openpgp2ssh [keyID] > gpg-auth-keyfile Not too pretty but it works. Thank you. Since it creates a separate key which is not tied to my secring.gpg the case left me wondering what will happen when I upgrade to gpg 2.1 in the future. I mean I'll run gpg 2.1 someday and it will convert my secring.gpg to some KEYGRIP.key files, including my A-capable key. Will the authentication key be the same and technically compatible with the key that I just created with openpgp2ssh and ssh-add commands? Just wondering. It's not that important. Some manual work is probably necessary anyway at the first upgrade. -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From stebe at mailbox.org Fri Nov 25 15:33:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Fri, 25 Nov 2016 14:33:00 +0000 Subject: What are those attachments you have on your email? In-Reply-To: References: Message-ID: <50f53074-4543-78b0-6337-75503ca9b9c3@mailbox.org> Sorry, David, for arriving a bit late to the party..., I had to answer Peter who had addressed several list mails in reply to mine yesterday and it took me a while. Yes, as Brian says, the verify command expects an .asc signature file and a message or a file signed with it as input. By using/fetching/retrieving the signer's key gpg verifies that this message/file really was signed by the one who claims to be the signer. Cheers Stephan David Adamson: > On Fri, Nov 25, 2016 at 5:28 AM, Stephan Beck wrote: >> Hi David, >> >> I kindly invite you to post your PM on-list. It might be of interest for >> other people as well. >> >> Thanks and regards >> >> Stephan >> > > Certainly that sounds like a good idea. > > Stephan, > > Thanks again for your help. I am playing around with generating my > keys, importing others and encrypting and decrypting. > > I was thinking of ways to get my key out to people without using the > keyservers and instead attaching my public key to my email seemed like a good > idea. I noticed you have two, one called 0x4218732B.asc and another > called signature.asc. Am I correct in assuming your first one is your > public key? The second one I'm not sure what it is for. I thought > maybe you were signing your public key so I ran the following but got > a BAD signature message so I thought maybe it's for something else - > > david at system:~/Downloads$ gpg2 --verify signature.asc 0x4218732B.asc > gpg: Signature made Wed 23 Nov 2016 11:41:22 AM EST > gpg: using RSA key 5E77973C5ED0E692 > gpg: Can't check signature: No public key > david at system:~/Downloads$ gpg2 --import 0x4218732B.asc > gpg: key 1CA0EF5E4218732B: public key "Stephan Beck > " imported > gpg: Total number processed: 1 > gpg: imported: 1 > david at system:~/Downloads$ gpg2 --verify signature.asc 0x4218732B.asc > gpg: Signature made Wed 23 Nov 2016 11:41:22 AM EST > gpg: using RSA key 5E77973C5ED0E692 > gpg: BAD signature from "Stephan Beck " [unknown] > > Thanks! > From brian at minton.name Fri Nov 25 15:16:30 2016 From: brian at minton.name (Brian Minton) Date: Fri, 25 Nov 2016 09:16:30 -0500 Subject: What are those attachments you have on your email? In-Reply-To: References: Message-ID: <20161125141628.j3gqxspgbu4tvj6f@brian.minton.name> On Fri, Nov 25, 2016 at 08:12:35AM -0500, David Adamson wrote: > On Fri, Nov 25, 2016 at 5:28 AM, Stephan Beck wrote: > I was thinking of ways to get my key out to people without using the > keyservers and instead attaching my public key to my email seemed like a good > idea. I noticed you have two, one called 0x4218732B.asc and another > called signature.asc. Am I correct in assuming your first one is your > public key? The second one I'm not sure what it is for. I thought > maybe you were signing your public key so I ran the following but got > a BAD signature message so I thought maybe it's for something else - A signature.asc file is usually for the message itself. See RFC 3156. https://tools.ietf.org/html/rfc3156 for more details. It's called PGP/MIME and it allows you to encrypt, sign, or both for messages containing attachments. -- Brian Minton brian at minton dot name http://brian.minton.name Live long, and prosper longer! OpenPGP fingerprint = 8213 71DD 4665 CF4F AE20 2206 0424 DC19 B678 A1A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 390 bytes Desc: not available URL: From davidadamson.md at gmail.com Fri Nov 25 17:01:11 2016 From: davidadamson.md at gmail.com (David Adamson) Date: Fri, 25 Nov 2016 11:01:11 -0500 Subject: What are those attachments you have on your email? In-Reply-To: <50f53074-4543-78b0-6337-75503ca9b9c3@mailbox.org> References: <50f53074-4543-78b0-6337-75503ca9b9c3@mailbox.org> Message-ID: On Fri, Nov 25, 2016 at 9:33 AM, Stephan Beck wrote: > Sorry, David, for arriving a bit late to the party..., I had to answer > Peter who had addressed several list mails in reply to mine yesterday > and it took me a while. > Yes, as Brian says, the verify command expects an .asc signature file > and a message or a file signed with it as input. By > using/fetching/retrieving the signer's key gpg verifies that this > message/file really was signed by the one who claims to be the signer. > > Cheers > > Stephan > Stephan so this is a result of you using a mail client that requires the signature file and If I used a similar mail client it could automatically verify this email message was signed by the holder of Stephan's private key? However is it the case as Juan put it that since I'm using another type of mail service, in my case gmail web based interface, that this signature will not be applicable? Juan said: "Otherwise, it looks like a normal message (or empty if PGP/MIME encrypted) with a signature.asc file (sometimes called differently) as an attachment." Brian, Thanks for the resource. I'll have to get used to reading/understanding this type of material/subject matter. From peter at digitalbrains.com Fri Nov 25 21:37:40 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 25 Nov 2016 21:37:40 +0100 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: <88beb5b3-46b2-f99e-84c6-b4f1c21739be@mailbox.org> References: <87lgw9neai.fsf@iki.fi> <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> <4e25256d-e658-19f8-a9db-e7cbd4fbad69@digitalbrains.com> <88beb5b3-46b2-f99e-84c6-b4f1c21739be@mailbox.org> Message-ID: On 25/11/16 14:36, Stephan Beck wrote: > Would you please describe more in detail where (or in which way, in > which use case) the window is left open? Let me reuse a bit of quote from an earlier mail: >>> A2) Export the secret subkey you'd like to use for ssh authentication >>> purposes and pipe it through openpgp2ssh >>> gpg2 --export-secret-subkeys \ >>> --export-options export-reset-subkey-passwd [keyID!] | \ >>> openpgp2ssh [keyID] > gpg-auth-keyfile Here a file is created with most likely mode 0644. It contains an unencrypted private key, and anyone being quick about it can read the file until you have time to type.... >>> >>> A3) Set correct permissions >>> >>> chmod 0600 gpg-auth-keyfile ... and from this moment on it is secure. If somebody knew beforehand you were going to do this on a multi-user system, he could monitor likely directories programmatically and catch you in the act. Paranoia mode... on! 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 mrsam at courier-mta.com Fri Nov 25 21:03:14 2016 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Fri, 25 Nov 2016 15:03:14 -0500 Subject: Should gpg2's --passphrase-fd option automatically set --pinentry-mode =?UTF-8?Q?loopback=3F?= Message-ID: I have an application that runs gpg in batch mode to sign files. No issues with using gpg: $ gpg --passphrase-fd 10 -s -b -a --default-key [hash] 10" 4096-bit RSA key, ID 279DBF25, created 2013-08-25 -----BEGIN PGP SIGNATURE----- [ the signature] But the same parameters do not work if I use gpg2 instead of gpg: $ gpg2 --passphrase-fd 10 -s -b -a --default-key [hash] 10 From anthony at cajuntechie.org Sat Nov 26 00:40:17 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Fri, 25 Nov 2016 17:40:17 -0600 Subject: Trying to figure out what's going on with a key update failure... In-Reply-To: References: <9bb32ac3-c823-ff3c-8202-cd2511c1d726@cajuntechie.org> Message-ID: <6830513b-813a-bfdd-3d58-2f0f5bb9fc18@cajuntechie.org> On 11/25/2016 4:02 AM, Stephan Beck wrote: > Hi Anthony, > > Stephan Beck: >> >> >> Anthony Papillion: >>> Hello Everyone, >>> >>> When I run >>> >>> gpg2 --keyserver --refresh-keys > >>> >>> Can someone tell me what this error means and how can I fix it? >> >> Which gpg2 version are you running? 2.0x or 2.1x? > > sorry for the delay in getting back to you on-list. > [Could you please send me the error output you get when decrypting the > encrypted message I sent you yesterday, telling you that I had problems > in checking keyserver's connection as well, it's just that I'm eager to > know and I want to exclude key compromise]. No problem. When I try to decrypt your message, I get the follow from GPG: gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped You need a passphrase to unlock the secret key for user: "Anthony Papillion " 4096-bit RSA key, ID 0x002919C90AF4A3BC, created 2016-10-12 (subkey on main key ID 0xCC9D1E072AC97369) gpg: no valid OpenPGP data found. > In order to get the details of the communication of keyserver helper > programs with the keyserver you should use the --use-temp-files and > --keep-temp-files --keyserver options. > > For example, I tried (a hundred times, with variations) to refresh your > key attempting to log keyserver<->helpers communication to check it > myself before giving advice After some testing, I found out that the keys were, in some/most cases actually getting refreshed. I'm going to try with the new options and see what information I can coax out of GPG. Anthony -- VoIP/SIP: 1259010 at localphone.com Skype: cajuntechie XMPP/Jabber: papillion at dukgo.com PGP Key: 0xCC9D1E072AC97369 Other Info: http://www.cajuntechie.org/p/my-pgp-key.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 caro at nymph.paranoici.org Sat Nov 26 02:17:31 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sat, 26 Nov 2016 01:17:31 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <7ce9e30b-0c13-215c-b94b-a1a43d4fc87a@andrewg.com> Message-ID: <20161126011731.16571100A9A2@remailer.paranoici.org> Andrew Gallagher wrote: >On 24/11/16 23:03, Carola Grunwald wrote: >> >> Let's just say I hold two nym accounts at different nym servers >> >> https://en.wikipedia.org/wiki/Pseudononymous_remailer#Contemporary_nym_servers >> >> and send WME encapsulated mail through both of them to a single >> recipient making him believe he talks to two different persons. > >In this case, you must have already created a separate PGP keypair on >your local machine for each nym username. WME encoding, remailing and nym handling are done completely at the proxy. You can use any, even the most primitive PGP-unaware MUA to send and receive standard mail and Usenet messages, crypto and anonymization capabilities are provided by the proxy. > >> WME encrypts the >> whole message for the recipient signing it with its individual WME key >> (which can be the nym server account key) > >So the server can sign the WME encapsulation with it's own key. By signing all WME messages of all your nym accounts with an identical key, your imaginary proxy server key, you disclose that all of them originate from the same server. That means on one hand you try to avoid all potential similarities between your nyms, from writing style to (day)time patterns of message creation, and on the other all your messages' signatures scream out loud 'We belong together!'. You see the discrepancy? Or what's your point here? > It >doesn't add anything for the server to use a per-userid key, because >the user must already have a per-userid key locally in order to use >nym, and so can sign the original message in the MUA. No problem to add another inner PGP encryption layer created locally by the MTA with a key controlled by the user. But MUAs don't have my proxy's header filtering, header and MIME boundary delimiter normalizing, nym formating and crypto capabilities that make it so easy to use remailers and nym servers in a secure way. > >> encrypts it for the nym >> server signed with the nym server account's key and sends the result >> through the remailer network to the nym server, which removes the nym >> server encoding layer checking the account signature and sends the >> resulting WME message to the recipient. > >The same applies at the receiving end. The recipient must have a >per-userid PGP key, and therefore can decrypt messages in their own >MUA. Which MUA can restore a WME encrypted message? > Encryption to the receiving nym server's common key is sufficient >for confidentiality as far as the mailbox - at which point it gets >converted back to a standard PGP message. In my example the message follows the path MUA > proxy (SMTP) > Tor network (3 nodes) > remailer network (1..20 hops) > nym server > POP3 server > proxy (POP3) > MUA And as I earlier tried to explain a standard PGP message leaks lots of information which a WME message doesn't. Kind regards Caro From wk at gnupg.org Sat Nov 26 11:01:27 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Nov 2016 11:01:27 +0100 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> (Stephan Beck's message of "Thu, 24 Nov 2016 16:51:00 +0000") References: <87lgw9neai.fsf@iki.fi> <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> Message-ID: <878ts6h85k.fsf@wheatstone.g10code.de> On Thu, 24 Nov 2016 17:51, stebe at mailbox.org said: > Yes, --export-ssh-key has been introduced in gpg with release of version > 2.1.11. Unfortunately there is a regession in 2.1.16 which renders this command unusable. 2.1.15 worked and we will fix the regression for 2.1.17. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Sat Nov 26 17:47:59 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Nov 2016 17:47:59 +0100 Subject: How to prevent passphrase caching in 2.1 In-Reply-To: <20161123022836.845501032265@remailer.paranoici.org> (Carola Grunwald's message of "Wed, 23 Nov 2016 02:28:36 +0000 (UTC)") References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161121142004.416101032265@remailer.paranoici.org> <20161122162026.CF0C2100B129@remailer.paranoici.org> <915f84a9-2b95-75eb-3ffa-d79f8ae5d000@digitalbrains.com> <20161123022836.845501032265@remailer.paranoici.org> Message-ID: <87d1hifark.fsf@wheatstone.g10code.de> On Wed, 23 Nov 2016 03:28, caro at nymph.paranoici.org said: > Sure, I like v1.4's small footprint and its reliability. But as the > --faked-system-time option, important in my application for privacy > reasons, wasn't backported to v1.4, I had to migrate to v2.1. I'm still If you are running on a glibc system you can apt-get install faketime to get basically the same effect. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From stebe at mailbox.org Sat Nov 26 21:17:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sat, 26 Nov 2016 20:17:00 +0000 Subject: What are those attachments you have on your email? In-Reply-To: References: <50f53074-4543-78b0-6337-75503ca9b9c3@mailbox.org> Message-ID: <6ba1aaf1-8f7a-b84d-91b2-bd12f2bf6e90@mailbox.org> Hi, David Adamson: > On Fri, Nov 25, 2016 at 9:33 AM, Stephan Beck wrote: > Stephan so this is a result of you using a mail client that requires > the signature file and If I used a similar mail client it could > automatically verify this email message was signed by the holder of > Stephan's private key? If you used a PGP/MIME compliant email client (may it be Claws or Thunderbird with the Enigmail plugin) you'd see the signature file as an attachment to the email, and by importing (or retrieving and importing it, if not yet present in the keyring) the sender's public key using the appropriate commands of this email client or the respective plugin like Enigmail, "you" could verify the signature, i.e. verify that the signed message was effectively signed with the private (signing) key of the holder of the respective public key. (The corresponding plugin such as Enigmail verifies the signature automatically when you select the message) If you used a non PGP/MIME email client (without any plugin of this kind) or a webmail interface (not capable of handling such messages) you would not be able to directly process the attachment for verifying purposes. But you could open the message's header ("View Source" command) copy and paste the signature including the --- BEGIN/END --- parts (see below) into a text file, save it with .asc file extension and verify it by means of gpg (or the dedicated gpgv package). gpg2 --verify signature.asc signed_message_text.txt. If it is a public key, you can copy and paste it (including the --- BEGIN/END --- parts) into a text file, save it with the .asc file extension and import it directly into your keyring using the gpg2 --import command -----BEGIN PGP SIGNATURE--- [SIGNATURE] -----END PGP SIGNATURE----- or (in case of a public key) -----BEGIN PGP PUBLIC KEY BLOCK----- [PUBLIC KEY in armored format] -----END PGP PUBLIC KEY BLOCK------- > > However is it the case as Juan put it that since I'm using another > type of mail service, in my case gmail web based interface, that this > signature will not be applicable? I actually don't know gmail well, so I cannot tell you (but you can) whether gmail has any type of PGP/MIME handling webmail-based apps. If not, the PGP/MIME signature attachment cannot be "processed" directly. But you could save the attachment as .asc file (seemingly you did that), save the message as a text file and put both (first the signature file) on gpg's command line (see above) to verify the signature (key will be retrieved by gpg if it's not yet present.) Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Sat Nov 26 21:33:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sat, 26 Nov 2016 20:33:00 +0000 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: References: <87lgw9neai.fsf@iki.fi> <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> <4e25256d-e658-19f8-a9db-e7cbd4fbad69@digitalbrains.com> <88beb5b3-46b2-f99e-84c6-b4f1c21739be@mailbox.org> Message-ID: <110518b3-0f83-22e0-9a0f-979b8e0eb25b@mailbox.org> Oh indeed! I didn't catch it at first glance that you were referring to that short moment between creating the file and chmod 0600! I thought I missed something with secure file permissions. :-) I only could say that I was "blinded by the light" you shed, but I won't Thanks! Stephan Peter Lebbing: > On 25/11/16 14:36, Stephan Beck wrote: >> Would you please describe more in detail where (or in which way, in >> which use case) the window is left open? > > Let me reuse a bit of quote from an earlier mail: > >>>> A2) Export the secret subkey you'd like to use for ssh authentication >>>> purposes and pipe it through openpgp2ssh >>>> gpg2 --export-secret-subkeys \ >>>> --export-options export-reset-subkey-passwd [keyID!] | \ >>>> openpgp2ssh [keyID] > gpg-auth-keyfile > > Here a file is created with most likely mode 0644. It contains an > unencrypted private key, and anyone being quick about it can read the > file until you have time to type.... > >>>> >>>> A3) Set correct permissions >>>> >>>> chmod 0600 gpg-auth-keyfile > > ... and from this moment on it is secure. > > If somebody knew beforehand you were going to do this on a multi-user > system, he could monitor likely directories programmatically and catch > you in the act. Paranoia mode... on! > > HTH, > > Peter. > From stebe at mailbox.org Sat Nov 26 22:04:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sat, 26 Nov 2016 21:04:00 +0000 Subject: Is --export-ssh-key functionality possible with GnuPG 2.0? In-Reply-To: <87a8cnobxs.fsf@iki.fi> References: <87lgw9neai.fsf@iki.fi> <6f705f2a-0625-7ac3-960d-56a3dca27562@mailbox.org> <87a8cnobxs.fsf@iki.fi> Message-ID: <874cf4b3-03a7-d565-def4-e151cd74f636@mailbox.org> Hi Teemu, Teemu Likonen: > Stephan Beck [2016-11-24 16:51:00Z] wrote: > >> A1) Install the monkeysphere package (1) that includes openpgp2ssh tool >> A2) Export the secret subkey you'd like to use for ssh authentication >> purposes and pipe it through openpgp2ssh >> gpg2 --export-secret-subkeys \ >> --export-options export-reset-subkey-passwd [keyID!] | \ >> openpgp2ssh [keyID] > gpg-auth-keyfile > > Not too pretty but it works. Thank you. > > Since it creates a separate key which is not tied to my secring.gpg the > case left me wondering what will happen when I upgrade to gpg 2.1 in the > future. I mean I'll run gpg 2.1 someday and it will convert my > secring.gpg to some KEYGRIP.key files, including my A-capable key. Will > the authentication key be the same and technically compatible with the > key that I just created with openpgp2ssh and ssh-add commands? > > Just wondering. It's not that important. Some manual work is probably > necessary anyway at the first upgrade. > I have compiled and installed gnupg-2.1.16 into the home directory to study it but nevertheless cannot really use it at the moment as I still have 2.0.x installed. I read that de-installing 2.0.x would rise problems, and for the smart card type I currently use, according to the manufacturer, it's better to stick to 2.0.x. But I'm curious! I consider installing and using it on another machine. That being said, 2.1. allows for the merging of secret keys, so I guess it's possible to keep on using your secret A-capable (sub)key. But I don't know for sure whether the conversion process of the secring.gpg mastered by gpg 2.1. will change any (mathematical/technical) properties of the key(s) (as I haven't done it for now) or not. In any case, it's good to back up the secret key (and the public part of the secret key) before piping it through the openpgp2ssh monkeysphere tool. I read that gpg 2.1 only touches secring.gpg once (for conversion) and never again. So if you re-import it to secring.gpg after that moment, maybe you could still use it with an installed 1.4.x version and then it really is the SAME key. Unfortunately I cannot tell you YES or NO for sure, but maybe a list fellow has already went through that process and is willing to give his 2 cent. Cheers Stephan From stebe at mailbox.org Sat Nov 26 22:38:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sat, 26 Nov 2016 21:38:00 +0000 Subject: Trying to figure out what's going on with a key update failure... In-Reply-To: <6830513b-813a-bfdd-3d58-2f0f5bb9fc18@cajuntechie.org> References: <9bb32ac3-c823-ff3c-8202-cd2511c1d726@cajuntechie.org> <6830513b-813a-bfdd-3d58-2f0f5bb9fc18@cajuntechie.org> Message-ID: <7e7b3043-11a5-d98f-91eb-77d6e3920e65@mailbox.org> Anthony Papillion: > On 11/25/2016 4:02 AM, Stephan Beck wrote: >> Hi Anthony, >> > No problem. When I try to decrypt your message, I get the follow from GPG: > > gpg: invalid radix64 character 2D skipped > gpg: invalid radix64 character 2D skipped > gpg: invalid radix64 character 2D skipped > gpg: invalid radix64 character 2D skipped > > You need a passphrase to unlock the secret key for > user: "Anthony Papillion " > 4096-bit RSA key, ID 0x002919C90AF4A3BC, created 2016-10-12 > (subkey on main key ID 0xCC9D1E072AC97369) > > gpg: no valid OpenPGP data found. > >> In order to get the details of the communication of keyserver helper >> programs with the keyserver you should use the --use-temp-files and >> --keep-temp-files --keyserver options. >> >> For example, I tried (a hundred times, with variations) to refresh your >> key attempting to log keyserver<->helpers communication to check it >> myself before giving advice > > After some testing, I found out that the keys were, in some/most cases > actually getting refreshed. I'm going to try with the new options and > see what information I can coax out of GPG. Thanks, Anthony. I'll have a look into libpgp-error, maybe I can find some info. The message may have been altered (tampered). Cheers Stephan From stebe at mailbox.org Sun Nov 27 00:17:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sat, 26 Nov 2016 23:17:00 +0000 Subject: Trying to figure out what's going on with a key update failure... In-Reply-To: <7e7b3043-11a5-d98f-91eb-77d6e3920e65@mailbox.org> References: <9bb32ac3-c823-ff3c-8202-cd2511c1d726@cajuntechie.org> <6830513b-813a-bfdd-3d58-2f0f5bb9fc18@cajuntechie.org> <7e7b3043-11a5-d98f-91eb-77d6e3920e65@mailbox.org> Message-ID: Stephan Beck: > > Anthony Papillion: [...] > > Thanks, Anthony. I'll have a look into libpgp-error, maybe I can find > some info. The message may have been altered (tampered). > Oops, I wrote and then I thought. To speak with the libgcrypt manual (libgcrypt uses libgpg-error) This manual is for Libgcrypt (version 1.4.4-svn1342, 20 October 2008), which is GNU's library of cryptographic building blocks. Copyright (C) 2000, 2002, 2003, 2004, 2006, 2007, 2008 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The text of the license can be found in the section entitled "GNU General Public License". ... "Some error values do not indicate a system error or an error in the operation, but the result of an operation that failed properly." So, nothing to be found there, apart from the fact that it's an example of the NO_DATA error. Cheers Stephan From stebe at mailbox.org Sun Nov 27 01:06:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 27 Nov 2016 00:06:00 +0000 Subject: Trying to figure out what's going on with a key update failure... In-Reply-To: <6830513b-813a-bfdd-3d58-2f0f5bb9fc18@cajuntechie.org> References: <9bb32ac3-c823-ff3c-8202-cd2511c1d726@cajuntechie.org> <6830513b-813a-bfdd-3d58-2f0f5bb9fc18@cajuntechie.org> Message-ID: <10d28be9-1ea2-b998-c2af-795ce9c8fb3c@mailbox.org> Hi Anthony, Anthony Papillion: > On 11/25/2016 4:02 AM, Stephan Beck wrote: [...] > > No problem. When I try to decrypt your message, I get the follow from GPG: > > gpg: invalid radix64 character 2D skipped > gpg: invalid radix64 character 2D skipped > gpg: invalid radix64 character 2D skipped > gpg: invalid radix64 character 2D skipped > > You need a passphrase to unlock the secret key for > user: "Anthony Papillion " > 4096-bit RSA key, ID 0x002919C90AF4A3BC, created 2016-10-12 > (subkey on main key ID 0xCC9D1E072AC97369) > > gpg: no valid OpenPGP data found. There are several possibilities (1,2,3,4), but it seems to be an encoding issue or a line-wrapping issue. Could you try to decrypt once again adding the --list-packets option Depending on the additional output you get you can narrow down the error source. (1) https://www.enigmail.net/list_archive/2011-April/013658.html (2) http://gnupg.10057.n7.nabble.com/Problem-when-decrypting-PGP-messages-td11154.html (3) https://superuser.com/questions/840257/why-does-gpg-not-like-this-encrypted-message (4) http://www.angelfire.com/pr/pgpf/pgpoddities.html Cheers Stephan From caro at nymph.paranoici.org Sun Nov 27 18:15:55 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sun, 27 Nov 2016 17:15:55 +0000 (UTC) Subject: How to prevent passphrase caching in 2.1 References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161122162026.CF0C2100B129@remailer.paranoici.org> <915f84a9-2b95-75eb-3ffa-d79f8ae5d000@digitalbrains.com> <20161123022836.845501032265@remailer.paranoici.org> <87d1hifark.fsf@wheatstone.g10code.de> Message-ID: <20161127171555.A1137100B022@remailer.paranoici.org> Werner Koch wrote: >On Wed, 23 Nov 2016 03:28, caro at nymph.paranoici.org said: > >> Sure, I like v1.4's small footprint and its reliability. But as the >> --faked-system-time option, important in my application for privacy >> reasons, wasn't backported to v1.4, I had to migrate to v2.1. I'm still > >If you are running on a glibc system you can apt-get install faketime to >get basically the same effect. Werner, thanks for your reply. But no, unfortunately it's a Windows server application with GnuPG, Tor, Mixmaster and Hamster embedded. And in a server environment it's problematic to switch system time back and forth, which this proxy nevertheless is forced to support though you get problems like this Tor confusion | 19:46:03.084 650 NOTICE Bootstrapped 100%: Done | 17:20:38.564 650 NOTICE Your system clock just jumped 181526 seconds backward; assuming established circuits no longer work. | 19:46:06.722 650 NOTICE Your system clock just jumped 181527 seconds forward; assuming established circuits no longer work. which by itself leaks information to the Internet. I'm stuck. Kind regards Caro From andrewg at andrewg.com Mon Nov 28 16:00:22 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 28 Nov 2016 15:00:22 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161126011731.16571100A9A2@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <7ce9e30b-0c13-215c-b94b-a1a43d4fc87a@andrewg.com> <20161126011731.16571100A9A2@remailer.paranoici.org> Message-ID: <9b2fcd15-6bb8-0943-dcfb-212306586ea0@andrewg.com> On 26/11/16 01:17, Carola Grunwald wrote: > > WME encoding, remailing and nym handling are done completely at the > proxy. You can use any, even the most primitive PGP-unaware MUA to send > and receive standard mail and Usenet messages, crypto and anonymization > capabilities are provided by the proxy. I understand how this would be useful for people with limited clients, but is it really worth it to worry about disclosing metadata at the server when you're leaking plaintext at the client? I was assuming that the end user would have a PGP-capable client. In the case where the end user does not have PGP, would it not be safer to use webmail over TLS? At least you won't leak plaintext... > By signing all WME messages of all your nym accounts with an identical > key, your imaginary proxy server key, you disclose that all of them > originate from the same server. Doesn't the return path leak this info anyway? Unless you're talking about one-shot messages with no return path, in which case why sign at all? 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 caro at nymph.paranoici.org Tue Nov 29 00:00:51 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Mon, 28 Nov 2016 23:00:51 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <7ce9e30b-0c13-215c-b94b-a1a43d4fc87a@andrewg.com> <20161126011731.16571100A9A2@remailer.paranoici.org> <9b2fcd15-6bb8-0943-dcfb-212306586ea0@andrewg.com> Message-ID: <20161128230051.9D86B100B094@remailer.paranoici.org> Andrew Gallagher wrote: >On 26/11/16 01:17, Carola Grunwald wrote: >> >> WME encoding, remailing and nym handling are done completely at the >> proxy. You can use any, even the most primitive PGP-unaware MUA to send >> and receive standard mail and Usenet messages, crypto and anonymization >> capabilities are provided by the proxy. > >I understand how this would be useful for people with limited clients, >but is it really worth it to worry about disclosing metadata at the >server when you're leaking plaintext at the client? Leaking what to whom? I don't quite understand what you mean. Do you mean the raw message the client sends to the proxy server? But that's within the LAN and protected by a direct SSL/TLS encrypted MUA-proxy connection. And if you're outside your LAN with your client then you may use an end-to-end encrypted Tor .onion connection to your proxy's service. And at the proxy your messages' metadata are cut down to what's mandatory to transfer the information. > >I was assuming that the end user would have a PGP-capable client. In >the case where the end user does not have PGP, would it not be safer to >use webmail over TLS? At least you won't leak plaintext... I hope that's addressed above. No problem to set up a local webmail system and connect it with the outer world through the proxy's SMTP and POP3 server. Btw, nearly all proxy parameters relevant for message processing can be controlled by adding certain custom headers to the message itself (normal vs. anonymous routing, remailer chain length, WME activation, message header items that have to be removed, whether the WME or nym public key have to be added to the header section and so on). > >> By signing all WME messages of all your nym accounts with an identical >> key, your imaginary proxy server key, you disclose that all of them >> originate from the same server. > >Doesn't the return path leak this info anyway? Unless you're talking >about one-shot messages with no return path, in which case why sign at all? If you need to remain anonymous towards your communication partner you have to involve a nym server, which holds your pseudonymous mailbox and provides your mail address. Replies sent there are PK-encrypted with your nym's key (signed with the nym server's key), then sent through 1+ Cypherpunk remailers (the first one at the nym server's location) to its destination, which can be either your true mail address or, more secure, a newsgroup (preferably alt.anonymous.messages) from where you can download it anonymously e.g through the Tor network. Each of the Cypherpunk remailers the message passes adds a symmetric encryption layer. The remailer routing and the passphrases they have to use were, defined by the nym user, packed into a so called reply-block and sent to the nym server with the initial nym creation message as described in http://www.danner-net.de/omom/appendhelpnymserver.htm Kind regards Caro From freelab at riseup.net Tue Nov 29 19:26:15 2016 From: freelab at riseup.net (Petros at Freelab) Date: Tue, 29 Nov 2016 20:26:15 +0200 Subject: Thunderbird / Enigmail / GnuPG2 -- cooperation stopped after GPG upgrade? Message-ID: I just had a routine upgrade of ThunderBird and my Enigmail. Now, I cannot do anything related to Enigmail. The interface starts, but then nothing happens beyond the first screen. No request for passphrase if I try to send a message. No downlload of a draft. Configuration wizard shows first form, but doesn't advance any further. Keys management shows "loading keys" forever. I discussed the issue at Enigmail forum (https://sourceforge.net/p/enigmail/forum/support/thread/80fde7d4/#e1b7) and the final answer was: > I am seeing the following in the log file. > > gpg: starting migration from earlier GnuPG versions > gpg: can't connect to the agent: IPC connect call failed > gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can > be started. > gpg: migration aborted > gpg: can't connect to the agent: IPC connect call failed > > This is a GnuPG setup issue. It looks like gpg (not Thunderbird or > Enigmail) got upgraded and doesn't work correctly anymore. I'm sorry, > but these sort of things are better supported by the GnuPG folks, not > Enigmail. > So, I am coming here... See previously generated logs & info: TB troubleshooting info http://pastebin.com/ujsLwdMi Enigmail log covering the operations: http://pastebin.com/RhJ3Wz6A (alternative method: http://imgur.com/a/Sh0vu) Content of ~/.gnupg folder: http://imgur.com/a/beRHH Best, Petros -- https://freelab.libtech.website researching freedom since 2011 >>> If Riseup is down, use freelab at aktivix.org <<< -------------- next part -------------- An HTML attachment was scrubbed... URL: From zepmaster at gmx.net Tue Nov 29 21:19:06 2016 From: zepmaster at gmx.net (zep) Date: Tue, 29 Nov 2016 21:19:06 +0100 Subject: private subkey not found Message-ID: <42e8f41e-8ee5-e16b-5672-e2aef80dc095@gmx.net> Hello, I have some trouble using an imported subkey: gpg --list-secret-keys sec rsa4096/0xABCDEFGH 2015-04-07 [SCA] [expires: 2020-04-05] Key fingerprint = ABCD ABCD ABCD .... uid [ultimate] zep ssb rsa4096/0xDEADBEEF 2015-04-07 [E] [expires: 2020-04-05] So it seems, the private master key (0xABCDEFGH) and the private subkey (0xDEADBEEF) are both available. But the decryption of a message encrypted with the subkey fails: gpg -e -r zepmaster at gmx.net test.txt gpg -d test.txt.gpg gpg: encrypted with 4096-bit RSA key, ID 0xDEADBEEF , created 2015-04-07 "zep " gpg: public key decryption failed: Invalid name gpg: decryption failed: No secret key Also, gpg-connect-agent, then keyinfo --list gives this: gpg-connect-agent > keyinfo --list S KEYINFO "some hex string" D - - - P - - - ERR 67108891 Not found Has anyone an idea, why decryption with this subkey does not work as obviously, the private subkey seems to be available. gpg (GnuPG) 2.1.15 libgcrypt 1.7.3 Thank you very much, Cheers, zep From gpg at rmf.io Wed Nov 30 07:16:19 2016 From: gpg at rmf.io (R. Martinho Fernandes) Date: Wed, 30 Nov 2016 07:16:19 +0100 Subject: PKA records Message-ID: <1480486579.3741809.803381865.118ADB59@webmail.messagingengine.com> I can't seem to find any up-to-date documentation on how to deploy DNS PKA records for use with `auto-key-locate`. I tried `gpg --export-options export-pka --export` and pasted those records directly in DNS, and yet when I use `--auto-key-locate pka`, I get: error retrieving 'rmf at rmf.io' via PKA: Not found The old PKA records (TXT "v=pka1; ...") had a URI, but I can see that the new one that I exported only includes the key fingerprint, so it obviously cannot be used for retrieval alone. What am I missing? From wk at gnupg.org Wed Nov 30 10:39:48 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Nov 2016 10:39:48 +0100 Subject: Thunderbird / Enigmail / GnuPG2 -- cooperation stopped after GPG upgrade? In-Reply-To: (Petros at Freelab's message of "Tue, 29 Nov 2016 20:26:15 +0200") References: Message-ID: <87zikh71cr.fsf@wheatstone.g10code.de> On Tue, 29 Nov 2016 19:26, freelab at riseup.net said: >> gpg: can't connect to the agent: IPC connect call failed >> gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can >> be started. Well, you need to do that: First enter gpg-agent --version Does the printed version match the gpg version? Try gpg --debug 1024 -v -K this has the side-effect of starting the agent. Same error mesage as above? Run gpg-agent -v --daemon this will start the agent directly. Error messages? Finally what is the output of gpgconf --list-dirs Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Wed Nov 30 10:44:08 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Nov 2016 10:44:08 +0100 Subject: private subkey not found In-Reply-To: <42e8f41e-8ee5-e16b-5672-e2aef80dc095@gmx.net> (zep's message of "Tue, 29 Nov 2016 21:19:06 +0100") References: <42e8f41e-8ee5-e16b-5672-e2aef80dc095@gmx.net> Message-ID: <87shq9715j.fsf@wheatstone.g10code.de> On Tue, 29 Nov 2016 21:19, zepmaster at gmx.net said: > sec rsa4096/0xABCDEFGH 2015-04-07 [SCA] [expires: 2020-04-05] > Key fingerprint = ABCD ABCD ABCD .... That does not look like the standard output of gpg 2.1.15 - Please remove the keyid-format option from your gpg.conf. > gpg-connect-agent >> keyinfo --list > S KEYINFO "some hex string" D - - - P - - - > ERR 67108891 Not found Are all keyfiles in ~/.gnupg/private-keys-v1.d/ readable ? Check the permissions. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Wed Nov 30 10:54:09 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Nov 2016 10:54:09 +0100 Subject: PKA records In-Reply-To: <1480486579.3741809.803381865.118ADB59@webmail.messagingengine.com> (R. Martinho Fernandes's message of "Wed, 30 Nov 2016 07:16:19 +0100") References: <1480486579.3741809.803381865.118ADB59@webmail.messagingengine.com> Message-ID: <87oa0x70ou.fsf@wheatstone.g10code.de> On Wed, 30 Nov 2016 07:16, gpg at rmf.io said: > the new one that I exported only includes the key fingerprint, so it > obviously cannot be used for retrieval alone. What am I missing? Use gpg --export-options export-pka --export USERID to create resource records for use in zone files. The format of the PKA record was changed from a TXT record to a CERT record (RFC-4398, IPGP subtype). The above command only includes the fingerprint, but you can also add an URL to it, albeit without gpg support to _create_ it. gpg uses the fingerprint from the CERT record to lookup the key from a keyserver or from the URL, if given. I would suggest not to use PKA or DANE but settle for the Web Key Directory; see recent posts at https://gnupg.org/blog/ Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From stargrave at stargrave.org Wed Nov 30 09:09:59 2016 From: stargrave at stargrave.org (Sergey Matveev) Date: Wed, 30 Nov 2016 11:09:59 +0300 Subject: PKA records In-Reply-To: <1480486579.3741809.803381865.118ADB59@webmail.messagingengine.com> References: <1480486579.3741809.803381865.118ADB59@webmail.messagingengine.com> Message-ID: <20161130080959.GA3030@stargrave.org> *** R. Martinho Fernandes [2016-11-30 10:50]: >I can't seem to find any up-to-date documentation on how to deploy DNS >PKA records for use with `auto-key-locate`. For me "gpg --export --export-options export-pka KEYID" works fine. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF From k at rdw.se Wed Nov 30 17:33:50 2016 From: k at rdw.se (Chris) Date: Wed, 30 Nov 2016 16:33:50 +0000 Subject: Is there a =?utf-8?B?4oCcZ3JvdW5kLXVw4oCd?= explanation of PGP/GnuPG? Message-ID: <87a8ch2ahd.fsf@vps.i-did-not-set--mail-host-address--so-tickle-me> I have asked this on HN[1] as well as Reddit[2] too, but I realised you people might be a better audience for the question! (...And it gives me a good excuse to subscribe to my first mailing list!) Question below: Understanding how git works internally "from the ground up" has been incredibly helpful in my everyday work; things like blobs, commit objects, hashes and how they connect to form the git experience as I know it. Where I had been cargo-culting along previously, it all became clear once I understood the fundamental model of what was going on underneath the interface. I feel like the same thing could apply to PGP/GnuPG. I am cargo culting my way along but I feel like I would feel much, much, much more comfortable if I knew how it worked from the ground up. I have loose ideas of asymmetric cryptography and trust circles and such, but nothing concrete to hinge my actions upon, so I mostly try different permutations of command line arguments until GPG appears to do what I want it to do. Is there a "from the ground up" good guide to PGP that allows me to break out of this pattern? [1]: https://news.ycombinator.com/item?id=13070261 [2]: https://www.reddit.com/r/GnuPG/comments/5fpfgy/crosspost_from_hn_is_there_a_groundup_explanation/ From lopaki at gmail.com Wed Nov 30 19:57:25 2016 From: lopaki at gmail.com (Scott Lambdin) Date: Wed, 30 Nov 2016 13:57:25 -0500 Subject: =?UTF-8?B?UmU6IElzIHRoZXJlIGEg4oCcZ3JvdW5kLXVw4oCdIGV4cGxhbmF0aW9uIG9mIFBHUC9Hbg==?= =?UTF-8?B?dVBHPw==?= In-Reply-To: <87a8ch2ahd.fsf@vps.i-did-not-set--mail-host-address--so-tickle-me> References: <87a8ch2ahd.fsf@vps.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: Hi - I liked The Code Book, by Simon Singh as a good start. It covers various (very various) code topics but it describes the PGP basics in plain talk. And now I know how an enigma machine works. On Wed, Nov 30, 2016 at 11:33 AM, Chris wrote: > I have asked this on HN[1] as well as Reddit[2] too, but I realised you > people might be a better audience for the question! (...And it gives me > a good excuse to subscribe to my first mailing list!) Question below: > > Understanding how git works internally "from the ground up" has been > incredibly helpful in my everyday work; things like blobs, commit > objects, hashes and how they connect to form the git experience as I > know it. Where I had been cargo-culting along previously, it all became > clear once I understood the fundamental model of what was going on > underneath the interface. > > I feel like the same thing could apply to PGP/GnuPG. I am cargo culting > my way along but I feel like I would feel much, much, much more > comfortable if I knew how it worked from the ground up. > > I have loose ideas of asymmetric cryptography and trust circles and > such, but nothing concrete to hinge my actions upon, so I mostly try > different permutations of command line arguments until GPG appears to do > what I want it to do. > > Is there a "from the ground up" good guide to PGP that allows me to > break out of this pattern? > > [1]: https://news.ycombinator.com/item?id=13070261 > [2]: https://www.reddit.com/r/GnuPG/comments/5fpfgy/ > crosspost_from_hn_is_there_a_groundup_explanation/ > > > _______________________________________________ > 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 rjh at sixdemonbag.org Wed Nov 30 22:04:26 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 30 Nov 2016 16:04:26 -0500 Subject: =?us-ascii?Q?RE:_Is_there_a_=22ground-up=22_explanation_of_PGP/GnuPG=3F?= In-Reply-To: <87a8ch2ahd.fsf@vps.i-did-not-set--mail-host-address--so-tickle-me> References: <87a8ch2ahd.fsf@vps.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: <017301d24b4d$56539950$02facbf0$@sixdemonbag.org> > Is there a "from the ground up" good guide to PGP that allows me to break > out of this pattern? Yes: RFC 4880. It's a highly technical guide to the entire OpenPGP standard. Once you have a basic understanding of what OpenPGP is and what it provides as far as capabilities go, the next step is to learn about packets, identifiers, octets, and more.