From johnk_km at hotmail.com Sat Dec 1 23:33:35 2018 From: johnk_km at hotmail.com (John Broyles) Date: Sat, 1 Dec 2018 22:33:35 +0000 Subject: How to start gnupg? Message-ID: I just installed gnupg software from source. There were no complaints that I could see. In fact when I typed sudo apt install gnupg, the response was that the current version was the latest. So, I assume that that means that the program is installed. However, how do I start and use the program? I have a large file that was encrypted with PGP and I want to decrypt it. Am I missing something simple? I am using Ubuntu 16.04 operating system. I can not find this program in the installed program list. Thanks, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.claas at posteo.de Sun Dec 2 13:37:36 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 2 Dec 2018 13:37:36 +0100 Subject: How to start gnupg? In-Reply-To: References: Message-ID: <20181202133736.475094fb@iria.my-fqdn.de> On Sat, 1 Dec 2018 22:33:35 +0000, John Broyles wrote: > I just installed gnupg software from source. There were no > complaints that I could see. In fact when I typed sudo apt install > gnupg, the response was that the current version was the latest. So, > I assume that that means that the program is installed. However, how > do I start and use the program? I have a large file that was > encrypted with PGP and I want to decrypt it. Am I missing something > simple? I am using Ubuntu 16.04 operating system. I can not find > this program in the installed program list. Hi John, try the command "which gpg" or "locate gpg". This tells you where it is installed. In order to use GnuPG simply run "gpg --help". If you need more infos check the man pages or the net for tutorials. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From fa-ml at ariis.it Sun Dec 2 15:53:20 2018 From: fa-ml at ariis.it (Francesco Ariis) Date: Sun, 2 Dec 2018 15:53:20 +0100 Subject: How to start gnupg? In-Reply-To: References: Message-ID: <20181202145320.ylc2hqusqchvvu2u@x60s.casa> Hello John, On Sat, Dec 01, 2018 at 10:33:35PM +0000, John Broyles wrote: > I have a large file that was encrypted with PGP and I want to decrypt it. Was encrypted by whom? Usually gpg tutorials start from creating your own key (which you and your friends can use to encrypt files to you), but apparently you have already created it. Or is it (if you know) a file encrypted with a simple passphrase (symmetric encryption)? -F From mirimir at riseup.net Tue Dec 4 02:47:43 2018 From: mirimir at riseup.net (Mirimir) Date: Mon, 3 Dec 2018 18:47:43 -0700 Subject: How to start gnupg? In-Reply-To: References: Message-ID: <0ecfaf6e-5ccf-f6e8-816f-5a8b7bd096f1@riseup.net> On 12/01/2018 03:33 PM, John Broyles wrote: > I just installed gnupg software from source. There were no complaints that I could see. In fact when I typed sudo apt install gnupg, the response was that the current version was the latest. So, I assume that that means that the program is installed. However, how do I start and use the program? I have a large file that was encrypted with PGP and I want to decrypt it. Am I missing something simple? I am using Ubuntu 16.04 operating system. I can not find this program in the installed program list. > > Thanks, > John It's not a GUI. If you want one, try GNU Privacy Assistant. From kynnjo at gmail.com Tue Dec 4 13:55:56 2018 From: kynnjo at gmail.com (Kynn Jones) Date: Tue, 4 Dec 2018 07:55:56 -0500 Subject: Book on gnupg? Message-ID: Hi everyone, I need to write a program that uses gnupg (possibly through gpgme), but I'm having a hard time understanding the documentation for this software. I took something like "cryptography 101" in college, way back when, but the stuff I read on gnupg/gpgme is filled with concepts that either I've never heard of before (e.g. "armor"), or I'm fuzzy on (e.g. "signature"). A further impediment I'm finding is that most of the information I find on gnupg is aimed for end-users. I have found relatively little aimed at software developers who want to use gnupg in their programs. Where can I find a high-level description of gnupg, if possible addressed to developers? (Also, if possible, I would prefer a book, or a chapter in a book.) Thanks in advance! kj -------------- next part -------------- An HTML attachment was scrubbed... URL: From justina at colmena.biz Tue Dec 4 20:58:41 2018 From: justina at colmena.biz (justina colmena) Date: Tue, 04 Dec 2018 10:58:41 -0900 Subject: GnuPG on Android In-Reply-To: <207F0CB8-47CA-4AF0-BBD9-BF54CC7AD2AB@colmena.biz> References: <207F0CB8-47CA-4AF0-BBD9-BF54CC7AD2AB@colmena.biz> Message-ID: <45E60C33-BD0E-46C3-9908-50CB1D484AE4@colmena.biz> Sorry. Missing signature. Hit send too soon. -------- Original Message -------- From: justina colmena Sent: December 4, 2018 10:56:27 AM AKST To: gnupg-users at gnupg.org Subject: GnuPG on Android Hello GnuPG users! This is somewhat related to a discussion from last month. https://lists.gnupg.org/pipermail/gnupg-users/2018-November/061122.html To answer the question about GnuPG on Android, the most useful application I have found so far is called OpenKeychain. https://www.openkeychain.org The K-9 Mail client, which I am using now, and a password store utility both make good use of OpenKeychain on Android. https://k9mail.github.io https://github.com/zeapo/Android-Password-Store I was able to create a key (see URL at the bottom of this email signature for public key), back it up, import it into GnuPG 1.4.23 and use it successfully, but I am unable to use the private key in GnuPG 2.2.9, because I cannot verify the pass phrase for the private key on gpg2 no matter what I do. I have signed this email with the key in question, for reference. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From justina at colmena.biz Tue Dec 4 20:56:27 2018 From: justina at colmena.biz (justina colmena) Date: Tue, 04 Dec 2018 10:56:27 -0900 Subject: GnuPG on Android Message-ID: <207F0CB8-47CA-4AF0-BBD9-BF54CC7AD2AB@colmena.biz> Hello GnuPG users! This is somewhat related to a discussion from last month. https://lists.gnupg.org/pipermail/gnupg-users/2018-November/061122.html To answer the question about GnuPG on Android, the most useful application I have found so far is called OpenKeychain. https://www.openkeychain.org The K-9 Mail client, which I am using now, and a password store utility both make good use of OpenKeychain on Android. https://k9mail.github.io https://github.com/zeapo/Android-Password-Store I was able to create a key (see URL at the bottom of this email signature for public key), back it up, import it into GnuPG 1.4.23 and use it successfully, but I am unable to use the private key in GnuPG 2.2.9, because I cannot verify the pass phrase for the private key on gpg2 no matter what I do. I have signed this email with the key in question, for reference. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: From angel at pgp.16bits.net Tue Dec 4 23:12:39 2018 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Tue, 04 Dec 2018 23:12:39 +0100 Subject: How to start gnupg? In-Reply-To: References: Message-ID: <1543961559.973.26.camel@16bits.net> On 2018-12-01 at 22:33 +0000, John Broyles wrote: > I just installed gnupg software from source. (...) I typed sudo apt > install gnupg When you say that you are installing a software from source, it usually means that you downloaded the source code (usually a tgz) and compiled it yourself. As you then mention that what you did was a sudo apt install gnupg, you were installing gnupg from Ubuntu 16.04 package manager. > when I typed sudo apt install gnupg, the response was that the current > version was the latest. So, I assume that that means that the program > is installed. Yes. That means that you (already) have installed the latest version of gnupg package that is packaged in Ubuntu 16.04 > However, how do I start and use the program? I have a large file that > was encrypted with PGP and I want to decrypt it. Am I missing > something simple? I am using Ubuntu 16.04 operating system. I can > not find this program in the installed program list. If you want a visual program to use for this, I would recommend you to install kleopatra If you are fine using the command line, run in a terminal gpg --decrypt-files Note that if it was encrypted to your public key, you would need to first import it with gpg --import, otherwise the above command will complain it doesn't have the needed key (the error message should point you in the right direction, though). The requirement to have is Graphical frontends like kleopatra will also allow you to decrypt files (File -> Decrypt/Verify files), but nevertheless you will need to have your key imported in order to do that (it allows you to do that graphically, though). Best regards From cod at cod-web.net Wed Dec 5 10:31:26 2018 From: cod at cod-web.net (Claudio Canavese) Date: Wed, 05 Dec 2018 10:31:26 +0100 Subject: Garbled data in keyservers Message-ID: <1544002286.1805.5.camel@cod-web.net> Hi everyone, I'm experiencing a strange behavior when looking for my email address on many keyserver web interfaces: I get al lot of garbled output from a key of someone else. I can't find and answer in this mailing list archives, so I decided to ask directly. Forgive me if it's a silly question. How to test this: 1) pick any keyserver, I tried https://pgp.mit.edu/ , https://keyserver.ubuntu.com/ , http://pool.sks-keyservers.net 2) search any key but mine by email: works? Well, so it was for me 3) now try with this email address On pool.sks-keyservers.net eveything works well while on other keyservers I get 47Mb of garbled data from Yegor Timoshenko key, which I never signed and I don't know exactly why it's included in search results. I had to use wget to download the web page since any browser will crash. Is this a bug I should submit somewhere? Can a key break the html output of a keyserver? Thanks you for your time ;-) -- CoD From wiktor at metacode.biz Wed Dec 5 12:23:52 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 5 Dec 2018 12:23:52 +0100 Subject: Garbled data in keyservers In-Reply-To: <1544002286.1805.5.camel@cod-web.net> References: <1544002286.1805.5.camel@cod-web.net> Message-ID: <0325426b-c73b-0fdc-ba32-142d4b2c151d@metacode.biz> Hi Claudio, You may find these SKS issues relevant: https://bitbucket.org/skskeyserver/sks-keyserver/issues/41 https://bitbucket.org/skskeyserver/sks-keyserver/issues/57 https://bitbucket.org/skskeyserver/sks-keyserver/issues/60 I'm not able to comment on the specifics of search implementation in SKS though... Kind regards, Wiktor On 05.12.2018 10:31, Claudio Canavese wrote: > Hi everyone, > I'm experiencing a strange behavior when looking for my email address on > many keyserver web interfaces: I get al lot of garbled output from a key > of someone else. > > I can't find and answer in this mailing list archives, so I decided to > ask directly. Forgive me if it's a silly question. > > How to test this: > 1) pick any keyserver, I tried https://pgp.mit.edu/ , > https://keyserver.ubuntu.com/ , http://pool.sks-keyservers.net > 2) search any key but mine by email: works? Well, so it was for me > 3) now try with this email address > > On pool.sks-keyservers.net eveything works well while on other > keyservers I get 47Mb of garbled data from Yegor Timoshenko key, which I > never signed and I don't know exactly why it's included in search > results. I had to use wget to download the web page since any browser > will crash. > > Is this a bug I should submit somewhere? > Can a key break the html output of a keyserver? > > > Thanks you for your time ;-) > > > -- > CoD > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- https://metacode.biz/@wiktor From cod at cod-web.net Wed Dec 5 12:36:54 2018 From: cod at cod-web.net (Claudio Canavese) Date: Wed, 05 Dec 2018 12:36:54 +0100 Subject: Garbled data in keyservers In-Reply-To: <0325426b-c73b-0fdc-ba32-142d4b2c151d@metacode.biz> References: <1544002286.1805.5.camel@cod-web.net> <0325426b-c73b-0fdc-ba32-142d4b2c151d@metacode.biz> Message-ID: <1544009814.2021.3.camel@cod-web.net> Thank you. Fun fact: https://bitbucket.org/skskeyserver/sks-keyserver/issues/57 > https://bitbucket.org/skskeyserver/sks-keyserver/issues/60 > were opened by Yegor Timoshenko himself ^__^ Thank you again for your quick and sharp answer! -- CoD From wk at gnupg.org Wed Dec 5 13:28:50 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Dec 2018 13:28:50 +0100 Subject: Garbled data in keyservers In-Reply-To: <1544002286.1805.5.camel@cod-web.net> (Claudio Canavese's message of "Wed, 05 Dec 2018 10:31:26 +0100") References: <1544002286.1805.5.camel@cod-web.net> Message-ID: <87o9a0cg3h.fsf@wheatstone.g10code.de> On Wed, 5 Dec 2018 10:31, cod at cod-web.net said: > On pool.sks-keyservers.net eveything works well while on other > keyservers I get 47Mb of garbled data from Yegor Timoshenko key, which I > never signed and I don't know exactly why it's included in search There are several problem with the keyservers due to their policy of being a plain data store. Actually this policy is a Good Thing because it allows to sync with other servers and their is no need for a central authority. The problem is that the keyservers are abused as data store and, worse, as a public search engine for such data. The latter point can be mitigated by not having a web interface which displays everything. Restricting user-ids and such does not help because there are other ways to store arbitrary data in a OpenPGP keyblock. Even keyservers which would checking the signatures won't help because key signatures can be made using an arbitrary amount of new keys. A better way of using keyservers would be to entire disable their search by name or mail address capabilities. Not only in the web interface but also in their API. Of course that will be a radical change but I consider it better for security: Too many users assume that the keyservers return a correct key; which they don't. In fact their is no way to get a key for a given mail address from a web server. It used to work just out of luck and because all keyserver users used to be fair netizens. The keyserver would then be used for getting the keys to verify a signature (because the lookup is by fingerprint) and to distribute revocations. That is still a useful thing to have. Further the keyservers should stop to accept key signature; for Web of Trust things signed keys should be mailed directly instead (caff already does that). FWIW, I have the problem of a garbled key for quite some time which I can fix for me using things like import-filter drop-sig= sig_created_d=2015-12-24 import-filter drop-sig=|| sig_created_d=2016-03-16 in my gpg.conf. But that is just a stopgap. 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: 227 bytes Desc: not available URL: From stefan.claas at posteo.de Wed Dec 5 17:34:18 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 5 Dec 2018 17:34:18 +0100 Subject: Garbled data in keyservers In-Reply-To: <87o9a0cg3h.fsf@wheatstone.g10code.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> Message-ID: <20181205173418.2ccfa1d7@iria.my-fqdn.de> On Wed, 05 Dec 2018 13:28:50 +0100, Werner Koch wrote: > A better way of using keyservers would be to entire disable their > search by name or mail address capabilities. Not only in the web > interface but also in their API. Of course that will be a radical > change but I consider it better for security: Can you give more details about the security aspect? Currently users can still search sks key servers by names, with Lynx... :-) As understood key server operators can still give a whole dump to 3rd parties, which like to analyze the data, or third parties run their own key server and analyze the data. So what purpose should your suggestion serve? If you are talking about GDPR issues, those keys server operators are not "licensed" by governmental institutions and run their servers according to some strict regulations. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From wk at gnupg.org Wed Dec 5 18:53:20 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Dec 2018 18:53:20 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181205173418.2ccfa1d7@iria.my-fqdn.de> (Stefan Claas's message of "Wed, 5 Dec 2018 17:34:18 +0100") References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> Message-ID: <8736rbdfn3.fsf@wheatstone.g10code.de> On Wed, 5 Dec 2018 17:34, stefan.claas at posteo.de said: > Can you give more details about the security aspect? People believe that the keyservers magically return a matching key for a mail address. There is no guarantee for this. In fact all people from the strong had meanwhile expired faked key on the servers, which was not easy to detect given that they were also signed by faked keys from the strong set. Thus if you have the capability to sniff mail you would upload a faked key and hope that future senders pick up that faked key and encrypt to it. You can now intercept that mail, read it, encrypt to the real key and send on. Even if you can't mount such an active MitM you can simply send on the newly encrypted mail with an additional line "sorry, I encrypted to the wrong key". Right the Web of Trust would stop this attack, but most people are not part of the WoT. Simple methods for initial /key discovery/ are required. Even autocrypt is better than keyservers and with the Web Key Directory you can get an even better assurance that it is the correct key. > run their own key server and analyze the data. So what purpose should > your suggestion serve? The additional benefit is that this would take away the load from the servers and allow that we can get back the large mesh of keyservers. Without being able to search user-ids it does not anymore make sense to use keyservers as search engines for magnet links to Bittorrent distributed data. 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: 227 bytes Desc: not available URL: From stefan.claas at posteo.de Wed Dec 5 19:56:13 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 5 Dec 2018 19:56:13 +0100 Subject: Garbled data in keyservers In-Reply-To: <8736rbdfn3.fsf@wheatstone.g10code.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> Message-ID: <20181205195613.4d371878@iria.my-fqdn.de> On Wed, 05 Dec 2018 18:53:20 +0100, Werner Koch wrote: > On Wed, 5 Dec 2018 17:34, stefan.claas at posteo.de said: > > > Can you give more details about the security aspect? > > People believe that the keyservers magically return a matching key > for a mail address. There is no guarantee for this. In fact all > people from the strong had meanwhile expired faked key on the > servers, which was not easy to detect given that they were also > signed by faked keys from the strong set. > > Thus if you have the capability to sniff mail you would upload a faked > key and hope that future senders pick up that faked key and encrypt to > it. You can now intercept that mail, read it, encrypt to the real key > and send on. Even if you can't mount such an active MitM you can > simply send on the newly encrypted mail with an additional line > "sorry, I encrypted to the wrong key". > > Right the Web of Trust would stop this attack, but most people are not > part of the WoT. Simple methods for initial /key discovery/ are > required. Even autocrypt is better than keyservers and with the Web > Key Directory you can get an even better assurance that it is the > correct key. Agreed. > > run their own key server and analyze the data. So what purpose > > should your suggestion serve? > > The additional benefit is that this would take away the load from the > servers and allow that we can get back the large mesh of keyservers. > Without being able to search user-ids it does not anymore make sense > to use keyservers as search engines for magnet links to Bittorrent > distributed data. Well, my understanding would be that a least one (search) criteria would be needed to fetch a key, right? And if so i could also imagine that this one criteria could be abused as well, in form of a given link to that resource, as long as it can be fetched via the web. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From justina at colmena.biz Wed Dec 5 21:24:10 2018 From: justina at colmena.biz (justina colmena) Date: Wed, 05 Dec 2018 11:24:10 -0900 Subject: Garbled data in keyservers In-Reply-To: <8736rbdfn3.fsf@wheatstone.g10code.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> Message-ID: A keyserver is a convenience. Of course it's not magic. Right now I am using K-9 Mail and OpenKeychain on Android. When I received the above message from the list, K-9 Mail informed me that it was signed with a key with fingerprint "0xff80ae9d1dec358d", and referred me to the OpenKeychain app, which searched keyservers and found a matching public key, which I was allowed to import to verify the signature, which I did so successfully. The fingerprints are some collision-resistant secure hashes, and in theory it is extraordinarily difficult to create another public key with the same fingerprint. I have never met "Werner Koch" personally, but I am about as certain as I can be (under the present scheme of things) that that is the key fingerprint of the person from GnuPG.org who posts to the mailing list, and that there would be quite a bit of noise on the list in case of a mistaken identity. There is a certain "reputation effect" with a public key which in theory obviates the need for in-person verification and secret handshakes. The major difficulties and points of weakness to the whole scheme, in my opinion, are, (a) retaining possession of the private key, and (b) denying others illicit access to the private key. Point (b) is a long-term, seemingly irremediable, problem. The long key lifetimes and the general lack of *Perfect Forward Secrecy* greatly aggravate the risk of a catastrophic total compromise of all data signed with or encrypted to the private key. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From stefan.claas at posteo.de Wed Dec 5 21:41:51 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 5 Dec 2018 21:41:51 +0100 Subject: Garbled data in keyservers In-Reply-To: References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> Message-ID: <20181205214151.2ae157b2@iria.my-fqdn.de> On Wed, 05 Dec 2018 11:24:10 -0900, justina colmena via Gnupg-users wrote: > A keyserver is a convenience. Of course it's not magic. Right now I > am using K-9 Mail and OpenKeychain on Android. When I received the > above message from the list, K-9 Mail informed me that it was signed > with a key with fingerprint "0xff80ae9d1dec358d", and referred me to > the OpenKeychain app, which searched keyservers and found a matching > public key, which I was allowed to import to verify the signature, > which I did so successfully. Sure, thats the way it works. If Werner and you for example had an implementation of Autocrypt installed then you would not need a key server. ;-) But what we are pointing out here are the problems the current key server network has, or might face in the future. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From wk at gnupg.org Thu Dec 6 09:03:32 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Dec 2018 09:03:32 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181205195613.4d371878@iria.my-fqdn.de> (Stefan Claas's message of "Wed, 5 Dec 2018 19:56:13 +0100") References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> Message-ID: <87d0qfaxpn.fsf@wheatstone.g10code.de> On Wed, 5 Dec 2018 19:56, stefan.claas at posteo.de said: > Well, my understanding would be that a least one (search) criteria > would be needed to fetch a key, right? And if so i could also imagine Right, the fingerprint. And maybe the long keyid for a transitional period because not all software already includes the fingerprint in the signature. > that this one criteria could be abused as well, in form of a given > link to that resource, as long as it can be fetched via the web. Being able to search for a fingerprint does not allow you to search for the latest blockbuster movie to get a torrent link. Thus there is no incentive to use the keyservers as an index and running a keyserver will be safer for most operators. 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: 227 bytes Desc: not available URL: From stefan.claas at posteo.de Thu Dec 6 10:24:59 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 6 Dec 2018 10:24:59 +0100 Subject: Garbled data in keyservers In-Reply-To: <87d0qfaxpn.fsf@wheatstone.g10code.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> Message-ID: <20181206102459.6261e216@iria.my-fqdn.de> On Thu, 06 Dec 2018 09:03:32 +0100, Werner Koch wrote: > On Wed, 5 Dec 2018 19:56, stefan.claas at posteo.de said: > > > Well, my understanding would be that a least one (search) criteria > > would be needed to fetch a key, right? And if so i could also > > imagine > > Right, the fingerprint. And maybe the long keyid for a transitional > period because not all software already includes the fingerprint in > the signature. O.k. > > that this one criteria could be abused as well, in form of a given > > link to that resource, as long as it can be fetched via the web. > > Being able to search for a fingerprint does not allow you to search > for the latest blockbuster movie to get a torrent link. Thus there > is no incentive to use the keyservers as an index and running a > keyserver will be safer for most operators. Well, i am not familiar how the current warez etc. scene works, but my assumption was the following (o.k. i am no programmer...): As long as we have the option to add additional UID's to a key my thinking was, after reading the links from Yegor, that one appends arbitrary data to a key and provides a link, at some other place, to that key, in the form of URL://keyserver/keyid_or_fp. People then would only need a little program to dearmor and extract the data from that key UID's. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From wiktor at metacode.biz Thu Dec 6 10:39:24 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Thu, 6 Dec 2018 10:39:24 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181206102459.6261e216@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102459.6261e216@iria.my-fqdn.de> Message-ID: <65382121-039d-af2e-baff-cb0fdfa34a79@metacode.biz> On 06.12.2018 10:24, Stefan Claas wrote: > As long as we have the option to add additional UID's to a key my > thinking was, after reading the links from Yegor, that one appends > arbitrary data to a key and provides a link, at some other place, to > that key, in the form of URL://keyserver/keyid_or_fp. > > People then would only need a little program to dearmor and > extract the data from that key UID's. But that "little program" would have to download the entire dump and provide search feature itself, making it non-trivial for most users. Sometimes raising a bar a little would solve most of the problem. (And then there are talks about removing UIDs from key servers, but that's a different matter). Kind regards, Wiktor -- https://metacode.biz/@wiktor From stefan.claas at posteo.de Thu Dec 6 10:58:48 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 6 Dec 2018 10:58:48 +0100 Subject: Garbled data in keyservers In-Reply-To: <65382121-039d-af2e-baff-cb0fdfa34a79@metacode.biz> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102459.6261e216@iria.my-fqdn.de> <65382121-039d-af2e-baff-cb0fdfa34a79@metacode.biz> Message-ID: <20181206105848.3d55a1d1@iria.my-fqdn.de> On Thu, 6 Dec 2018 10:39:24 +0100, Wiktor Kwapisiewicz wrote: Hi Wiktor, > On 06.12.2018 10:24, Stefan Claas wrote: > > As long as we have the option to add additional UID's to a key my > > thinking was, after reading the links from Yegor, that one appends > > arbitrary data to a key and provides a link, at some other place, to > > that key, in the form of URL://keyserver/keyid_or_fp. > > > > People then would only need a little program to dearmor and > > extract the data from that key UID's. > > But that "little program" would have to download the entire dump and > provide search feature itself, making it non-trivial for most users. I don't think so... https://github.com/yakamok/keyserver-fs Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From wiktor at metacode.biz Thu Dec 6 11:09:04 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Thu, 6 Dec 2018 11:09:04 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181206105848.3d55a1d1@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102459.6261e216@iria.my-fqdn.de> <65382121-039d-af2e-baff-cb0fdfa34a79@metacode.biz> <20181206105848.3d55a1d1@iria.my-fqdn.de> Message-ID: <18c8277a-808c-5fd6-bb57-08095fdc8315@metacode.biz> >> But that "little program" would have to download the entire dump and >> provide search feature itself, making it non-trivial for most users. > I don't think so... > > https://github.com/yakamok/keyserver-fs Yes: > WARNING: this may break easily and is intended for use only on linux > *Notice:* This Program is very slow to add data to the gpg pubkey so dont plan on super large files. I don't think a lot of users use this or would use this. It's more convenient and easier to store data somewhere else (pastebins?). Also, storing blobs is not a unique problem of keyservers, one can store it in Certificate Transparency logs by issuing certs from Let's Encrypt or in Bitcoin blockchain or even X.509 timestamping services. It would be slow and inefficient, that's why practically no-one misuses it. Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.claas at posteo.de Thu Dec 6 11:27:18 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 6 Dec 2018 11:27:18 +0100 Subject: Garbled data in keyservers In-Reply-To: <18c8277a-808c-5fd6-bb57-08095fdc8315@metacode.biz> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102459.6261e216@iria.my-fqdn.de> <65382121-039d-af2e-baff-cb0fdfa34a79@metacode.biz> <20181206105848.3d55a1d1@iria.my-fqdn.de> <18c8277a-808c-5fd6-bb57-08095fdc8315@metacode.biz> Message-ID: <20181206112718.010e0b64@iria.my-fqdn.de> On Thu, 6 Dec 2018 11:09:04 +0100, Wiktor Kwapisiewicz wrote: > >> But that "little program" would have to download the entire dump > >> and provide search feature itself, making it non-trivial for most > >> users. > > I don't think so... > > > > https://github.com/yakamok/keyserver-fs > > Yes: > > > WARNING: this may break easily and is intended for use only on > > linux > > > *Notice:* This Program is very slow to add data to the gpg pubkey > > so dont plan > on super large files. > > I don't think a lot of users use this or would use this. It's more > convenient and easier to store data somewhere else (pastebins?). At least the cat is out of the bag and i could imagine if only one person would misuse this technique operators could face problems in the future. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From stefan.claas at posteo.de Thu Dec 6 14:05:37 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 6 Dec 2018 14:05:37 +0100 Subject: Garbled data in keyservers In-Reply-To: <87y3939bs7.fsf@wheatstone.g10code.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> Message-ID: <20181206140537.7288e687@iria.my-fqdn.de> On Thu, 06 Dec 2018 11:42:32 +0100, Werner Koch wrote: > On Thu, 6 Dec 2018 10:22, stefan.claas at posteo.de said: > > > As long as we have the option to add additional UID's to a key my > > You can't add an UID to a key without having a signature from the > primary key. If the keyservers accept that any OpenPGP implementation > will simply skip such an UID. Understood. Please check this example, a key with with plenty of data, which only needs to be extracted. https://pgp.circl.lu/pks/lookup?op=get&search=0x73253A1F090C53B6 > > People then would only need a little program to dearmor and > > extract the data from that key UID's. > > But they can't search for it on public servers. Thus there is no gain > here. If you require a dedicated program anyway, that program can > anyway consult one of the Tor hidden servers. But no search engine > will show it. That's right, but my thought is / was someone can (ab)use key servers as data storage / retrieval system and then only provides the key id in a link. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From stefan.claas at posteo.de Thu Dec 6 14:36:50 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 6 Dec 2018 14:36:50 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181206140537.7288e687@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> Message-ID: <20181206143650.0b066987@iria.my-fqdn.de> On Thu, 6 Dec 2018 14:05:37 +0100, Stefan Claas wrote: > On Thu, 06 Dec 2018 11:42:32 +0100, Werner Koch wrote: > > On Thu, 6 Dec 2018 10:22, stefan.claas at posteo.de said: > > > > > As long as we have the option to add additional UID's to a key > > > my > > > > You can't add an UID to a key without having a signature from the > > primary key. If the keyservers accept that any OpenPGP > > implementation will simply skip such an UID. > > Understood. Please check this example, a key with with plenty of data, > which only needs to be extracted. > > https://pgp.circl.lu/pks/lookup?op=get&search=0x73253A1F090C53B6 O.k. curious how i am, i extracted the data and it shows an image of Kristian, size 1178x1439 pixels, 96 dpi.. :-D Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From wk at gnupg.org Thu Dec 6 15:22:14 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Dec 2018 15:22:14 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181206140537.7288e687@iria.my-fqdn.de> (Stefan Claas's message of "Thu, 6 Dec 2018 14:05:37 +0100") References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> Message-ID: <87va4691m1.fsf@wheatstone.g10code.de> On Thu, 6 Dec 2018 14:05, stefan.claas at posteo.de said: > Understood. Please check this example, a key with with plenty of data, > which only needs to be extracted. > > https://pgp.circl.lu/pks/lookup?op=get&search=0x73253A1F090C53B6 Surely you can put arbitrary data into into a user-id. > That's right, but my thought is / was someone can (ab)use key servers > as data storage / retrieval system and then only provides the key id As it has been commeted, there are easier ways to do that. 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: 227 bytes Desc: not available URL: From dirk.gottschalk1980 at googlemail.com Fri Dec 7 00:26:02 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Fri, 07 Dec 2018 00:26:02 +0100 Subject: Error after secret key list. In-Reply-To: <87in0n37sf.fsf@wheatstone.g10code.de> References: <87zhtz3iom.fsf@wheatstone.g10code.de> <98e6ddf0ab5497f9de9fd8320e556c034bcbc81d.camel@googlemail.com> <87in0n37sf.fsf@wheatstone.g10code.de> Message-ID: <120f7593834758b8b5894d9f09777b22f66f283a.camel@googlemail.com> Hi. Am Freitag, den 23.11.2018, 20:36 +0100 schrieb Werner Koch: > On Fri, 23 Nov 2018 18:56, dirk.gottschalk1980 at googlemail.com said: > > > I saw the Listing in the debugging log. I tried this also. > > gpg -k does not show this message, but two messages regarding two > > keys, > > Hmmm, not easy to debug by mail. > > > gpg: bad data signature from key 2894CD20EE47166D: Wrong key usage > > (0x19, 0x2) > > That is bug we introduced in 2.2.10 or so which was fixed in > 2.2.11. It > is just wrong diagnostic. > > > Could this be the reason for this error message? > > No. Thanks to all for your help. Just to update you: I solved the problem by exporting the public keyring into a file, deleting pubring.kbx and re-importing the entire keyring. Not to mention that the problem fixed itself automagically. GnuPG reported one key less as imported than the keyring contained and the "dead bird" has been gone. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From janek99 at interiowy.pl Fri Dec 7 13:04:06 2018 From: janek99 at interiowy.pl (Jan Kamracki) Date: Fri, 07 Dec 2018 13:04:06 +0100 Subject: a minimal version of PGP/GPG for the Win32/64 bits for command line Message-ID: Hello!I need a GPG/PGP version running from the command line for Win32/64 bits.Something like PGP5i.I wanted to generate a pair of keys and send someone a gpg.exe/pgp.exe + public key, so that he could encrypt a file without any installation PGP/GPG and send it to me.What do you propose?RegardsJanek -------------- next part -------------- An HTML attachment was scrubbed... URL: From angel at pgp.16bits.net Fri Dec 7 17:05:43 2018 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 07 Dec 2018 17:05:43 +0100 Subject: a minimal version of PGP/GPG for the Win32/64 bits for command line In-Reply-To: References: Message-ID: <1544198743.966.27.camel@16bits.net> On 2018-12-07 at 13:04 +0100, Jan Kamracki wrote: > Hello! > > > I need a GPG/PGP version running from the command line for Win32/64 > bits. > Something like PGP5i. > I wanted to generate a pair of keys and send someone a gpg.exe/pgp.exe > + public key, so that he could encrypt a file without any installation > PGP/GPG and send it to me. > What do you propose? > Point them to https://www.gpg4win.org/ I think you could extract the command line binaries and run them as portable apps, but actually, I think it would be easier for them to run the installer and have a nice GUI app rather than a cli app. Not to mention that, if you expected to send them gpg.exe by email so that they could reply with an encrypted mail, (a) you are setting a very bad precedent expecting them to run an arbitrary executable they received from an untrusted medium and (b) the mail server would most likely block your message anyway. Best regards From justina at colmena.biz Fri Dec 7 17:28:19 2018 From: justina at colmena.biz (justina colmena) Date: Fri, 07 Dec 2018 07:28:19 -0900 Subject: gpg2: unable to use secret key from OpenKeychain Message-ID: Subject: secret key data (test key) Date: 2018-12-07 This attachment is an encrypted backup I made from the OpenKeychain app of a test key I made for the purpose. The passphrase for this one is 5101-2272-0596-2716-2013-3210-0535-7592-9890 but it looks like the whole thing is encrypted by symmetric-key (AES-256) cipher because it is not encrypted to any particular public key, and furthermore, once decrypted and imported, the secret key is no longer protected by a passphrase, until I explicitly create one for it with "gpg --edit-key". For some odd reason I am unable to use the secret key in gpg2 (~2.2.11), even though I can still encrypt to the imported key or verify signatures with it in gpg2. There does not seem to be any problem with using the secret key in "gpg" = GnuPG 1.4.23. $ gpg --decrypt backup_2018-12-07.sec.pgp | gpg --import gpg: unknown armor header: Passphrase-Format: numeric9x4 gpg: unknown armor header: Passphrase-Begin: 51 gpg: AES256 encrypted data gpg: encrypted with 1 passphrase gpg: key CAC8E3E7: public key "Test Key 1 " imported gpg: key CAC8E3E7: secret key imported gpg: key CAC8E3E7: "Test Key 1 " not changed gpg: Total number processed: 2 gpg: imported: 1 (RSA: 1) gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ -----BEGIN PGP PUBLIC KEY BLOCK----- mQGNBFwKeG8BDAClaZu5lcIM12biCt7tyoddrwFl/UwERhfVMqZccMXrF+puP+0I FsVvV/EqI+tOhYLepOmCj9KfGQ0KFi/UtElbMZma7WFuDu/mVh+Hrl2wVbqSjR8u coHKJ4Wr2ocROWmxFxdMy2acIhGKpmbvXXFsFrsTiJxM/C4YTGmktAI20qxk8QX1 +006xPEUUL8vFc/CppekpgQzff3505iPJ0fvYK+Q2D9NUCvCy4vFWR1jTu8MK1pp 0ftp9IR/WUVQwdA7GE6z6VlCEMtJsYxkCco3FgfuYr0hiSDSLZ75e7FuRGVwrrWp GswqH9a8TIJHVfKSJ4hukmGt02UMR/L03nRCgaLyIrI6GxMzbI59di/jKmH0F6py gP7s17DI2FlXrL/Cby8KJosMnRqeFOBFySbGxJVIZEb2vGXHpCI/Zy1rEu4mLel1 7eKdZauucwAnoomIh5WQzw+lMVGbS1RteL4nwmKdCRGZ4hWj8nToIYzyK5ekB2dk x2VX71ywh5hNo7MAEQEAAbQjVGVzdCBLZXkgMSA8dGVzdC1rZXktMUBleGFtcGxl LmNvbT6JAbAEEwEKABoECwkIBwIVCgIWAQIZAQWCXAp4bwKeAQKbAwAKCRAbJcGU ysjj5/q+C/9jpyCYgqvlgY37g6uMdumjeMlQPJQ/xNH4De0GGuMESby4HEUs67oP qEP2kImWBp4fhL4zqjyYRb4U6NH6H+u8eWhUpLU7W98/6xv5qRruOl4lhnnDzM10 g2q5Ew+xwbM0MwS3zeE8lEPmTh0LPVRGwHuhiUY1pFuePOBGvI8BQRni+dMz78Hz 5kU+Fz0uD2b9ZoG9j1VV26/EjbM3EZVG8hRpKEnitlflbSG8454kLwx0KnG62/il ONWl6wkR0llAhuVWywB26jYhC561tKROMWz/BaSeJoEUyprAvNsFirojwDnT63vt IhMOqnMB3Vzk2d8CtNHChPYkRO7RjYwX4Z/1hzS6iM9k7RbjaTsrDkIbSiXYYhFy 63kIIu0Q7m5EJnOxEgUEJqPMJv6hlnHRM5q5vMlksLKFOoldOKxKOJXhcvXE3aYz gWve/l127jdDrjny6AyS7d6wD7eLaWs/pm/mWywtc1JBFU4mC/NtfRhI+4q8QAFd Sv64hbrD8va5AY0EXAp4bwEMAL4k6ahXxvGwQ+dQf8qPjxBn5DCuDuA013+vds36 GDhsoJk4N9xiYaY9PjgnBpvPnwp+Moa6ahNJqw+qm+Wb++1pcNz5iTKs0YOtZ6Q8 9DlD9CgTTOYNnmdZvd6WpRAaiSaxgmx6bTZklL5x6icahI5vna7F8tBvr3BuzOBa dHdQD6JuroOkLsF1J39jw1zwdilIwbKLO3tlu51IsCxv682Fi3oe1hyLCXU5Evuy LA8FQXpNQnaDm5XnMQNxQMPoXVwL/cHBszqyKmETm6Q0hJhKDF3GZ8vRPY25xeWv GStZAPo5MWTBP31pwXs27lvFPKlOEadDD7X9n5M5CZ3e2NpdL+2Pwg8HN/edwJQd IeKK1yhNU11PN9s46qUC1vvAqJnr6a2VCSQ9EaleCTDrMoLGFVkHfNLTh9b0gJFo jeZKeqJxwdSmqzzUKWTZmTO0xIEJ3dDs+ZsYnALzkLgpRC9GXNbY5nv3RQagZTDa soIDAO/TAH5r/0DipdfKQ1xKiQARAQABiQGfBBgBCgAJBYJcCnhvApsMAAoJEBsl wZTKyOPnoa4MAJScUzpCjHwAFxhyUTpSTfIoA9Og2wIkMuqfqrzDRr9LnqR0Fao/ 0VjDv0H2kpGNk1B1pr8IFY9UwSBpyk+cvoteFvjeSh1L3JHbKJXQ+22nQNA4ucG1 9Kb4BTak74Q6BPTZ1v735TNNkRCTVP8oC1mSDoDrST5KgRSM3C3LqT+bDcqgjW6M vkRQDr2Tx9aFKuRfU5mQLJdVoEL3c1O7unhmnm8SiWqSQCaztFZ+3DT8tlmTtgXi 6WHNj5R//PsHiKpBKtSijBEI49M/q/yOFD9j/QGxlYAa1xQXnMPuTlVbNG9Mbd5s LHwdk7is1Cxjn5qz7mdk1HK8x1dTVhPjj7caEcOEvFAbbpTpba1tktcjDB6l/zkZ woXm4YgoKcYo08JyW7pMR6P1F5f31DO48Tng8IRh55OaLIW6M+FCEHrZEL/BfMeY dK0sveGAy2sn7V7uWyqeSIRPpg6MZ2UbhU7S1akjYcelucURYnfsx+0kXdLgzEpw ThlRvnZJ/htBWA== =rOgB -----END PGP PUBLIC KEY BLOCK----- -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: backup_2018-12-07.sec.pgp Type: application/pgp-signature Size: 5869 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From justina at colmena.biz Fri Dec 7 19:14:25 2018 From: justina at colmena.biz (justina colmena) Date: Fri, 07 Dec 2018 09:14:25 -0900 Subject: gpg2: unable to use secret key from OpenKeychain In-Reply-To: References: Message-ID: <329FED93-D058-45DB-ACE3-C49912193EE6@colmena.biz> A non-text attachment was scrubbed... Name: not available Type: application/pgp-encrypted Size: 10 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: encrypted.asc Type: application/octet-stream Size: 14544 bytes Desc: not available URL: From justina at colmena.biz Fri Dec 7 19:35:40 2018 From: justina at colmena.biz (justina colmena) Date: Fri, 07 Dec 2018 09:35:40 -0900 Subject: gpg2: unable to use secret key from OpenKeychain In-Reply-To: <329FED93-D058-45DB-ACE3-C49912193EE6@colmena.biz> References: <329FED93-D058-45DB-ACE3-C49912193EE6@colmena.biz> Message-ID: <2B42E759-8A74-4FDF-B7A4-60E247CC6658@colmena.biz> Garbled again! Encrypted by mistake, apparently only to myself. The attachment is the part starting "BEGIN PGP MESSAGE". Copy & paste that part into a text editor and save as backup_2018-12-07.sec.pgp -------- Original Message -------- From: justina colmena via Gnupg-users Sent: December 7, 2018 9:14:25 AM AKST To: gnupg-users at gnupg.org Subject: Re: gpg2: unable to use secret key from OpenKeychain On December 7, 2018 7:28:19 AM AKST, justina colmena via Gnupg-users wrote: >Subject: secret key data (test key) >Date: 2018-12-07 > >This attachment is an encrypted backup I made from the OpenKeychain app >of a test key I made for the purpose. The passphrase for this one is > >5101-2272-0596-2716-2013-3210-0535-7592-9890 > >but it looks like the whole thing is encrypted by symmetric-key >(AES-256) cipher because it is not encrypted to any particular public >key, and furthermore, once decrypted and imported, the secret key is no >longer protected by a passphrase, until I explicitly create one for it >with "gpg --edit-key". > >For some odd reason I am unable to use the secret key in gpg2 >(~2.2.11), even though I can still encrypt to the imported key or >verify signatures with it in gpg2. > >There does not seem to be any problem with using the secret key in >"gpg" = GnuPG 1.4.23. > >$ gpg --decrypt backup_2018-12-07.sec.pgp | gpg --import >gpg: unknown armor header: Passphrase-Format: numeric9x4 >gpg: unknown armor header: Passphrase-Begin: 51 >gpg: AES256 encrypted data >gpg: encrypted with 1 passphrase >gpg: key CAC8E3E7: public key "Test Key 1 " >imported >gpg: key CAC8E3E7: secret key imported >gpg: key CAC8E3E7: "Test Key 1 " not changed >gpg: Total number processed: 2 >gpg: imported: 1 (RSA: 1) >gpg: unchanged: 1 >gpg: secret keys read: 1 >gpg: secret keys imported: 1 >$ > >-----BEGIN PGP PUBLIC KEY BLOCK----- > >mQGNBFwKeG8BDAClaZu5lcIM12biCt7tyoddrwFl/UwERhfVMqZccMXrF+puP+0I >FsVvV/EqI+tOhYLepOmCj9KfGQ0KFi/UtElbMZma7WFuDu/mVh+Hrl2wVbqSjR8u >coHKJ4Wr2ocROWmxFxdMy2acIhGKpmbvXXFsFrsTiJxM/C4YTGmktAI20qxk8QX1 >+006xPEUUL8vFc/CppekpgQzff3505iPJ0fvYK+Q2D9NUCvCy4vFWR1jTu8MK1pp >0ftp9IR/WUVQwdA7GE6z6VlCEMtJsYxkCco3FgfuYr0hiSDSLZ75e7FuRGVwrrWp >GswqH9a8TIJHVfKSJ4hukmGt02UMR/L03nRCgaLyIrI6GxMzbI59di/jKmH0F6py >gP7s17DI2FlXrL/Cby8KJosMnRqeFOBFySbGxJVIZEb2vGXHpCI/Zy1rEu4mLel1 >7eKdZauucwAnoomIh5WQzw+lMVGbS1RteL4nwmKdCRGZ4hWj8nToIYzyK5ekB2dk >x2VX71ywh5hNo7MAEQEAAbQjVGVzdCBLZXkgMSA8dGVzdC1rZXktMUBleGFtcGxl >LmNvbT6JAbAEEwEKABoECwkIBwIVCgIWAQIZAQWCXAp4bwKeAQKbAwAKCRAbJcGU >ysjj5/q+C/9jpyCYgqvlgY37g6uMdumjeMlQPJQ/xNH4De0GGuMESby4HEUs67oP >qEP2kImWBp4fhL4zqjyYRb4U6NH6H+u8eWhUpLU7W98/6xv5qRruOl4lhnnDzM10 >g2q5Ew+xwbM0MwS3zeE8lEPmTh0LPVRGwHuhiUY1pFuePOBGvI8BQRni+dMz78Hz >5kU+Fz0uD2b9ZoG9j1VV26/EjbM3EZVG8hRpKEnitlflbSG8454kLwx0KnG62/il >ONWl6wkR0llAhuVWywB26jYhC561tKROMWz/BaSeJoEUyprAvNsFirojwDnT63vt >IhMOqnMB3Vzk2d8CtNHChPYkRO7RjYwX4Z/1hzS6iM9k7RbjaTsrDkIbSiXYYhFy >63kIIu0Q7m5EJnOxEgUEJqPMJv6hlnHRM5q5vMlksLKFOoldOKxKOJXhcvXE3aYz >gWve/l127jdDrjny6AyS7d6wD7eLaWs/pm/mWywtc1JBFU4mC/NtfRhI+4q8QAFd >Sv64hbrD8va5AY0EXAp4bwEMAL4k6ahXxvGwQ+dQf8qPjxBn5DCuDuA013+vds36 >GDhsoJk4N9xiYaY9PjgnBpvPnwp+Moa6ahNJqw+qm+Wb++1pcNz5iTKs0YOtZ6Q8 >9DlD9CgTTOYNnmdZvd6WpRAaiSaxgmx6bTZklL5x6icahI5vna7F8tBvr3BuzOBa >dHdQD6JuroOkLsF1J39jw1zwdilIwbKLO3tlu51IsCxv682Fi3oe1hyLCXU5Evuy >LA8FQXpNQnaDm5XnMQNxQMPoXVwL/cHBszqyKmETm6Q0hJhKDF3GZ8vRPY25xeWv >GStZAPo5MWTBP31pwXs27lvFPKlOEadDD7X9n5M5CZ3e2NpdL+2Pwg8HN/edwJQd >IeKK1yhNU11PN9s46qUC1vvAqJnr6a2VCSQ9EaleCTDrMoLGFVkHfNLTh9b0gJFo >jeZKeqJxwdSmqzzUKWTZmTO0xIEJ3dDs+ZsYnALzkLgpRC9GXNbY5nv3RQagZTDa >soIDAO/TAH5r/0DipdfKQ1xKiQARAQABiQGfBBgBCgAJBYJcCnhvApsMAAoJEBsl >wZTKyOPnoa4MAJScUzpCjHwAFxhyUTpSTfIoA9Og2wIkMuqfqrzDRr9LnqR0Fao/ >0VjDv0H2kpGNk1B1pr8IFY9UwSBpyk+cvoteFvjeSh1L3JHbKJXQ+22nQNA4ucG1 >9Kb4BTak74Q6BPTZ1v735TNNkRCTVP8oC1mSDoDrST5KgRSM3C3LqT+bDcqgjW6M >vkRQDr2Tx9aFKuRfU5mQLJdVoEL3c1O7unhmnm8SiWqSQCaztFZ+3DT8tlmTtgXi >6WHNj5R//PsHiKpBKtSijBEI49M/q/yOFD9j/QGxlYAa1xQXnMPuTlVbNG9Mbd5s >LHwdk7is1Cxjn5qz7mdk1HK8x1dTVhPjj7caEcOEvFAbbpTpba1tktcjDB6l/zkZ >woXm4YgoKcYo08JyW7pMR6P1F5f31DO48Tng8IRh55OaLIW6M+FCEHrZEL/BfMeY >dK0sveGAy2sn7V7uWyqeSIRPpg6MZ2UbhU7S1akjYcelucURYnfsx+0kXdLgzEpw >ThlRvnZJ/htBWA== >=rOgB >-----END PGP PUBLIC KEY BLOCK----- > >-- >A well regulated Militia, being necessary to the security of a free >State, the right of the people to keep and bear Arms, shall not be >infringed. > >https://www.colmena.biz/~justina/justina.colmena.asc The "PGP MESSAGE" attachment at the bottom of this email looks like it was stripped by the mailing list. I have included it inline below, but now it will have to be copied and pasted into a text editor if anyone wants to look at it or do anything with it. -----BEGIN PGP MESSAGE----- Passphrase-Format: numeric9x4 Passphrase-Begin: 51 jA0ECQMCXn78/MkFNjJg0s/IAe8chth4jDYqEu+cpgHCSvtVw326i89X1oir1h7w IsWgL3noFc5gaqHmfYK03Eah4VzutAC0nkecJkj6QQ7geNwZvREEm/8l0k0JKQHc gaKM524M9B156UdzamJqFJOJrQmpFcgrdcjcsVAtDZr6EBdmbEcdRcoo34m17aBE 9QFMLo9fkjyb6d6vrbGZGzgdg7wWBwlS2QkIGB1Krreoux1dU+m4QVeWfSVe1XOQ SKKuBoYMKv3EI/NKDpeUefrLo52bRFMIpne3JTIYut6kcu/tdd6yK9PsPIHyCkFF N5XOzR0xxKa61h+n3u37H2Mpvbg3ts9CqaH+s86zpgvlV6bs3ncNVZ5hlRKEpFcn 7i4UJ9DljT2IX1iHjVpqDRt4mgF6zY1MjiJzaSNMNg+ceK1aTjDd9IRC+4Hi9orY UGiDV695zIPHPuIg1hhA7TVfnr9q8NyGIZutnANMbMXlwKnGF3tK5jaE/Re0mSiD 9WtqliraNCBRVtsuU3sYd5d2zYxtrCzEw+dAtsEN4hy03Bbls9pjNd31x+3mwyQ/ WzGw6BKyuqT7qz1kkbc7xOL++cuveWlu5yL72M2utmjl/c6biLtK+uYzwydSJHzb NfrEQ5/eD8Em8HyG6AS1w7gQ5qrldZYvQseVzBGyM4vJPkYErfGrWrRs+SnmMDVC RBRExpG3s3TSQtiTetC5Xm99hpJg5RqKAv+5askQh1NhG/0LJu1fiMjh+oyulZI0 iuZc0pRH5618M2RqXn+V+lMSqL+aFOwbPJxDDeJnI6wzhWoxzNt9ZsM7ozwKpybi t7eAzM3zVizhUQPvO+qJMpTnjAACU9AOn2+ueAiN6VUFQSGy8YZ2Kceq5zZL2iIp IIBXTz8dFj8mMJs5YOKgE6l/VlJdhA4T9YXBgGA6hAyax9sIGRVp1uCNT/3eTxZk lUDcc4qf+dpkHONu8d/zXEeou+uWRrE7NeGnbSjDEP3z7enR3V8Vv+MESKJv+2JA 054sFByDH+JXj8zyZSPZ7md9+fS8WdMTJtx9nH6Tmq5aUEe62SIZ5qj0dLpOOL1d th1zZQCwxCax9Hto5yiaOA4QD5X8KpHMGkYNcQViFnjLwDNvX3mOEQ6pTF39IbA/ WsyH3K4MWBcYSw1IlvDD51wcAaXbFuEgGtagEIjkw2Txwygj8PaVEkudFIue9sz9 MbBbGIckBkOnu2yY6GZAywwqSQdjlJfCD6L8to2yCW73EWBlYk2F2ztLYeCRbbxv t1rMpt3GncGAlC30usV1VeFwqfCbHYw3Cif2vPz8EFHkSDO1Uc/hscAEDAekeM2A YmoHkjU8w6Gr8KojRSn3tZs6Y4qolpJmlZ9TC6IFBGCjABFhOfFeP/1ixb+VHyd7 +/YLpkPrKN7M8TKY8HtZv2eIC+r1qAN5pxxGm3ZgShkp1y25bCZUhxHVTvBduKyj LU7Tt2/ct2Yo6h7VhhU+nPZZZVXf81rvN7zw7YSN8bI1ugUzUlmX+M9We3CvmNEJ iR/aZFIHNZR52KGvVnVGzOjd+Ugexc7s5lkshhz+TZs8cAa74u7kop9qDXweT83d MfjewBhc7QqA68ZghaLsE5e9MGt0mg3m8CZp635dMqesEB4QxZ+g+71M/XiUQ6kL XEucbzsJcCZZ1rc/orCLKpk6eDZv+rgNW82j3ydwwbqPZREHNLkaYyiwuBlzGcL7 JDuXd65D0ZzWJQoBB67Z0sc9vQP28wbS/HnFkfWxtbZo8VVA6hM71S10PVU5clob aExiyYCJkm7IwoMpo1XFwdmEOs8p3OyV9Rc0XIPPQgHhVHgHJLEdeitj2hGY+PKr khEia/H9w1r87VOaw4kDlcJvyg34OcwqHH1ByaDjVGGGwmyL0yEzvr1d5aj+HXbb RmuMTXsunkl3rqTWFDApIlmOiywItvlTaSnkEm7RVZVEXSJzvcvT9Tey5tX6BasG zdEmtuyaRyoHAnbN2hHsK+LTSc2/glWyaZFsIKwE7DbAJXd02NIvBCAtaEmEs2fA kXYj1ADmXukY0zyhlAverbcbaiNTumtvuPHJ1rfQSumRak8lkOfjUX/0dQR1i4EF CO4pWkahbaDfrrTxAKuCrNQ3tqKqow10hrHHavuwrFoZYGIbiYsisMK91iIGzSzq 5iWN1H08aTDy89D5srnxeTVuboccyxAYmYnSTX/H+g36gegxIERbKNOvJsufxQcQ QDqlAV0EY3Di+ucW4HpCz9gR/RQquq0rXP+aOYCWCVi+QHYmpv/yGnwTCYjVbbSF q7kkRaqdANR/WW+Y3qJ4l/x5I+W6sudCgKH7wt3OLpFRCmaLn68hKywCHXjgB8F4 h0+1cenH/h3+FxO67D+HySY9jpEHPmSm0W2MXjd4Z+RD34QVOxHPbDiRhOW5px6x so191+oUy8lNKY/4uFJ+Piz9xeEce0HIX2NuMdIZqzN0w+NN2p+h8AMBPEnYq7pq HmMzGmhU1Zr56y4gPRPismub8g6zy3n/yrhCt7/A1X8ddoAYxrB+hEgQWdHKMvnq xaleRf3KIkQl6+ceM9oTmuImgDt6xJB8MNUj5gs0UCDyVMbGFj7pMYTwjfpY+BoL aJa/TGJXqcoPWp87X2hJQNKfoBOlROMRhXo2PaHY+pxqFftnGzTH2GfDeEdCWwvT 1+RZneMwCYIOyKe/xBD9UMK5AeIogiU29UWAy6vk4Vc+aGlWh0LSj2iJD1KSLQfr iEtP45cTq1Yp+pyMKLLfwzxccxdssjPwpvqav14/KScKHV8sNlr67y4LbjOfZhi9 VlZd9OLFkPpSz5XllLiD8djAXQIVVB1MlK9FUu4qjEaL9XKQoUn9dmWPwClm7Pk4 4xbiKQYdT+qE5ExRGJ6qK1NW8Lrh7PLpeW/1a2J+meIUhOSBNXBwJOUNlGfVh86c wpXv9iAWKAsYKLtMtBRavW5XomCVU/iy41/jLnwCUERIpOa9fYrXgr+JNHeYUKZv ACWj0AncG8ZnXhlBhgYNymE4CF9FQQWSWhrBaXEo3tGMXkMgI4QOF+9m9BiTR+32 Bqz1XaHgpBv0S5Dlg9YkQrusqX5fMC5aZplJ+fn7vA30rNXsd9WmO3abBqx9o7HI TlnhIWhl+zDmqSawiBz6qqqYbPbHrx1QMBsJgD68giKZnh3GMzVqXjNdeyrph0K8 /qe1t4nErwcgpySQljGzGk47eeJ/KZejbb2fZbMH1nwWJQ6ySfs1G62nvrqMhS5p jncw/jiuEWtPPjk4rq7ExoLQFmbzWCiSWs37shndGCQAzh9sHQaFBN6XPtOUgOak UKKmh68dmqSj/Bd2wwHLOO442SueYkndh2Hq24ID4iaVJYyRMvDWyyX00JmRlo8s 1uACGhPlAKWU9nFeWzSwTJbfuYFk4WBsJg5Lab951/q+p5jbx6klUlwCNp1l+paN 3FFRm/r3kZSESD3KDizd6Oo+f1sqsFYTaZzFTB7vWCuOTFhvN9Z/YLObOlWwZnmY VOQyruZsbySvoABn5PjLeOK2VGZnVraY1hhPPqOZ14s6wn4BRajGThaOATNc+DIC XEWgaQ7Dz8VgfxqSktd5oWpO2xZTYtThThLvLwM1A3q10beJQ+4W/A9nZLftVoNA aBMdph/ovokFnfI2pN4jkq7DpAhy2G8Rz+SvbEIOfiuZvODEofGtbER2uCLT9Tk0 ODN83eZe54B6pIPPtaf19yRmzLngAIwr3iLW/oW6h0BJ/LubrrKGQSKRi1PadI/4 j7/+E2KvMFDYRFg3hsHAIr/z6ONBvdufNHNcpb9+HTBnL6bWr4YgmSrpK7E5WBvD SWCikLpe88Tdqbkzbvt7dhUs9itYnQUcDgd4hixIw5wIMCTvKJbPQZcjvJx9SBky AR8yist+NOJS38AJEe3AQh5/fQsSRHn1vnXDdd688CVmj83EPZ6mlk33Llw4bWRI hziibEg80s4KkXjspvpGoOTm0uqXPLHg36XFSI6chym7hmFTavwy2UGIS1vJsNQR zYhE9PkE9z8dtRSbv1uyqm3nO5TRl8PTv3kDGTFKd593X478awHLGdPTFnYqdhWx xLWyswZ8WkbuNGYB6K1i+A8nAOedwsamFQ3MbOJfYZh4TVRbPeOvJ3N9Bqb3zzZ5 ZUxRigx/ww2ontGVSktGPnpPi6P6Iml3Gy78WUTZwW9fBQnBy5duilDPWwjvY/tm +ufRKQ+BylSSD9oxjj+xGh7WB71tTO1orfX97xxQhAxkox/58x7Gdmf1CF6MItec QEwaDLZo/xx9V8uSO6um+jAbtkW6ScvYuf0wC5xpHBUrytApmFo6Od+AUYy0P1dF 1OGyh3N26KoEO4thi0ZDnjvz+9dQDHz2N2wxTPFOazrbZOB4BEUxezoCbPcIIU2w 9G0N/IwBO5ws6uTIHx3E2wPW4b/tqWiFrBdz2JHzzbWnabYDwkJq9MQUS+OcGWcA j9n2Oi86I7unCfRgS7f0Sy6Co1+EiIMo/DWXEM6akl9/ug8xUNFpESCi5TyejWFi 5mn/d4XxQoTU18BAPw+kzGIKQ3vY/GiDfprmlKKShOE9kdzDDNn/Zq69tF1egVWD tsbptpDn4eFDkaGodumPh1rWFsYY+Ps6aCdFKRp2hd81I7gj3k099TYA7FUEZ9FY ZLmtfAjh8ly13fgXrn1CpVKq9Kc5XCBm5bbABP8l0f3ROudPEKzrJdS16mj0j7GQ CgWXhHsEDUOuMDmoARWv2H0Kx4xqA44YYLLe3gE+xYFGM7dJ+4KbCwPYiHAXCts7 ofroXIerrxoKR7PdjKXO1EKv4Kd1DC/hJbW7ysCVp8lCAj6BgSzCGaTsCUjgHokn vARNum5Y6pji6IRb1tiYXubiQhuoY/dUZBokue++itAARk0C8rT4yPt6DVZQkjvC XT9/XLwzOOGJ+CWixHUaV+oAr30OP8LZpQg3jMEmaU0Ov8YM4tKjTzqGPfe6J+ke YC4cCHPJvWcpHvaaZ9oa4b+V8KxtNiUiOtioYZZXOWStjZtbQnKAsTf0ui6oNLeI a73tKE4akL7z2Ogt1a4FC2CKqTDc8VMzQAAGDyJTsf/mNbOUxCRhjZVtrJB/MDYz De4UTRfYWvDGcPtDAlxAYuYgCdb9m5WRwq2BCwfgU7xe/HoNlty1ipf+u5CrmfoO NtjVK99UvBq4RFZf/aXrHoWGytSQTvm9XPKJ2LKyVkgrVQC80GirzRnTZwzzzcxG 711nGVo59lS4PJ24bGye8BdiCfmpGkffqBGTcKtdot0qJw91gQM8sVeRYShCpbVw 8m9KqMJNhj8Zz4aRnL7r5x3KsblBAj3qxapgG9fSYbvu5AfkP/atafDfMpLr5YrU iTSCwJBqHg3V2BmbDuMn1JaYZp9jiA7hC6sBt5gz1bPaJRFylzfv4xXbwuHEjj5V cbDj8FTLeXtNgcOqX6s+3PMNMxuzGDHGzjI6PJd5cBkD3f/RuKsPfToMc6F3rZf3 tuwBnqHmOfLspNBxWUUj54x7Y7/O/ZlHJnnUGuUeioawfLEuA8jTfe2Hn+kVpgy2 5jSb0xM51R229oOjwSG598cXe4FKUYitIOb6LPfNMrnyp7/mbyGTL6WPxksVj71r asx1KJC6/W+h5+1VAt5QmMSDC2ybj507FWs= =K27J -----END PGP MESSAGE----- -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From per.tore.johansen at ecp.no Fri Dec 7 14:51:28 2018 From: per.tore.johansen at ecp.no (Per Tore Johansen) Date: Fri, 7 Dec 2018 14:51:28 +0100 Subject: Problem with the GnuPG - gen-key Message-ID: <01cb01d48e33$f42f64d0$dc8e2e70$@ecp.no> Hi, Installed GnuPG from : gnupg-i5pase-1.4.10b.tar.Z on Power for I. OS release V7R3 Katalog . . . . . : /usr/local/gpg/bin and also the same in /qopensys/local/gpg/bin Alt Objektlenke Type Attributt Tekst gpg STMF gpg-zip STMF gpgsplit STMF gpgv STMF mklinks STMF Opened Putty login as: myuser myuser at 10.5.72.1's password: # cd /usr/local/gpg/bin # gpg --gen-key gpg: syntax error at line 1: `<' unexpected Anyone that can help my on this? Kind regards / Med vennlig hilsen Per Tore Johansen _______________________________________________________ Electronic Commerce Partners AS * Trondheimsveien 436A. 0962 OSLO - NORWAY * per.tore.johansen at ecp.no * Mobile: (+47) 90 94 10 89 i http://www.ecp.no P Before printing, please think Environment -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1970 bytes Desc: not available URL: From juergen at bruckner.tk Fri Dec 7 21:36:37 2018 From: juergen at bruckner.tk (Juergen Bruckner) Date: Fri, 7 Dec 2018 21:36:37 +0100 Subject: a minimal version of PGP/GPG for the Win32/64 bits for command line In-Reply-To: <1544198743.966.27.camel@16bits.net> References: <1544198743.966.27.camel@16bits.net> Message-ID: <9b970c5e-3363-d9ec-834a-b1e6149ab1c2@bruckner.tk> Hello! GnuPG is also available as PortableApp. www.portableapps.com regards Juergen Am 07.12.18 um 17:05 schrieb ?ngel: > On 2018-12-07 at 13:04 +0100, Jan Kamracki wrote: >> Hello! >> >> >> I need a GPG/PGP version running from the command line for Win32/64 >> bits. >> Something like PGP5i. >> I wanted to generate a pair of keys and send someone a gpg.exe/pgp.exe >> + public key, so that he could encrypt a file without any installation >> PGP/GPG and send it to me. >> What do you propose? >> > Point them to https://www.gpg4win.org/ > > I think you could extract the command line binaries and run them as > portable apps, but actually, I think it would be easier for them to run > the installer and have a nice GUI app rather than a cli app. > Not to mention that, if you expected to send them gpg.exe by email so > that they could reply with an encrypted mail, (a) you are setting a very > bad precedent expecting them to run an arbitrary executable they > received from an untrusted medium and (b) the mail server would most > likely block your message anyway. > > Best regards > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Juergen Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From justina at colmena.biz Sun Dec 9 05:03:50 2018 From: justina at colmena.biz (justina colmena) Date: Sat, 08 Dec 2018 19:03:50 -0900 Subject: gpg2: unable to use secret key from OpenKeychain In-Reply-To: <2B42E759-8A74-4FDF-B7A4-60E247CC6658@colmena.biz> References: <329FED93-D058-45DB-ACE3-C49912193EE6@colmena.biz> <2B42E759-8A74-4FDF-B7A4-60E247CC6658@colmena.biz> Message-ID: This is the error message I get in gpg2 with (my own) key. GnuPG 2.2.9~11 gives me no indication that anything is wrong with the key until I am prompted for the passphrase, and then even the correct passphrase is rejected. Please enter the passphrase to unlock the OpenPGP secret key: "justina colmena " 3072-bit RSA key, ID D514FB3FDF44BDA4, created 2018-10-27 (main key ID 6B4FF696F20E3CC5). Bad Passphrase (try 2 of 3) Passphrase: ___________________________ I have no problem unlocking the secret key or setting or changing its passphrase in gpg1, but I have no idea how to import or use the secret key in gpg2. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From stefan.claas at posteo.de Sun Dec 9 13:54:01 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 9 Dec 2018 13:54:01 +0100 Subject: Garbled data in keyservers In-Reply-To: <87va4691m1.fsf@wheatstone.g10code.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> Message-ID: <20181209135401.735f1678@iria.my-fqdn.de> On Thu, 06 Dec 2018 15:22:14 +0100, Werner Koch wrote: > > That's right, but my thought is / was someone can (ab)use key > > servers as data storage / retrieval system and then only provides > > the key id > > As it has been commeted, there are easier ways to do that. I have read also the threads at sks devel ML and my suggestions would be that we need more international CA's to get rid of all the problems, the key server network has. People should think about the following: Get a sig from a CA and then upload your key via email. Then the key servers do something like a gpg --check-sigs to see if a key bears a valid CA sig and if it is found in their index the key will be added to the network, once the submitted UID matches with the email address header. So no cryptographic verification is imho needed. This would also eliminate, i think, that someone else can upload someone else's pub key. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From justina at colmena.biz Sun Dec 9 18:23:03 2018 From: justina at colmena.biz (justina colmena) Date: Sun, 09 Dec 2018 08:23:03 -0900 Subject: Garbled data in keyservers In-Reply-To: <20181209135401.735f1678@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> Message-ID: <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> On December 9, 2018 7:54:01 AM EST, Stefan Claas wrote:: > >Get a sig from a CA and then upload your key via email. > That's a bit steep, and was never the original goal of PGP or GPG. If the goal is to eliminate the bulk of bad keys and junk from key servers, an account creation with basic email verification for adding or removing keys should suffice. Let's be honest: no one really wants an infrastructure of legally valid or enforceable GPG signatures, either. It's a technical verification that something is very unlikely to be altered if the signature is valid. Any particular overriding legal significance beyond that is unnecessary. Don't overdo it, please. PGP key servers are not supposed to be "authoritative." They are a convenience to extend an informal web of trust. Let's resist that German urge toward authoritarianism and absolutism, shall we? Bosses and bullies do not help with privacy, personal digital signatures, or cryptography for personal use. The CA stuff is mostly for business, not personal. The adversaries in that case are pickpockets and credit card skimmers, not major governments and political enemies. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc From dirk.gottschalk1980 at googlemail.com Sun Dec 9 18:24:38 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 09 Dec 2018 18:24:38 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181209135401.735f1678@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> Message-ID: <860cf0621e2b8c35ef66c75c1d03b3af9544622a.camel@googlemail.com> Hi. Am Sonntag, den 09.12.2018, 13:54 +0100 schrieb Stefan Claas: > On Thu, 06 Dec 2018 15:22:14 +0100, Werner Koch wrote: > > > > That's right, but my thought is / was someone can (ab)use key > > > servers as data storage / retrieval system and then only provides > > > the key id > > > > As it has been commeted, there are easier ways to do that. > I have read also the threads at sks devel ML and my suggestions > would be that we need more international CA's to get rid of all > the problems, the key server network has. > People should think about the following: > Get a sig from a CA and then upload your key via email. > Then the key servers do something like a gpg --check-sigs > to see if a key bears a valid CA sig and if it is found in their > index the key will be added to the network, once the submitted > UID matches with the email address header. So no cryptographic > verification is imho needed. This would also eliminate, i think, > that someone else can upload someone else's pub key. And who decides which CA ist trustworthy and which is not? The problem ist, like in the X.509 land, that it depends on an initial trust to one or more central authorities. Who decides whom one can trust. And further, why should anyone run something like a ca CA for free. Sure, CAcert does it. But that's the onl?y organisation I know who does this. And then again the question, who decides who get's the nedded trust? Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Sun Dec 9 18:34:54 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 09 Dec 2018 18:34:54 +0100 Subject: Garbled data in keyservers In-Reply-To: <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> Message-ID: <309168346c43f98200de7922030e542010ef2268.camel@googlemail.com> Hello Justina Am Sonntag, den 09.12.2018, 08:23 -0900 schrieb justina colmena via Gnupg-users: > On December 9, 2018 7:54:01 AM EST, Stefan Claas < > stefan.claas at posteo.de> wrote:: > > Get a sig from a CA and then upload your key via email. > > > That's a bit steep, and was never the original goal of PGP or GPG. Correct. > If the goal is to eliminate the bulk of bad keys and junk from key > servers, an account creation with basic email verification for adding > or removing keys should suffice. That's something I thought about, too. > Let's be honest: no one really wants an infrastructure of legally > valid or enforceable GPG signatures, either. It's a technical > verification that something is very unlikely to be altered if the > signature is valid. Any particular overriding legal significance > beyond that is unnecessary. Legal significcance is one point and it's to complicated in many countries. > Don't overdo it, please. PGP key servers are not supposed to be > "authoritative." They are a convenience to extend an informal web of > trust. Let's resist that German urge toward authoritarianism and > absolutism, shall we? Yeah, RIGHT! As a German I say, this urge in Germany and even in Europe is totally silly at all. They are making an A 380 out of a duck, so to say. Or like we call it in germany: "eine M?cke zu einem Elefanten machen". > Bosses and bullies do not help with privacy, personal digital > signatures, or cryptography for personal use. The CA stuff is mostly > for business, not personal. The adversaries in that case are > pickpockets and credit card skimmers, not major governments and > political enemies. Right, but, to be honest, in some cases a GPG signature should be even enough to prove the origin in a legal way. Some countries accept this already, but not in silly old europe. Okay, EU sucks, but that's another topic. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From stefan.claas at posteo.de Sun Dec 9 19:38:31 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 9 Dec 2018 19:38:31 +0100 Subject: Garbled data in keyservers In-Reply-To: <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> Message-ID: <20181209193831.07ccd749@iria.my-fqdn.de> On Sun, 09 Dec 2018 08:23:03 -0900, justina colmena via Gnupg-users wrote: > On December 9, 2018 7:54:01 AM EST, Stefan Claas > wrote:: > > > >Get a sig from a CA and then upload your key via email. > > > That's a bit steep, and was never the original goal of PGP or GPG. No, in 2018 i think it is not. CA's can be run by non-profit organizations like EFF etc., which i believe a lot of people trust. Then don't forget all the worldwide assurers from CAcert.org. > If the goal is to eliminate the bulk of bad keys and junk from key > servers, an account creation with basic email verification for adding > or removing keys should suffice. I don't think so. Create an anon account at ProtonMail via Tor for example and then do "funny stuff" with those keys. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From stefan.claas at posteo.de Sun Dec 9 19:54:56 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 9 Dec 2018 19:54:56 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181209195137.48a9deb1@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <860cf0621e2b8c35ef66c75c1d03b3af9544622a.camel@googlemail.com> <20181209195137.48a9deb1@iria.my-fqdn.de> Message-ID: <20181209195456.25e397ed@iria.my-fqdn.de> On Sun, 9 Dec 2018 19:51:37 +0100, Stefan Claas wrote: > On Sun, 09 Dec 2018 18:24:38 +0100, Dirk Gottschalk wrote: Hi Dirk, > > > Get a sig from a CA and then upload your key via email. > > Then the key servers do something like a gpg --check-sigs > > to see if a key bears a valid CA sig and if it is found in their > > index the key will be added to the network, once the submitted > > UID matches with the email address header. So no cryptographic > > verification is imho needed. This would also eliminate, i think, > > > that someone else can upload someone else's pub key. > > > > And who decides which CA ist trustworthy and which is not? The > > problem ist, like in the X.509 land, that it depends on an initial > > trust to one or more central authorities. Who decides whom one can > > trust. If trusted organizations like EFF etc. would run a CA... > > And further, why should anyone run something like a ca CA for > > free. Nobody said that it should be free. > > And then again the question, who decides who get's the nedded > > trust? I have learned in the past the phrase "trust nobody" when it comes to IoT. That means also I don't have to trust GnuPG users, for example... ;-) Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From stefan.claas at posteo.de Sun Dec 9 20:03:09 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 9 Dec 2018 20:03:09 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181209193831.07ccd749@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> Message-ID: <20181209200309.10c7950f@iria.my-fqdn.de> On Sun, 9 Dec 2018 19:38:31 +0100, Stefan Claas wrote: > On Sun, 09 Dec 2018 08:23:03 -0900, justina colmena via Gnupg-users > wrote: > > On December 9, 2018 7:54:01 AM EST, Stefan Claas > > wrote:: > > > > > >Get a sig from a CA and then upload your key via email. > > > > > That's a bit steep, and was never the original goal of PGP or GPG. > > No, in 2018 i think it is not. CA's can be run by non-profit > organizations like EFF etc., which i believe a lot of people trust. > > Then don't forget all the worldwide assurers from CAcert.org. > > > If the goal is to eliminate the bulk of bad keys and junk from key > > servers, an account creation with basic email verification for > > adding or removing keys should suffice. > > I don't think so. Create an anon account at ProtonMail via Tor for > example and then do "funny stuff" with those keys. My proposal could be run also in parallel. I think it would be only a weekend job for a programmer to modify the server code, so that it accepts only incoming and verified email and not web or GnuPG via Tor submissions. People can then still use the old key servers (until they may become obsolete...) or use keybase. To bad that Werner's WKD is not widely adopted from email service providers... Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From dirk.gottschalk1980 at googlemail.com Sun Dec 9 20:13:46 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 09 Dec 2018 20:13:46 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181209195456.25e397ed@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <860cf0621e2b8c35ef66c75c1d03b3af9544622a.camel@googlemail.com> <20181209195137.48a9deb1@iria.my-fqdn.de> <20181209195456.25e397ed@iria.my-fqdn.de> Message-ID: <0b0cea8a3f426c713d969a9d8454cecc6716b491.camel@googlemail.com> Am Sonntag, den 09.12.2018, 19:54 +0100 schrieb Stefan Claas: > On Sun, 9 Dec 2018 19:51:37 +0100, Stefan Claas wrote: > > On Sun, 09 Dec 2018 18:24:38 +0100, Dirk Gottschalk wrote: > > Hi Dirk, > > > Get a sig from a CA and then upload your key via email. > > > Then the key servers do something like a gpg --check-sigs > > > to see if a key bears a valid CA sig and if it is found in their > > > index the key will be added to the network, once the submitted > > > UID matches with the email address header. So no cryptographic > > > verification is imho needed. This would also eliminate, i think, > > > > that someone else can upload someone else's pub key. > > > > > > And who decides which CA ist trustworthy and which is not? The > > > problem ist, like in the X.509 land, that it depends on an > > > initial > > > trust to one or more central authorities. Who decides whom one > > > can > > > trust. > If trusted organizations like EFF etc. would run a CA... > > > And further, why should anyone run something like a ca CA for > > > free. > Nobody said that it should be free. That's a point one would have to discuss. A small one time fee would be okay, but not to much, ore we are at the same point like in X.509 land and nobody wants to invest, except for real good reasons. > > > And then again the question, who decides who get's the nedded > > > trust? > I have learned in the past the phrase "trust nobody" when it comes > to IoT. That means also I don't have to trust GnuPG users, for > example... ;-) Exactly this is the point where the key signatures get in place. You can decide whom you trust, or not, and how far your trust goes. Than you can see, if somebody you don't know yet is trusted by a user you trust. Then the trustdb comes into place. Exactly this is how PGP works. PGP is not a replacement for the X.509 infrastructure like it is used in companies or other organizations. And even there often PGP is enough, at least for Email signature or encryption. I'm still not sure what you're trying to achieve. A Replacement for X.509? Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Sun Dec 9 20:26:21 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 09 Dec 2018 20:26:21 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181209193831.07ccd749@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> Message-ID: Hi Stefan. Am Sonntag, den 09.12.2018, 19:38 +0100 schrieb Stefan Claas: > On Sun, 09 Dec 2018 08:23:03 -0900, justina colmena via Gnupg-users > wrote: > > On December 9, 2018 7:54:01 AM EST, Stefan Claas > > wrote:: > > > Get a sig from a CA and then upload your key via email. > > > > > That's a bit steep, and was never the original goal of PGP or GPG. > No, in 2018 i think it is not. CA's can be run by non-profit > organizations like EFF etc., which i believe a lot of people trust. > Then don't forget all the worldwide assurers from CAcert.org. > > > If the goal is to eliminate the bulk of bad keys and junk from key > > servers, an account creation with basic email verification for > > adding > > or removing keys should suffice. > I don't think so. Create an anon account at ProtonMail via Tor for > example and then do "funny stuff" with those keys. Nah, the server code has just to be modified, then a plausibility check could be established if the UID is a valid one, or an abusive. This would disable abusive UIDs with malicious data. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Sun Dec 9 20:34:55 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 09 Dec 2018 20:34:55 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181209200309.10c7950f@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> Message-ID: Am Sonntag, den 09.12.2018, 20:03 +0100 schrieb Stefan Claas: > On Sun, 9 Dec 2018 19:38:31 +0100, Stefan Claas wrote: > > On Sun, 09 Dec 2018 08:23:03 -0900, justina colmena via Gnupg-users > > wrote: > > > On December 9, 2018 7:54:01 AM EST, Stefan Claas > > > wrote:: > > > > Get a sig from a CA and then upload your key via email. > > > > > > > That's a bit steep, and was never the original goal of PGP or > > > GPG. > > No, in 2018 i think it is not. CA's can be run by non-profit > > organizations like EFF etc., which i believe a lot of people trust. > > Then don't forget all the worldwide assurers from CAcert.org. > > > If the goal is to eliminate the bulk of bad keys and junk from > > > key > > > servers, an account creation with basic email verification for > > > adding or removing keys should suffice. > > I don't think so. Create an anon account at ProtonMail via Tor for > > example and then do "funny stuff" with those keys. > My proposal could be run also in parallel. I think it would be > only a weekend job for a programmer to modify the server code, > so that it accepts only incoming and verified email and not web > or GnuPG via Tor submissions. That's also what GPG is made for. Privacy. So TOR usage is quite okay. The Idea with an email bot instead of a HKP for upload is something that could be taken into consideration to validate sender and key, I agree. A weekend job... Muhahahahahahaha, you don't do much programming, don't you? One would have to write an email bot, change the keyserver code to no longer accept submissions via HKP, then it would be neccessary do disable HKP for upload in GnuPG to avoid broken Clients and so on. > People can then still use the old key servers (until they may become > obsolete...) or use keybase. Keybase is an option, yes., And the Keyservers could be fixed. HKP for retrieval is very comfortable and there is no need to disable also the retrieval. > To bad that Werner's WKD is not widely adopted from email > service providers... WKD is a good thing, but has not yet widely spread. I think one oif the problems is the small amount of users demanding it. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From stefan.claas at posteo.de Sun Dec 9 20:36:25 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 9 Dec 2018 20:36:25 +0100 Subject: Fw: Garbled data in keyservers Message-ID: <20181209203625.36e1c85c@iria.my-fqdn.de> Beginn der weitergeleiteten Nachricht: Datum: Sun, 9 Dec 2018 20:35:41 +0100 Von: Stefan Claas An: Dirk Gottschalk Betreff: Re: Garbled data in keyservers On Sun, 09 Dec 2018 20:26:21 +0100, Dirk Gottschalk wrote: Hi Dirk, > > I don't think so. Create an anon account at ProtonMail via Tor for > > example and then do "funny stuff" with those keys. > > Nah, the server code has just to be modified, then a plausibility > check could be established if the UID is a valid one, or an abusive. > This would disable abusive UIDs with malicious data. Well, if one creates a valid UID for ProtonMail, for example, the the Server needs then also to check additional UID's or "funny" sigs, right? A key which would bear a CA sig would imho not have such additional and funny UID's or sigs, because it would make the key owner look a bit stupid, i would say. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From dirk.gottschalk1980 at googlemail.com Sun Dec 9 20:39:07 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 09 Dec 2018 20:39:07 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181209193831.07ccd749@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> Message-ID: <99a994a028a9b1b708764147be157817d708f55b.camel@googlemail.com> Hello Stefan. Am Sonntag, den 09.12.2018, 19:38 +0100 schrieb Stefan Claas: > On Sun, 09 Dec 2018 08:23:03 -0900, justina colmena via Gnupg-users > wrote: > > On December 9, 2018 7:54:01 AM EST, Stefan Claas > > wrote:: > > > Get a sig from a CA and then upload your key via email. > > > > > That's a bit steep, and was never the original goal of PGP or GPG. > No, in 2018 i think it is not. CA's can be run by non-profit > organizations like EFF etc., which i believe a lot of people trust. > Then don't forget all the worldwide assurers from CAcert.org. > > If the goal is to eliminate the bulk of bad keys and junk from key > > servers, an account creation with basic email verification for > > adding or removing keys should suffice. > I don't think so. Create an anon account at ProtonMail via Tor for > example and then do "funny stuff" with those keys. There is always a way to abuse things. And a plausibility check on UIDs would remove the possibility for abusive data encoding in these. I think that would be a starting point. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From stefan.claas at posteo.de Sun Dec 9 20:48:38 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 9 Dec 2018 20:48:38 +0100 Subject: Garbled data in keyservers In-Reply-To: References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> Message-ID: <20181209204838.16128a68@iria.my-fqdn.de> On Sun, 09 Dec 2018 20:34:55 +0100, Dirk Gottschalk wrote: > Am Sonntag, den 09.12.2018, 20:03 +0100 schrieb Stefan Claas: Hi Dirk, > A weekend job... Muhahahahahahaha, you don't do much programming, > don't you? One would have to write an email bot, change the keyserver > code to no longer accept submissions via HKP, then it would be > neccessary do disable HKP for upload in GnuPG to avoid broken Clients > and so on. Mind you in the 90's PGP key servers accepted also email and Usenet submissions, if i remember correctly. The keyword was then simple the word "add" in the subject line of an email. > > People can then still use the old key servers (until they may become > > obsolete...) or use keybase. > > Keybase is an option, yes., And the Keyservers could be fixed. HKP for > retrieval is very comfortable and there is no need to disable also the > retrieval. The retrieval is of course good and it did not say something about it. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From wiktor at metacode.biz Sun Dec 9 20:49:55 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Sun, 9 Dec 2018 20:49:55 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181209200309.10c7950f@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> Message-ID: <0b64c133-f94f-f622-61f3-dcd9ce713769@metacode.biz> On 09.12.2018 20:03, Stefan Claas wrote: > To bad that Werner's WKD is not widely adopted from email > service providers... Just for the record but it is adopted by e-mail service providers that are interested in OpenPGP (like ProtonMail and Posteo.de, see https://wiki.gnupg.org/WKD). As for "e-mail service providers" like Gmail or Yahoo that obviously is not going to happen (unless one uses Google Suite with custom domain, etc.) Kind regards, Wiktor -- https://metacode.biz/@wiktor From juergen at bruckner.tk Sun Dec 9 21:11:12 2018 From: juergen at bruckner.tk (Juergen Bruckner) Date: Sun, 9 Dec 2018 21:11:12 +0100 Subject: Garbled data in keyservers In-Reply-To: <860cf0621e2b8c35ef66c75c1d03b3af9544622a.camel@googlemail.com> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <860cf0621e2b8c35ef66c75c1d03b3af9544622a.camel@googlemail.com> Message-ID: <260ff146-7b32-1624-8bbb-bca8f7b8e4a6@bruckner.tk> Am 09.12.18 um 18:24 schrieb Dirk Gottschalk via Gnupg-users: > And further, why should anyone run something like a ca CA for free. > Sure, CAcert does it. But that's the onl?y organisation I know who does > this. Also WPIA [1] plans to do this and started a audit process for their CA. regards Juergen [1] https://wpia.club -- Juergen Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From stefan.claas at posteo.de Sun Dec 9 21:13:51 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 9 Dec 2018 21:13:51 +0100 Subject: Garbled data in keyservers In-Reply-To: References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209203541.6d0853d1@iria.my-fqdn.de> Message-ID: <20181209211351.30a71e5e@iria.my-fqdn.de> On Sun, 09 Dec 2018 20:55:36 +0100, Dirk Gottschalk wrote: Hello Dirk, > That I mentioned in the other reply I have sent a few seconds ago. > > > right? A key which would bear a CA sig would imho not have such > > additional and funny UID's or sigs, because it would make the key > > owner look a bit stupid, i would say. > > No. The signatures on a key are nor related to each other. A funni > signature could be backdated before the signature by the CA were made. > Who's the stupid now, in the eyes of the user seeing this? ^^ Do you really think a user with a CA sig would do that, with my proposals i have made? Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From stefan.claas at posteo.de Sun Dec 9 21:17:34 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 9 Dec 2018 21:17:34 +0100 Subject: Garbled data in keyservers In-Reply-To: <260ff146-7b32-1624-8bbb-bca8f7b8e4a6@bruckner.tk> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <860cf0621e2b8c35ef66c75c1d03b3af9544622a.camel@googlemail.com> <260ff146-7b32-1624-8bbb-bca8f7b8e4a6@bruckner.tk> Message-ID: <20181209211734.732f3417@iria.my-fqdn.de> On Sun, 9 Dec 2018 21:11:12 +0100, Juergen Bruckner wrote: > Am 09.12.18 um 18:24 schrieb Dirk Gottschalk via Gnupg-users: > > And further, why should anyone run something like a ca CA for free. > > Sure, CAcert does it. But that's the onl?y organisation I know who > > does this. > > Also WPIA [1] plans to do this and started a audit process for their > CA. > > regards > Juergen > > [1] https://wpia.club Very cool Juergen! Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From dirk.gottschalk1980 at googlemail.com Sun Dec 9 21:36:50 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 09 Dec 2018 21:36:50 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181209211351.30a71e5e@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209203541.6d0853d1@iria.my-fqdn.de> <20181209211351.30a71e5e@iria.my-fqdn.de> Message-ID: Hi Stefan. Am Sonntag, den 09.12.2018, 21:13 +0100 schrieb Stefan Claas: > On Sun, 09 Dec 2018 20:55:36 +0100, Dirk Gottschalk wrote: > > Hello Dirk, > > > That I mentioned in the other reply I have sent a few seconds ago. > > > > > right? A key which would bear a CA sig would imho not have such > > > additional and funny UID's or sigs, because it would make the key > > > owner look a bit stupid, i would say. > > > > No. The signatures on a key are nor related to each other. A funni > > signature could be backdated before the signature by the CA were > > made. > > Who's the stupid now, in the eyes of the user seeing this? ^^ > > Do you really think a user with a CA sig would do that, with my > proposals i have made? Yes, for sure. With a backdated signature the CA could be blamed in the eyes of some not so firm users. Even if it's only for this purpose. First the UID problem should be fixed and then a similar mechanism for the signatures could be introduces. This would fix the well known problems and no CA would be needed. That is unrelated to the CA's for "assurance" which are not a really bad idea, but it has nothing to do with the flaws in the key servers and even wou?t be a fix for this. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From justina at colmena.biz Sun Dec 9 23:42:32 2018 From: justina at colmena.biz (justina colmena) Date: Sun, 09 Dec 2018 13:42:32 -0900 Subject: Garbled data in keyservers In-Reply-To: <20181209211734.732f3417@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <860cf0621e2b8c35ef66c75c1d03b3af9544622a.camel@googlemail.com> <260ff146-7b32-1624-8bbb-bca8f7b8e4a6@bruckner.tk> <20181209211734.732f3417@iria.my-fqdn.de> Message-ID: <285117FE-653F-4444-8023-BFA9702E1810@colmena.biz> On December 9, 2018 11:17:34 AM AKST, Stefan Claas wrote: >On Sun, 9 Dec 2018 21:11:12 +0100, Juergen Bruckner wrote: >> Am 09.12.18 um 18:24 schrieb Dirk Gottschalk via Gnupg-users: >> > And further, why should anyone run something like a ca CA for free. >> > Sure, CAcert does it. But that's the onl?y organisation I know who >> > does this. >> >> Also WPIA [1] plans to do this and started a audit process for their >> CA. >> >> regards >> Juergen >> >> [1] https://wpia.club > >Very cool Juergen! > >Regards >Stefan > >-- >https://www.behance.net/futagoza >https://keybase.io/stefan_claas What was that German company, StartSSL or something, that offered free certs for a while, big on S/MIME, (almost deprecated PGP/GPG,) and personal client certificates on the browser, that sort of thing? Then there was a big kerfuffle because the Chinese allegedly bought them out. Then EFF / certbot / letsencrypt started offering them. It's a "gentleman's agreement" of sorts. One and only one CA will offer "free" certs, and they're "well-known," basically for development and not for e-commerce. I'm rather upset with EFF at the moment, by the way. They're always pushing "adult content" like a bunch of porno addicts and they have acquired almost a Salesforce- or SAP-like CRM system in their back office, collecting lot of personal information on political dissidents and precisely the privacy-minded individuals who would rather not have such possibly derogatory information collected about them. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From wiktor at metacode.biz Mon Dec 10 14:25:08 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 10 Dec 2018 14:25:08 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181209204838.16128a68@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> <20181209204838.16128a68@iria.my-fqdn.de> Message-ID: <258efe05-2ac9-9939-a5d6-31ead14187bf@metacode.biz> On 09.12.2018 20:48, Stefan Claas wrote: > Mind you in the 90's PGP key servers accepted also email and Usenet > submissions, if i remember correctly. The keyword was then simple > the word "add" in the subject line of an email. > > That's an interesting idea, it seems GnuPG has some support for sending keys via e-mail. From the "--keyserver" option documentation [0]: > This is the server that --receive-keys, --send-keys, and --search-keys will > communicate with to receive keys from, send keys to, and search for keys on. > (...) The scheme is the type of keyserver: "hkp" for the HTTP (or compatible) > keyservers, "ldap" for the LDAP keyservers, or *"mailto" for the Graff email > keyserver*. I didn't manage to get it running though ("gpg: keyserver send failed: No keyserver available"), probably it depends on some package that I don't have locally. By the way validation of keys sent from e-mail would require DKIM as it's easy to spoof "From" (that's why most solutions send verification e-mails to the e-mail address instead of receiving it). Kind regards, Wiktor [0]: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html -- https://metacode.biz/@wiktor -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Mon Dec 10 15:56:54 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 10 Dec 2018 14:56:54 +0000 Subject: Garbled data in keyservers In-Reply-To: <258efe05-2ac9-9939-a5d6-31ead14187bf@metacode.biz> References: <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> <20181209204838.16128a68@iria.my-fqdn.de> <258efe05-2ac9-9939-a5d6-31ead14187bf@metacode.biz> Message-ID: <20181210145654.sbd7dg6fed3rh3pg@CHS-TMB-078.qmcr.qmul.ac.uk> On Mon, Dec 10, 2018 at 02:25:08PM +0100, Wiktor Kwapisiewicz via Gnupg-users wrote: > On 09.12.2018 20:48, Stefan Claas wrote: > > Mind you in the 90's PGP key servers accepted also email and Usenet > > submissions, if i remember correctly. The keyword was then simple > > the word "add" in the subject line of an email. > > [...] > > I didn't manage to get it running though ("gpg: keyserver send failed: No > keyserver available"), probably it depends on some package that I don't have > locally. As far as I know, most keyservers nowadays no longer accepts key submission by e-mail. Those that still support the e-mail interface only do so to allow *querying* the keyserver, not *adding* any key; that is, they only support the INDEX and the GET commands, not the ADD command. - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wiktor at metacode.biz Mon Dec 10 16:25:36 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 10 Dec 2018 15:25:36 +0000 Subject: Garbled data in keyservers In-Reply-To: <20181210145654.sbd7dg6fed3rh3pg@CHS-TMB-078.qmcr.qmul.ac.uk> References: <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> <20181209204838.16128a68@iria.my-fqdn.de> <258efe05-2ac9-9939-a5d6-31ead14187bf@metacode.biz> <20181210145654.sbd7dg6fed3rh3pg@CHS-TMB-078.qmcr.qmul.ac.uk> Message-ID: <2510F46F-7780-4C0D-9EB6-60A0FC5C7CC0@metacode.biz> Hi, I use an address I control, but the email was not even sent so I guess the error happened before the key hit the network. Kind regards, Wiktor Dnia December 10, 2018 2:56:54 PM UTC, Damien Goutte-Gattat napisa?(a): >On Mon, Dec 10, 2018 at 02:25:08PM +0100, Wiktor Kwapisiewicz via >Gnupg-users wrote: >> On 09.12.2018 20:48, Stefan Claas wrote: >> > Mind you in the 90's PGP key servers accepted also email and Usenet >> > submissions, if i remember correctly. The keyword was then simple >> > the word "add" in the subject line of an email. >> >> [...] >> >> I didn't manage to get it running though ("gpg: keyserver send >failed: No >> keyserver available"), probably it depends on some package that I >don't have >> locally. > >As far as I know, most keyservers nowadays no longer accepts key >submission by e-mail. Those that still support the e-mail >interface only do so to allow *querying* the keyserver, not >*adding* any key; that is, they only support the INDEX and the GET >commands, not the ADD command. > > >- Damien -- metacode -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.claas at posteo.de Mon Dec 10 17:32:36 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Mon, 10 Dec 2018 17:32:36 +0100 Subject: Garbled data in keyservers In-Reply-To: <258efe05-2ac9-9939-a5d6-31ead14187bf@metacode.biz> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> <20181209204838.16128a68@iria.my-fqdn.de> <258efe05-2ac9-9939-a5d6-31ead14187bf@metacode.biz> Message-ID: <20181210173236.3bbd4dbe@iria.my-fqdn.de> On Mon, 10 Dec 2018 14:25:08 +0100, Wiktor Kwapisiewicz wrote: Hi Wiktor, > That's an interesting idea, it seems GnuPG has some support for sending keys via > e-mail. > By the way validation of keys sent from e-mail would require DKIM as it's easy > to spoof "From" (that's why most solutions send verification e-mails to the > e-mail address instead of receiving it). Yes, it seems it would be a good start. However, if unwanted data can then be still submitted remains to bee seen, because what if anonymous email services would use DKIM too? As per Werner's suggestion to make only the fingerprint available for (Web/API) searches, is also a thing, because like i previously said a list of fingerprints for example can still be generated and uploaded with a description of a file name, so that users only need to use a one line like that: fp=0x1E2CE500D7C6ACD8D41DABAB73253A1F090C53B6 gpg --recv-key $fp | gpg --export $fp > key.asc && gpg --list-packets key.asc |\ grep -e '^:user ID packet: "[[:digit:]]'|sed -e 's/^:user ID packet: "//' |\ sort -n | sed -e 's/^[^@]*@//'| tr -d '"\015\012' | fold -w 76 | base64 -d > Kristian.jpg And i tried also a modified version of the github program (uploading disabled) and it is pretty fast imho for generating jpg image content keys. For other binary stuff it is slow. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From wiktor at metacode.biz Mon Dec 10 18:34:49 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 10 Dec 2018 18:34:49 +0100 Subject: Garbled data in keyservers In-Reply-To: <20181210173236.3bbd4dbe@iria.my-fqdn.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> <20181209204838.16128a68@iria.my-fqdn.de> <258efe05-2ac9-9939-a5d6-31ead14187bf@metacode.biz> <20181210173236.3bbd4dbe@iria.my-fqdn.de> Message-ID: <15ee3c7f-0919-1a21-9b34-bd21c2c705f7@metacode.biz> On 10.12.2018 17:32, Stefan Claas wrote: > Yes, it seems it would be a good start. However, if unwanted data can then be still > submitted remains to bee seen, because what if anonymous email services would use > DKIM too? Well it depends on the implementation. In current keyserver model everyone can append signatures to everyone's keys because the design assumed that it's good that other people can certify your key and didn't predict "trollwot". But it's technically possible to accept key signatures for a key only from the key owner. Of course implementing that in SKS would take a lot of work. Then if someone used anonymous e-mail service they could update only their keys. If you consider that a risk then the software shouldn't accept foreign keys at all as e-mail verification won't solve the SPAM problem in general. That is also a benefit of WKD because everyone takes care of their own keys and no one has to volunteer to host other people's stuff. > As per Werner's suggestion to make only the fingerprint available for (Web/API) searches, > is also a thing, because like i previously said a list of fingerprints for example can still be This would solve some problems but not others. I think Web Key Directory (for people controlling their domains) coupled with Autocrypt (for everyone else) already solves a large number of use cases people need key servers. The only real problem that keyservers are good at is storing revocations in a way that is hard to delete. But if that is so "maybe we need just a revocation server" as someone said on the OpenPGP Email Summit 2018 (https://wiki.gnupg.org/EmailSummit2018Notes). Kind regards, Wiktor -- https://metacode.biz/@wiktor From stefan.claas at posteo.de Mon Dec 10 19:00:51 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Mon, 10 Dec 2018 19:00:51 +0100 Subject: Garbled data in keyservers In-Reply-To: <15ee3c7f-0919-1a21-9b34-bd21c2c705f7@metacode.biz> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> <20181209204838.16128a68@iria.my-fqdn.de> <258efe05-2ac9-9939-a5d6-31ead14187bf@metacode.biz> <20181210173236.3bbd4dbe@iria.my-fqdn.de> <15ee3c7f-0919-1a21-9b34-bd21c2c705f7@metacode.biz> Message-ID: <20181210190051.53a841ad@iria.my-fqdn.de> On Mon, 10 Dec 2018 18:34:49 +0100, Wiktor Kwapisiewicz wrote: > On 10.12.2018 17:32, Stefan Claas wrote: > > As per Werner's suggestion to make only the fingerprint available for (Web/API) searches, > > is also a thing, because like i previously said a list of fingerprints for example can still be > > This would solve some problems but not others. I think Web Key Directory (for > people controlling their domains) coupled with Autocrypt (for everyone else) > already solves a large number of use cases people need key servers. The only > real problem that keyservers are good at is storing revocations in a way that is > hard to delete. Yes, WKD and Autocrypt is a really good enhancement. > But if that is so "maybe we need just a revocation server" as someone said on > the OpenPGP Email Summit 2018 (https://wiki.gnupg.org/EmailSummit2018Notes). Thanks for the link, just started reading the content. Very good read! Best regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From wk at gnupg.org Tue Dec 11 10:48:46 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Dec 2018 10:48:46 +0100 Subject: Problem with the GnuPG - gen-key In-Reply-To: <01cb01d48e33$f42f64d0$dc8e2e70$@ecp.no> (Per Tore Johansen's message of "Fri, 7 Dec 2018 14:51:28 +0100") References: <01cb01d48e33$f42f64d0$dc8e2e70$@ecp.no> Message-ID: <87d0q8gzr5.fsf@wheatstone.g10code.de> On Fri, 7 Dec 2018 14:51, per.tore.johansen at ecp.no said: > Installed GnuPG from : gnupg-i5pase-1.4.10b.tar.Z on Power for I. OS > release V7R3 That looks like a modified version of an old GnuPG 1 version from 2009. Please do not use such an old version. The current 1.4 version 1.4.23 From this year. > login as: myuser > > myuser at 10.5.72.1's password: > > # cd /usr/local/gpg/bin > > # gpg --gen-key > > gpg: syntax error at line 1: `<' unexpected Seems you are using a non standard shell on that box or you didn't copied the entire transcript of your session. 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: 227 bytes Desc: not available URL: From fkater at posteo.net Tue Dec 11 09:28:47 2018 From: fkater at posteo.net (Felix A. Kater) Date: Tue, 11 Dec 2018 09:28:47 +0100 Subject: Chance to get --with-agent-s2k-calibration=MSEC into stable branch? Message-ID: <20181211082847.GB10304@host> Hi, in the master branch there is the commit https://dev.gnupg.org/rG926d07c5fa05de05caef3a72b6fe156606ac0549 from September 2017 for configure.ac that allows to circumvent a huge performance regression with gnupg v2 keys in some contexts. This commit is not in stable though. I am not familiar with the process how commits get selected for inclusion into the stable branch. Is there a chance that it will make it into gnupg stable anytime soon? Thanks Felix To recall: This issue applies to contexts like gnupg being called internally by postgresql where there is no agent, so the security calibration / delay of 100 MESC is applied to every single decryption call. Refer to my original posting and the explanation by Werner Koch, proposing to reduce MSEC at compile time: https://lists.gnupg.org/pipermail/gnupg-users/2018-September/060999.html From vesely at tana.it Tue Dec 11 12:35:57 2018 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 11 Dec 2018 12:35:57 +0100 Subject: Smart cards Message-ID: Hi all, I'm trying to spread use of OpenPGP among users of my tiny mail server. I'm recommending 4096-bit keys on smart card, which seems to be the safest bet for a long lasting setup. I print email addresses on the cards, and publish their keys on the web server's wkd. My problem is with smart cards readers. Floss-shop's cards are perfect for a PC, but difficult for smartphones. I'm not using smartphones, and I don't see how anything related could be considered to be secure. However, people uses them, and mounting an external device in order to read iso7816 cards sounds cumbersome given that many of them can do near field communication (NFC) natively. Is it possible to get OpenPGP functionality on one of those contactless cards? Let me add that, after several years of iso7816 cards issued by local administrations, Italian government is introducing iso14443 cards. That seems to be a common trend in Europe: https://en.wikipedia.org/wiki/National_identity_cards_in_the_European_Economic_Area#Electronic_identity_cards Is there anything I can do to foster GnuPG development on such kind of cards? Best Ale -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Dec 11 18:21:35 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Dec 2018 18:21:35 +0100 Subject: Chance to get --with-agent-s2k-calibration=MSEC into stable branch? In-Reply-To: <20181211082847.GB10304@host> (Felix A. Kater's message of "Tue, 11 Dec 2018 09:28:47 +0100") References: <20181211082847.GB10304@host> Message-ID: <87mupcf080.fsf@wheatstone.g10code.de> On Tue, 11 Dec 2018 09:28, fkater at posteo.net said: > from September 2017 for configure.ac that allows to circumvent a > huge performance regression with gnupg v2 keys in some contexts. > > This commit is not in stable though. Right. The bug was closed so we forgot about it. Thanks for the reminder. > I am not familiar with the process how commits get selected for > inclusion into the stable branch. Is there a chance that it will I pushed it to 2.2 and also added a new runtime option --s2k-calibration which allows to set the calibration time between 1ms and 60s at runtime. A SIGHUP will also trigger a re-calibration. > internally by postgresql where there is no agent, so the security > calibration / delay of 100 MESC is applied to every single > decryption call. Refer to my original posting and the explanation You should however make sure that an agent is started only once and not terminated after each operation. 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: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Tue Dec 11 19:11:03 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 11 Dec 2018 18:11:03 +0000 Subject: Smart cards In-Reply-To: References: Message-ID: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> On Tue, Dec 11, 2018 at 12:35:57PM +0100, Alessandro Vesely wrote: > Is it possible to get OpenPGP functionality on one of those > contactless cards? I know of at least one NFC-enabled OpenPGP card, the "Fidesmo Card" [1]. I never tested it, but from what I remember when I delved into their site, the OpenPGP feature of that card is provided by the same JavaCard applet than the one used in the Yubikey NEO. Which means, among other things, that it does not implement version 3 of the OpenPGP Card specification (so, no ECC keys), and does not support RSA keys larger than 2048 bits. Another provider of NFC-enabled OpenPGP cards was Sigilance [2], but they have since ceased all operations. Their cards were also based on the same JavaCard applet, with the same limitations. I am not aware of an available implementation of the OpenPGP Card v3, with support for ECC keys and RSA 4096-bit, on a NFC-enabled support. - Damien [1] http://shop.fidesmo.com/product/fidesmo-card [2] https://www.sigilance.com/ (warning: expired certificate) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From vesely at tana.it Tue Dec 11 19:51:41 2018 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 11 Dec 2018 19:51:41 +0100 Subject: Smart cards In-Reply-To: References: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> Message-ID: Thank you for your answers. On Tue 11/Dec/2018 19:27:28 +0100 Arthur Ulfeldt wrote: > using openkeychain with a yubikey nfc is totally solid, and convenient. I've > been using them for years. they also plug into the bottom of the phones which > some people prefer. I dislike yubikey because of the form factor. While USB seems convenient because every PC has lots of slots, USB keys are easily lost. In addition, you cannot print the owner name on them. Fidesmo looks better, except for its depending on the Fidesmo Card App Store. Isn't it possible to "burn" a blank card, somehow? Best Ale -- > On Tue, Dec 11, 2018, 10:14 AM Damien Goutte-Gattat via Gnupg-users > wrote: > > On Tue, Dec 11, 2018 at 12:35:57PM +0100, Alessandro Vesely wrote: > > Is it possible to get OpenPGP functionality on one of those > > contactless cards? > > I know of at least one NFC-enabled OpenPGP card, the "Fidesmo > Card" [1]. > > I never tested it, but from what I remember when I delved into > their site, the OpenPGP feature of that card is provided by the > same JavaCard applet than the one used in the Yubikey NEO. Which > means, among other things, that it does not implement version 3 of > the OpenPGP Card specification (so, no ECC keys), and does not > support RSA keys larger than 2048 bits. > > Another provider of NFC-enabled OpenPGP cards was Sigilance [2], > but they have since ceased all operations. Their cards were also > based on the same JavaCard applet, with the same limitations. > > I am not aware of an available implementation of the OpenPGP Card > v3, with support for ECC keys and RSA 4096-bit, on a NFC-enabled > support. > > > - Damien > > [1] http://shop.fidesmo.com/product/fidesmo-card > [2] https://www.sigilance.com/ (warning: expired certificate) From wiktor at metacode.biz Tue Dec 11 20:18:02 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 11 Dec 2018 20:18:02 +0100 Subject: Smart cards In-Reply-To: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> References: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> Message-ID: <458fd8d5-5e4c-d0ba-45fb-38771b4f6e1c@metacode.biz> On 11.12.2018 19:11, Damien Goutte-Gattat via Gnupg-users wrote: > On Tue, Dec 11, 2018 at 12:35:57PM +0100, Alessandro Vesely wrote: >> Is it possible to get OpenPGP functionality on one of those >> contactless cards? > > I know of at least one NFC-enabled OpenPGP card, the "Fidesmo > Card" [1]. > > I never tested it, but from what I remember when I delved into > their site, the OpenPGP feature of that card is provided by the > same JavaCard applet than the one used in the Yubikey NEO. Which > means, among other things, that it does not implement version 3 of > the OpenPGP Card specification (so, no ECC keys), and does not > support RSA keys larger than 2048 bits. I'm using Fidesmo and it works fine with OpenKeychain, and also through USB NFC reader with GnuPG. The note about keys is correct, no ECC, RSA only up to 2048 bits. There are two ways of getting 4096 bits with NFC as far as I'm aware: Yubikey 5 and Cotech Card. The latter I've never seen in real life but given that this is from the same people that created OpenKeychain I believe it's legit :) [0]: https://www.yubico.com/product/yubikey-5-nfc/ [1]: https://www.cotech.de/docs/hw-supported-hardware/ Most hardware that supports ECC either supports it only in PIV applet (so not applicable to OpenPGP) or doesn't use tamper-resistant hardware (depending on one's threat model this may or may not be OK). On 11.12.2018 19:51, Alessandro Vesely wrote: > Fidesmo looks better, except for its depending on the Fidesmo Card App Store. You don't need the store if you buy the card with OpenPGP (or PGP as they call it) applet preinstalled. This store is only needed to customize what is in the card, once PGP is installed you don't need it as Fidesmo PGP speaks standard protocol. Disclaimer: I'm not affiliated with any of these companies but I got the Fidesmo card for free for contributing to OpenKeychain [2]. [2]: https://www.openkeychain.org/pr-incentive Kind regards, Wiktor -- https://metacode.biz/@wiktor From arthur at ulfeldt.com Tue Dec 11 19:27:28 2018 From: arthur at ulfeldt.com (Arthur Ulfeldt) Date: Tue, 11 Dec 2018 10:27:28 -0800 Subject: Smart cards In-Reply-To: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> References: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> Message-ID: using openkeychain with a yubikey nfc is totally solid, and convenient. I've been using them for years. they also plug into the bottom of the phones which some people prefer. On Tue, Dec 11, 2018, 10:14 AM Damien Goutte-Gattat via Gnupg-users < gnupg-users at gnupg.org wrote: > On Tue, Dec 11, 2018 at 12:35:57PM +0100, Alessandro Vesely wrote: > > Is it possible to get OpenPGP functionality on one of those > > contactless cards? > > I know of at least one NFC-enabled OpenPGP card, the "Fidesmo > Card" [1]. > > I never tested it, but from what I remember when I delved into > their site, the OpenPGP feature of that card is provided by the > same JavaCard applet than the one used in the Yubikey NEO. Which > means, among other things, that it does not implement version 3 of > the OpenPGP Card specification (so, no ECC keys), and does not > support RSA keys larger than 2048 bits. > > Another provider of NFC-enabled OpenPGP cards was Sigilance [2], > but they have since ceased all operations. Their cards were also > based on the same JavaCard applet, with the same limitations. > > I am not aware of an available implementation of the OpenPGP Card > v3, with support for ECC keys and RSA 4096-bit, on a NFC-enabled > support. > > > - Damien > > [1] http://shop.fidesmo.com/product/fidesmo-card > [2] https://www.sigilance.com/ (warning: expired certificate) > _______________________________________________ > 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 wiktor at metacode.biz Wed Dec 12 10:15:33 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 12 Dec 2018 10:15:33 +0100 Subject: Keyserver access changes in GnuPG Message-ID: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> Hello all, I recently saw a message from one of Fedora's maintainers: > Coming soon to Fedora30 (rawhide), gnupg v1.4.x renamed to gnupg1. Also dropping keyserver support at Werner's suggestion since upstream plans to disable that soon. Source: https://infosec.exchange/@bcl/101195051788828345 Does anyone know anything about dropping keyserver support in GnuPG? That seems a little bit radical but maybe I've missed something... Thanks in advance! Kind regards, Wiktor -- https://metacode.biz/@wiktor From p at sys4.de Tue Dec 11 22:24:00 2018 From: p at sys4.de (Patrick Ben Koetter) Date: Tue, 11 Dec 2018 22:24:00 +0100 Subject: GnuPG, (neo)mutt and S/MIME Message-ID: <20181211212400.y7ztfyxyzxzb6k2g@sys4.de> Greetings, I was told GnuPG has this wonderful tool gpgsm, which helps to handle S/MIME keys/certs and also to sign and encrypt messages. Is this true or am I mixing things? I played a little with the gpgsm and was able to add my S/MIME keys/certs. Now I wonder how I would make use of them with in neomutt. Is there any other infrastructure/tool I need to setup and configure to sign and encrypt messages in mutt? TIA p at rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schlei?heimer Stra?e 26/MG,80333 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein From stefan.claas at posteo.de Wed Dec 12 12:35:43 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 12 Dec 2018 12:35:43 +0100 Subject: Keyserver access changes in GnuPG In-Reply-To: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> References: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> Message-ID: <20181212123543.10630005@iria.my-fqdn.de> On Wed, 12 Dec 2018 10:15:33 +0100, Wiktor Kwapisiewicz via Gnupg-users wrote: > Hello all, > > I recently saw a message from one of Fedora's maintainers: > > > Coming soon to Fedora30 (rawhide), gnupg v1.4.x renamed to gnupg1. Also dropping keyserver support at Werner's > > suggestion since upstream plans to disable that soon. > > Source: https://infosec.exchange/@bcl/101195051788828345 > > Does anyone know anything about dropping keyserver support in GnuPG? That seems > a little bit radical but maybe I've missed something... If so, I see it as a consequent move from past discussions on ML's and that Werner shows responsibility, while everybody else defended the old system or put their head in the sand. Bravo! Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From justina at colmena.biz Wed Dec 12 18:05:58 2018 From: justina at colmena.biz (justina colmena) Date: Wed, 12 Dec 2018 08:05:58 -0900 Subject: Keyserver access changes in GnuPG In-Reply-To: <20181212123543.10630005@iria.my-fqdn.de> References: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> <20181212123543.10630005@iria.my-fqdn.de> Message-ID: <8C91CF3D-D74F-4C99-AE1B-3F8D9A8C086C@colmena.biz> On December 12, 2018 2:35:43 AM AKST, Stefan Claas wrote: >On Wed, 12 Dec 2018 10:15:33 +0100, Wiktor Kwapisiewicz via Gnupg-users >wrote: >> Hello all, >> >> I recently saw a message from one of Fedora's maintainers: >> >> > Coming soon to Fedora30 (rawhide), gnupg v1.4.x renamed to gnupg1. >Also dropping keyserver support at Werner's >> > suggestion since upstream plans to disable that soon. >> >> Source: https://infosec.exchange/@bcl/101195051788828345 >> >> Does anyone know anything about dropping keyserver support in GnuPG? >That seems >> a little bit radical but maybe I've missed something... > >If so, I see it as a consequent move from past discussions on ML's and >that Werner shows >responsibility, while everybody else defended the old system or put >their head in the sand. > >Bravo! > >Regards >Stefan > >-- >https://www.behance.net/futagoza >https://keybase.io/stefan_claas One disadvantage of "keyservers" in general is that the automated queries to them leak "too much information" on the parties with whom one is communicating - even the fact that one is using PGP at all. One of the original goals of PGP, and later on, GnuPG, was to avoid the reliance on a central point of failure such as a "server." It was to be a most explicitly *decentralized* system. *Probably nothing wrong* with a keyserver if the key is tied to one's everyday real-life identity, but that is not always the use case of public key cryptography. Not everyone wants his or her phone number, email address, and residence address published in a database accessible to the public. The big advantage, of course, to the keyservers is that they make it convenient for people to use PGP and GnuPG who might not otherwise bother with encryption at all. In any case, I am sure that the keyserver support functionality could easily be split off into a separate program if it is being dropped from GnuPG, which to be honest is getting rather bloated and could do well to focus on its core competencies. Right now the OpenKeychain app on my phone is configured to search OpenPGP keyservers: hkps://keyserver.ubuntu.com hkps://hkps.pool.sks-keyservers.net (hkp://jirk5u4osbsr34t5.onion) hkps://pgp.mit.edu hkps://keys.fedoraproject.org (which I added because I use Fedora.) There is also a "keybase.io" and a "Web Key Directory" search. It might seem a bit much, but the general goal here is not "absolute privacy" but to enable the dumb user of a smart phone to make use of PGP encryption. This whole debate, I seem to recall, took place many, many years ago, and of course different groups have different goals and find different technical solutions for their respective situations. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From stefan.claas at posteo.de Wed Dec 12 18:52:24 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 12 Dec 2018 18:52:24 +0100 Subject: Keyserver access changes in GnuPG In-Reply-To: <8C91CF3D-D74F-4C99-AE1B-3F8D9A8C086C@colmena.biz> References: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> <20181212123543.10630005@iria.my-fqdn.de> <8C91CF3D-D74F-4C99-AE1B-3F8D9A8C086C@colmena.biz> Message-ID: <20181212185224.3189f3c5@iria.my-fqdn.de> On Wed, 12 Dec 2018 08:05:58 -0900, justina colmena via Gnupg-users wrote: > One disadvantage of "keyservers" in general is that the automated queries to them leak "too much information" on the > parties with whom one is communicating - even the fact that one is using PGP at all. This can be simply avoided by using a mixnym address and using the Usenet group alt.anonymous messages. It requires of course that people get familiar with Mixmaster, which is as old as PGP. Or simply use Bitmessage. > One of the original goals of PGP, and later on, GnuPG, was to avoid the reliance on a central point of failure such > as a "server." It was to be a most explicitly *decentralized* system. Nobody is against a decentralized system. > *Probably nothing wrong* with a keyserver if the key is tied to one's everyday real-life identity, but that is not > always the use case of public key cryptography. Not everyone wants his or her phone number, email address, and > residence address published in a database accessible to the public. And probably nobody wants that 3rd parties can upload your key with funny or not so funny signatures, or knock-out your key so that friends can't no longer download it from key servers. > The big advantage, of course, to the keyservers is that they make it convenient for people to use PGP and GnuPG who > might not otherwise bother with encryption at all. The latest user guide from EFF shows key server usage as *last* option in their document and also tells people to think about it, uploading a key to a key server. > This whole debate, I seem to recall, took place many, many years ago, and of course different groups have different > goals and find different technical solutions for their respective situations. True, but have you ever seen replies from (a) key server software developer(s) saying we are aware of all those problems and we are working on a solution? I don't refer here to the pgp.com key server, WKD, Autocrypt or keybase, i mean the widely used SKS key server network. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From nzisis at flexit.gr Wed Dec 12 13:29:55 2018 From: nzisis at flexit.gr (Nikos - FlexIT) Date: Wed, 12 Dec 2018 12:29:55 +0000 Subject: Setup encrypted email Message-ID: Hello Can I setup encrypted emails completely free with gpg? I am using Microsoft outlook 2016. Can you please inform me how I can do it? ?? ???????? ????????????/ Best Regards, ????? ????? System Administrator [1] FlexIT Information Technology Outsourcing PC [2] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2976 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11621 bytes Desc: image002.png URL: From arthur at ulfeldt.com Wed Dec 12 21:01:39 2018 From: arthur at ulfeldt.com (Arthur Ulfeldt) Date: Wed, 12 Dec 2018 12:01:39 -0800 Subject: Setup encrypted email In-Reply-To: References: Message-ID: Yes! All the encryption happens on your computer (and or your phone) and you have complete control of the process. The flip side of this is you are responsible for the whole process. There are *many* ways to go about this for different people in different situations. Here is just one option. * make yourself a key using gpg * put that key on the devices you want to use (I use a yubikey for this, and that costs $ which is totally optional) * setup your email, gpg4win is one popular option: https://www.gpg4win.org/about.html * set it up on your phone. openkeychain is popular on android and has been solid for me for years. * setup facebook to send you encrypted notifications (optional and purely for fun) * get comfortable with this process for a while then explore more complex and or customized options. On Wed, Dec 12, 2018 at 11:24 AM Nikos - FlexIT wrote: > Hello > > > > Can I setup encrypted emails completely free with gpg? I am using > Microsoft outlook 2016. > > Can you please inform me how I can do it? > > > > ?? ???????? ????????????/ Best Regards, > > > > ????? ????? > > *System Administrator* > > [image: 1] > > *FlexIT Information Technology Outsourcing PC* > > [image: 2] > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11621 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11621 bytes Desc: not available URL: From stefan.claas at posteo.de Wed Dec 12 21:04:10 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 12 Dec 2018 21:04:10 +0100 Subject: GnuPG, (neo)mutt and S/MIME In-Reply-To: <20181211212400.y7ztfyxyzxzb6k2g@sys4.de> References: <20181211212400.y7ztfyxyzxzb6k2g@sys4.de> Message-ID: <20181212210410.014b4661@iria.my-fqdn.de> On Tue, 11 Dec 2018 22:24:00 +0100, Patrick Ben Koetter wrote: Hi Patrick, > I was told GnuPG has this wonderful tool gpgsm, which helps to handle S/MIME > keys/certs and also to sign and encrypt messages. Is this true or am I mixing > things? Yes, that is true. However, if i remember correctly gpgsm by itself does not produce a message body format for an an email which looks like those created from other S/MIME capable email clients. > I played a little with the gpgsm and was able to add my S/MIME keys/certs. Now > I wonder how I would make use of them with in neomutt. > > Is there any other infrastructure/tool I need to setup and configure to sign > and encrypt messages in mutt? While i also played with S/MIME and PGP setup's in Mutt long time ago, i am using now for regular S/MIME email communications Thunderbird. I also remember vaguely that for those (Neo)Mutt S/MIME set-up gpgsm was not required. I would suggest that you simply google for "Mutt S/MIME" to see a lot of tutorials on how to do that. Once you have a correct neomutt set-up you can send me an S/MIME signed email so that we can see if your set-up works properly. I have a D-Trust certificate. The D-Trust root certificates should be already installed in most systems. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From wiktor at metacode.biz Wed Dec 12 22:25:04 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 12 Dec 2018 22:25:04 +0100 Subject: Setup encrypted email In-Reply-To: References: Message-ID: <67ed304b-2fe6-5cad-5e30-4f85c86a0513@metacode.biz> On 12.12.2018 13:29, Nikos - FlexIT wrote: > Hello > > ? > > Can I setup encrypted emails completely free with gpg? I am using Microsoft > outlook 2016. > > Can you please inform me how I can do it? Hi Nicos, Check out Gpg4Win and one of its components: GpgOL - an add-in for Outlook: https://www.gpg4win.org/screenshots.html Kind regards, Wiktor -- https://metacode.biz/@wiktor From email at andrewnesbit.org Wed Dec 12 22:35:32 2018 From: email at andrewnesbit.org (Andrew Luke Nesbit) Date: Wed, 12 Dec 2018 21:35:32 +0000 Subject: Keyserver access changes in GnuPG In-Reply-To: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> References: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> Message-ID: <2a03dc2f-ec57-dfda-61f6-88367b9ca957@andrewnesbit.org> On 12/12/2018 09:15, Wiktor Kwapisiewicz via Gnupg-users wrote: >> Coming soon to Fedora30 (rawhide), gnupg v1.4.x renamed to gnupg1. Also dropping keyserver support at Werner's suggestion since upstream plans to disable that soon. > > Source: https://infosec.exchange/@bcl/101195051788828345 > > Does anyone know anything about dropping keyserver support in GnuPG? That seems > a little bit radical but maybe I've missed something... I feel that I've missed a memo too. I've never liked public keyservers either. Or, rather, the way they are normally used. I especially dislike how beginners' tutorials encourage their users to upload just-made keys to public keyservers before they (the users) have even learned how to use GPG with any degree of fluency... or even confirmed that their new keys are appropriately made or configured. Can somebody please point me to a more authoritative source of this keyserver news? Did Werner himself write anything about this? If it's true, then I welcome it too. On a highly related topic... My subkeys expired on Monday, 10/12/2018. I've updated my subkeys with a new expiration date (in one year). I'm considering NOT uploading the new public keys to the keyservers. Rather, I will distribute them using other channels, such as downloading from my personal website or sneakernet. Should I issue and publish a revocation certificate? Will this cause problems considering that I'm still using the same master key? Kind regards, Andrew -- EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wiktor at metacode.biz Wed Dec 12 22:43:49 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 12 Dec 2018 22:43:49 +0100 Subject: Keyserver access changes in GnuPG In-Reply-To: <2a03dc2f-ec57-dfda-61f6-88367b9ca957@andrewnesbit.org> References: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> <2a03dc2f-ec57-dfda-61f6-88367b9ca957@andrewnesbit.org> Message-ID: On 12.12.2018 22:35, Andrew Luke Nesbit wrote: > My subkeys expired on Monday, 10/12/2018. I've updated my subkeys with > a new expiration date (in one year). I'm considering NOT uploading the > new public keys to the keyservers. Rather, I will distribute them using > other channels, such as downloading from my personal website or sneakernet. > > Should I issue and publish a revocation certificate? Will this cause > problems considering that I'm still using the same master key? I don't think revocation is necessary if the private subkeys are still safe. It may be just inconvenient for people that want to contact you / verify your signatures to see your subkeys expired and when they "gpg --refresh-keys" (as they always do) your key would still be expired with no apparent way of proceeding. If I saw something like that I'd think the key is abandoned. If you had HTTPS on your site I'd recommend Web Key Directory as this downloads keys from your site *and* refreshes expired keys from your site too automatically. Kind regards, Wiktor -- https://metacode.biz/@wiktor From email at andrewnesbit.org Wed Dec 12 23:08:27 2018 From: email at andrewnesbit.org (Andrew Luke Nesbit) Date: Wed, 12 Dec 2018 22:08:27 +0000 Subject: Keyserver access changes in GnuPG In-Reply-To: References: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> <2a03dc2f-ec57-dfda-61f6-88367b9ca957@andrewnesbit.org> Message-ID: <97502e0b-d9c3-4374-963a-906c5e87d77d@andrewnesbit.org> On 12/12/2018 21:43, Wiktor Kwapisiewicz wrote: >> Should I issue and publish a revocation certificate? Will this cause >> problems considering that I'm still using the same master key? > > I don't think revocation is necessary if the private subkeys are still safe. Yes, they are still safe. On thinking about it, issuing a revocation certificate could be overkill. It might even cause more confusion than it is meant to solve. > It may be just inconvenient for people that want to contact you / verify your > signatures to see your subkeys expired and when they "gpg --refresh-keys" (as > they always do) your key would still be expired with no apparent way of > proceeding. If I saw something like that I'd think the key is abandoned. Indeed, so would I. But then there's also a pretty good chance that the same person might write to me and ask, "Hey, what's up with your OpenPGP keys?" Then I could explain and point them to the right place. Or, by then, my website or my email signature might have enough information to point them in the right direction before it even becomes an issue. > If you had HTTPS on your site I'd recommend Web Key Directory as this downloads > keys from your site *and* refreshes expired keys from your site too automatically. I am coincidentally currently in the process of provisioning an Apache server with HTTPS/443 enabled. Not even HTTP/80 will be open, so HTTP to HTTPS redirection won't be implemented either. I've looked up Web Key Directory and had a quick browse, and this is exactly the kind of thing I need. Thank you!! Kind regards, Andrew -- EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tmz at pobox.com Thu Dec 13 00:00:18 2018 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 12 Dec 2018 18:00:18 -0500 Subject: Keyserver access changes in GnuPG In-Reply-To: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> References: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> Message-ID: <20181212230018.GK14069@zaya.teonanacatl.net> Wiktor Kwapisiewicz via Gnupg-users wrote: > Hello all, > > I recently saw a message from one of Fedora's maintainers: > >> Coming soon to Fedora30 (rawhide), gnupg v1.4.x renamed to gnupg1. Also dropping keyserver support at Werner's suggestion since upstream plans to disable that soon. > > Source: https://infosec.exchange/@bcl/101195051788828345 > > Does anyone know anything about dropping keyserver support in GnuPG? That seems > a little bit radical but maybe I've missed something... This only applies to the gnupg-1.4.x packages in Fedora. Fedora 30 will ship with gnupg-2.x as /usr/bin/gpg (with keyserver support intact). The packages from the 1.4.x branch will be installed as /usr/bin/gpg1 for users who want to keep using it. Dropping the keyserver and photoviewer helpers is part of the next planned release from the 1.4.x branch, which is being tracked in https://dev.gnupg.org/T3443. Hopefully that helps clarify things a bit and removes any worries that Fedora is stripping keyserver support from the default /usr/bin/gpg. -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You know an odd feeling? Sitting on the toilet eating a chocolate candy bar. -- George Carlin, Napalm & Silly Putty -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From justina at colmena.biz Thu Dec 13 02:14:18 2018 From: justina at colmena.biz (justina colmena) Date: Wed, 12 Dec 2018 16:14:18 -0900 Subject: Keyserver access changes in GnuPG In-Reply-To: <20181212230018.GK14069@zaya.teonanacatl.net> References: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> <20181212230018.GK14069@zaya.teonanacatl.net> Message-ID: <7E4BD9CC-7A56-4B13-95D5-1BB6553CF1BE@colmena.biz> On December 12, 2018 2:00:18 PM AKST, Todd Zullinger wrote: > > the keyserver and photoviewer helpers > A permanent record and a mug shot for the cops and every thief, hooker, and pickpocket on the block, respectively. And they all just help themselves to the secret key. Someone puts out a little bit of money for secret keys and passphrases, they know your real name and where you live, and it just all goes to hell in a handbasket. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 13 07:44:27 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Dec 2018 07:44:27 +0100 Subject: GnuPG, (neo)mutt and S/MIME In-Reply-To: <20181211212400.y7ztfyxyzxzb6k2g@sys4.de> (Patrick Ben Koetter's message of "Tue, 11 Dec 2018 22:24:00 +0100") References: <20181211212400.y7ztfyxyzxzb6k2g@sys4.de> Message-ID: <87mupahqno.fsf@wheatstone.g10code.de> On Tue, 11 Dec 2018 22:24, p at sys4.de said: > Is there any other infrastructure/tool I need to setup and configure to sign > and encrypt messages in mutt? set crypt_use_gpgme and then use the S/MIME options in Mutt's menu: hit 'p', 'b' and 'm' to encrypt and sign with S/MIME. ('m' switches to S/MIME mode). 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: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 13 07:50:53 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Dec 2018 07:50:53 +0100 Subject: Keyserver access changes in GnuPG In-Reply-To: <20181212230018.GK14069@zaya.teonanacatl.net> (Todd Zullinger's message of "Wed, 12 Dec 2018 18:00:18 -0500") References: <57348246-57c7-668d-baba-58de5f968035@metacode.biz> <20181212230018.GK14069@zaya.teonanacatl.net> Message-ID: <87ftv1j4xe.fsf@wheatstone.g10code.de> On Thu, 13 Dec 2018 00:00, tmz at pobox.com said: > /usr/bin/gpg1 for users who want to keep using it. Dropping > the keyserver and photoviewer helpers is part of the next > planned release from the 1.4.x branch, which is being > tracked in https://dev.gnupg.org/T3443. Right. Given that gpg1 is a fallback solution to work with archived encrypted mails it does not make much sense to keep on maintain the keyserver helpers and extras like photo id viewers. 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: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 13 08:13:58 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Dec 2018 08:13:58 +0100 Subject: Smart cards In-Reply-To: (Arthur Ulfeldt's message of "Tue, 11 Dec 2018 10:27:28 -0800") References: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> Message-ID: <878t0tj3ux.fsf@wheatstone.g10code.de> On Tue, 11 Dec 2018 19:27, arthur at ulfeldt.com said: > using openkeychain with a yubikey nfc is totally solid, and convenient. > I've been using them for years. they also plug into the bottom of the > phones which some people prefer. You should keep in mind that you can eavesdrop on NFC communication within several meters. Right, it is required that the card is niot more than about 10cm away from the reader but that is only to convey the power to the card, the HF is readable from several meters as soon as the card is powered up. If you care about side channel attacks, NFC communication is a bad idea because the decrypted session key can easily be picked up. To avoid this, /secure communication/ needs to be used but that is cumbersome because this requires a shared secret between host and card. But well, smartphones are not a safe device anyway. 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: 227 bytes Desc: not available URL: From justina at colmena.biz Thu Dec 13 09:36:21 2018 From: justina at colmena.biz (justina colmena) Date: Wed, 12 Dec 2018 23:36:21 -0900 Subject: Smart cards In-Reply-To: <878t0tj3ux.fsf@wheatstone.g10code.de> References: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> <878t0tj3ux.fsf@wheatstone.g10code.de> Message-ID: On December 12, 2018 10:13:58 PM AKST, Werner Koch wrote: >On Tue, 11 Dec 2018 19:27, arthur at ulfeldt.com said: >> using openkeychain with a yubikey nfc is totally solid, and >convenient. >> I've been using them for years. they also plug into the bottom of the >> phones which some people prefer. > >You should keep in mind that you can eavesdrop on NFC communication >within several meters. Right, it is required that the card is niot >more >than about 10cm away from the reader but that is only to convey the >power to the card, the HF is readable from several meters as soon as >the >card is powered up. > >If you care about side channel attacks, NFC communication is a bad idea >because the decrypted session key can easily be picked up. To avoid >this, /secure communication/ needs to be used but that is cumbersome >because this requires a shared secret between host and card. But well, >smartphones are not a safe device anyway. > > >Shalom-Salam, > > Werner I agree that smartphones are not safe, but I am not particularly in favor of smartcards, dongles, and security tokens like yubikeys, either. Any kind of special-purpose cryptographic *hardware* is essentially proprietary, and too attractive and soft a target for various nations' spy agencies to covertly backdoor. "Don't look at me! I've got something to hide, and nowhere to protect it!" There's a secure phone on the President's desk, and not even the Secret Service can say it's all that "secure." Open-source cryptographic software that runs on general purpose computer hardware is generally much more difficult to backdoor. If you plug some little doohickey or thingamagig into your computer to do *crypto*, of all things, your computer is liable to become infected with spyware over the USB bus via BadUSB and various firmware- and device-related security vulnerabilities. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc From johndoe65534 at mail.com Thu Dec 13 09:40:08 2018 From: johndoe65534 at mail.com (john doe) Date: Thu, 13 Dec 2018 09:40:08 +0100 Subject: Setup encrypted email In-Reply-To: References: Message-ID: <7967bf96-c880-884b-5220-8c08c80d2335@mail.com> On 12/12/2018 9:01 PM, Arthur Ulfeldt wrote: > Yes! All the encryption happens on your computer (and or your phone) and > you have complete control of the process. True for the computer, by nature phone are not secure. > The flip side of this is you are responsible for the whole process. There > are *many* ways to go about this for different > people in different situations. Here is just one option. > > * make yourself a key using gpg > * put that key on the devices you want to use (I use a yubikey for this, > and that costs $ which is totally optional) > * setup your email, gpg4win is one popular option: > https://www.gpg4win.org/about.html Thunderbird with enigmail. Obviously, the recipient would need to use gpg to be able to decrypt. > * set it up on your phone. openkeychain is popular on android and has been > solid for me for years. I recommend to sign only e-mails using your phone. That is one signing key per device and one encryption key on a computer. > * setup facebook to send you encrypted notifications (optional and purely > for fun) Yes, Facebook rings more with security breach. > * get comfortable with this process for a while then explore more complex > and or customized options. > TB and enigmail are a good place to start on Windows or Linux for that matter. -- John Doe From andreas.schwier.ml at cardcontact.de Thu Dec 13 10:48:52 2018 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Thu, 13 Dec 2018 10:48:52 +0100 Subject: Smart cards In-Reply-To: References: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> <878t0tj3ux.fsf@wheatstone.g10code.de> Message-ID: > I agree that smartphones are not safe, but I am not particularly in favor of smartcards, dongles, and security tokens like yubikeys, either. > > Any kind of special-purpose cryptographic *hardware* is essentially proprietary, and too attractive and soft a target for various nations' spy agencies to covertly backdoor. "Don't look at me! I've got something to hide, and nowhere to protect it!" So you really believe that international payment organizations or mobile network operators worldwide or border control authorities rely their risk management on a piece of hardware from well known chip manufacturer that could easily be subverted by a national security agency ? I you believe that, then an Intel Management Engine, a ARM Trust Zone or the baseband processor in mobile phone isn't anything better. Then it doesn't help if your software is open source, because your keys are "open source" as well. I've been working in the smart card industry for over 30 years now and the tale of subverted smart card chips has been around for ages. It's one of the often told myths - but there hasn't been any evidence that this has already happened. Yes, this technology is far from being perfect and so are people implementing code of those devices. We've seen a number of security flaws in smart card systems, that is unfortunately true. Still, I would rely on a smart card well designed for the purpose of keeping things secret. > > There's a secure phone on the President's desk, and not even the Secret Service can say it's all that "secure." Fact or fiction ? > > Open-source cryptographic software that runs on general purpose computer hardware is generally much more difficult to backdoor. And why ? > > If you plug some little doohickey or thingamagig into your computer to do *crypto*, of all things, your computer is liable to become infected with spyware over the USB bus via BadUSB and various firmware- and device-related security vulnerabilities. But that has nothing to do with smart cards. > I believe you are working for one of those nations' spy agencies and are unable to break in. So you want us to believe that those devices can be broken. so we leave our keys unprotected. Sounds absurd ? Andreas -- --------- 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 andreas.schwier.ml at cardcontact.de Thu Dec 13 11:31:55 2018 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Thu, 13 Dec 2018 11:31:55 +0100 Subject: Smart cards In-Reply-To: <878t0tj3ux.fsf@wheatstone.g10code.de> References: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> <878t0tj3ux.fsf@wheatstone.g10code.de> Message-ID: <4209e3cc-f926-c755-67a4-4bf3d52d2dd1@cardcontact.de> On 13.12.2018 08:13, Werner Koch wrote: > If you care about side channel attacks, NFC communication is a bad idea > because the decrypted session key can easily be picked up. To avoid > this, /secure communication/ needs to be used but that is cumbersome > because this requires a shared secret between host and card. Shared secret or asymmetric authentication with secure messaging like Chip Authentication from BSI TR-03110. That also helps to transmit the PIN securely. From email at andrewnesbit.org Thu Dec 13 16:34:34 2018 From: email at andrewnesbit.org (Andrew Luke Nesbit) Date: Thu, 13 Dec 2018 15:34:34 +0000 Subject: Smart cards In-Reply-To: References: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> Message-ID: <7da272b0-068b-e70e-1c30-cc38ca99368f@andrewnesbit.org> Hey Arthur, what makes you think that Yubikey is trustworthy? Is it because you have assessed your threat model and you disbelieve that any potential attacks via Yubikey would be not used against you? Or have you done an independent audit of the Yubikey and satisfied yourself that it's safe enough for your reasons? Or is it a bit of both? Or is it something completely different? I'd love something as convenient as Yubikey but given how strictly I've set up my workflow; and given that I want to make a habit best practices wherever possible; I cannot use it because it will introduce a weak link. I saw a few different devices that look auditable and like I might be able to trust them more. I'll find them in my notes and make a post later. On 11/12/2018 18:27, Arthur Ulfeldt wrote: > using openkeychain with a yubikey nfc is totally solid, and convenient. > I've been using them for years. they also plug into the bottom of the > phones which some people prefer.? > > On Tue, Dec 11, 2018, 10:14 AM Damien Goutte-Gattat via Gnupg-users > wrote: > > On Tue, Dec 11, 2018 at 12:35:57PM +0100, Alessandro Vesely wrote: > > Is it possible to get OpenPGP functionality on one of those > > contactless cards? > > I know of at least one NFC-enabled OpenPGP card, the "Fidesmo > Card" [1]. > > I never tested it, but from what I remember when I delved into > their site, the OpenPGP feature of that card is provided by the > same JavaCard applet than the one used in the Yubikey NEO. Which > means, among other things, that it does not implement version 3 of > the OpenPGP Card specification (so, no ECC keys), and does not > support RSA keys larger than 2048 bits. > > Another provider of NFC-enabled OpenPGP cards was Sigilance [2], > but they have since ceased all operations. Their cards were also > based on the same JavaCard applet, with the same limitations. > > I am not aware of an available implementation of the OpenPGP Card > v3, with support for ECC keys and RSA 4096-bit, on a NFC-enabled > support. > > > - Damien > > [1] http://shop.fidesmo.com/product/fidesmo-card > [2] https://www.sigilance.com/ (warning: expired certificate) > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From justina at colmena.biz Thu Dec 13 23:40:56 2018 From: justina at colmena.biz (justina colmena) Date: Thu, 13 Dec 2018 13:40:56 -0900 Subject: Importing keys into GnuPG 2.2 series Message-ID: <26A09052-E870-4547-B70B-8E19C0219645@colmena.biz> This e-mail is signed with a key generated by OpenKeychain on a smartphone. I am able to verify the signatures on other signed e-mails I get on this mailing list, with the exception of the footer added by the mailing list software. I was able to back up the key, import it into GnuPG 1.4.23 and sign some old papers which I had sitting around, with the same key, which ironically is now newer than any of the papers. I have made both attached and detached signatures. https://www.colmena.biz/~justina/bor/bor.pdf https://www.colmena.biz/~justina/bor/bor.pdf.gpg https://www.colmena.biz/~justina/bor/bor.pdf.sig https://www.colmena.biz/~justina/doi/doi.pdf https://www.colmena.biz/~justina/doi/doi.pdf.gpg https://www.colmena.biz/~justina/doi/doi.pdf.sig https://www.colmena.biz/~justina/pnp/pnp.pdf https://www.colmena.biz/~justina/pnp/pnp.pdf.gpg https://www.colmena.biz/~justina/pnp/pnp.pdf.sig https://www.colmena.biz/~justina/Rab/Rab.pdf https://www.colmena.biz/~justina/Rab/Rab.pdf.gpg https://www.colmena.biz/~justina/Rab/Rab.pdf.sig OpenKeychain on my smartphone is able to verify the attached signatures .gpg, but not the detached .sig files. For some reason I cannot get GnuPG 2.2.11 to recognize the passphrase for the secret key, which I am only able to set, use, or change in GnuPG 1.4.23. MAIN QUESTION: Is this a pinentry-curses problem with the tty over ssh, or is it an actual key incompatibility issue? If for some reason the key is not actually compatible with GnuPG 2, then shouldn't I just generate a new key in GnuPG 2, and then sign it with my old key in GnuPG 1 and also import it back into the OpenKeychain app if I want to use it on my phone? Thank you. There is quite a discussion going on about other matters, and I am not sure I asked the right question for what I wanted to know. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/justina.colmena.asc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From angel at pgp.16bits.net Fri Dec 14 00:22:02 2018 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 14 Dec 2018 00:22:02 +0100 Subject: Importing keys into GnuPG 2.2 series In-Reply-To: <26A09052-E870-4547-B70B-8E19C0219645@colmena.biz> References: <26A09052-E870-4547-B70B-8E19C0219645@colmena.biz> Message-ID: <1544743322.993.2.camel@16bits.net> On 2018-12-13 at 13:40 -0900, justina colmena via Gnupg-users wrote: > MAIN QUESTION: Is this a pinentry-curses problem with the tty over > ssh, or is it an actual key incompatibility issue? Looks like a pinentry issue. I guess you are using some non-alphanumerical characters in the passphrase? My guess would be that they are getting "lost". I would start questioning the encoding of your input on that terminal, but as you mention that you are using pinentry-curses over ssh, can you even type the through ssh? I have seen ssh connections where characters like ? got dropped when some package/env variable wasn't set in the remote server. Best regards From dkg at fifthhorseman.net Fri Dec 14 00:28:38 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Dec 2018 18:28:38 -0500 Subject: Importing keys into GnuPG 2.2 series In-Reply-To: <26A09052-E870-4547-B70B-8E19C0219645@colmena.biz> References: <26A09052-E870-4547-B70B-8E19C0219645@colmena.biz> Message-ID: <87ftv12ehl.fsf@fifthhorseman.net> I'm confused by this e-mail, hopefully the notes and questions below can start to un-confuse it a bit. On Thu 2018-12-13 13:40:56 -0900, justina colmena via Gnupg-users wrote: > OpenKeychain on my smartphone is able to verify the attached > signatures .gpg, but not the detached .sig files. This appears to be a question about OpenKeychain verifying signatures, which has nothing to do with passphrases. it might be better asked in an OpenKeychain forum, as i don't know what user interface OpenKeychain expects for dealing with detached signatures. > For some reason I cannot get GnuPG 2.2.11 to recognize the passphrase > for the secret key, which I am only able to set, use, or change in > GnuPG 1.4.23. GnuPG 1.4.23 and 2.2.11 do not really interoperate well, when sharing the same homedir. I recommend that you choose one and stick with it. 2.2.11 is the better choice. > MAIN QUESTION: Is this a pinentry-curses problem with the tty over > ssh, or is it an actual key incompatibility issue? you haven't described what action you're doing that makes you think that you need a passphrase in the first place, or how you are connected to your computer in such a way that "tty over ssh" is a meaningful question. please show more of what you're doing! > If for some reason the key is not actually compatible with GnuPG 2, > then shouldn't I just generate a new key in GnuPG 2, and then sign it > with my old key in GnuPG 1 and also import it back into the > OpenKeychain app if I want to use it on my phone? this sounds like a very complicated route to take, and it results in you having multiple outstanding keys, which is likely to confuse some of the people you communicate with. i'd try to keep it simpler if possible. regards, --dkg From vesely at tana.it Fri Dec 14 12:41:51 2018 From: vesely at tana.it (Alessandro Vesely) Date: Fri, 14 Dec 2018 12:41:51 +0100 Subject: Smart cards In-Reply-To: References: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> <878t0tj3ux.fsf@wheatstone.g10code.de> Message-ID: On Thu 13/Dec/2018 10:48:52 +0100 Andreas Schwier wrote: > >> I agree that smartphones are not safe, but I am not particularly in favor of smartcards, dongles, and security tokens like yubikeys, either. >> >> Any kind of special-purpose cryptographic *hardware* is essentially proprietary, and too attractive and soft a target for various nations' spy agencies to covertly backdoor. "Don't look at me! I've got something to hide, and nowhere to protect it!" > > So you really believe that international payment organizations or mobile > network operators worldwide or border control authorities rely their > risk management on a piece of hardware from well known chip manufacturer > that could easily be subverted by a national security agency ? Let me just note that there are people who believe it so hardly as to arrest Meng Wanzhou. > I you believe that, then an Intel Management Engine, a ARM Trust Zone or > the baseband processor in mobile phone isn't anything better. Then it > doesn't help if your software is open source, because your keys are > "open source" as well. You mean the backdoors in NIST elliptic curves? > I've been working in the smart card industry for over 30 years now and > the tale of subverted smart card chips has been around for ages. It's > one of the often told myths - but there hasn't been any evidence that > this has already happened. Yet, alas, the software on OpenPGP cards "is not available as free software due to NDAs required for certain parts", according to g10code[*]. [*] http://www.g10code.com/p-card.html > Yes, this technology is far from being perfect and so are people > implementing code of those devices. We've seen a number of security > flaws in smart card systems, that is unfortunately true. Still, I would > rely on a smart card well designed for the purpose of keeping things secret. Of course, one has to adjust the local paranoia level to some practical value. >> There's a secure phone on the President's desk, and not even the Secret Service can say it's all that "secure." > Fact or fiction ? We miss a theoretical definition of "secure". However, there are lots of funny anecdotes about President's smartphone. >> Open-source cryptographic software that runs on general purpose computer hardware is generally much more difficult to backdoor. > And why ? Free software is patched and upgraded much more often than proprietary one. That increases difficulty considerably, methinks. Best Ale From robert at ephemeric.online Fri Dec 14 12:26:34 2018 From: robert at ephemeric.online (Robert Gabriel) Date: Fri, 14 Dec 2018 13:26:34 +0200 Subject: Private Keys on Card Not Loaded Message-ID: <20181214112634.GB11850@mail.ephemeric.local> Hi, I have created a master key along with a subkey for authenticating and a subkey for signing. I copied the subkeys to my smartcard (Nitrokey Pro 2) using gpg2 --edit-key 93DA8C1D and did not enter save thereafter, but deleted them manually using gpg2 --card-edit. I deleted the master private key. gpg2 -k 93DA8C1D pub rsa4096/93DA8C1D 2018-07-23 [SC] [expires: 2028-07-20] uid [ultimate] Robert Gabriel (Mitigate) uid [ultimate] Robert Gabriel (SLOB) uid [ultimate] Robert Gabriel (Net) uid [ultimate] Robert Gabriel (GSOC) sub rsa4096/1314AB17 2018-07-23 [E] [expires: 2028-07-20] sub rsa4096/DB545B92 2018-07-23 [S] [expires: 2028-07-20] gpg2 --card-status Reader ...........: 20A0:4108:000000000000000000006F45:0 Application ID ...: D276000124010303000500006F450000 Version ..........: 3.3 Manufacturer .....: ZeitControl Serial number ....: 00006F45 Name of cardholder: Robert Gabriel Language prefs ...: en Sex ..............: male URL of public key : [not set] Login data .......: robert Signature PIN ....: not forced Key attributes ...: rsa4096 rsa4096 rsa4096 Max. PIN lengths .: 64 64 64 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: C78B 8DEA 8BFC A3F8 FE02 01B2 25BB 65A3 DB54 5B92 created ....: 2018-07-23 15:05:07 Encryption key....: 96D3 A550 23CD 70C6 B299 9D8A DC14 1A1E 1314 AB17 created ....: 2018-07-23 14:43:10 Authentication key: B903 8DB5 0E48 9465 172F 45D2 7E9B 41FE 36CF 0D3F created ....: 2018-11-27 18:08:06 General key info..: sub rsa4096/DB545B92 2018-07-23 Robert Gabriel (Mitigate) sec rsa4096/93DA8C1D created: 2018-07-23 expires: 2028-07-20 ssb rsa4096/1314AB17 created: 2018-07-23 expires: 2028-07-20 ssb rsa4096/DB545B92 created: 2018-07-23 expires: 2028-07-20 gpg2 -K no private keys are visible. What have I missed? I read online the stubs are generated automatically with the above command. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From wk at gnupg.org Fri Dec 14 16:00:14 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 14 Dec 2018 16:00:14 +0100 Subject: [Announce] GnuPG 2.2.12 released Message-ID: <8736r0dugx.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.12. This is a maintenance release; see below for a list of fixed bugs. 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. As an universal crypto engine 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. Noteworthy changes in version 2.2.12 ==================================== * tools: New commands --install-key and --remove-key for gpg-wks-client. This allows to prepare a Web Key Directory on a local file system for later upload to a web server. * gpg: New --list-option "show-only-fpr-mbox". This makes the use of the new gpg-wks-client --install-key command easier on Windows. * gpg: Improve processing speed when --skip-verify is used. * gpg: Fix a bug where a LF was accidentally written to the console. * gpg: --card-status now shwos whether a card has the new KDF feature enabled. * agent: New runtime option --s2k-calibration=MSEC. New configure option --with-agent-s2k-calibration=MSEC. [https://dev.gnupg.org/T3399] * dirmngr: Try another keyserver from the pool on receiving a 502, 503, or 504 error. [https://dev.gnupg.org/T4175] * dirmngr: Avoid possible CSRF attacks via http redirects. A HTTP query will not anymore follow a 3xx redirect unless the Location header gives the same host. If the host is different only the host and port is taken from the Location header and the original path and query parts are kept. * dirmngr: New command FLUSHCRL to flush all CRLS from disk and memory. [https://dev.gnupg.org/T3967] * New simplified Chinese translation (zh_CN). Release-info: https://dev.gnupg.org/T4289 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.12 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: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.12.tar.bz2 (6525k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.12.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.12_20181214.exe (3965k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.12_20181214.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. 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.2.12.tar.bz2 you would use this command: gpg --verify gnupg-2.2.12.tar.bz2.sig gnupg-2.2.12.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.2.12.tar.bz2, you run the command like this: sha1sum gnupg-2.2.12.tar.bz2 and check that the output matches the next line: 2aeccc35ea8034306ff7a1072b84abbaa79619c3 gnupg-2.2.12.tar.bz2 304785d6db3d490265f8638ec3fb7340050b58bd gnupg-w32-2.2.12_20181214.tar.xz 8efed66ebfe68bae3069f7d1724c8b4b9de0b00b gnupg-w32-2.2.12_20181214.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= 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 reference manual of the system. Separate man pages are included as well but they miss some of the details availabale only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF 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 to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. In case of build problems specific to this release please first check https://dev.gnupg.org/T4289 for updated information. 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. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and two contractors. All work exclusively on GnuPG and closely related software like Libgcrypt and GPGME. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers 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: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 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 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 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 jack at vpngeeks.com Fri Dec 14 13:31:30 2018 From: jack at vpngeeks.com (Jack Foster) Date: Fri, 14 Dec 2018 12:31:30 +0000 (UTC) Subject: Blog Post Question Message-ID: <57284284.2334228.1544790690856@ip-10-1-0-82.ec2.internal> Hey there, My name is Jack and I saw this post of yours:?https://lists.gt.net/gnupg/users/69568 (password security is so important).? In fact, it inspired me to create a more in-depth?version (14 ways to create a secure password!).? https://www.vpngeeks.com/how-to-secure-your-passwords ( https://www.vpngeeks.com/how-to-secure-your-passwords ) It would be great if you could mention it within your post.? I'll even post it across our social channels! Kind Regards, Jack Click here ( http://unsubscribe.bz-mail-us1.com/unsubscribe?e=gnupg-users%40gnupg.org&i=57284284.2334228.1544790690856%40ip-10-1-0-82&u=55993&g=31896 ) if you don't want to receive?any further emails from me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phoenyx33 at gmail.com Fri Dec 14 16:41:42 2018 From: phoenyx33 at gmail.com (Kenneth Benson) Date: Fri, 14 Dec 2018 10:41:42 -0500 Subject: Gnupg-devel Digest, Vol 183, Issue 5 In-Reply-To: References: Message-ID: I was wondering if the pdf is going to be updated anytime soon? It's title page still says it's for version 2.2.7? Also availabale should be available. On 12/14/2018 10:14 AM, gnupg-devel-request at gnupg.org wrote: > Subject: > [Announce] GnuPG 2.2.12 released > From: > Werner Koch > Date: > 12/14/2018, 10:00 AM > > To: > gnupg-announce at gnupg.org, info-gnu at gnu.org > > > Hello! > > We are pleased to announce the availability of a new GnuPG release: > version 2.2.12. This is a maintenance release; see below for a list > of fixed bugs. > > > 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. As an universal crypto > engine 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. > > > > > Documentation and Support > ========================= > > 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 reference manual of the system. > Separate man pages are included as well but they miss some of the > details available only in thee manual. The manual is also available > online at > > https://gnupg.org/documentation/manuals/gnupg/ > > or can be downloaded as PDF at > //////////////////////////////// > https://gnupg.org/documentation/manuals/gnupg.pdf . \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > 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: > > rsa2048 2011-01-12 [expires: 2019-12-31] > Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 > Werner Koch (dist sig) > > rsa2048 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 2014-10-29 [expires: 2020-10-30] > Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 > NIIBE Yutaka (GnuPG Release Key) > > rsa3072 2017-03-17 [expires: 2027-03-15] > Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 > Andre Heinecke (Release Signing Key) > > The keys are availabale at and > in any recently released GnuPG tarball in the file g10/distsigkey.gpg . > Note that this mail has been signed by a different key. > > -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-announce mailing list > Gnupg-announce at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-announce > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From dirk.gottschalk1980 at googlemail.com Sat Dec 15 00:12:09 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sat, 15 Dec 2018 00:12:09 +0100 Subject: Private Keys on Card Not Loaded In-Reply-To: <20181214112634.GB11850@mail.ephemeric.local> References: <20181214112634.GB11850@mail.ephemeric.local> Message-ID: <3b4b78d93208c5deab70640ad7ee0fb6d3e77e15.camel@googlemail.com> Hi. Am Freitag, den 14.12.2018, 13:26 +0200 schrieb Robert Gabriel: > Hi, > > I have created a master key along with a subkey for authenticating > and a subkey for signing. > > I copied the subkeys to my smartcard (Nitrokey Pro 2) using gpg2 -- > edit-key 93DA8C1D and did not enter save thereafter, but deleted them > manually using gpg2 --card-edit. > > I deleted the master private key. > gpg2 -K no private keys are visible. > > What have I missed? I read online the stubs are generated > automatically with the above command. Did you import the public keys? Are they in the key-Ring? If not, than you should do it, or the keys won't be recocnized. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From louis at opter.org Fri Dec 14 23:37:26 2018 From: louis at opter.org (Louis Opter) Date: Fri, 14 Dec 2018 14:37:26 -0800 Subject: Keyring management with multiple smart cards Message-ID: <4ED3AF1B-8FDC-4B74-97AF-451355CE0B37@opter.org> Hello, I have a certify-only master keypair in an air-gapped machine. I only use that machine to create subkeys and sign other people keys. The subkeys are copied onto smartcards which I use in daily life. Assuming that smartcards aren't indestructible and can be lost I always have a backup smartcard handy. Because you can't really share a subkey with multiple smartcards [1], I took the approach of generating subkeys for each smartcard. This means that I have multiple sign/enc/auth subkeys that are used in lockstep, but I have a single $GNUPGHOME and it is really easy for me to use any of my smartcards: data that I care about is encrypted for all the smartcards and all the smartcards are authorized for ssh logins. On the other hand, having multiple sign subkeys doesn't really make sense to publish data (e.g: software releases). Moreover my ring of enc subkeys is not useable for people who are trying to communicate with me: it's not really reasonable to ask people to encrypt data for all my subkeys, and GPG is designed to use the most recent key for the requested (sign/enc/auth) usage anyway. To alleviate that problem I was wondering if it was possible to create another sign/enc subkey and publish (to keyservers) that subkey only? (along with my master public key of course). In other words I would have two views of the same keyring: one with all my subkeys for my own use with my smartcards, and one for use by other people with only my master key and my sign/enc subkey so that there is no ambiguity on the subkey to use when communicating with me or verifying my signatures. I hope this intelligible and I am curious about how other people approached that problem. Thank you & have a nice week-end, [1] https://dev.gnupg.org/T2291 -- Louis Oper From wiktor at metacode.biz Sat Dec 15 09:53:23 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Sat, 15 Dec 2018 09:53:23 +0100 Subject: Keyring management with multiple smart cards In-Reply-To: <4ED3AF1B-8FDC-4B74-97AF-451355CE0B37@opter.org> References: <4ED3AF1B-8FDC-4B74-97AF-451355CE0B37@opter.org> Message-ID: Hi Louis, I have a very similar setup. After working with several different options and encountering the same problems as you have (GPG does not encrypt to all encryption subkeys, not possible to have the same subkeys on different smartcards) I observed the following facts: 1. I use one smartcard as a primary device so T2291 isn't that critical, if that one fails I can just remove shadow files and --card-status a new card, it will work. That doesn't happen frequently so manual removal of shadow file is not a big problem (but it would be nice if the shadow files supported multiple card serial numbers!). 2. As GnuPG does not encrypt to all encryption subkeys you *need* to have the same encryption subkeys on different smartcards anyway, but it's not a problem in practice because of 1. So, load the same encryption subkey on all devices and in case your main one is lost just remove the corresponding shadow file (this can be dangerous if you don't know what you're doing e.g. using private keys generated locally on GnuPG). One signing subkey per smartcard is fine as they're bound to the same primary key (but if you're not using expiration users can get some interesting behavior like [1]). Hope this helps! Kind regards, Wiktor [1]: https://www.reddit.com/r/tails/comments/9rchgi/ On 14.12.2018 23:37, Louis Opter wrote: > Hello, > > I have a certify-only master keypair in an air-gapped machine. I only > use that machine to create subkeys and sign other people keys. The > subkeys are copied onto smartcards which I use in daily life. > > Assuming that smartcards aren't indestructible and can be lost I always > have a backup smartcard handy. Because you can't really share a subkey > with multiple smartcards [1], I took the approach of generating subkeys > for each smartcard. This means that I have multiple sign/enc/auth > subkeys that are used in lockstep, but I have a single $GNUPGHOME and > it is really easy for me to use any of my smartcards: data that I care > about is encrypted for all the smartcards and all the smartcards are > authorized for ssh logins. > > On the other hand, having multiple sign subkeys doesn't really make > sense to publish data (e.g: software releases). Moreover my ring of enc > subkeys is not useable for people who are trying to communicate with me: > it's not really reasonable to ask people to encrypt data for all my > subkeys, and GPG is designed to use the most recent key for the > requested (sign/enc/auth) usage anyway. > > To alleviate that problem I was wondering if it was possible to create > another sign/enc subkey and publish (to keyservers) that subkey only? > (along with my master public key of course). > > In other words I would have two views of the same keyring: one with all > my subkeys for my own use with my smartcards, and one for use by other > people with only my master key and my sign/enc subkey so that there is > no ambiguity on the subkey to use when communicating with me or > verifying my signatures. > > I hope this intelligible and I am curious about how other people > approached that problem. > > Thank you & have a nice week-end, > > [1] https://dev.gnupg.org/T2291 > -- https://metacode.biz/@wiktor From wk at gnupg.org Sat Dec 15 16:36:57 2018 From: wk at gnupg.org (Werner Koch) Date: Sat, 15 Dec 2018 16:36:57 +0100 Subject: Gnupg-devel Digest, Vol 183, Issue 5 In-Reply-To: (Kenneth Benson's message of "Fri, 14 Dec 2018 10:41:42 -0500") References: Message-ID: <87efaidco6.fsf@wheatstone.g10code.de> On Fri, 14 Dec 2018 16:41, phoenyx33 at gmail.com said: > I was wondering if the pdf is going to be updated anytime soon? It's > title page still says it's for version 2.2.7? Done that. > > Also availabale should be available. I use always the last announcement as a template. I see how I can remember to fix that typo. Thanks. 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: 227 bytes Desc: not available URL: From robert at ephemeric.online Sun Dec 16 20:24:55 2018 From: robert at ephemeric.online (Robert Gabriel) Date: Sun, 16 Dec 2018 21:24:55 +0200 Subject: Private Keys on Card Not Loaded In-Reply-To: <3b4b78d93208c5deab70640ad7ee0fb6d3e77e15.camel@googlemail.com> References: <20181214112634.GB11850@mail.ephemeric.local> <3b4b78d93208c5deab70640ad7ee0fb6d3e77e15.camel@googlemail.com> Message-ID: <20181216192455.GA2854@mail.ephemeric.local> Hi, I deleted ~/.gnupg and imported the public key as you asked. All is working, thank you Dirk. I apologise for not checking this sooner and I'm not sure what broke as I tried a clean import previously. PS I also picked up a few good tips just by watching this list (thank you Werner for "echo foo | gpg --clearsign -v --debug ipc"). On Sat Dec 15 00:12, Dirk Gottschalk wrote: > Hi. > > Am Freitag, den 14.12.2018, 13:26 +0200 schrieb Robert Gabriel: > > Hi, > > > > I have created a master key along with a subkey for authenticating > > and a subkey for signing. > > > > I copied the subkeys to my smartcard (Nitrokey Pro 2) using gpg2 -- > > edit-key 93DA8C1D and did not enter save thereafter, but deleted them > > manually using gpg2 --card-edit. > > > > I deleted the master private key. > > gpg2 -K no private keys are visible. > > > > What have I missed? I read online the stubs are generated > > automatically with the above command. > > Did you import the public keys? Are they in the key-Ring? If not, than > you should do it, or the keys won't be recocnized. > > Regards, > Dirk > > -- > Dirk Gottschalk > Paulusstrasse 6-8 > 52064 Aachen, Germany > > GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 > Keybase.io: https://keybase.io/dgottschalk > GitHub: https://github.com/Dirk1980ac > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From stefan.claas at posteo.de Sun Dec 16 22:06:55 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 16 Dec 2018 22:06:55 +0100 Subject: Garbled data in keyservers In-Reply-To: References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> Message-ID: <43Hxg42Ym9z6tm9@submission01.posteo.de> On Sun, 09 Dec 2018 20:34:55 +0100, Dirk Gottschalk wrote: > Am Sonntag, den 09.12.2018, 20:03 +0100 schrieb Stefan Claas: > > My proposal could be run also in parallel. I think it would be > > only a weekend job for a programmer to modify the server code, > > so that it accepts only incoming and verified email and not web > > or GnuPG via Tor submissions. > A weekend job... Muhahahahahahaha, you don't do much programming, don't > you? One would have to write an email bot, change the keyserver code to > no longer accept submissions via HKP, then it would be neccessary do > disable HKP for upload in GnuPG to avoid broken Clients and so on. While testing today how to make someones pub key non-importable,non- receivable, with an evil version of GnuPG, I am wondering about the following: Is it not possible that for pub key submissions GnuPG could be installed on key servers to check if the key material is valid, prior keys got added? My test today showed me that it looks like that GnuPG is not used on key servers. In case if there would be email submissions possible, in the future, i think it could work something like this: Install postfix and procmail, while procmail would pipe that message to gnupg for verification of valid key data, prior the pub key gets added to the pool. Well, just some thoughts. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From louis at opter.org Mon Dec 17 03:28:19 2018 From: louis at opter.org (Louis Opter) Date: Sun, 16 Dec 2018 21:28:19 -0500 Subject: Keyring management with multiple smart cards In-Reply-To: References: <4ED3AF1B-8FDC-4B74-97AF-451355CE0B37@opter.org> Message-ID: <2a8a4570-b668-43a9-af49-3a627c920388@sloti7d1t30> On Sat, Dec 15, 2018, at 12:53 AM, Wiktor Kwapisiewicz wrote: > 1. I use one smartcard as a primary device so T2291 isn't that critical, if that > one fails I can just remove shadow files and --card-status a new card, it will > work. That doesn't happen frequently so manual removal of shadow file is not a > big problem (but it would be nice if the shadow files supported multiple card > serial numbers!). Where is the procedure to remove shadow files documented? I found this to be confusing to do, hence why I favored different subkeys for different smartcards. > One signing subkey per smartcard is fine as they're bound to the same primary > key (but if you're not using expiration users can get some interesting behavior > like [1]). > > [1]: https://www.reddit.com/r/tails/comments/9rchgi/ Thanks for the tip! I have an expiration date set on all my keys. Thank you very much for your feedback Wiktor! -- Louis Opter From wiktor at metacode.biz Mon Dec 17 09:43:55 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 17 Dec 2018 09:43:55 +0100 Subject: Keyring management with multiple smart cards In-Reply-To: <2a8a4570-b668-43a9-af49-3a627c920388@sloti7d1t30> References: <4ED3AF1B-8FDC-4B74-97AF-451355CE0B37@opter.org> <2a8a4570-b668-43a9-af49-3a627c920388@sloti7d1t30> Message-ID: <010478fc-5e66-f30e-a636-d8e2c06013b2@metacode.biz> On 17.12.2018 03:28, Louis Opter wrote: > Where is the procedure to remove shadow files documented? I found this to be > confusing to do, hence why I favored different subkeys for different smartcards. Uhm, this is kind of internal GnuPG details so I guess it's not documented anywhere. But it's something like this: $ gpg --with-keygrip -K You get keygrip from one of your subkeys and look for a file named the same in ~/.gnupg/private-keys-v1.d. Removing, well, just use "rm" (or "mv" just in case;). Note that this is implementation detail so it may change in the future. > Thank you very much for your feedback Wiktor! No problem, one thing I forgot to mention - as far as I know RFC 4880 (OpenPGP) doesn't precise which encryption subkey to use and some implementations (e.g. OpenKeychain) use all valid encryption subkeys (so a scheme of using one encryption subkey per token would work). Kind regards, Wiktor -- https://metacode.biz/@wiktor From stefan.claas at posteo.de Mon Dec 17 17:54:02 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Mon, 17 Dec 2018 17:54:02 +0100 Subject: Garbled data in keyservers In-Reply-To: <43Hxg42Ym9z6tm9@submission01.posteo.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> <43Hxg42Ym9z6tm9@submission01.posteo.de> Message-ID: <43JS0q6Jkvz6tmM@submission01.posteo.de> On Sun, 16 Dec 2018 22:06:55 +0100, Stefan Claas wrote: > While testing today how to make someones pub key non-importable,non- > receivable, For the interested reader: and : gpg --keyserver-option import-clean --keyserver pgp.circl.lu --recv-key 0x981eb7c382ec52b4 does not work for me under macOS. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From danielmang at gmail.com Mon Dec 17 11:14:08 2018 From: danielmang at gmail.com (Daniel Mang) Date: Mon, 17 Dec 2018 11:14:08 +0100 Subject: Encrypted document vs Key manager - security question (slightly off topic) Message-ID: Hi Maybe one of you knowledgeable people on this list might be willing to give me your qualified opinion on the issue. Sorry if this post is too far off topic. Years ago, before I had really heard of key managers, I started putting login credentials, PIN numbers and other private and confidential information into a file that I would then encrypt with GPG and keep on my computer. When I was on Linux I had the whole disk encrypted, now that I am using a Mac I use File Vault to encrypt the whole disk. I use the GPG Suite for Mac by GPG Tools. Of course I would erase the unencrypted original of this file and only keep the encrypted file, but I am a bit worried about the feasibility of really erasing anything on an SSD (I'm on one of these 12" "Retina" MacBooks). I work on two computers, and for this and other reasons, a while back I put most of my documents in the cloud using an instance of NextCloud on a server in France run by very security conscious friends. I sync that encrypted file with my passwords etc along with everything else. When I open my encrypted file to consult or modify it, of course I first turn off sync and only turn it on again after the plain file is trashed, so that only the encrypted file ends up in cloud storage. So my question is, do you think this system is ridiculously insecure or is it at least no worse than using something like KeePassX? Kind regards Daniel Mang From dirk.gottschalk1980 at googlemail.com Tue Dec 18 22:57:36 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 18 Dec 2018 22:57:36 +0100 Subject: Garbled data in keyservers In-Reply-To: <43Hxg42ZcWz6tmH@submission01.posteo.de> References: <1544002286.1805.5.camel@cod-web.net> <87o9a0cg3h.fsf@wheatstone.g10code.de> <20181205173418.2ccfa1d7@iria.my-fqdn.de> <8736rbdfn3.fsf@wheatstone.g10code.de> <20181205195613.4d371878@iria.my-fqdn.de> <87d0qfaxpn.fsf@wheatstone.g10code.de> <20181206102205.3c19626c@iria.my-fqdn.de> <87y3939bs7.fsf@wheatstone.g10code.de> <20181206140537.7288e687@iria.my-fqdn.de> <87va4691m1.fsf@wheatstone.g10code.de> <20181209135401.735f1678@iria.my-fqdn.de> <6CD7A6A9-9EC1-49AC-9E76-B870456AC248@colmena.biz> <20181209193831.07ccd749@iria.my-fqdn.de> <20181209200309.10c7950f@iria.my-fqdn.de> <43Hxg42ZcWz6tmH@submission01.posteo.de> Message-ID: <2181dfff10962ba9027013ac6c8b4fb14725a8b6.camel@googlemail.com> Hi Stefan. Am Sonntag, den 16.12.2018, 22:06 +0100 schrieb Stefan Claas: > On Sun, 09 Dec 2018 20:34:55 +0100, Dirk Gottschalk wrote: > > Am Sonntag, den 09.12.2018, 20:03 +0100 schrieb Stefan Claas: > > > My proposal could be run also in parallel. I think it would be > > > only a weekend job for a programmer to modify the server code, > > > so that it accepts only incoming and verified email and not web > > > or GnuPG via Tor submissions. > > A weekend job... Muhahahahahahaha, you don't do much programming, > > don't you? One would have to write an email bot, change the > > keyserver code to no longer accept submissions via HKP, then it > > would be neccessary do disable HKP for upload in GnuPG to avoid > > broken Clients and so on. > While testing today how to make someones pub key non-importable,non- > receivable, with an evil version of GnuPG, I am wondering about the > following: > Is it not possible that for pub key submissions GnuPG could be > installed on key servers to check if the key material is valid, prior > keys got added? This would be possible for sure. Most Servers I know run on Linux, GPG should be installed anyways. The simpliest way would be to store the key temporarily, try to import it into a dummy keyring and check the success/failure of the import. On Success use the key, on failure reject it. > My test today showed me that it looks like that GnuPG is not used on > key servers. That's true. I also don't know a server doing it this way, but it would be possible without the need to break the actual HKP. > In case if there would be email submissions possible, in the future, > i think it could work something like this: Install postfix and > procmail, while procmail would pipe that message to gnupg for > verification of valid key data, prior the pub key gets added to the > pool. This would be possible, too. Years ago there was an email submission possibility. Some mail clients even had a menu item to add the ascii armoured key into the mail body. But, this functions have gone years ago. I think nobody really used it, so it was abandonned. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From vesely at tana.it Wed Dec 19 11:21:49 2018 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 19 Dec 2018 11:21:49 +0100 Subject: Smart cards In-Reply-To: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> References: <20181211181103.qcuoqpkqckaxeusw@CHS-TMB-078.qmcr.qmul.ac.uk> Message-ID: Hi Damien, On Tue 11/Dec/2018 19:11:03 +0100 Damien Goutte-Gattat wrote: > > I know of at least one NFC-enabled OpenPGP card, the "Fidesmo > Card" [1]. I contacted Leif Scheppelmann at Cotech.de. He says they don't have a shop for their cards because end user market is too small. However, he's going to send me a card for 15? (+3 shipping). I'll write when I'll have received it. For now, let me just quote his words: Unfortunately you are not able to use your 4096-key with our card. We just support 2048-keys. Our assumption is that the amount of energy that can be shipped over NFC is limited. We are in contact with the supplier to get 4096-keys working. In future we will switch to ecc-keys by default in all our applications. We are following ISO/IEC 7816 Part1-4, ISO14443 Part1-4 and Java Card 3.0.4 specification and using the OpenPGP-Card-Applet. The card supports common algorithms such as MD5, SHA-family, DES, AES, RSA. I think you may want to mention those cards on your Implementations of the OpenPGP application for smart cards page. Best Ale -- > [1] http://shop.fidesmo.com/product/fidesmo-card -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Wed Dec 26 10:39:39 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 26 Dec 2018 10:39:39 +0100 Subject: A question about WKD Message-ID: <43PnxT3yYDz9rxR@submission02.posteo.de> Hi all, hope you all had a nice Christmas! I have set up WKD on my VPS, in order to learn more about it and get now the following error: gpg --encrypt -r sac at 300baud.de OpenSSL.txt gpg: error retrieving 'sac at 300baud.de' via WKD: Not trusted gpg: sac at 300baud.de: skipped: Not trusted gpg: OpenSSL.txt: encryption failed: Not trusted I assume that dirmngr is downloading my cert and thinks it is not trusted. However, my site uses a popular Comodo cert. Any ideas what is going on here and how to fix this? Regards Stefan From vesely at tana.it Wed Dec 26 14:35:28 2018 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 26 Dec 2018 14:35:28 +0100 Subject: A question about WKD In-Reply-To: <43PnxT3yYDz9rxR@submission02.posteo.de> References: <43PnxT3yYDz9rxR@submission02.posteo.de> Message-ID: On Wed 26/Dec/2018 10:39:39 +0100 Stefan Claas wrote: > > I have set up WKD on my VPS, in order to learn more about it and get now > the following error: > > gpg --encrypt -r sac at 300baud.de OpenSSL.txt > gpg: error retrieving 'sac at 300baud.de' via WKD: Not trusted You seem to have already solved that: ale at pcale:~/tmp$ curl -o /dev/null -v https://300baud.de/.well-known/openpgpkey/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 167.99.129.126... * TCP_NODELAY set * Connected to 300baud.de (167.99.129.126) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): } [5 bytes data] * TLSv1.2 (OUT), TLS handshake, Client hello (1): } [512 bytes data] * TLSv1.2 (IN), TLS handshake, Server hello (2): { [113 bytes data] * TLSv1.2 (IN), TLS handshake, Certificate (11): { [5662 bytes data] * TLSv1.2 (IN), TLS handshake, Server key exchange (12): { [333 bytes data] * TLSv1.2 (IN), TLS handshake, Server finished (14): { [4 bytes data] * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): } [70 bytes data] * TLSv1.2 (OUT), TLS change cipher, Client hello (1): } [1 bytes data] * TLSv1.2 (OUT), TLS handshake, Finished (20): } [16 bytes data] * TLSv1.2 (IN), TLS change cipher, Client hello (1): { [1 bytes data] * TLSv1.2 (IN), TLS handshake, Finished (20): { [16 bytes data] * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: OU=Domain Control Validated; OU=PositiveSSL; CN=300baud.de * start date: Dec 23 00:00:00 2018 GMT * expire date: Dec 23 23:59:59 2019 GMT * subjectAltName: host "300baud.de" matched cert's "300baud.de" * issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA * SSL certificate verify ok. } [5 bytes data] > GET /.well-known/openpgpkey/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33 HTTP/1.1 > Host: 300baud.de > User-Agent: curl/7.52.1 > Accept: */* > { [5 bytes data] < HTTP/1.1 200 OK < Date: Wed, 26 Dec 2018 13:33:07 GMT < Server: Apache/2.4.18 (Ubuntu) < Last-Modified: Tue, 25 Dec 2018 17:27:21 GMT < ETag: "1f4-57ddc06a6a77b" < Accept-Ranges: bytes < Content-Length: 500 < Content-Language: de < { [5 bytes data] * Curl_http_done: called premature == 0 100 500 100 500 0 0 7025 0 --:--:-- --:--:-- --:--:-- 7042 * Connection #0 to host 300baud.de left intact And, using the attached script: ale at pcale:~/tmp$ testwkd.sh sac at 300baud.de gpg: keybox '/tmp/user/1000/tmp.EDqjfCCXPH/pubring.kbx' created gpg: /tmp/user/1000/tmp.EDqjfCCXPH/trustdb.gpg: trustdb created gpg: using pgp trust model gpg: error retrieving 'sac at 300baud.de' via None: No public key gpg: no running Dirmngr - starting '/usr/bin/dirmngr' gpg: waiting for the dirmngr to come up ... (5s) gpg: connection to the dirmngr established gpg: pub ed25519/9A234E0B0E1F1FE8 2018-12-25 Stefan Claas gpg: key 9A234E0B0E1F1FE8: public key "Stefan Claas " imported gpg: no running gpg-agent - starting '/usr/bin/gpg-agent' gpg: waiting for the agent to come up ... (5s) gpg: connection to agent established gpg: Total number processed: 1 gpg: imported: 1 gpg: auto-key-locate found fingerprint EC15C644C35948FCB47E15899A234E0B0E1F1FE8 gpg: automatically retrieved 'sac at 300baud.de' via WKD pub ed25519 2018-12-25 [SC] EC15C644C35948FCB47E15899A234E0B0E1F1FE8 uid [ unknown] Stefan Claas sub cv25519 2018-12-25 [E] gpg: using pgp trust model /tmp/user/1000/tmp.EDqjfCCXPH/pubring.kbx ----------------------------------------- pub ed25519 2018-12-25 [SC] EC15C644C35948FCB47E15899A234E0B0E1F1FE8 uid [ unknown] Stefan Claas sig!3 P 9A234E0B0E1F1FE8 2018-12-25 Stefan Claas sub cv25519 2018-12-25 [E] sig! P 9A234E0B0E1F1FE8 2018-12-25 Stefan Claas gpg: 2 good signatures Best Ale -------------- next part -------------- A non-text attachment was scrubbed... Name: testwkd.sh Type: application/x-shellscript Size: 328 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Wed Dec 26 17:08:16 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 26 Dec 2018 17:08:16 +0100 Subject: A question about WKD In-Reply-To: References: <43PnxT3yYDz9rxR@submission02.posteo.de> Message-ID: <43PyYt3FqNz6tmD@submission01.posteo.de> On Wed, 26 Dec 2018 14:35:28 +0100, Alessandro Vesely wrote: > And, using the attached script: > > ale at pcale:~/tmp$ testwkd.sh sac at 300baud.de > gpg: keybox '/tmp/user/1000/tmp.EDqjfCCXPH/pubring.kbx' created > gpg: /tmp/user/1000/tmp.EDqjfCCXPH/trustdb.gpg: trustdb created > gpg: using pgp trust model > gpg: error retrieving 'sac at 300baud.de' via None: No public key > gpg: no running Dirmngr - starting '/usr/bin/dirmngr' > gpg: waiting for the dirmngr to come up ... (5s) > gpg: connection to the dirmngr established > gpg: pub ed25519/9A234E0B0E1F1FE8 2018-12-25 Stefan Claas > gpg: key 9A234E0B0E1F1FE8: public key "Stefan Claas " imported > gpg: no running gpg-agent - starting '/usr/bin/gpg-agent' > gpg: waiting for the agent to come up ... (5s) > gpg: connection to agent established > gpg: Total number processed: 1 > gpg: imported: 1 > gpg: auto-key-locate found fingerprint EC15C644C35948FCB47E15899A234E0B0E1F1FE8 > gpg: automatically retrieved 'sac at 300baud.de' via WKD > pub ed25519 2018-12-25 [SC] > EC15C644C35948FCB47E15899A234E0B0E1F1FE8 > uid [ unknown] Stefan Claas > sub cv25519 2018-12-25 [E] > > gpg: using pgp trust model > /tmp/user/1000/tmp.EDqjfCCXPH/pubring.kbx > ----------------------------------------- > pub ed25519 2018-12-25 [SC] > EC15C644C35948FCB47E15899A234E0B0E1F1FE8 > uid [ unknown] Stefan Claas > sig!3 P 9A234E0B0E1F1FE8 2018-12-25 Stefan Claas > sub cv25519 2018-12-25 [E] > sig! P 9A234E0B0E1F1FE8 2018-12-25 Stefan Claas > > gpg: 2 good signatures Thanks for testing! So it works for you and probably others too, but not for me. :-( ./testwkd.sh sac at 300baud.de gpg: keybox '/var/folders/hf/wc4hsm4n53523ym60s065zv00000gn/T/tmp.iKVxe7r2/pubring.kbx' created gpg: /var/folders/hf/wc4hsm4n53523ym60s065zv00000gn/T/tmp.iKVxe7r2/trustdb.gpg: trustdb created gpg: using pgp trust model gpg: error retrieving 'sac at 300baud.de' via None: No public key gpg: no running Dirmngr - starting '/usr/local/gnupg-2.2/bin/dirmngr' gpg: waiting for the dirmngr to come up ... (5s) gpg: connection to dirmngr established gpg: error retrieving 'sac at 300baud.de' via WKD: Not trusted gpg: error reading key: Not trusted gpg: using pgp trust model I am using the latest GnuPG version for macOS from SourceForge. Regards Stefan From stefan.claas at posteo.de Wed Dec 26 22:59:19 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 26 Dec 2018 22:59:19 +0100 Subject: A question about WKD In-Reply-To: References: <43PnxT3yYDz9rxR@submission02.posteo.de> Message-ID: <43Q6Lx1rN5z6tmB@submission01.posteo.de> On Wed, 26 Dec 2018 14:35:28 +0100, Alessandro Vesely wrote: > You seem to have already solved that: May i ask you what version of GnuPG you are using and what OS? I ask, because i tried also the following with gpg4win earlier today and it sayd in German no data found. Then i set up an SRV record on my VPS for WKD and i was able to download the the pub key via gpg -er sac at 300.baud.de file.txt The Windows version is GnuPG 2.2.11 I then tried again with the macOS version, which is 2.2.12 and it did not worked again. :-( Regards Stefan From vesely at tana.it Thu Dec 27 10:35:22 2018 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 27 Dec 2018 10:35:22 +0100 Subject: A question about WKD In-Reply-To: <43Q6Lx1rN5z6tmB@submission01.posteo.de> References: <43PnxT3yYDz9rxR@submission02.posteo.de> <43Q6Lx1rN5z6tmB@submission01.posteo.de> Message-ID: On Wed 26/Dec/2018 22:59:19 +0100 Stefan Claas wrote: > >> You seem to have already solved that: > > May i ask you what version of GnuPG you are using and what OS? Sure: ale at pcale:~/tmp$ uname -a Linux pcale 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux ale at pcale:~/tmp$ ale at pcale:~/tmp$ gpg2 --version gpg (GnuPG) 2.1.18 libgcrypt 1.7.6-beta Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/ale/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 > I ask, because i tried also the following with gpg4win earlier today > and it sayd in German no data found. Then i set up an SRV record > on my VPS for WKD and i was able to download the the pub key > via gpg -er sac at 300.baud.de file.txt The Windows version is > GnuPG 2.2.11 I see no SRV record from here, and I don't need one since 300baud.de resolves correctly. ale at pcale:~/tmp$ dig @ns1.digitalocean.com _https._tcp.300baud.de srv ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 21947 ;; Flags: qr aa rd; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0 ;; QUESTION SECTION: ;; _https._tcp.300baud.de. IN SRV ;; AUTHORITY SECTION: 300baud.de. 1800 IN SOA ns1.digitalocean.com. hostmaster.300baud.de. 1545858070 10800 3600 604800 1800 ;; Received 107 B ;; Time 2018-12-27 10:23:39 CET ;; From 173.245.58.51 at 53(UDP) in 49.1 ms > I then tried again with the macOS version, which is 2.2.12 and it > did not worked again. :-( Couldn't that be something with your CA bundle? What do you get if you try and download your keys with curl, e.g.: curl -o /dev/null -v https://300baud.de/.well-known/openpgpkey/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33 ? Best Ale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Thu Dec 27 16:01:52 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 27 Dec 2018 16:01:52 +0100 Subject: A question about WKD In-Reply-To: References: <43PnxT3yYDz9rxR@submission02.posteo.de> <43Q6Lx1rN5z6tmB@submission01.posteo.de> Message-ID: <43QY2n6Y02z9rxN@submission02.posteo.de> On Thu, 27 Dec 2018 10:35:22 +0100, Alessandro Vesely wrote: > On Wed 26/Dec/2018 22:59:19 +0100 Stefan Claas wrote: > > > >> You seem to have already solved that: > > > > May i ask you what version of GnuPG you are using and what OS? > > Sure: > ale at pcale:~/tmp$ uname -a > Linux pcale 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux > ale at pcale:~/tmp$ > ale at pcale:~/tmp$ gpg2 --version > gpg (GnuPG) 2.1.18 > libgcrypt 1.7.6-beta > Copyright (C) 2017 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: /home/ale/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 Thanks! > I see no SRV record from here, and I don't need one since 300baud.de resolves correctly. host -t srv _openpgpkey._tcp.300baud.de _openpgpkey._tcp.300baud.de has SRV record 10 100 443 300baud.de. > > I then tried again with the macOS version, which is 2.2.12 and it > > did not worked again. :-( > > > Couldn't that be something with your CA bundle? What do you get if you try and download your keys with curl, e.g.: > curl -o /dev/null -v https://300baud.de/.well-known/openpgpkey/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33 > ? Mmhh, good question... when downloading it says CAfile: /Users/sac/anaconda2/ssl/cacert.pem CApath: none, but i can download without a problem: curl -o /dev/null -v https://300baud.de/.well-known/openpgpkey/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 167.99.129.126... * TCP_NODELAY set * Connected to 300baud.de (167.99.129.126) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /Users/sac/anaconda2/ssl/cacert.pem CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): } [5 bytes data] * TLSv1.2 (OUT), TLS handshake, Client hello (1): } [512 bytes data] 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0* TLSv1.2 (IN), TLS handshake, Server hello (2): { [113 bytes data] * TLSv1.2 (IN), TLS handshake, Certificate (11): { [5662 bytes data] * TLSv1.2 (IN), TLS handshake, Server key exchange (12): { [333 bytes data] * TLSv1.2 (IN), TLS handshake, Server finished (14): { [4 bytes data] * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): } [70 bytes data] * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): } [1 bytes data] * TLSv1.2 (OUT), TLS handshake, Finished (20): } [16 bytes data] * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): { [1 bytes data] * TLSv1.2 (IN), TLS handshake, Finished (20): { [16 bytes data] * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: OU=Domain Control Validated; OU=PositiveSSL; CN=300baud.de * start date: Dec 23 00:00:00 2018 GMT * expire date: Dec 23 23:59:59 2019 GMT * subjectAltName: host "300baud.de" matched cert's "300baud.de" * issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA * SSL certificate verify ok. } [5 bytes data] > GET /.well-known/openpgpkey/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33 HTTP/1.1 > Host: 300baud.de > User-Agent: curl/7.62.0 > Accept: */* > { [5 bytes data] < HTTP/1.1 200 OK < Date: Thu, 27 Dec 2018 14:47:52 GMT < Server: Apache/2.4.18 (Ubuntu) < Last-Modified: Tue, 25 Dec 2018 17:27:21 GMT < ETag: "1f4-57ddc06a6a77b" < Accept-Ranges: bytes < Content-Length: 500 < Content-Language: de < { [5 bytes data] 100 500 100 500 0 0 396 0 0:00:01 0:00:01 --:--:-- 396 * Connection #0 to host 300baud.de left intact As a test i also created a blank .gnupg folder and tried to encrypt but it still say not trusted. I run out of ideas now and i will contact Patrick Brunschwig and wait what he says, because he is the maintainer of the SourceForge binary. Regards Stefan From stefan.claas at posteo.de Thu Dec 27 18:19:11 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 27 Dec 2018 18:19:11 +0100 Subject: A question about WKD In-Reply-To: <43QY2n6Y02z9rxN@submission02.posteo.de> References: <43PnxT3yYDz9rxR@submission02.posteo.de> <43Q6Lx1rN5z6tmB@submission01.posteo.de> <43QY2n6Y02z9rxN@submission02.posteo.de> Message-ID: <43Qc5R6qMYz6tmB@submission01.posteo.de> On Thu, 27 Dec 2018 16:01:52 +0100, Stefan Claas wrote: > As a test i also created a blank .gnupg folder and tried to encrypt but it still > say not trusted. I run out of ideas now and i will contact Patrick Brunschwig > and wait what he says, because he is the maintainer of the SourceForge > binary. O.k. i received a reply from Patrick. So as understood he uses the original code from GnuPG. So it looks to me that one under Linux oder when using his version must properly configure GnuPG, in order that this works. gpg4win does not need this and as two GPGTools Mac users have told me it works for them too. What to do... Should i switch then back to GPGTools or is someone here so kind and tell me the required steps for an actual 2.2.12 Linux version configuration, so that i can try it out with the Patrick's version? Regards Stefan From stefan.claas at posteo.de Thu Dec 27 18:40:19 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 27 Dec 2018 18:40:19 +0100 Subject: A question about WKD In-Reply-To: <43Qc5R6qMYz6tmB@submission01.posteo.de> References: <43PnxT3yYDz9rxR@submission02.posteo.de> <43Q6Lx1rN5z6tmB@submission01.posteo.de> <43QY2n6Y02z9rxN@submission02.posteo.de> <43Qc5R6qMYz6tmB@submission01.posteo.de> Message-ID: <43QcYd4217z6tm5@submission01.posteo.de> On Thu, 27 Dec 2018 18:19:11 +0100, Stefan Claas wrote: > On Thu, 27 Dec 2018 16:01:52 +0100, Stefan Claas wrote: > > > As a test i also created a blank .gnupg folder and tried to encrypt but it still > > say not trusted. I run out of ideas now and i will contact Patrick Brunschwig > > and wait what he says, because he is the maintainer of the SourceForge > > binary. > > O.k. i received a reply from Patrick. So as understood he uses the original > code from GnuPG. So it looks to me that one under Linux oder when using > his version must properly configure GnuPG, in order that this works. I received a second reply and it works for him. He gave me also an advice but it still does not work for me, strange. Regards Stefan From wiktor at metacode.biz Thu Dec 27 20:48:09 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Thu, 27 Dec 2018 20:48:09 +0100 Subject: A question about WKD In-Reply-To: <43PnxT3yYDz9rxR@submission02.posteo.de> References: <43PnxT3yYDz9rxR@submission02.posteo.de> Message-ID: <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> On 26.12.2018 10:39, Stefan Claas wrote: > Hi all, > > hope you all had a nice Christmas! > > I have set up WKD on my VPS, in order to learn more about it and get now > the following error: > > gpg --encrypt -r sac at 300baud.de OpenSSL.txt > gpg: error retrieving 'sac at 300baud.de' via WKD: Not trusted > gpg: sac at 300baud.de: skipped: Not trusted > gpg: OpenSSL.txt: encryption failed: Not trusted > > I assume that dirmngr is downloading my cert and thinks it > is not trusted. However, my site uses a popular Comodo cert. > > Any ideas what is going on here and how to fix this? It works "on my end" too (GnuPG 2.2.12 on Linux). Did you try fetching some "well-known" WKD people? E.g.: $ gpg --auto-key-locate clear,wkd,nodefault --locate-key wk at gnupg.org My first guess would also be a bad certificate bundle but when I try using "bad" domains from this list https://badssl.com the error is: gpg: error retrieving 'test at expired.badssl.com' via WKD: General error gpg: error reading key: General error Rather than "not trusted" (maybe you could try experimenting with these domains to see if the error is different). There is also "--debug lookup" flag, and "-vvv": $ gpg -vvv --debug lookup --auto-key-locate clear,wkd,nodefault --locate-key EMAIL Maybe that'd print something useful? Do you have anything "exotic" in .gnupg/gpg.conf? Kind regards, Wiktor -- https://metacode.biz/@wiktor From stefan.claas at posteo.de Thu Dec 27 23:43:34 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 27 Dec 2018 23:43:34 +0100 Subject: A question about WKD References: <43PnxT3yYDz9rxR@submission02.posteo.de> <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> Message-ID: <43QlHW2JQRz9rxH@submission02.posteo.de> On Thu, 27 Dec 2018 20:48:09 +0100, Wiktor Kwapisiewicz wrote: > It works "on my end" too (GnuPG 2.2.12 on Linux). That is good to know! > Did you try fetching some "well-known" WKD people? E.g.: > > $ gpg --auto-key-locate clear,wkd,nodefault --locate-key wk at gnupg.org No, i did not. > There is also "--debug lookup" flag, and "-vvv": > > $ gpg -vvv --debug lookup --auto-key-locate clear,wkd,nodefault --locate-key EMAIL Thanks for the info. Should this happen again i will try that. > Do you have anything "exotic" in .gnupg/gpg.conf? No, actually not. I downloading GPGTools and extracted the binaries and no luck. Then i build from source, which compiled fine and it worked with old agents from MacPorts, which i still have installed. But i did not liked that combination. So i tried to set it up that way that it does not use the MacPorts agents, but it failed. Finally i decided to update MacPorts and now i am using GnuPG 2.2.10, which is the latest there. With The MacPorts version everything works as expected. However, it would be nice to know why GnuPG told me that the certs are not trusted. I googled for that but could not find anything. Regards Stefan From robin.krahl at ireas.org Fri Dec 28 10:58:29 2018 From: robin.krahl at ireas.org (Robin Krahl) Date: Fri, 28 Dec 2018 10:58:29 +0100 Subject: Unblocking the user PIN does not work with a new PIN Message-ID: <20181228095829.GA844@spectator> Hi, according to the documentation [0], the unblock PIN command for a OpenPGP smart card allows the user to choose a new user PIN. But on my smart card, the command fails with the error message ?Error unblocking the PIN: Conditions of use not satisfied? if I choose a new PIN. It succeeds if I enter the current user PIN. Is this a bug in GnuPG, or is my smart card not working properly? Or am I missing something? I?m using a Nitrokey Storage with a ZeitControl OpenPGP v3.3 smart card. I attached the transcript of a shell session showing the problem. For the first unblock command, I chose a new user PIN. For the second, I entered the current user PIN. /Robin [0] https://www.gnupg.org/howtos/card-howto/en/ch03s02.html -------------- next part -------------- $ gpg --card-status Reader ...........: 20A0:4109:0000000000000:0 Application ID ...: D27600012401030300050000636F0000 Version ..........: 3.3 Manufacturer .....: ZeitControl Serial number ....: 0000636F Name of cardholder: [not set] Language prefs ...: de Sex ..............: unspecified URL of public key : [not set] Login data .......: [not set] Signature PIN ....: not forced Key attributes ...: rsa4096 rsa2048 rsa2048 Max. PIN lengths .: 64 64 64 PIN retry counter : 0 0 3 Signature counter : 0 KDF setting ......: on Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none] $ gpg --change-pin gpg: OpenPGP card no. D27600012401030300050000636F0000 detected 1 - change PIN 2 - unblock PIN 3 - change Admin PIN 4 - set the Reset Code Q - quit Your selection? 2 Error unblocking the PIN: Conditions of use not satisfied 1 - change PIN 2 - unblock PIN 3 - change Admin PIN 4 - set the Reset Code Q - quit Your selection? 2 PIN unblocked and new PIN set. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From kynnjo at gmail.com Fri Dec 28 15:57:07 2018 From: kynnjo at gmail.com (Kynn Jones) Date: Fri, 28 Dec 2018 09:57:07 -0500 Subject: How to use *.pub/*.sec files to encrypt/decrypt another file? Message-ID: I created a pair of *.pub and *.sec files using the instructions and code given here: https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html (I am using this documentation because the ultimate application I have in mind is an automated encryption/decryption pipeline.) How can use gpg2 and the *.pub file to encrypt another file? And how can I use gpg2 and the companion *.sec to decrypt the result of that last encryption? Any pointers to relevant documentation would greatly appreciated. I've never been so lost when learning about a piece of software as I am with gpg2. Thanks in advance! k -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.claas at posteo.de Sat Dec 29 15:48:43 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Sat, 29 Dec 2018 15:48:43 +0100 Subject: A question about WKD In-Reply-To: <43QlHW2JQRz9rxH@submission02.posteo.de> References: <43PnxT3yYDz9rxR@submission02.posteo.de> <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> <43QlHW2JQRz9rxH@submission02.posteo.de> Message-ID: Am 27.12.18 um 23:43 schrieb Stefan Claas: > > However, it would be nice to know why GnuPG told me > that the certs are not trusted. I googled for that but could > not find anything. > > Regards > Stefan > > Hi all, is it also possible to add manually more pub keys to WKD or do i have to install WKS for that purpose? I ask, because in case i like to add more users to my mail server. Regards Stefan From wiktor at metacode.biz Sat Dec 29 20:18:54 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Sat, 29 Dec 2018 20:18:54 +0100 Subject: A question about WKD In-Reply-To: References: <43PnxT3yYDz9rxR@submission02.posteo.de> <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> <43QlHW2JQRz9rxH@submission02.posteo.de> Message-ID: On 29.12.2018 15:48, Stefan Claas wrote: > Hi all, > > is it also possible to add manually more pub keys to WKD > or do i have to install WKS for that purpose? > > I ask, because in case i like to add more users to my > mail server. Just create more files in .well-known/openpgpkey/hu directory. I didn't follow how you set it up initially but you can grab the file name (hash) using this command: $ gpg --with-wkd -k KEY Substitute KEY with key ID or an email, etc. For example for me it prints the following line of hash: gebusffkx9g581i6ch4t3ewgwd6dctmp at metacode.biz If you export binary key to .well-known/openpgpkey/hu and name it "gebusffkx9g581i6ch4t3ewgwd6dctmp" (no quotes, no extension, just like that) then it would work. WKS is not needed. Actually WKS is only when you want users to manage their keys using their e-mail client. I know other people that manage WKD differently, e.g. Gentoo has a strict set of known keys and they update their WKD directory with a cron job (so developers update the key on keyservers and WKD is automatically refreshed). I did a small proof-of-concept checker for small deployments, that you may find useful: https://metacode.biz/openpgp/web-key-directory Kind regards, Wiktor -- https://metacode.biz/@wiktor From wiktor at metacode.biz Sat Dec 29 20:53:03 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Sat, 29 Dec 2018 20:53:03 +0100 Subject: A question about WKD In-Reply-To: <20181229205002.6b7053e5@300baud> References: <43PnxT3yYDz9rxR@submission02.posteo.de> <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> <43QlHW2JQRz9rxH@submission02.posteo.de> <20181229205002.6b7053e5@300baud> Message-ID: On 29.12.2018 20:50, Stefan Claas wrote: >> I did a small proof-of-concept checker for small deployments, that you may find >> useful: https://metacode.biz/openpgp/web-key-directory > That is very interesting! I checked Werner's, yours and my key. > > With yours everything is fine, with Werner's there is one issue and > with mine the same issue as with Werner's and also it says with my key that > it is ASCII armored, which is not the case because i exported as binary. Ha, I didn't emphasize the "proof of concept" enough :) Thanks for the "test samples", I'll use them to improve the tool! Kind regards, Wiktor -- https://metacode.biz/@wiktor From sac at 300baud.de Sat Dec 29 20:50:02 2018 From: sac at 300baud.de (Stefan Claas) Date: Sat, 29 Dec 2018 20:50:02 +0100 Subject: A question about WKD In-Reply-To: References: <43PnxT3yYDz9rxR@submission02.posteo.de> <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> <43QlHW2JQRz9rxH@submission02.posteo.de> Message-ID: <20181229205002.6b7053e5@300baud> On Sat, 29 Dec 2018 20:18:54 +0100, Wiktor Kwapisiewicz via Gnupg-users wrote: > On 29.12.2018 15:48, Stefan Claas wrote: > Just create more files in .well-known/openpgpkey/hu directory. Ah, o.k. thanks! > I didn't follow how you set it up initially but you can grab the file name > (hash) using this command: > > $ gpg --with-wkd -k KEY > > Substitute KEY with key ID or an email, etc. > > For example for me it prints the following line of hash: > > gebusffkx9g581i6ch4t3ewgwd6dctmp at metacode.biz > > If you export binary key to .well-known/openpgpkey/hu and name it > "gebusffkx9g581i6ch4t3ewgwd6dctmp" (no quotes, no extension, just like that) > then it would work. I did the same steps. > WKS is not needed. Actually WKS is only when you want users to manage their keys > using their e-mail client. I know other people that manage WKD differently, e.g. > Gentoo has a strict set of known keys and they update their WKD directory with a > cron job (so developers update the key on keyservers and WKD is automatically > refreshed). Good to know! :-) > I did a small proof-of-concept checker for small deployments, that you may find > useful: https://metacode.biz/openpgp/web-key-directory That is very interesting! I checked Werner's, yours and my key. With yours everything is fine, with Werner's there is one issue and with mine the same issue as with Werner's and also it says with my key that it is ASCII armored, which is not the case because i exported as binary. I ask also several people on Win / Mac boxes which could get my key via WKD. You could also fetch my key with your latest GnuPG version, under Linux, IIRC. Regards Stefan From sac at 300baud.de Sat Dec 29 21:27:43 2018 From: sac at 300baud.de (Stefan Claas) Date: Sat, 29 Dec 2018 21:27:43 +0100 Subject: Test - Please Ignore Message-ID: <20181229212743.488c5ca2@300baud> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 My reply to Wiktor came not through yet, so let's see if this message makes it. Regards Stefan -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTsFcZEw1lI/LR+FYmaI04LDh8f6AUCXCfYvwAKCRCaI04LDh8f 6I4xAQDz4bG/GayV/Kcb0ZRxo728Ddu9pOnZpf3WpY3MiYxmgQEAw1Pa5bSuFOUq +hM8HbfzZWehG0dHfkMn/wAc5nTHmwQ= =i+0A -----END PGP SIGNATURE----- From peter at digitalbrains.com Sun Dec 30 12:35:34 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 30 Dec 2018 12:35:34 +0100 Subject: Unblocking the user PIN does not work with a new PIN In-Reply-To: <20181228095829.GA844@spectator> References: <20181228095829.GA844@spectator> Message-ID: <782560e8-fdb4-583a-3847-08cfc7f2c3b9@digitalbrains.com> Hi, PINs need to be at least 6 characters long (8 for Admin PIN). Do you perhaps try to set a too short PIN? 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From robin.krahl at ireas.org Sun Dec 30 13:19:49 2018 From: robin.krahl at ireas.org (Robin Krahl) Date: Sun, 30 Dec 2018 13:19:49 +0100 Subject: Unblocking the user PIN does not work with a new PIN In-Reply-To: <782560e8-fdb4-583a-3847-08cfc7f2c3b9@digitalbrains.com> References: <20181228095829.GA844@spectator> <782560e8-fdb4-583a-3847-08cfc7f2c3b9@digitalbrains.com> Message-ID: <20181230121949.GA749@spectator> Hi Peter, you are right, that was the problem. If I choose a longer PIN, it is working as expected. Thank you! /Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gernot.pokorny.dev at gmail.com Sun Dec 30 18:05:37 2018 From: gernot.pokorny.dev at gmail.com (Gernot Pokorny) Date: Sun, 30 Dec 2018 18:05:37 +0100 Subject: gpg - difference --encrypt-to and --recipient Message-ID: What is the difference between --encrypt-to and --recipient and what are the advantages and disadvantages of using one over the other, which one should you use for encrypting your own files and what does the following mean? --encrypt-to ... The key specified by name is used only when there are other recipients given by the user or by use of the option recipient. ... I also posted that question under stackoverflow: https://superuser.com/questions/1389024/gpg-difference-encrypt-to-and-recipient/1389030#1389030 Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From sac at 300baud.de Sun Dec 30 22:40:18 2018 From: sac at 300baud.de (Stefan Claas) Date: Sun, 30 Dec 2018 22:40:18 +0100 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: References: Message-ID: <20181230224018.5495b170@300baud> On Sun, 30 Dec 2018 18:05:37 +0100, Gernot Pokorny wrote: Hi, > What is the difference between --encrypt-to and --recipient and what are > the advantages and disadvantages of using one over the other, which one > should you use for encrypting your own files and what does the following > mean? > > --encrypt-to ... The key specified by name is used only when there are > other recipients given by the user or by use of the option recipient. ... > > > I also posted that question under stackoverflow: > https://superuser.com/questions/1389024/gpg-difference-encrypt-to-and-recipient/1389030#1389030 Simply said you put encrypt-to, with your key-id, in your gpg.conf and when you do a gpg --recipient yourfriend it encrypts to your friend and also to you. Regards Stefan From dirk.gottschalk1980 at googlemail.com Mon Dec 31 07:17:21 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Mon, 31 Dec 2018 07:17:21 +0100 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: <20181230224018.5495b170@300baud> References: <20181230224018.5495b170@300baud> Message-ID: Hello. Am Sonntag, den 30.12.2018, 22:40 +0100 schrieb Stefan Claas: > On Sun, 30 Dec 2018 18:05:37 +0100, Gernot Pokorny wrote: > Hi, > > > What is the difference between --encrypt-to and --recipient and > > what are the advantages and disadvantages of using one over the > > other, which one should you use for encrypting your own files and > > what does the following mean? > > --encrypt-to ... The key specified by name is used only when there > > are other recipients given by the user or by use of the option > > recipient. ... > Simply said you put encrypt-to, with your key-id, in your gpg.conf > and when you do a gpg --recipient yourfriend it encrypts to your > friend and also to you. Yes, that's correct. Anyways, I prefer using the --hidden-recipient for this purpose. That prevents the disclosure of the communication paths with pure GPG-Packet analysis. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From gernot.pokorny.dev at gmail.com Mon Dec 31 12:04:29 2018 From: gernot.pokorny.dev at gmail.com (Gernot Pokorny) Date: Mon, 31 Dec 2018 12:04:29 +0100 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: References: <20181230224018.5495b170@300baud> Message-ID: But isn't the documentation wrong for the edge-case when you specify --encryp-to within gpg.conf and do not specify a recipient? According to that documentation when you only specify --encrypt-to, but no --recipient, then the value of --encrypt-to should also not be used and that means we would have no valid command and that there should be an error, which is not the case in the gpg implementation. The gpg that I have running simply takes the name from encrypt-to as a recipient, which makes sense, but is not in sync with the documentation. On Mon, Dec 31, 2018 at 7:57 AM Dirk Gottschalk via Gnupg-users < gnupg-users at gnupg.org> wrote: > Hello. > > Am Sonntag, den 30.12.2018, 22:40 +0100 schrieb Stefan Claas: > > On Sun, 30 Dec 2018 18:05:37 +0100, Gernot Pokorny wrote: > > Hi, > > > > > What is the difference between --encrypt-to and --recipient and > > > what are the advantages and disadvantages of using one over the > > > other, which one should you use for encrypting your own files and > > > what does the following mean? > > > > --encrypt-to ... The key specified by name is used only when there > > > are other recipients given by the user or by use of the option > > > recipient. ... > > > Simply said you put encrypt-to, with your key-id, in your gpg.conf > > and when you do a gpg --recipient yourfriend it encrypts to your > > friend and also to you. > > Yes, that's correct. Anyways, I prefer using the --hidden-recipient for > this purpose. That prevents the disclosure of the communication paths > with pure GPG-Packet analysis. > > Regards, > Dirk > > -- > Dirk Gottschalk > Paulusstrasse 6-8 > 52064 Aachen, Germany > > GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 > Keybase.io: https://keybase.io/dgottschalk > GitHub: https://github.com/Dirk1980ac > > _______________________________________________ > 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 dgouttegattat at incenp.org Mon Dec 31 13:45:44 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 31 Dec 2018 12:45:44 +0000 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: References: <20181230224018.5495b170@300baud> Message-ID: <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> On Mon, Dec 31, 2018 at 07:17:21AM +0100, Dirk Gottschalk via Gnupg-users wrote: > Yes, that's correct. Anyways, I prefer using the --hidden-recipient for > this purpose. That prevents the disclosure of the communication paths > with pure GPG-Packet analysis. You do realize that, in the case of e-mail, the communication paths are already disclosed by the SMTP protocol (command "RCPT TO") and the mail headers ("From", "To", and the like), which both are outside the scope of OpenPGP protection? Using --hidden-recipient only protects against an hypothetic attacker who is somehow only able to obtain the email body (the OpenPGP message itself) without the surrounding metadata. - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From sac at 300baud.de Mon Dec 31 13:57:18 2018 From: sac at 300baud.de (Stefan Claas) Date: Mon, 31 Dec 2018 13:57:18 +0100 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> References: <20181230224018.5495b170@300baud> <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> Message-ID: <20181231135718.0f719f63@300baud> On Mon, 31 Dec 2018 12:45:44 +0000, Damien Goutte-Gattat wrote: > On Mon, Dec 31, 2018 at 07:17:21AM +0100, Dirk Gottschalk via Gnupg-users wrote: > > Yes, that's correct. Anyways, I prefer using the --hidden-recipient for > > this purpose. That prevents the disclosure of the communication paths > > with pure GPG-Packet analysis. > > You do realize that, in the case of e-mail, the communication paths are > already disclosed by the SMTP protocol (command "RCPT TO") and the mail > headers ("From", "To", and the like), which both are outside the scope > of OpenPGP protection? > > Using --hidden-recipient only protects against an hypothetic attacker > who is somehow only able to obtain the email body (the OpenPGP message > itself) without the surrounding metadata. But it is imho good if you use anonymous remailers, either for email or Usenet postings. In the case of email Mallory would only see that Bob received a message, but does not know from whom it originated and in case of proper Usenet usage nobody would know who send the message and who is the recipient. Regards Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From dirk.gottschalk1980 at googlemail.com Mon Dec 31 15:38:10 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Mon, 31 Dec 2018 15:38:10 +0100 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> References: <20181230224018.5495b170@300baud> <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> Message-ID: <3bf3bf9025c0f5ca295dc53a570992741f91fc5d.camel@googlemail.com> Hello Damien. Am Montag, den 31.12.2018, 12:45 +0000 schrieb Damien Goutte-Gattat: > On Mon, Dec 31, 2018 at 07:17:21AM +0100, Dirk Gottschalk via Gnupg- > users wrote: > > Yes, that's correct. Anyways, I prefer using the --hidden-recipient > > for this purpose. That prevents the disclosure of the communication > > paths with pure GPG-Packet analysis. > You do realize that, in the case of e-mail, the communication paths > are already disclosed by the SMTP protocol (command "RCPT TO") and > the mail headers ("From", "To", and the like), which both are outside > the scope of OpenPGP protection? Yes, sure I do. But referencing the command line options, I thought he was speaking about encryption of files. In this case, it could be of (even if small) benefits to avoid the disclosure of the path. > Using --hidden-recipient only protects against an hypothetic attacker > who is somehow only able to obtain the email body (the OpenPGP > message itself) without the surrounding metadata. That's correct. As told, I was talking about encrypted files. If you upload en encrypted file to a cloud service, for example, it could be a good idea to encrypt only to hidden recipients. Security my obscurity is not everytime a bad thing. ;) Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From justina at colmena.biz Mon Dec 31 22:06:39 2018 From: justina at colmena.biz (justina colmena) Date: Mon, 31 Dec 2018 12:06:39 -0900 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: <3bf3bf9025c0f5ca295dc53a570992741f91fc5d.camel@googlemail.com> References: <20181230224018.5495b170@300baud> <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> <3bf3bf9025c0f5ca295dc53a570992741f91fc5d.camel@googlemail.com> Message-ID: <6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz> On December 31, 2018 5:38:10 AM AKST, Dirk Gottschalk via Gnupg-users wrote: >Hello Damien. > >Am Montag, den 31.12.2018, 12:45 +0000 schrieb Damien Goutte-Gattat: >> On Mon, Dec 31, 2018 at 07:17:21AM +0100, Dirk Gottschalk via Gnupg- >> users wrote: >> > Yes, that's correct. Anyways, I prefer using the --hidden-recipient > >> > for this purpose. That prevents the disclosure of the communication >> > paths with pure GPG-Packet analysis. > >> You do realize that, in the case of e-mail, the communication paths >> are already disclosed by the SMTP protocol (command "RCPT TO") and >> the mail headers ("From", "To", and the like), which both are outside >> the scope of OpenPGP protection? > >Yes, sure I do. But referencing the command line options, I thought he >was speaking about encryption of files. In this case, it could be of >(even if small) benefits to avoid the disclosure of the path. > > >> Using --hidden-recipient only protects against an hypothetic attacker >> who is somehow only able to obtain the email body (the OpenPGP >> message itself) without the surrounding metadata. > >That's correct. As told, I was talking about encrypted files. If you >upload en encrypted file to a cloud service, for example, it could be a >good idea to encrypt only to hidden recipients. Security my obscurity >is not everytime a bad thing. ;) > >Regards, >Dirk For some reason I'm not getting a "Reply-To:" for the whole list here... Hidden recipients are normally given in the BCC (Blind Carbon Copy) field in the case of email, and the communication paths are not disclosed to other recipients. Shouldn't an email message (for example) be encrypted separately to each BCC recipient, or is this an intended all-in-one multiple-recipient encryption which cannot conceal from the cryptanalyst the fact that the same message, encrypted only once, is being sent to more than one receiving party? I hate to see the vast number of gpg command-line options get so carried away that we lose grip of the basic cryptography that we want to use GnuPG for. And now the *secret* keys are going in "~/.gnupg/pubring.gpg" with the false implication by its name that the file contains only public keys which need not be so carefully guarded against disclosure. -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: