From bernhard.kleine at gmx.net Tue Oct 1 14:16:15 2019 From: bernhard.kleine at gmx.net (Bernhard Kleine) Date: Tue, 1 Oct 2019 14:16:15 +0200 Subject: We have GOT TO make things simpler In-Reply-To: References: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> Message-ID: <9c8f9df1-bcda-050a-4270-5784fe2d51ef@gmx.net> Am 30.09.2019 um 21:32 schrieb Dennis Clarke: > I use Thunderbird 70.0b2 and have used it for years. However it is a > major pain to implement digital signage and encryption. A pain. I use enigmail and the signing and encrypting runs very smooth with thunderbird. Regards Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From codeguro at gmail.com Wed Oct 2 01:55:04 2019 From: codeguro at gmail.com (Tony Lane) Date: Tue, 1 Oct 2019 19:55:04 -0400 Subject: We have GOT TO make things simpler In-Reply-To: References: Message-ID: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 With all due respect... NO. It is not wise to impede on the power-users who use GPG due to the availability of the various configurations that brought us here in the first place. On 9/30/19 9:43 AM, Roland Siemons wrote:[snip] > 4/ Here is my proposal: > 4.1/ Stimulate that people use a GUI like GPA or Kleopatra. Not Enigmail, although it offers the same, but it offers too much for beginners. Email integration comes after people have a basic understanding. Please do appreciate if people only want to be able to prepare encrypted documents for sending them as attachments. This is not an issue with GnuPG. GnuPG is a back-end utility that front-end applications (like GUIs) interface to. Go to your vendor of choice that interfaces with GPG and complain to them about the complexity their interface. As far as GPG goes, it does exactly what it's supposed to. It's a command-line utility. Its raw interface is not supposed to be exposed to the kind of user you're expecting. > 4.2/ Ensure that, when generating a keypair, GnuPG creates one directory "Secretkeys", and one directory "Publickeys". Make GnuPG to store the public part and the secret part separately in those directories. If GnuPG needs also keypairs in a single file, store that under Secretkeys.Keys are stored in a keyring database. You're not supposed to export them by copying files over in this way. You use the command-line utility to import or export your public keys. For instance, the following command exports all of your signed public keys in PGP format: gpg -a --export ...or you can export a specific key by suffixing that last command with the key (or name or email some other identifier) that you want to export. Exporting private keys is done the same way. Exporting the trust database can be done this way as well, albeit with different options. > 4.5/ Get rid of the options to NOT publish keys on keyservers. Just work the opt-in alternative: If you want to publish to keyservers, make that a separate action that requires some effort.AFAIK, distributing keys to keyservers already takes a separate action. Unless there's some other command I'm not aware about, the only way I see to distribute keys to some keyserver is with the following command: gpg --send-keys $KEY_IDENTIFIER -----BEGIN PGP SIGNATURE----- iLcEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXZPnWAAKCRDo8fj9gx4T 0/YtAgEBKgPN/9Ua2odPSPn2K7g1Qnc2XovMnDWE30reqNT4/cYCQmnVuwjMspqs w5dA7SSIj/fSm9NJptn5dS7y70NoIgIEDJ2+QDNj/4PpUSkkIr3zHpI+y4yIanLP UxWL8YI5mHUAfGAZ05O8HwwDUm+Z+q4joxVjBjP8pNASTklHrf4U32A= =Oi8M -----END PGP SIGNATURE----- From hello at ezaquarii.com Wed Oct 2 22:15:43 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Wed, 2 Oct 2019 21:15:43 +0100 Subject: We have GOT TO make things simpler In-Reply-To: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> Message-ID: On 02/10/2019 00:55, Tony Lane via Gnupg-users wrote: > This is not an issue with GnuPG. GnuPG is a back-end utility that front-end applications (like GUIs) interface to. Go to your vendor of choice that interfaces with GPG and complain (...) And this is precisely why GnuPG failed. Cheers, Chris From dclarke at blastwave.org Thu Oct 3 04:10:49 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 2 Oct 2019 22:10:49 -0400 Subject: We have GOT TO make things simpler In-Reply-To: References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> Message-ID: <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> On 10/2/19 4:15 PM, Chris Narkiewicz via Gnupg-users wrote: > On 02/10/2019 00:55, Tony Lane via Gnupg-users wrote: >> This is not an issue with GnuPG. GnuPG is a back-end utility that front-end applications (like GUIs) interface to. Go to your vendor of choice that interfaces with GPG and complain (...) > > And this is precisely why GnuPG failed. > Cheers, > Chris If a user needs a masters degree and twenty years of experience to use a tool then the tool will only ever be used by such people. Common sense. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From sac at 300baud.de Thu Oct 3 23:53:00 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 3 Oct 2019 23:53:00 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> Message-ID: <20191003235300.00006232.sac@300baud.de> Dennis Clarke wrote: > On 10/2/19 4:15 PM, Chris Narkiewicz via Gnupg-users wrote: > > On 02/10/2019 00:55, Tony Lane via Gnupg-users wrote: > >> This is not an issue with GnuPG. GnuPG is a back-end utility that > >> front-end applications (like GUIs) interface to. Go to your vendor of > >> choice that interfaces with GPG and complain (...) > > > > And this is precisely why GnuPG failed. > > Cheers, > > Chris > > > If a user needs a masters degree and twenty years of experience to use a > tool then the tool will only ever be used by such people. Common sense. And this is probably the reason why digital signatures from GnuPG were never been adopted (for business related things) in the EU and elsewere. A good example for easy creation of digital signatures I came across today. This service is free of charge. One only needs a card reader and his / her ID-card. plus the free Open eCard software. https://pilots.futuretrust.eu/sigs Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From codeguro at gmail.com Fri Oct 4 06:01:44 2019 From: codeguro at gmail.com (Tony Lane) Date: Fri, 4 Oct 2019 00:01:44 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <20191003235300.00006232.sac@300baud.de> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> Message-ID: <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/3/19 5:53 PM, Stefan Claas via Gnupg-users wrote: > And this is probably the reason why digital signatures from GnuPG were never > been adopted (for business related things) in the EU and elsewere. I don't know about the EU, but I can name at least 20 fortune-500 businesses that use GPG, including Facebook (yes, even they use GPG, see for yourself). And those are just the ones -I- know of. And this isn't even counting government. As far as security goes, you cannot beat GnuPG. You do not have to submit your secret online or to some shady third party. In fact, there's an entire industry dedicated to the sorts of services GnuPG provides, you might've heard of one - Yubikey. -----BEGIN PGP SIGNATURE----- iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXZbEKAAKCRDo8fj9gx4T 05qBAgY94RW3iWAsqAp1epy44ArbPCRkU56kq9VihTKqQls/TMDx2FTx28LpafC5 qaUZhvABKoW9/5a2wN0m0av3aaB+bgIJAaCwT2qBU5OYpvxyaDX+RZwQ7GDd1/LT 3B8cJeQhCcDigoO4OazoMd1CgD6F1e63Y+NKeWfnLUlC3mvYcMnc2FQh =abwF -----END PGP SIGNATURE----- From sac at 300baud.de Fri Oct 4 09:35:04 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 4 Oct 2019 09:35:04 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> Message-ID: <20191004093504.00006eef.sac@300baud.de> Tony Lane via Gnupg-users wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 10/3/19 5:53 PM, Stefan Claas via Gnupg-users wrote: > > And this is probably the reason why digital signatures from GnuPG were never > > been adopted (for business related things) in the EU and elsewere. > > I don't know about the EU, but I can name at least 20 fortune-500 businesses > that use GPG, including Facebook (yes, even they use GPG, see for yourself). > And those are just the ones -I- know of. And this isn't even counting > government. As far as security goes, you cannot beat GnuPG. You do not have > to submit your secret online or to some shady third party. In fact, there's > an entire industry dedicated to the sorts of services GnuPG provides, you > might've heard of one - Yubikey. And do those 20 companies business with their customers were GnuPG signatures are legally binding, like real signatures on letters? That for example is the case with eIDAS conform digital signatures here in Europe. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From codeguro at gmail.com Fri Oct 4 19:08:14 2019 From: codeguro at gmail.com (Tony Lane) Date: Fri, 4 Oct 2019 13:08:14 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <20191004093504.00006eef.sac@300baud.de> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/4/19 3:35 AM, Stefan Claas wrote: > And do those 20 companies business with their customers were GnuPG > signatures are legally binding, like real signatures on letters? _At least_ 20 fortune 500 businesses _that I know of_. Mind you, I'm not even counting governments. And yes, it is recognized by the US government at the very least. See https://lists.gnupg.org/pipermail/gnupg-users/2018-September/060987.html and https://app.leg.wa.gov/RCW/default.aspx?cite=42.45.130 > That for example is the case with eIDAS conform digital signatures > here in Europe. Digital signatures are, in general, legally binding. If for instance a government official who's known to use PGP signatures signs off on a treasonous act, that signature can be used against him or her in court of law. But it can also be used for contracts. e-signature is a legal concept used to capture a person?s intent to be legally bound by the terms of an agreement or contract. While a digital signature is a mathematical algorithm. A cryptographic technology used to make data tamper evident, digitally sign of documents. Even the "newer" signatures that are the Elliptic Curves are recognized as per FIPS-186-4, see: https://www.federalregister.gov/documents/2015/10/20/2015-26539/federal-information-processing-standard-fips-186-4-digital-signature-standard-request-for-comments#h-9 and notably https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf -----BEGIN PGP SIGNATURE----- iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXZd8fgAKCRDo8fj9gx4T 02ZvAgjW4j3F1vJna5KRq2po8xW6qmds0u8wUIJNDnQ46nBecy7nxTVyRNgMqdTq kG19RhDdWvQZ850hmeAK6KJiYUAR+gIJAQ7YSL91Ncopuj8Eeamlh/KBpHfsrCS9 KT/7ZaFhKusw8fOz5XjvQxTksxeJrDsAYvIyufjdu837ri+qEqXWMWSd =Lx49 -----END PGP SIGNATURE----- From sac at 300baud.de Fri Oct 4 21:00:37 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 4 Oct 2019 21:00:37 +0200 Subject: We have GOT TO make things simpler In-Reply-To: References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> Message-ID: <20191004210037.00000746.sac@300baud.de> Tony Lane wrote: > Digital signatures are, in general, legally binding. In the EU qualified digital signatures (QES) are legally binding and I strongly doubt that in the U.S. with it's ESIGN Act the same holds true for GnuPG home installations. I guess a proper Google search will show it us. :-) Otherwise the commercially available PGP or free GnuPG would have been mentioned in the news as a low cost eSig solution long time ago, right? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Fri Oct 4 21:28:37 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 4 Oct 2019 21:28:37 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <20191004210037.00000746.sac@300baud.de> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <20191004210037.00000746.sac@300baud.de> Message-ID: <20191004212837.000004f7.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Tony Lane wrote: > > > Digital signatures are, in general, legally binding. > > In the EU qualified digital signatures (QES) are legally binding > and I strongly doubt that in the U.S. with it's ESIGN Act the same > holds true for GnuPG home installations. > > I guess a proper Google search will show it us. :-) Well, I was wrong. It seems that the U.S. ESIGN Act is pretty relaxed and does not need such strong requirements like in the EU. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From hello at ezaquarii.com Sat Oct 5 08:11:03 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Sat, 5 Oct 2019 07:11:03 +0100 Subject: We have GOT TO make things simpler In-Reply-To: References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> Message-ID: <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> > On 10/4/19 3:35 AM, Stefan Claas wrote: >> And do those 20 companies business with their customers were GnuPG >> signatures are legally binding, like real signatures on letters? > > _At least_ 20 fortune 500 businesses _that I know of_. Mind you, I'm not even counting governments. 20? Wow. There are 8 billion people on this planet, most of them don't work at 20 companies from Fortune 500. WhatsApp build crypto system that is successfully adopted by billions of users without technical knowledge. Our views on what can be considered a successful adoption are strongly misaligned. From codeguro at gmail.com Sat Oct 5 09:34:01 2019 From: codeguro at gmail.com (Tony Lane) Date: Sat, 5 Oct 2019 03:34:01 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> Message-ID: <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> On 10/5/19 2:11 AM, Chris Narkiewicz via Gnupg-users wrote: > 20? Wow. There are 8 billion people on this planet, most of them don't > work at 20 companies from Fortune 500. Most don't even work on software to begin with. What's your point? > WhatsApp build crypto system that is successfully adopted by billions of > users without technical knowledge. Did you really set the bar _that_ low? Forgetting for a moment that Whatsapp is proprietary and there's no way to actually audit the code... We already know that governments have been pushing https://archive.is/suDJS for ways to decrypt it directly and that they can in fact read messages via a central authority/server https://archive.is/2TXqU when the receiving user of a message is offline. If you consider deliberately breaking E2E encryption by design a "success" then yes, our views _strongly_ differ on not just what's successful, but also what's acceptable. But go ahead, please rationalize why "ease-of-use" is more important than actual security for power-users such as myself and those who absolutely won't compromise on true E2EE. From sac at 300baud.de Sat Oct 5 12:15:17 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 5 Oct 2019 12:15:17 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> Message-ID: <20191005121517.00006566.sac@300baud.de> Tony Lane via Gnupg-users wrote: > But go ahead, please rationalize why "ease-of-use" is more important than > actual security for power-users such as myself and those who absolutely won't > compromise on true E2EE. Not to rain your parade, but I follow the topic encryption since the mid '80s and can say nowadays that GnuPG has failed to become an email encryption product for the masses, which IIRC was the initial goal of Mr Zimmermann's PGP back in the early ninetees. Instead GnuPG became the ultimate tool for PGPGs[1]. Try the following experiment, as power user: Explain to your loved ones, friends and co-workers GnuPG usage (with all its surrounding stuff like installing MUAs and plug-ins, besides of GnuPG) point them to the FAQ as learning resource and then show them as modern alternative Mailvelope or the new Autocrypt from Vincent ... Once done consider again why in modern software design ease of use is an important factor, if you like to reach out to the masses and want to convince people to use software based on the OpenPGP protocol. [1] Pretty Good Privacy Geek Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From siemons at cleanfuels.nl Sat Oct 5 12:52:02 2019 From: siemons at cleanfuels.nl (Roland Siemons) Date: Sat, 5 Oct 2019 12:52:02 +0200 Subject: We have GOT TO make things simpler In-Reply-To: References: Message-ID: Dear List, I explained a problem. I proposed a step forward towards a solution. There were 17 responses. So far, those responses either: - advised to no longer use GnuPG, or - denied or downplayed the problem (although I demonstrated the existence of the problem), or - argued against those who denied or downplayed the problem. No single response touched upon my proposal. This is very disappointing. Developers, please consider my proposition, and tell me what you like or dislike about it. Sincerely, Roland From wk at gnupg.org Sat Oct 5 13:12:16 2019 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Oct 2019 13:12:16 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <20191004212837.000004f7.sac@300baud.de> (Stefan Claas via Gnupg-users's message of "Fri, 4 Oct 2019 21:28:37 +0200") References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <20191004210037.00000746.sac@300baud.de> <20191004212837.000004f7.sac@300baud.de> Message-ID: <87zhiffnu7.fsf@wheatstone.g10code.de> On Fri, 4 Oct 2019 21:28, Stefan Claas said: > Well, I was wrong. It seems that the U.S. ESIGN Act is pretty relaxed > and does not need such strong requirements like in the EU. The EU neither. Even the Qualifizierte Elektronische Signatur, introduced in Germany ages ago, is not anymore a requirement for the majority of transactions. In fact the Einfache Elektronische Signatur (i.e. your name below a email) is often sufficient. It is the same as with handwritten signatures - if it comes to a litigation the court decides and evaluates the entire circumstances. Having a government issued token (e.g. a qualified electronic signature) puts more trust into the validity of the signature but still allows the signer to repudiate the signature just by telling that the token was lost and the PIN was on an attached post-it. Recall that for VAT purposes (the major revenue source of almost countries) no signature on digital invoices is required. A EU decision once overturned the German requirement for a government issued qualified signature on invoices and thus was the tombstone for the qualified electronic signature (modulo that some companies try to keep them alive as their business model but that, along with their questionable legal hack, is a different story). It is a perfectly okay to allow a Fortgeschrittene Elektronische Signatur (advanced electronic sigature, i.e. S/MIME or OpenPGP) to replace a handwritten signature if that has been stated in contracts or constitutional documents or their bylaws. This prima facie evidence is nearly always sufficient unless notarial documents are anyway required. There is a lot of literature on that topic which can easily be found and studied. It is is not the topic of this technical mailing list, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Sat Oct 5 13:19:51 2019 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Oct 2019 13:19:51 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <20191005121517.00006566.sac@300baud.de> (Stefan Claas via Gnupg-users's message of "Sat, 5 Oct 2019 12:15:17 +0200") References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> Message-ID: <87v9t3fnhk.fsf@wheatstone.g10code.de> On Sat, 5 Oct 2019 12:15, Stefan Claas said: > installing MUAs and plug-ins, besides of GnuPG) point them to the FAQ as > learning resource and then show them as modern alternative Mailvelope And don't forget to point them to all the HOWTOS and RFCs required to to use and admin a MUA, sendmail, and the net configuration to name just a few. The point here is that you falsely compare a system tool with an end user visible interface. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jrallen at runbox.com Sat Oct 5 14:05:37 2019 From: jrallen at runbox.com (Jeff Allen) Date: Sat, 5 Oct 2019 08:05:37 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <20191005121517.00006566.sac@300baud.de> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> Message-ID: <1fc1b0c7-f376-30aa-30f6-6d626d53bcb3@runbox.com> On 10/5/19 6:15 AM, Stefan Claas via Gnupg-users wrote: > Tony Lane via Gnupg-users wrote: > >> But go ahead, please rationalize why "ease-of-use" is more important than >> actual security for power-users such as myself and those who absolutely won't >> compromise on true E2EE. > > Not to rain your parade, but I follow the topic encryption since the mid '80s > and can say nowadays that GnuPG has failed to become an email encryption > product for the masses, which IIRC was the initial goal of Mr Zimmermann's PGP > back in the early ninetees. The original poster, perhaps unintentionally, stated the real reason the masses have not adopted PGP, "Please do appreciate that the persons who we are convincing and instructing are not particularly interested in privacy." That's it in a nutshell. The masses are not particularly interested in privacy. If they were, they'd abandon Gmail and Yahoo and all the other providers who make no excuse for the fact their economic model depends on users being not particularly interested in privacy. I have used GnuPG since it was first released and PGP2 and PGP5 before that. I read "Why Johnny Can't Encrypt" 20 years ago. I didn't believe it then and don't believe it now because in my experience any sufficiently motivated, reasonably intelligent person who wants to use these tools can learn to do so expending less time and effort than it takes to master the latest video game. > Instead GnuPG became the ultimate tool for PGPGs[1]. Sure it is. As Mr. Lane explained, its supposed to be. But that doesn't mean that it can't be used by non-PGPGs. You don't have to understand every command and option to use GnuPG effectively. A handful will suffice for file or email encryption. > Try the following experiment, as power user: Explain to your loved ones, > friends and co-workers GnuPG usage (with all its surrounding stuff like > installing MUAs and plug-ins, besides of GnuPG) point them to the FAQ as > learning resource and then show them as modern alternative Mailvelope > or the new Autocrypt from Vincent ... I agree that there are easier-to-learn encryption solutions than GnuPG. Mailvelope, FlowCrypt, ProtonMail, Mailfence and Tutanota come immediately to mind. Any is adequate for the privacy needs of the masses. Unfortunately, the masses haven't swarmed to them any more than to PGP or GnuPG. The masses think they have nothing to hide. They aren't at all concerned about privacy. > [1] Pretty Good Privacy Geek Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Sat Oct 5 14:34:18 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 5 Oct 2019 14:34:18 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <87v9t3fnhk.fsf@wheatstone.g10code.de> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <87v9t3fnhk.fsf@wheatstone.g10code.de> Message-ID: <20191005143418.00001d60.sac@300baud.de> Werner Koch wrote: > On Sat, 5 Oct 2019 12:15, Stefan Claas said: > > > installing MUAs and plug-ins, besides of GnuPG) point them to the FAQ as > > learning resource and then show them as modern alternative Mailvelope > > And don't forget to point them to all the HOWTOS and RFCs required to to > use and admin a MUA, sendmail, and the net configuration to name just a > few. The point here is that you falsely compare a system tool with an > end user visible interface. Well, it has to do with the fact that I started with MacPGP in the mid '90s which was GUI based and no Linux system tool. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Sat Oct 5 15:41:40 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 5 Oct 2019 15:41:40 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <1fc1b0c7-f376-30aa-30f6-6d626d53bcb3@runbox.com> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <1fc1b0c7-f376-30aa-30f6-6d626d53bcb3@runbox.com> Message-ID: <20191005154140.0000217f.sac@300baud.de> Jeff Allen via Gnupg-users wrote: > I agree that there are easier-to-learn encryption solutions than GnuPG. > Mailvelope, FlowCrypt, ProtonMail, Mailfence and Tutanota come > immediately to mind. Any is adequate for the privacy needs of the > masses. Unfortunately, the masses haven't swarmed to them any more than > to PGP or GnuPG. The masses think they have nothing to hide. They > aren't at all concerned about privacy. We should also ask ourselves why for example a required minimum set from the OpenPGP protocol is not natively supported by major apps, like MUAs and Web browsers or on OS level like GnuPG in Linux but not in macOS or Windows? Everybody speaks https or smtps and probably S/MIME but what about OpenPGP? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From rjh at sixdemonbag.org Sat Oct 5 16:00:53 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 5 Oct 2019 10:00:53 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <20191005154140.0000217f.sac@300baud.de> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <1fc1b0c7-f376-30aa-30f6-6d626d53bcb3@runbox.com> <20191005154140.0000217f.sac@300baud.de> Message-ID: > Everybody speaks https or smtps and probably S/MIME but what about > OpenPGP? S/MIME adoption has far exceeded OpenPGP's in the world of email for a simple reason: You can make a whole ton of money as an S/MIME CA. OpenPGP was designed such as to, as far as possible, cut centralized trusted introducers out of the equation. Of course, those centralized trusted introducers are also the groups with the greatest ability to influence market decisions. ("While you're buying new SSL certs for your business, have you thought about email security? We offer S/MIME certs for affordable prices...") S/MIME prevailed over OpenPGP not for technical decisions, but economic ones. Given this is a technical mailing list, we should probably just give a grudging nod in the direction of Adam Smith and his Invisible Hand and move on to more technically-oriented lines of discussion. From rjh at sixdemonbag.org Sat Oct 5 16:06:41 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 5 Oct 2019 10:06:41 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> Message-ID: > Our views on what can be considered a successful adoption are strongly > misaligned. OpenPGP was never meant to be about email. It was never meant to be about instant messaging. It was never meant to be about any of that. It was meant to be a toolbox people could use to help solve a wide variety of communications security problems, and in that respect it's been astonishingly successful. For example, pretty much every Linux installation on the planet uses GnuPG to verify downloaded packages. Every single time you update your Linux box, you're calling GnuPG to verify your supply chain. If you want to say "OpenPGP hasn't been successful in this specific niche," well, that may or may not be true, dunno, but we can at least discuss it. But if you say "OpenPGP hasn't been successfully adopted," there you're just wrong: there are lots of niches it's been successfully adopted. They're just ones you're either unaware of or deem unimportant. From rjh at sixdemonbag.org Sat Oct 5 16:10:06 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 5 Oct 2019 10:10:06 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <20191005121517.00006566.sac@300baud.de> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> Message-ID: <6d512982-bf9b-134b-7075-755e48228f88@sixdemonbag.org> > Not to rain your parade, but I follow the topic encryption since the mid '80s > and can say nowadays that GnuPG has failed to become an email encryption > product for the masses, which IIRC was the initial goal of Mr Zimmermann's PGP > back in the early ninetees. It was not to be an email encryption tool. It was to be a *file* encryption tool. This is all that RFC1991 has to say about email: "This radix-64 conversion ... is used to protect binary messages during transmission over non-binary channels, such as Internet Email." That's it. The only other mention of "email" in the entire document is to list email addresses for Derek Atkins, Bill Stallings, and Phil Zimmermann. From sac at 300baud.de Sat Oct 5 17:40:49 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 5 Oct 2019 17:40:49 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <6d512982-bf9b-134b-7075-755e48228f88@sixdemonbag.org> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <6d512982-bf9b-134b-7075-755e48228f88@sixdemonbag.org> Message-ID: <20191005174049.00007684.sac@300baud.de> Robert J. Hansen wrote: > > Not to rain your parade, but I follow the topic encryption since the mid > > '80s and can say nowadays that GnuPG has failed to become an email > > encryption product for the masses, which IIRC was the initial goal of Mr > > Zimmermann's PGP back in the early ninetees. > > It was not to be an email encryption tool. It was to be a *file* > encryption tool. > > This is all that RFC1991 has to say about email: > > "This radix-64 conversion ... is used to protect binary messages during > transmission over non-binary channels, such as Internet Email." > > That's it. The only other mention of "email" in the entire document is > to list email addresses for Derek Atkins, Bill Stallings, and Phil > Zimmermann. Well, I only remember learning about PGP back then in Usenet and everybody used it for email communications or with Cypherpunk Remailers and seldom for file encryption. Anyways then one question arises ... if it's design goal was only meaned for file encryption why then pub keys with email addresses, names and a WoT back then plus shortly later key servers and the stories about Alice, Bob, Eve and Mallory? Wasn't for example Mallory not always interested in Alice's and Bob's email communications? I no longer have the original MIT booklet from Mr Zimmermann, to check in there. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From rjh at sixdemonbag.org Sat Oct 5 18:30:09 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 5 Oct 2019 12:30:09 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <20191005174049.00007684.sac@300baud.de> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <6d512982-bf9b-134b-7075-755e48228f88@sixdemonbag.org> <20191005174049.00007684.sac@300baud.de> Message-ID: > Well, I only remember learning about PGP back then in Usenet and everybody > used it for email communications or with Cypherpunk Remailers and seldom for > file encryption. No, they were using it for file encryption. They were using email as a file transport protocol. That's what inline PGP is: you take a blob of data, do crypto, base64 it, drop it in email. At the other end you pull it out and undo the process. But the inline PGP payload is in *absolutely no way* integrated into the email message. That had to wait until the PGP/MIME RFCs -- that was when OpenPGP became an email protocol. > Anyways then one question arises ... if it's design goal was only meaned for > file encryption why then pub keys with email addresses, names and a WoT back > then plus shortly later key servers and the stories about Alice, Bob, Eve and > Mallory? See above. Email was used as a way to transfer files. But there was nothing special about using email to transfer files. You could just as easily replace the Alice, Bob, and Eve stories by saying "Alice is delivering a 5.25-inch floppy to Bob, but is afraid Eve might get her hands on it while Alice is distracted at the coffeeshop." From wk at gnupg.org Sat Oct 5 18:54:02 2019 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Oct 2019 18:54:02 +0200 Subject: How to improve our GUIs (was: We have GOT TO make things simpler) In-Reply-To: (Roland Siemons's message of "Mon, 30 Sep 2019 10:58:09 +0200") References: Message-ID: <87h84nf80l.fsf_-_@wheatstone.g10code.de> On Mon, 30 Sep 2019 10:58, Roland Siemons said: > 4/ Here is my proposal: > 4.1/ Stimulate that people use a GUI like GPA or Kleopatra. Not Enigmail, Enigmail folks won't like that suggestion. Users need to install a second tool which behaves different (because Enigmail implements parts of GnuPG on its own). I agree with you and, although I sometimes hack on GPA, I would suggest Kleopatra. On Windows Kleopatra and the Explorer plugin do actually do what you suggest and we LOTS of folks using Gpg4win. Be it for plain file encryption or for its Outlook plugin. > 4.2/ Ensure that, when generating a keypair, GnuPG creates one directory > "Secretkeys", and one directory "Publickeys". Make GnuPG to store the public > part and the secret part separately in those directories. If GnuPG needs also > keypairs in a single file, store that under Secretkeys. That are all internals of GnuPG (except for the revocations directory) and should not be touched by most users. The problem is that there are so many howtos and tutorials floating around which suggest to modify this or that or to do that. In most cases this is not appropriate. gpg --import and --export are the interfaces which users need to know about - iff they really want to use the gpg _tool_. See your first point. > 4.3/ Get rid of the confusing menu/Exportkeys/ vs. menu/Exportsecretkey. etc. Exporting public keys is an important operation for everyone and thus it needs to be prominent. Exporting secret keys should come with a strong warning or better be removed and replaced by a sync-with-other-device feature. If you have concrete suggestions for Kleopatra, I am sure Andre will listen to you. For GPA it is unlikely that we put a lot work into it - it is these days mostly a test bench for my changes to GPGME. > 4.5/ Get rid of the options to NOT publish keys on keyservers. Just work the > opt-in alternative: If you want to publish to keyservers, make that a separate > action that requires some effort. No. Despite the current problems with keyservers, we like keyservers because they make public key encryption easier. Deployment of the Web Key Directory is still rare and some mail providers will never deploy that. Thus the second best option is to send initially a signed mail and the recipient can then reply encrypted - this works by looking up the signature key on a keyserver and use that for encryption. We are currently in the process of tweaking this so that we can eventually make this again the default behaviour. Shalom-Salam, Werner p.s. I took the freedom to change the subject to better reflect what your suggestion is about. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From johndoe65534 at mail.com Sat Oct 5 20:05:55 2019 From: johndoe65534 at mail.com (john doe) Date: Sat, 5 Oct 2019 20:05:55 +0200 Subject: How to improve our GUIs (was: We have GOT TO make things simpler) In-Reply-To: <87h84nf80l.fsf_-_@wheatstone.g10code.de> References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> Message-ID: <599023a9-9eca-96c5-cfe5-2d43d25f02f6@mail.com> On 10/5/2019 6:54 PM, Werner Koch via Gnupg-users wrote: > On Mon, 30 Sep 2019 10:58, Roland Siemons said: > >> 4/ Here is my proposal: >> 4.1/ Stimulate that people use a GUI like GPA or Kleopatra. Not Enigmail, > > Enigmail folks won't like that suggestion. Users need to install a > second tool which behaves different (because Enigmail implements parts > of GnuPG on its own). > > I agree with you and, although I sometimes hack on GPA, I would suggest > Kleopatra. On Windows Kleopatra and the Explorer plugin do actually do > what you suggest and we LOTS of folks using Gpg4win. Be it for plain > file encryption or for its Outlook plugin. > >> 4.2/ Ensure that, when generating a keypair, GnuPG creates one directory >> "Secretkeys", and one directory "Publickeys". Make GnuPG to store the public >> part and the secret part separately in those directories. If GnuPG needs also >> keypairs in a single file, store that under Secretkeys. > > That are all internals of GnuPG (except for the revocations directory) > and should not be touched by most users. The problem is that there are > so many howtos and tutorials floating around which suggest to modify > this or that or to do that. In most cases this is not appropriate. > gpg --import and --export are the interfaces which users need to know > about - iff they really want to use the gpg _tool_. See your first point. > >> 4.3/ Get rid of the confusing menu/Exportkeys/ vs. menu/Exportsecretkey. etc. > > Exporting public keys is an important operation for everyone and thus it > needs to be prominent. Exporting secret keys should come with a strong > warning or better be removed and replaced by a sync-with-other-device > feature. > > If you have concrete suggestions for Kleopatra, I am sure Andre will > listen to you. For GPA it is unlikely that we put a lot work into it - > it is these days mostly a test bench for my changes to GPGME. > Given that, wouldn't be better to remove GPA all together from Gpg4win? As an aside, I don't use Cleopatra at all, is there anyway to install Gpg4win without Cliopatra? Inother words, how can I only install the command line version of GPG on Windows. -- John Doe From codeguro at gmail.com Sat Oct 5 22:57:44 2019 From: codeguro at gmail.com (Tony Lane) Date: Sat, 5 Oct 2019 16:57:44 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <87v9t3fnhk.fsf@wheatstone.g10code.de> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <87v9t3fnhk.fsf@wheatstone.g10code.de> Message-ID: <655cb424-146e-0d93-07e3-e717b0beaa70@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/5/19 7:19 AM, Werner Koch via Gnupg-users wrote: > On Sat, 5 Oct 2019 12:15, Stefan Claas said: > >> installing MUAs and plug-ins, besides of GnuPG) point them to the FAQ as >> learning resource and then show them as modern alternative Mailvelope > > And don't forget to point them to all the HOWTOS and RFCs required to to > use and admin a MUA, sendmail, and the net configuration to name just a > few. The point here is that you falsely compare a system tool with an > end user visible interface. Thank you. This was exactly the point that set me off in my first message. The standalone GnuPG interface was never meant for those kinds of end-users. It was meant for power-users, system administrators, developers, and other folk who know their way around the terminal. If we want, say, an elegant graphical user interface for your average Joe, then that's a discussion to be had. But it's not an issue with GnuPG, per say. Applications that interface to GnuPG are responsible for _that_ burden. You don't go complain to OpenSSL devs when it's difficult to attain a secure connection to some website unless it's a technical issue with OpenSSL. No, you complain to Mozilla (or whoever made your browser of choice) or to Github admins. OpenSSL (or NSS, whatever your tool of choice) is just a back-end utility that non-tech-folk who don't know what they're doing should -never- interface to. And it's not because it's a difficult tool to use (it is), but because it's not intended for them. Dumbing the interface down, _especially_ if it compromises its security or our level of control over it, is a recipe for disaster. /endrant -----BEGIN PGP SIGNATURE----- iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXZkDyAAKCRDo8fj9gx4T 0wd8AgkB71/0Q2AE0QxTQsDLtvCnnuZo2bOGhyhOKeNaJ0FiTcGdxIo+nAyEh+NF D1DF0wIAkfSywJemPVFP2NaHGm2JPvcCCLLfVZ7ZeYT86BvVnrcnlNFXSGZkNiVC JXwuTjLNRNsgG/TI+KwtBZmfQmeQ3Cs2XNle63yKHeRw9BRQD+ERo1LR =KeRH -----END PGP SIGNATURE----- From vedaal at nym.hush.com Sun Oct 6 03:21:07 2019 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Sat, 05 Oct 2019 21:21:07 -0400 Subject: How to improve our GUIs (was: We have GOT TO make things simpler) In-Reply-To: <87h84nf80l.fsf_-_@wheatstone.g10code.de> References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> Message-ID: <20191006012108.4180D40620@smtp.hushmail.com> On 10/5/2019 at 12:58 PM, "Werner Koch via Gnupg-users" wrote: >I agree with you and, although I sometimes hack on GPA, I would >suggest >Kleopatra. On Windows Kleopatra and the Explorer plugin do >actually do >what you suggest and we LOTS of folks using Gpg4win. Be it for >plain >file encryption or for its Outlook plugin. ... >If you have concrete suggestions for Kleopatra, ===== Kleopatra already has an export keys menu. Right Click on any key, and a menu opens, with the options of 'Export Key' and then a separate option of "Export Secret Keys" and works on Ubuntu (and probably on other Linux flavors too, but have not tested them) vedaal From pittillojack87 at gmail.com Sat Oct 5 13:13:05 2019 From: pittillojack87 at gmail.com (Jack Pittillo) Date: Sat, 5 Oct 2019 07:13:05 -0400 Subject: We have GOT TO make things simpler Message-ID: <3EA22721-0222-43F1-ADC1-8798EDECFC0C@gmail.com> Sent from my iPad From howlatmoon at omail.pro Sun Oct 6 19:31:03 2019 From: howlatmoon at omail.pro (Caleb Wolf) Date: Sun, 6 Oct 2019 17:31:03 +0000 Subject: "best" ed25519/curve25519 setup? In-Reply-To: <20180101183331.GA7187%40localhost.localdomain> References: <20180101183331.GA7187%40localhost.localdomain> Message-ID: <8f7fb443-3875-52ab-cc09-6b84333c7b30@omail.pro> On Mon, 01 Jan 2018 at 19:33:31 +0100, Guilhem Moulin wrote: > Hi Simon, > > On Mon, 01 Jan 2018 at 14:28:34 +0100, Simon Josefsson wrote: >> I want to use ed25519/curve25519, but right now I have an offline >> master RSA key with three subkeys. Does it work well to add new >> subkeys for Ed25519/Curve25519? What is the user experience in >> various applications? I'm thinking MUAs, SSH, git, gpg itself, and >> also more exotic approaches like K9Mail. > > AFAICT multiple Ed25519/Curve25519 subkeys work fine, with the following > caveats: > > * You'll want to sign with both your Ed25519 and non-ECC (sub-)keys, > otherwise non-ECC capable OpenPGP implementations won't be able to > verify your data signatures. You can do this by adding > > local-user $FINGERPRINT! > > for each (sub)key to sign with (note the trailing exclamation mark > to specify the subkey). > > * You'll want to create your Curve25519 encryption subkey *after* the > non-ECC one, as `gpg --encrypt --recipient $KEYID` only uses the > most recent valid encryption-capable subkey, I think. So if you > have an older non-ECC encryption subkey, older gpg(1) will encrypt > to it while ?2.1 will use the Curve25519 encryption subkey. > > * You can use multiple authentication subkeys with gpg-agent's SSH > agent emulation, but `gpg --export-ssh-key $KEYID` currently only > exports the most recent authentication (sub)key, so you'll need to > generate the relevant authorized_keys(5) for OpenSSH as follows: > > gpg --with-colons --list-key $FINGERPRINT \ > | sed -nr 's/^[ps]ub:[^deir:]*(:[^:]*){2}:([0-9a-fA-F]+)(:[^:]*){7}a.*/\2/p' \ > | xargs -I{} gpg --export-ssh-key {}\! > > (note the trailing exclamation mark to specify the subkey). Recent > OpenSSH's PubkeyAcceptedKeyTypes default value contain ?ssh-ed25519, > ssh-rsa? in that order so the Ed25519 (sub)key will be tried first. > Older OpenSSH ? that don't support Ed25519 ? will fallback to the > RSA (sub)key. > >> The alternative for me of course is to create a brand new key, with an >> offline Ed25519 master key, plus some subkeys. Has anyone done this, >> and can share their experience? > > IMHO it's too early to use an Ed25519 master key in production, because > there are still a lot of legacy systems out there and that will make the > whole key unusable for encryption and verification. It's fine to start > bring such key to KSPs to improve its reputation and have a less painful > key rollover later, though :-) > Hi, This is a bit of a necro post but it seemed most appropriate to reply here. I have two 4096 bit RSA keys, one is for work, and one is my personal one. I got given a Yubikey 5 https://www.yubico.com/product/yubikey-5-nfc and wanted to make use of it. In fact I was thinking of doing something like https://www.grepular.com/An_NFC_PGP_SmartCard_For_Android as I have a phone that has NFC. I do want to email people on Protonmail, I believe they like ECC https://protonmail.com/blog/elliptic-curve-cryptography/ as their default now. I still want to remain compatible for people who can only do RSA. I am not on Protonmail however, I use my own email server with Thunderbird, or K-9 Mail on my phone. What I want to know is, is this still the best way I should set things up. I was thinking this: # Personal RSA offline master key RSA subkey for signature RSA subkey for decryption RSA subkey for authentication Ed25519 subkey for signature Curve25519 subkey for authentication Curve25519 subkey for decryption # Work RSA offline master key RSA subkey for signature RSA subkey for decryption RSA subkey for authentication Ed25519 subkey for signature Curve25519 subkey for authentication Curve25519 subkey for decryption Then loading both keys and the subkeys on my Yubikey 5. I understand keys cannot be removed once they are loaded on to the Yubikey for security reasons. For safe keeping I was going to burn my keys onto an optical disc and put it in my safety deposit box. (Just in case I lost the Yubikey or it broke). My already existing keypair would become my "master key" and I would start using the subkeys I guess. The next post in this thread https://lists.gnupg.org/pipermail/gnupg-users/2018-January/059863.html kind of confused me: On Mon, 23 Jan 2018 at 09:01:25 +0100, Simon Josefsson wrote: > I already have a good RSA-based master key setup: > > RSA offline master key > RSA subkey for signature > RSA subkey for decryption > RSA subkey for authentication > > So I'm thinking that my new setup should be 25519-based. > > Would you want to use separate Curve25519 keys for authentication and > signatures? > > So I guess the "perfect" setup for me would then be to add the following > new key: > > Ed25519 offline master key > Ed25519 subkey for signature > Curve25519 subkey for authentication > Curve25519 subkey for decryption > > ? > Wouldn't using a separate Ed25519/Curve25519 key like this make it incompatible with people who are unable to decrypt ECC? > I could adopt the middle way and continue to use my current RSA-based > key and a new Ed25519-based key, and have both algorithms available as > subkeys. > > RSA offline master key > RSA subkey for signature > RSA subkey for decryption > RSA subkey for authentication > Ed25519 subkey for signature > Curve25519 subkey for authentication > Curve25519 subkey for decryption > > Ed25519 offline master key > RSA subkey for signature > RSA subkey for decryption > RSA subkey for authentication > Ed25519 subkey for signature > Curve25519 subkey for authentication > Curve25519 subkey for decryption > > I wonder if I should re-use the RSA subkeys from my current key into the > new one... I suppose for SSH it would be useful, but for anything > OpenPGP-related it should be based on the master key id, right? > > Algorithm migration is really tricky... Wouldn't having a Ed25519 master key be incompatible with anything that cannot handle ECC? It seems a bit redundant to have two master keys. -- Caleb Wolf From hello at ezaquarii.com Sun Oct 6 22:03:01 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Sun, 6 Oct 2019 21:03:01 +0100 Subject: We have GOT TO make things simpler In-Reply-To: References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> Message-ID: On 05/10/2019 15:06, Robert J. Hansen wrote: > OpenPGP was never meant to be about email. https://www.openpgp.org/ tells a different story. It would benefit the community if you guys stop bending over backwards, explaining potential users that their needs are invalid. Over and out. I really don't want to continue this fruitless conversation. Chris From 2017-r3sgs86x8e-lists-groups at riseup.net Sun Oct 6 23:58:03 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sun, 6 Oct 2019 22:58:03 +0100 Subject: How to improve our GUIs (was: We have GOT TO make things simpler) In-Reply-To: <599023a9-9eca-96c5-cfe5-2d43d25f02f6@mail.com> References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> <599023a9-9eca-96c5-cfe5-2d43d25f02f6@mail.com> Message-ID: <123774961.20191006225803@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 5 October 2019 at 7:05:55 PM, in , john doe wrote:- > In other words, how can I only install the command > line version of GPG on > Windows. At https://gnupg.org/download/index.html#sec-1-2 there's a link to download "Simple installer for the current GnuPG" (and a link to a signature file to check integrity of the installer file). - -- Best regards MFPA Artificial Intelligence is no match for natural stupidity. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXZpjf18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +kNcAQCWt2aZUDHGO8jOJLzUhnYWE76dnok88O3Ff44hUK8BKAEAoicub5JiTeq9 9t7DholXFSzt5WeqXVJtYRzbkRYhDACJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXZpjgF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/6wVD/9qK28etDThbBhTelgz+UPFH6Sn WhF8CKqGEarYGkGixVGgIon+Cgwndh6/vxqkQuf5PUXraW5i2z5oe+Qy1XwwtZpW /NlGJCJJoEIPtkMQWLwKOhKOuJH0OpPIxae7ESfo8H/u/ObmG5uz5dMAUeCiDxNp m4vAZxipS/9gWFxKC6tiKaTgayUOAguWAPzGjQqyzGHur6OKjZvee3H9SKcuWMIc stm9jf10K8qv2bEHGvfWfvWGkbqAyt1MwWP2D+Cy64yMJ4IkQy+quJTYn4IwoQRH Vehn2zqZT7iX+bQne59S08luOka2FJ7KfDS7GpD09+xYVLgdUZeJZolHQbxhO9ST pIIQOI7fTGM4MQ7zI17pD32qrKryrS0LJXPqG94UJVScoYXLVSUCnlrYzJkXX5Bm qJS9Gi6cwu259pzf3lmu3773iELuE1Io3SBXD024kAvXnCWgrR+vOeD8nz+wPp2W xb0e9lHzVYDSGwCTH1ijJS2soC4r0VueIHiH1od9Sm1vdpqWBSwwtZsD6f/D6HaZ F3IhOSww9bsbtpOoUqv5O0MmVkoW2q6DcpHUTEam4Y2l/Yl0LJTOLDuU7EsjfSfF oEy+B4DdU4/8O5KcMqQr4TKGsmv7qDgNquv8OcE18lztE6Wf//esBsjZkdrr9mx7 gQ0PGPIGP7c8NYITJQ== =++Ix -----END PGP SIGNATURE----- From johndoe65534 at mail.com Mon Oct 7 10:15:54 2019 From: johndoe65534 at mail.com (john doe) Date: Mon, 7 Oct 2019 10:15:54 +0200 Subject: How to improve our GUIs (was: We have GOT TO make things simpler) In-Reply-To: <123774961.20191006225803@my_localhost_LG> References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> <599023a9-9eca-96c5-cfe5-2d43d25f02f6@mail.com> <123774961.20191006225803@my_localhost_LG> Message-ID: <543a86d8-21bf-aec3-5141-84e005d2def6@mail.com> Hi, thanks for your answer. > Hi > > > On Saturday 5 October 2019 at 7:05:55 PM, in > , john doe wrote:- > > >> In other words, how can I only install the command >> line version of GPG on >> Windows. > > At https://gnupg.org/download/index.html#sec-1-2 there's a link to > download "Simple installer for the current GnuPG" (and a link to > a signature file to check integrity of the installer file). > > In the above link, only the cli version of the 1.4 release is available. I got it from (1). As far as I can tell, at (1) there is noway to checksum the downloaded files, would it be possible to add the ability to checksum the binaries? Idealy, all binaries would be checksummed in a file and that file would be also gpg signed. 1) https://gnupg.org/ftp/gcrypt/binary/ -- John Doe From wk at gnupg.org Mon Oct 7 12:04:33 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Oct 2019 12:04:33 +0200 Subject: How to improve our GUIs In-Reply-To: <20191006012108.4180D40620@smtp.hushmail.com> (vedaal via Gnupg-users's message of "Sat, 05 Oct 2019 21:21:07 -0400") References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> <20191006012108.4180D40620@smtp.hushmail.com> Message-ID: <878spweury.fsf@wheatstone.g10code.de> On Sat, 5 Oct 2019 21:21, vedaal said: > and then a separate option of > "Export Secret Keys" The OP explictly suggested to make the exporting of the secret key not too easy so that users don't accidently send out their secret keys. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Oct 7 12:03:03 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Oct 2019 12:03:03 +0200 Subject: How to improve our GUIs In-Reply-To: <543a86d8-21bf-aec3-5141-84e005d2def6@mail.com> (john doe's message of "Mon, 7 Oct 2019 10:15:54 +0200") References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> <599023a9-9eca-96c5-cfe5-2d43d25f02f6@mail.com> <123774961.20191006225803@my_localhost_LG> <543a86d8-21bf-aec3-5141-84e005d2def6@mail.com> Message-ID: <87d0f8euug.fsf@wheatstone.g10code.de> On Mon, 7 Oct 2019 10:15, john doe said: > In the above link, only the cli version of the 1.4 release is available. > I got it from (1). Nope. That is always the current 2.2. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupgpacker at on.yourweb.de Mon Oct 7 10:37:56 2019 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Mon, 7 Oct 2019 10:37:56 +0200 Subject: Manipulating primary key and subkeys at once with key *... Message-ID: <000001d57cea$8768c700$963a5500$@on.yourweb.de> Hello, possibly there is a bug present if manipulating a GnuPG key with subkeys attached!? Example: We want to expire validity of primary key and all subkeys. C:>gpg --edit-key 7BF4xxxx gpg> expire This command modifies the date for primary key only, subkeys are NOT affected. BUT: C:>gpg --edit-key 7BF4xxxx gpg> key * gpg> expire This command only modifies the date for all subkeys, primary key is NOT affected. In my opinion gpg> key * should select all included key parts, primary key + all subkeys, but it doesn't!? So is it 'by design' (not logical, why?) or is it a bug in GnuPG-2.2x? How to select all key parts (sec + ssb + ssb + ssb...)? Thx + regards, Chris From wk at gnupg.org Mon Oct 7 12:29:30 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Oct 2019 12:29:30 +0200 Subject: We have GOT TO make things simpler In-Reply-To: (Robert J. Hansen's message of "Sat, 5 Oct 2019 12:30:09 -0400") References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <6d512982-bf9b-134b-7075-755e48228f88@sixdemonbag.org> <20191005174049.00007684.sac@300baud.de> Message-ID: <874l0ketmd.fsf@wheatstone.g10code.de> On Sat, 5 Oct 2019 12:30, Robert J. Hansen said: > *absolutely no way* integrated into the email message. That had to wait > until the PGP/MIME RFCs -- that was when OpenPGP became an email protocol. MIME types for PGP inline were used on Unix soon after the introduction of MIME in 1992 at about the same time PGP started its life. The original use cases for MSDOS PGP were BBS (e.g. FidoNet) where it does not make sense to distinguish between mail and files. RFC-2015 (PGP/MIME) was published in fall 1996 and predates the OpenPGP specs. I recall that Mutt implemented PGP/MIME even before its publication. > See above. Email was used as a way to transfer files. But there was > nothing special about using email to transfer files. You could just as Everything is a file on Unix (or well, on Plan-9) ;) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From johndoe65534 at mail.com Mon Oct 7 15:35:14 2019 From: johndoe65534 at mail.com (john doe) Date: Mon, 7 Oct 2019 15:35:14 +0200 Subject: How to improve our GUIs In-Reply-To: <87d0f8euug.fsf@wheatstone.g10code.de> References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> <599023a9-9eca-96c5-cfe5-2d43d25f02f6@mail.com> <123774961.20191006225803@my_localhost_LG> <543a86d8-21bf-aec3-5141-84e005d2def6@mail.com> <87d0f8euug.fsf@wheatstone.g10code.de> Message-ID: <4d0fe99b-29a7-751e-4420-715c1eee31a3@mail.com> On 10/7/2019 12:03 PM, Werner Koch wrote: > On Mon, 7 Oct 2019 10:15, john doe said: > >> In the above link, only the cli version of the 1.4 release is available. >> I got it from (1). > > Nope. That is always the current 2.2. > Yes it is there, some how I mist it! :) Maybe adding something like the following would avoid such confusion in the future: "A frontend for GPG is available in the 'gpg4win' executable, this is a CLI only release." -- John Doe From phill at thesusis.net Mon Oct 7 15:32:23 2019 From: phill at thesusis.net (Phillip Susi) Date: Mon, 07 Oct 2019 09:32:23 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <1fc1b0c7-f376-30aa-30f6-6d626d53bcb3@runbox.com> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <1fc1b0c7-f376-30aa-30f6-6d626d53bcb3@runbox.com> Message-ID: <87y2xwfzq0.fsf@vps.thesusis.net> Jeff Allen via Gnupg-users writes: > The original poster, perhaps unintentionally, stated the real reason the > masses have not adopted PGP, "Please do appreciate that the persons who > we are convincing and instructing are not particularly interested in > privacy." That's it in a nutshell. The masses are not particularly > interested in privacy. If they were, they'd abandon Gmail and Yahoo and > all the other providers who make no excuse for the fact their economic > model depends on users being not particularly interested in privacy. Bingo! And as long as the user is not interested in it, and won't learn how to properly use it, all they will get is the veneer of privacy and learn the hard way that they really aren't secure. You just can't make security idiot proof. There was also mention of "legally binding digital signatures" in practice. So far, the ones I have seen are nothing more than a web site that you log into with a username/password, click sign, and it adds a nice forged signature to the pdf document with an attestation that the server verified your identity at such and such a time. That's not a cryptographic signature in any way and only an idiot would consider it "legally binding". Yet that is exactly how I signed the contract to purchase my house a little over two years ago. From 2017-r3sgs86x8e-lists-groups at riseup.net Mon Oct 7 22:00:53 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Mon, 7 Oct 2019 21:00:53 +0100 Subject: How to improve our GUIs (was: We have GOT TO make things simpler) In-Reply-To: <543a86d8-21bf-aec3-5141-84e005d2def6@mail.com> References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> <599023a9-9eca-96c5-cfe5-2d43d25f02f6@mail.com> <123774961.20191006225803@my_localhost_LG> <543a86d8-21bf-aec3-5141-84e005d2def6@mail.com> Message-ID: <755157848.20191007210053@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 7 October 2019 at 9:15:54 AM, in , john doe wrote:- > would it be possible to add the ability to > checksum the binaries? When a new GnuPG version is announced, there are checksums in the announcement. For example, see https://gnupg.org/index.html#sec-3-2. - -- Best regards MFPA Two wrongs don't make a right. But three lefts do. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXZuZdV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +vm4AP4kg56p3NfBv3Z0IVkLsw9ohHn/4RS3Yo/yxdNF+YsLIwD/W852swDuAFha gtZvBoy5xzAqZAaDYC0sJNy4HXpcjgWJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXZuZdV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/2+GD/9EccWCtYBvwt9wKpyIN2pypz5o r0Xg2dLEaUzBqs/yGIwXdAjySFKwTX2vjNVx71UGlcunbqsmefwPNGYPj0dDcOk1 kPLOy2LGKeAuJgWqViG5rnkQJWz9gEMMLvlc/MV15wUvortVF7fO/5gtjtrAKHeF iFy2l0nadZuddkBl9ia7C8cuF41GMKLmarcM9hWE1AlW2sVoZo42uPZLaMiEaazY VWPL69pF2617Dm+EKof7SNtk6zYTvWuDsSFtX5mH1IhmofW0NA8v4hYXv40zOxAi lOC0mTAiV6EOF3qzoRw54bpiafJbLJj/YH2Dm4c+KVzRE3e18lKMtvdUsInoHaXR A6IWwUa7V7K0ooPGtySpd5seFJ81o0hjWFFO8UsfZTmrAknJGA2bF/v+3z3NYrTq SenfO5vwL9xAhaz0Pd8Mps3hTRocoOebwqR4Ntcm/i3r6XyffB9zUMh4GlIjeh6F nCSZnmZbGvgKd4ce22/uzW5TVKRIspifC+kCQXm3eHP1TMRiHo3O4pj5tdPxOKdn tgOBd3y2SIMnYcKoNyPIOsD6hTTFFu7jJQ5wZNlR4y/yP4a+xALFxMiT7+HGJLfj BtqbX9WDz44wZUpyHztuJuGfbXINpD0QMhvxrfTacVKnE9exjlXIYau8CKEnOpGI D5qWJSlSerK+tVuahA== =sm0V -----END PGP SIGNATURE----- From jeandavid8 at verizon.net Mon Oct 7 21:49:35 2019 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Mon, 7 Oct 2019 15:49:35 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <87y2xwfzq0.fsf@vps.thesusis.net> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <1fc1b0c7-f376-30aa-30f6-6d626d53bcb3@runbox.com> <87y2xwfzq0.fsf@vps.thesusis.net> Message-ID: <18647603-5231-6886-0b40-c8cb3d55eddd@verizon.net> On 10/7/19 9:32 AM, Phillip Susi wrote: > Bingo! And as long as the user is not interested in it, and won't learn > how to properly use it, all they will get is the veneer of privacy and > learn the hard way that they really aren't secure. You just can't make > security idiot proof. I had a realistic uncle who used to say, "You can always design a system to be fool-proof; but if you do, a damned-fool will come along. -- .~. Jean-David Beyer /V\ PGP-Key:166D840A 0C610C8B /( )\ Shrewsbury, New Jersey ^^-^^ 15:45:01 up 13 days, 21:19, 2 users, load average: 4.39, 4.72, 4.87 From sheogorath at shivering-isles.com Mon Oct 7 22:59:53 2019 From: sheogorath at shivering-isles.com (Sheogorath) Date: Mon, 7 Oct 2019 22:59:53 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> References: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> Message-ID: On 9/30/19 4:38 PM, Jeff Allen via Gnupg-users wrote: > On 9/30/19 4:58 AM, Roland Siemons wrote: >> Dear GNUPG developers, >> >> We have GOT TO make things simpler. > >> 3/ Please do appreciate that the persons who we are convincing and >> instructing are not particularly interested in privacy. They need simple >> approaches. > > ProtonMail or Tutanota. Both ensure far more privacy and security than > Gmail. Both offer free accounts and smartphone apps. If you need to > communicate privately with someone, have them get an account. > I'm sorry to disappoint you here: Neither ProtonMail nor Tutanota speak proper OpenPGP (by default) with outside services. Tutanota doesn't speak OpenPGP at all and completely bound to their own way of doing "email"(?)[1]. Protonmail on the other hand is able to speak OpenPGP, they just don't do it. Not even when you answer to a OpenPGP encrypted email, which will result in the answer getting send to you in plaintext. And since a reply contains a copy of the original email at the bottom you also get your own, previously encrypted mail as answer without encryption. I had this experience recently when sending emails with their support. So it's not just a user error, but their UI simply doesn't think about sending emails properly encrypted to the outside world. Sadly. And no, making a mail account at each of those providers is no solution. We have email to explicitly not run into this problem. [1]: https://tutanota.com/faq/#pgp -- Signed Sheogorath OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From howlatmoon at omail.pro Tue Oct 8 07:42:59 2019 From: howlatmoon at omail.pro (Caleb Wolf) Date: Tue, 8 Oct 2019 05:42:59 +0000 Subject: We have GOT TO make things simpler In-Reply-To: References: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> Message-ID: <5e3f035f-485e-eedc-df4e-6ed28d40b63f@omail.pro> Sheogorath via Gnupg-users: > I'm sorry to disappoint you here: Neither ProtonMail nor Tutanota speak > proper OpenPGP (by default) with outside services. Tutanota doesn't > speak OpenPGP at all and completely bound to their own way of doing > "email"(?)[1]. > > Protonmail on the other hand is able to speak OpenPGP, they just don't > do it. Not even when you answer to a OpenPGP encrypted email, which will > result in the answer getting send to you in plaintext. And since a reply > contains a copy of the original email at the bottom you also get your > own, previously encrypted mail as answer without encryption. > > I had this experience recently when sending emails with their support. > So it's not just a user error, but their UI simply doesn't think about > sending emails properly encrypted to the outside world. Sadly. I asked about this in https://lists.gnupg.org/pipermail/gnupg-users/2019-October/062767.html if someone with more experience than me wouldn't mind imparting their knowledge. -- Caleb Wolf From johndoe65534 at mail.com Tue Oct 8 07:45:34 2019 From: johndoe65534 at mail.com (john doe) Date: Tue, 8 Oct 2019 07:45:34 +0200 Subject: How to improve our GUIs (was: We have GOT TO make things simpler) In-Reply-To: <755157848.20191007210053@my_localhost_LG> References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> <599023a9-9eca-96c5-cfe5-2d43d25f02f6@mail.com> <123774961.20191006225803@my_localhost_LG> <543a86d8-21bf-aec3-5141-84e005d2def6@mail.com> <755157848.20191007210053@my_localhost_LG> Message-ID: <221f5cf8-af01-e7d7-06a4-01276ed1a1b9@mail.com> > Hi > > > On Monday 7 October 2019 at 9:15:54 AM, in > , john doe wrote:- > > >> would it be possible to add the ability to >> checksum the binaries? > > When a new GnuPG version is announced, there are checksums in the > announcement. For example, see https://gnupg.org/index.html#sec-3-2. > To summarize: - Checksumming a file insures that the file has not been corrupted - Verifying a file insures that the file has not been tempered with Idealy, both steps are to be done. To download gnupg: https://gnupg.org/download/index.html To checksum gnupg files you will fine the checksums in the announcement e-mail which can be found at: https://gnupg.org/index.html#sec-3-2 For example, the checksums for 2.2.17 are to be found at: https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html To download gpg4win: https://gpg4win.org/download.html Thanks to "Werner Koch wk at gnupg.org" and "MFPA <2017-r3sgs86x8e-lists-groups at riseup.net>" for the help. -- John Doe From patrick at enigmail.net Tue Oct 8 09:08:13 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 8 Oct 2019 09:08:13 +0200 Subject: Future OpenPGP Support in Thunderbird Message-ID: The Thunderbird developers have announced that they will implement OpenPGP support in Thunderbird 78 [1]. Support for Thunderbird in Enigmail will therefore be discontinued. I'd like to explain in the following paragraphs what this will mean for Enigmail, and why this is an inevitable step. The Future of Enigmail ---------------------- I will continue to support and maintain Enigmail for Thunderbird 68 until 6 months after Thunderbird 78 will have been released (i.e. a few months beyond Thunderbird 68 EOL). Enigmail will not run anymore on Thunderbird 72 beta and newer. Will this be the end of Enigmail? No! I will continue to maintain and support Enigmail for Postbox, which is running on a different release schedule than Thunderbird for the foreseeable future. Why Is This Happening? ---------------------- The Mozilla developers have been and still are actively working on removing old code from their code base. This affects not only Thunderbird itself, but also add-ons. While it was possible for Thunderbird to keep old "legacy" add-ons alive for a certain time, the time has come for Thunderbird to stop supporting them [2]. Thunderbird 78 will no longer to support the APIs that Enigmail requires and only allow new "WebExtensions". WebExtensions have a completely different API than classical add-ons, and a much reduced set of capabilities to hook into the user interface. For Enigmail to continue to work, it would therefore be required to rewrite it from scratch. However, that's beyond my available time limitations. The Thunderbird developers and I have therefore agreed that it's much better to implement OpenPGP support directly in Thunderbird. The set of functionalities will be different than what Enigmail offers, and at least initially likely be less feature-rich. But in my eyes, this is by far outweighed by the fact that OpenPGP will be part of Thunderbird and no add-on and no third-party tool will be required. -Patrick [1] https://blog.mozilla.org/thunderbird/2019/10/thunderbird-enigmail-and-openpgp/ [2] https://groups.google.com/forum/#!topic/tb-planning/-E8Yw6POxEE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From vesely at tana.it Tue Oct 8 17:07:10 2019 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 8 Oct 2019 17:07:10 +0200 Subject: How to improve our GUIs In-Reply-To: <878spweury.fsf@wheatstone.g10code.de> References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> <20191006012108.4180D40620@smtp.hushmail.com> <878spweury.fsf@wheatstone.g10code.de> Message-ID: <08599e5f-757d-5374-3446-b4bfd378f496@tana.it> On Mon 07/Oct/2019 12:04:33 +0200 Werner Koch via Gnupg-users wrote: > On Sat, 5 Oct 2019 21:21, vedaal said: > >> and then a separate option of >> "Export Secret Keys" > > The OP explictly suggested to make the exporting of the secret key not > too easy so that users don't accidently send out their secret keys. On the other hand, if the user received a malicious mail explicitly asking to click so and so to export secret keys, does the GUI have to issue several warnings before eventually letting the user do it? What about users who are so gullible to not actually discern true from false? Trying to support _all computer users_[*] may turn out to displease more than expected. Best Ale -- [*] https://www.gnu.org/gnu/manifesto.html#benefit -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupgpacker at on.yourweb.de Tue Oct 8 20:47:44 2019 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Tue, 8 Oct 2019 20:47:44 +0200 Subject: gpg.conf for use with gpg-1.4x and -2.2x... Message-ID: <000001d57e08$df5bc830$9e135890$@on.yourweb.de> Hello, are there recommendations or samples for common gpg.conf file out there for secure and convenient use with v2.x *and* v1.4? On my system GPG-2.x (Gpg4win) and GPG-1.4x (GpgRelay) are both used, so compatibility is eligible. Thx + regards, Chris From sac at 300baud.de Tue Oct 8 15:56:28 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 8 Oct 2019 15:56:28 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: <20191008155628.00004ca2.sac@300baud.de> Patrick Brunschwig wrote: > The Thunderbird developers have announced that they will implement > OpenPGP support in Thunderbird 78 [1]. Support for Thunderbird in > Enigmail will therefore be discontinued. [snip] > The Thunderbird developers and I have therefore agreed that it's much > better to implement OpenPGP support directly in Thunderbird. The set of > functionalities will be different than what Enigmail offers, and at > least initially likely be less feature-rich. But in my eyes, this is by > far outweighed by the fact that OpenPGP will be part of Thunderbird and > no add-on and no third-party tool will be required. Great news, Patrick. Thanks for sharing! Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From me at halfdog.net Tue Oct 8 20:02:07 2019 From: me at halfdog.net (halfdog) Date: Tue, 08 Oct 2019 18:02:07 +0000 Subject: We have GOT TO make things simpler In-Reply-To: <87y2xwfzq0.fsf@vps.thesusis.net> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <1fc1b0c7-f376-30aa-30f6-6d626d53bcb3@runbox.com> <87y2xwfzq0.fsf@vps.thesusis.net> Message-ID: <998-1570557727.754012@IEkL.Zu5T.6AEt> Phillip Susi writes: > > Jeff Allen via Gnupg-users writes: > > The original poster, perhaps unintentionally, stated the real reason the > > masses have not adopted PGP, "Please do appreciate that the persons who > > we are convincing and instructing are not particularly interested in > > privacy." That's it in a nutshell. The masses are not particularly > > interested in privacy. If they were, they'd abandon Gmail and Yahoo and > > all the other providers who make no excuse for the fact their economic > > model depends on users being not particularly interested in privacy. > > Bingo! And as long as the user is not interested in it, and won't learn > how to properly use it, all they will get is the veneer of privacy and > learn the hard way that they really aren't secure. You just can't make > security idiot proof... In my opinion this argument has some similarity to arguments brought up years ago when safety belt use for car driving was made mandatory by law. Before that the individual driver deemed the safety belt just an unneccessary obstacle when getting in and out of the car. Also using it has no benefits for him as he believed to be a low-risk, careful driver not crashing anyway. On the other side on whole-society level a noticable loss of workforce, tragedies was statistically measured, that could be prevented by belt use. As with encryption software, even "fool-proof" and easy-to-use safety belts did not change behaviour, there had to be incentives in place to trigger adoption ... The main "incentive" introduced in the end was to be able to use the whole road network without being annoyed by police asking you for money when you use it. Therefore the belt-use rate increased quickly ... So to put that to mail encryption, maybe use this tech-fiction mind experiment: let's assume, there would be an SMTP response code to "RCPT:
" saying something like "550 Address rejected, unencrypted message storage not safe, use key [id]". The only thing the sending SMTP would then need to do is to check, if the message was already encrypted, if not encrypt it with the given key, then continue with the secure recipient call "SRCPT:
". The receiving SMTP would not even need to check if the transmitted message is then really encrypted, just a well-behaved sender would not maliciously declare unencrypted data as encrypted. Why would that be an incentive to get own keys? Because e.g. your bank, your tax administration, your doctor, your lawer would refuse to accept unencrypted messages (or to respond to them) when they deem associated risks of data leakage too high, e.g. by violating GDPR. So if you as client want to use mail transport also for these purposes instead of showing up in the office or installing tons of specialized apps for specifically communicating with one partner, users would start registering keys, because they get a benefit from it. As the average dude does not operate his own SMTP servers, the major mail providers are somehow forced to provide this functionality with server-stored keys. Still anyone having motivation to take things further can do local decryption, even use hardware security modules to avoid key theft. So in the end safety belt for every one, super-high-quality safety belts for those, who deem their risks for crashes above average. I hope I managed to make my point clear. Please do not be picky if the hypothetical SMTP extension would be the best lever to provide that incentive for encryption adoption, maybe there are better ones (or none). Still I would be interested if my argument seems correct or if someone can point out serious flaws in it. hd From jrallen at runbox.com Tue Oct 8 15:21:49 2019 From: jrallen at runbox.com (Jeff Allen) Date: Tue, 8 Oct 2019 09:21:49 -0400 Subject: We have GOT TO make things simpler In-Reply-To: References: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> Message-ID: On 10/7/19 4:59 PM, Sheogorath via Gnupg-users wrote: > On 9/30/19 4:38 PM, Jeff Allen via Gnupg-users wrote: >> On 9/30/19 4:58 AM, Roland Siemons wrote: >>> Dear GNUPG developers, >>> >>> We have GOT TO make things simpler. >> >>> 3/ Please do appreciate that the persons who we are convincing and >>> instructing are not particularly interested in privacy. They need simple >>> approaches. >> >> ProtonMail or Tutanota. Both ensure far more privacy and security than >> Gmail. Both offer free accounts and smartphone apps. If you need to >> communicate privately with someone, have them get an account. >> > > I'm sorry to disappoint you here: Neither ProtonMail nor Tutanota speak > proper OpenPGP (by default) with outside services. Tutanota doesn't > speak OpenPGP at all and completely bound to their own way of doing > "email"(?)[1]. So what? If the goal is private communication, ProtonMail and Tutanota are nearly effortless ways to achieve it. Sign up for a free account and have at it. Most folks could care less about speaking proper OpenPGP with outside services. Those who do will use ProtonMail, not Tutanota. > Protonmail on the other hand is able to speak OpenPGP, they just don't > do it. Not even when you answer to a OpenPGP encrypted email, which will > result in the answer getting send to you in plaintext. And since a reply > contains a copy of the original email at the bottom you also get your > own, previously encrypted mail as answer without encryption. I disagree. No widely used OpenPGP implementation is going to automatically encrypt replies to encrypted email out of the box. With ProtonMail you have to import your correspondent's public key and flip an encryption switch in settings. You have to do that with GnuPG too, whether you are working from the command line or using Thunderbird/Enigmail or a GUI front-end. > I had this experience recently when sending emails with their support. > So it's not just a user error, but their UI simply doesn't think about > sending emails properly encrypted to the outside world. Sadly. > > And no, making a mail account at each of those providers is no solution. > We have email to explicitly not run into this problem. Sure it's a solution. I have accounts at both. Most of my email is not encrypted because, as the original poster pointed out, most people I communicate with are not particularly interested in privacy. When a private discussion _is_ required, I suggest that we have it on one of those platforms. All my family members have ProtonMail accounts. They don't use them most of the time. They have Gmail accounts for daily use. But when we discuss financial matters or anything else we'd rather not have Google a party to, ProtonMail is the answer. If someone tells me they have a Tutanota account or are willing to get one, I say "fine!" and give them my Tutanota address. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jerry at seibercom.net Tue Oct 8 14:07:44 2019 From: jerry at seibercom.net (Jerry) Date: Tue, 8 Oct 2019 08:07:44 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <18647603-5231-6886-0b40-c8cb3d55eddd@verizon.net> References: <59bcef77-9a6a-dfef-d52a-ff7476e08d74@gmail.com> <5ac75226-7cd4-06a3-0311-3b1b32fe3930@blastwave.org> <20191003235300.00006232.sac@300baud.de> <4a0cdbdc-8966-bf56-1c30-8fd1bd66ae39@gmail.com> <20191004093504.00006eef.sac@300baud.de> <34baa69f-797c-68ec-8529-4a902cf33878@ezaquarii.com> <849b7d0c-1f37-8781-afcf-8091d1a62f91@gmail.com> <20191005121517.00006566.sac@300baud.de> <1fc1b0c7-f376-30aa-30f6-6d626d53bcb3@runbox.com> <87y2xwfzq0.fsf@vps.thesusis.net> <18647603-5231-6886-0b40-c8cb3d55eddd@verizon.net> Message-ID: <20191008080744.00000026@seibercom.net> On Mon, 7 Oct 2019 15:49:35 -0400, Jean-David Beyer via Gnupg-users stated: >On 10/7/19 9:32 AM, Phillip Susi wrote: >> Bingo! And as long as the user is not interested in it, and won't >> learn how to properly use it, all they will get is the veneer of >> privacy and learn the hard way that they really aren't secure. You >> just can't make security idiot proof. > >I had a realistic uncle who used to say, "You can always design a >system to be fool-proof; but if you do, a damned-fool will come along. Every day, man is making bigger and better fool-proof things, and every day, nature is making bigger and better fools. So far, I think nature is winning. Albert Einstein -- Jerry From pkk at spth.de Tue Oct 8 15:34:28 2019 From: pkk at spth.de (Philipp Klaus Krause) Date: Tue, 8 Oct 2019 15:34:28 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: While having OpenPGP support directly in Thunderbird is probably a good thing, I found it convenient to just use the gpg kerys for Email encryption and signing (and conversely, being able to just use keys imported via Enigmail to encrypt files using gpg). It would be really nice, if Thunderbird could add an option to use the gpg key storage instead of its own, but so far the developers want to always keep the Thunderbird key storage separately (thoug they are considering functionality to import keys from gpg to Thunderbird): https://wiki.mozilla.org/Thunderbird:OpenPGP:2020 Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From codeguro at gmail.com Wed Oct 9 06:26:31 2019 From: codeguro at gmail.com (Tony Lane) Date: Wed, 9 Oct 2019 00:26:31 -0400 Subject: We have GOT TO make things simpler In-Reply-To: References: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> Message-ID: <6b8b5087-9c62-a4ee-a5c2-2320eb9ea946@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/8/19 9:21 AM, Jeff Allen via Gnupg-users wrote: > On 10/7/19 4:59 PM, Sheogorath via Gnupg-users wrote: >> Protonmail on the other hand is able to speak OpenPGP, they just don't >> do it. Not even when you answer to a OpenPGP encrypted email, which will >> result in the answer getting send to you in plaintext. And since a reply >> contains a copy of the original email at the bottom you also get your >> own, previously encrypted mail as answer without encryption. > > I disagree. No widely used OpenPGP implementation is going to > automatically encrypt replies to encrypted email out of the box. With > ProtonMail you have to import your correspondent's public key and flip > an encryption switch in settings. You have to do that with GnuPG too, > whether you are working from the command line or using > Thunderbird/Enigmail or a GUI front-end. Not quite. Enigmail addon Thunderbird and even GPGMail addon for Apple Mail encrypt it out of the box if you reply to a recipient who's sent you an an encrypted email if you already imported their public key. Moreover, the private key is stored on your local machine so no middleman can read it without access to your device. AFAIK, protonmail holds your private keys for you in some server. That doesn't sound very safe to me, and I wouldn't take that risk. I would argue even Gmail with inline PGP encryption over Enigmail or GPGMail is more secure than protonmail for this reason alone. >> And no, making a mail account at each of those providers is no solution. >> We have email to explicitly not run into this problem. > > Sure it's a solution. I have accounts at both. Most of my email is not > encrypted because, as the original poster pointed out, most people I > communicate with are not particularly interested in privacy. When a > private discussion _is_ required, I suggest that we have it on one of > those platforms. That seems terribly inefficient. Do you intend to maintain accounts on each of these platforms and take all of the risks of each into account? You must have a lot more trust than I do, but I digress. I think his whole point is "We should use e-mail as an insecure transport protocol and do secure end-to-end encryption on an agnostic encryption module such as GPG". And it makes sense to do things this way if you want to be secure. And before you point me to how PM stores your private keys (I've read it), remember that all of that salting and hash/password storage is done using business logic they developed, which means anytime there's an update, hidden or announced, you are running a risk of a backdoor being introduced. Can you even audit that code? At least with GPG I can not just audit but also substitute the module with any OpenPGP-compliant library. This gives me a heck of a lot more freedom (and security) than maintaining a thousand different accounts on a thousand different platforms. -----BEGIN PGP SIGNATURE----- iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXZ1hdwAKCRDo8fj9gx4T 03jGAgdQ5F64jhGM2rYwAJjGW0sD75tE029SMUxSbL2mV90XcL6Rdu94YL6oTpSE QJWP93dCYmqvX9btuRviFBjuIyBtmAIJASKWeAzEyfrva2ljveBPOru3XsvM5xL4 bHwgTEmycH6nG6JMwBIu5A450OdEIC/83EgRVFXG4NZo67ndhHTGA+KN =K5la -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Oct 9 06:28:31 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 9 Oct 2019 00:28:31 -0400 Subject: gpg.conf for use with gpg-1.4x and -2.2x... In-Reply-To: <000001d57e08$df5bc830$9e135890$@on.yourweb.de> References: <000001d57e08$df5bc830$9e135890$@on.yourweb.de> Message-ID: > are there recommendations or samples for common gpg.conf file out there for > secure and convenient use with v2.x *and* v1.4? Not really. Name them gpg.conf-1 and gpg.conf-2. GnuPG 2 will use the -2 file, GnuPG 1.4 will use the -1 file. From andrewg at andrewg.com Wed Oct 9 08:23:59 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 9 Oct 2019 07:23:59 +0100 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: > On 9 Oct 2019, at 04:47, Philipp Klaus Krause wrote: > > It would be really nice, if Thunderbird could add an option to use the > gpg key storage instead of its own, but so far the developers want to > always keep the Thunderbird key storage separately (thoug they are > considering functionality to import keys from gpg to Thunderbird): Agreed. Such functionality is vital for those of us who use smartcards. A From codeguro at gmail.com Wed Oct 9 09:06:33 2019 From: codeguro at gmail.com (Tony Lane) Date: Wed, 9 Oct 2019 03:06:33 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/8/19 9:34 AM, Philipp Klaus Krause wrote: > It would be really nice, if Thunderbird could add an option to use the > gpg key storage instead of its own, but so far the developers want to > always keep the Thunderbird key storage separately (thoug they are > considering functionality to import keys from gpg to Thunderbird): It doesn't do that? Why would they choose to tightly couple TB with OpenPGP? If I have to maintain two key databases, that's a dealbreaker for me. Welp, looks like I won't be upgrading. Thanks Mozilla. -----BEGIN PGP SIGNATURE----- iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXZ2G+QAKCRDo8fj9gx4T 04hBAgkBa3KJriiIvDBG91RKezHEYrPK10Y8Rcc4rYa4RSTq266MGgNu8R0lY8q9 dSYL6JgM+aRvfvD56bclhkTVl/mROJECBiIeo/CBtU78+RFq8hbgpb+4hI5GKt+R s2/Oabhg+t5i9TZ4c3pG9y30A6Ih01bFgeX6FMA7HliGPGKr3PuWG0QO =AwFo -----END PGP SIGNATURE----- From hernani.marques at pep.foundation Tue Oct 8 18:57:55 2019 From: hernani.marques at pep.foundation (=?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?=) Date: Tue, 8 Oct 2019 18:57:55 +0200 Subject: [Enigmail] Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: <08044fc3-1fd9-b26a-82e8-0985dc9dbd6a@pep.foundation> On 08.10.19 18:37, Dmitry Alexandrov wrote: > Pity, but I hope it will be better that way. In particular I hope, that Mozilla will not follow your example and won?t entice users to proprietary isolated keyserver [0] instead of distributed SKS network thus splitting the keybase. And won?t promote standards [1] that suspiciously resemble embrace-extend-and-extinguish tactics employed against PGP either. > > [0] https://keys.openpgp.org > [1] https://pep.security pEp is not against PGP, it's just PGP-supporting as much as it makes sense for interop reasons and goes beyond email already today; and it's designed from the very beginning on to support other crypto as well (agnosticism on messaging & crypto). -- p?p foundation: https://pep.foundation/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xCB5738652768F7E9.asc Type: application/pgp-keys Size: 26656 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From 321942 at gmail.com Tue Oct 8 20:39:24 2019 From: 321942 at gmail.com (Dmitry Alexandrov) Date: Tue, 08 Oct 2019 21:39:24 +0300 Subject: [Enigmail] Future OpenPGP Support in Thunderbird In-Reply-To: <08044fc3-1fd9-b26a-82e8-0985dc9dbd6a@pep.foundation> (=?utf-8?Q?=22Hern=C3=A2ni?= Marques =?utf-8?Q?=28p=E2=89=A1p?= foundation)"'s message of "Tue, 8 Oct 2019 18:57:55 +0200") References: <08044fc3-1fd9-b26a-82e8-0985dc9dbd6a@pep.foundation> Message-ID: <8spv3wv7.321942@gmail.com> "Hern?ni Marques (p?p foundation)" wrote: > On 08.10.19 18:37, Dmitry Alexandrov wrote: > >> Pity, but I hope it will be better that way. In particular I hope, that Mozilla will not follow your example and won?t entice users to proprietary isolated keyserver [0] instead of distributed SKS network thus splitting the keybase. And won?t promote standards [1] that suspiciously resemble embrace-extend-and-extinguish tactics employed against PGP either. >> >> [0] https://keys.openpgp.org >> [1] https://pep.security > > pEp is not against PGP it's just PGP-supporting as much as it makes sense for interop reasons Well, I?m glad to hear that, but it?s really a pity, that supporting Autocrypt does not make sense for you. > and goes beyond email already today; and it's designed from the very beginning on to support other crypto[formats] as well (agnosticism on messaging & crypto[format]) A double pity in light of your decision to not only support but actually _prefer_ other cryptoformats over PGP whenever possible for the sake of ?forward secrecy? [1] ? that?s when Autocrypt is exactly the extension to PGP that can provide forward secrecy, if needed. [1] | How does p?p select the most secure way of sending an email or a message? | | When a p?p user is communicating with another p?p user: | | 1. if online communication available: OTR through GNUnet. | | 2. if online communication not available: | | a. if anonymizing platform available, OpenPGP through anonymizing platform (i.e. Qabel), | | b. if anonymizing platform not available, fallback to OpenPGP. | | When a p?p user is communicating with a non-p?p user then depending on the capabilities of the non-p?p user: | | 1. if anonymizing and forward secrecy is possible, use that (i.e. OTR over GNUnet). | | 2. if anonymizing but no forward secrecy is possible, use that (i.e. OpenPGP over Qabel). | | 3. if forward secrecy is possible, use that (i.e. OTR). | | 4. if hard cryptography but no forward secrecy is possible, use that (i.e. OpenPGP) | | 5. if only weak cryptography is possible, use that (i.e. S/MIME with commercial CAs) | | 6. send unencrypted. ? https://www.pep.security/en/faq/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From 321942 at gmail.com Tue Oct 8 18:37:54 2019 From: 321942 at gmail.com (Dmitry Alexandrov) Date: Tue, 08 Oct 2019 19:37:54 +0300 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: (Patrick Brunschwig's message of "Tue, 8 Oct 2019 09:08:13 +0200") References: Message-ID: Patrick Brunschwig wrote: > The Thunderbird developers have announced that they will implement OpenPGP support in Thunderbird 78 [1]. A long awaited news indeed! > Support for Thunderbird in Enigmail will therefore be discontinued. Pity, but I hope it will be better that way. In particular I hope, that Mozilla will not follow your example and won?t entice users to proprietary isolated keyserver [0] instead of distributed SKS network thus splitting the keybase. And won?t promote standards [1] that suspiciously resemble embrace-extend-and-extinguish tactics employed against PGP either. [0] https://keys.openpgp.org [1] https://pep.security -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From acolomb at schickhardt.org Tue Oct 8 23:56:59 2019 From: acolomb at schickhardt.org (=?ISO-8859-1?Q?Andr=E9_Colomb?=) Date: Tue, 08 Oct 2019 23:56:59 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: Hi Patrick, >The Thunderbird developers and I have therefore agreed that it's much >better to implement OpenPGP support directly in Thunderbird. The set of >functionalities will be different than what Enigmail offers, and at >least initially likely be less feature-rich. But in my eyes, this is by >far outweighed by the fact that OpenPGP will be part of Thunderbird and >no add-on and no third-party tool will be required. Great news overall and thanks for the announcement. Thunderbird with direct OpenPGP integration has long been overdue IMHO. So according to the wiki page [1] I understand that the secret keys will be managed by Thunderbird. That is quite a limitation I think, in contrast to reusing a GPG agent of some sort. Depending on the chosen alternative, it might offer better OS integration, a long time proven secure process architecture, possible reuse with only one central key store and most of all integration with hardware tokens. I personally would not entrust my private keys to a mail application that also displays HTML and possibly executes JavaScript etc. after what we have seen with Efail for example. So could you please elaborate or extend the wiki page to clear up how hardware tokens fit into the new picture? Thanks and kind regards. Andr? [1]: https://wiki.mozilla.org/Thunderbird:OpenPGP:2020 -- Greetings... From: Andre Colomb From jan-peter at ruehmann.name Wed Oct 9 08:36:00 2019 From: jan-peter at ruehmann.name (=?UTF-8?Q?Jan-Peter_R=c3=bchmann?=) Date: Wed, 9 Oct 2019 08:36:00 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... 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 fta at firkant.net Wed Oct 9 15:42:28 2019 From: fta at firkant.net (Fta) Date: Wed, 09 Oct 2019 15:42:28 +0200 Subject: can not se and run gpg2 command Message-ID: <5185eab23532042dccd2be781d9ace98@firkant.net> ?Hi I have installed Gnup in me windows 7, but I can not se and run the command gpg2 C:\Users\Danuna\AppData\Roaming\gnupg>gpg.exe --version gpg (GnuPG) 2.2.17 libgcrypt 1.8.4 Copyright (C) 2019 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: C:/Users/Danuna/AppData/Roaming/gnupg Underst?ttede algoritmer: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Chiffer: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, ? ? ? ? ?CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Komprimering: Ukomprimeret, ZIP, ZLIB, BZIP2 C:\Users\Danuna\AppData\Roaming\gnupg> gpg2.exe --version 'gpg2.exe' is not recognized as an internal or external command, operable program or batch file. How can possibley get it to work Kind regards Fadel -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Oct 9 22:24:09 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Oct 2019 22:24:09 +0200 Subject: can not se and run gpg2 command In-Reply-To: <5185eab23532042dccd2be781d9ace98@firkant.net> (Fta's message of "Wed, 09 Oct 2019 15:42:28 +0200") References: <5185eab23532042dccd2be781d9ace98@firkant.net> Message-ID: <87ftk1sm52.fsf@wheatstone.g10code.de> On Wed, 9 Oct 2019 15:42, Fta said: > I have installed Gnup in me windows 7, but I can not se and run the > command gpg2 On some systems (mainly older Linux distributions), the current gpg is still installed under the name gpg2. On Windows we are using the name gpg.exe now for many years. Some HOWTOS tell you to use gpg2.exe but you can and should use gpg.exe. > C:\Users\Danuna\AppData\Roaming\gnupg>gpg.exe --version > gpg (GnuPG) 2.2.17 Good. You are using the latest version. BTW, to get information on where GnuPG is installed you can use gpgconf.exe --list-dirs Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jrallen at runbox.com Thu Oct 10 15:05:42 2019 From: jrallen at runbox.com (Jeff Allen) Date: Thu, 10 Oct 2019 09:05:42 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <6b8b5087-9c62-a4ee-a5c2-2320eb9ea946@gmail.com> References: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> <6b8b5087-9c62-a4ee-a5c2-2320eb9ea946@gmail.com> Message-ID: <6329860b-c8fc-de88-a601-dd833b81b671@runbox.com> On 10/9/2019 Tony Lane wrote: > On 10/8/19 9:21 AM, Jeff Allen via Gnupg-users wrote: >> Sure it's a solution. I have accounts at both. Most of my email is not >> encrypted because, as the original poster pointed out, most people I >> communicate with are not particularly interested in privacy. When a >> private discussion _is_ required, I suggest that we have it on one of >> those platforms. > > That seems terribly inefficient. Do you intend to maintain accounts on > each of these platforms and take all of the risks of each into account? > You must have a lot more trust than I do, but I digress. I think his whole > point is "We should use e-mail as an insecure transport protocol and do > secure end-to-end encryption on an agnostic encryption module such as GPG". Of course we should. I'm happy to do that when the person with whom I want to communicate privately is willing to do the same. Most aren't, and I am unwilling to let the perfect be the enemy of the good. > And it makes sense to do things this way if you want to be secure. > And before you point me to how PM stores your private keys (I've read it), > remember that all of that salting and hash/password storage is done using > business logic they developed, which means anytime there's an update, > hidden or announced, you are running a risk of a backdoor being introduced. > Can you even audit that code? Personally, I am not capable of auditing code, including that of GnuPG. It is unrealistic to think most users, even most power users, have the time and ability to audit the code of their security software. My threat model is not overly demanding. Mainly I want to avoid getting targeted pharma ads or being denied insurance if I discuss a medical issue in an email. I'd prefer that Google not be able to surmise my income sources and net worth based on information I share with family members. Were I worried about being targeted by NSA, law enforcement or a civil court order, I'd be a lot more demanding of my correspondents and myself. I have used PGP since at least version 2.6.x. I can do OpenPGP via Thunderbird/Enigmail, mutt, GPGShell, Geany, Kleopatra or the command line and don't find any of them to be particularly daunting. What I haven't been able to do is convince many people to do the same. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From phill at thesusis.net Fri Oct 11 15:18:08 2019 From: phill at thesusis.net (Phillip Susi) Date: Fri, 11 Oct 2019 09:18:08 -0400 Subject: We have GOT TO make things simpler In-Reply-To: References: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> Message-ID: <878sprs9nz.fsf@vps.thesusis.net> Jeff Allen via Gnupg-users writes: > So what? If the goal is private communication, ProtonMail and Tutanota > are nearly effortless ways to achieve it. Sign up for a free account How do you figure that? If they aren't encrypting mail then how is it private? Or or is it using some other form of encryption ( s/mime )? If that's the case then why don't you just use that yourself and skip the centralized web site for holding your key? > I disagree. No widely used OpenPGP implementation is going to > automatically encrypt replies to encrypted email out of the box. With Of course they do. If they don't, then they utterly fail to maintain your privacy. > ProtonMail you have to import your correspondent's public key and flip > an encryption switch in settings. You have to do that with GnuPG too, > whether you are working from the command line or using > Thunderbird/Enigmail or a GUI front-end. iirc, it may poke you to import the key, but at least it tells you "hey! I can't encrypt this without the key. Unless you *really* don't want to encrypt this?" Silently sending the reply unencrypted is entirely unacceptable. > Sure it's a solution. I have accounts at both. Most of my email is not > encrypted because, as the original poster pointed out, most people I > communicate with are not particularly interested in privacy. When a > private discussion _is_ required, I suggest that we have it on one of > those platforms. All my family members have ProtonMail accounts. They > don't use them most of the time. They have Gmail accounts for daily > use. But when we discuss financial matters or anything else we'd rather > not have Google a party to, ProtonMail is the answer. If someone tells > me they have a Tutanota account or are willing to get one, I say "fine!" > and give them my Tutanota address. So you think it is easier to sign up for some dedicated private webmail service that can only communicate securely with other people using that service than to run proper e2e on a real mail client? I suppose that's a matter of opinion, but it certainly is less secure and conveinient. And by conveinient I mean it is annoying to have both parties switch to some silly web site instead of just following their normal and preferred email routine. From computer at boehlk.com Fri Oct 11 14:41:41 2019 From: computer at boehlk.com (Andreas Boehlk) Date: Fri, 11 Oct 2019 14:41:41 +0200 (CEST) Subject: How to improve our GUIs (was: We have GOT TO make things simpler) In-Reply-To: <221f5cf8-af01-e7d7-06a4-01276ed1a1b9@mail.com> References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> <599023a9-9eca-96c5-cfe5-2d43d25f02f6@mail.com> <123774961.20191006225803@my_localhost_LG> <543a86d8-21bf-aec3-5141-84e005d2def6@mail.com> <755157848.20191007210053@my_localhost_LG> <221f5cf8-af01-e7d7-06a4-01276ed1a1b9@mail.com> Message-ID: <1710684135.241000.1570797701067@email.ionos.de> > john doe hat am 8. Oktober 2019 um 07:45 geschrieben: > To summarize: > > - Checksumming a file insures that the file has not been corrupted > - Verifying a file insures that the file has not been tempered with I totally agree to both statements > > Idealy, both steps are to be done. > I do not agree with this one. IMHO the verification with a trusted GPG-Key is absolutely sufficiant and the checksum-proof is not needed at all. Regards Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: Boehlk,Andreas.vcf Type: text/vcard Size: 471 bytes Desc: not available URL: From phill at thesusis.net Fri Oct 11 20:15:55 2019 From: phill at thesusis.net (Phillip Susi) Date: Fri, 11 Oct 2019 14:15:55 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: <875zkvrvvo.fsf@vps.thesusis.net> Philipp Klaus Krause writes: > While having OpenPGP support directly in Thunderbird is probably a good > thing, I found it convenient to just use the gpg kerys for Email > encryption and signing (and conversely, being able to just use keys > imported via Enigmail to encrypt files using gpg). > It would be really nice, if Thunderbird could add an option to use the > gpg key storage instead of its own, but so far the developers want to > always keep the Thunderbird key storage separately (thoug they are > considering functionality to import keys from gpg to Thunderbird): Why the heck don't they just run gpg the way enigmail did? From phill at thesusis.net Fri Oct 11 19:54:44 2019 From: phill at thesusis.net (Phillip Susi) Date: Fri, 11 Oct 2019 13:54:44 -0400 Subject: How to improve our GUIs (was: We have GOT TO make things simpler) In-Reply-To: <1710684135.241000.1570797701067@email.ionos.de> References: <87h84nf80l.fsf_-_@wheatstone.g10code.de> <599023a9-9eca-96c5-cfe5-2d43d25f02f6@mail.com> <123774961.20191006225803@my_localhost_LG> <543a86d8-21bf-aec3-5141-84e005d2def6@mail.com> <755157848.20191007210053@my_localhost_LG> <221f5cf8-af01-e7d7-06a4-01276ed1a1b9@mail.com> <1710684135.241000.1570797701067@email.ionos.de> Message-ID: <877e5brwuz.fsf@vps.thesusis.net> Andreas Boehlk writes: > I do not agree with this one. IMHO the verification with a trusted GPG-Key is absolutely sufficiant and the checksum-proof is not needed at all. True, since validating the signature means validating the secure hash of the contents. That is, the checkum is reisistant to accidental corruption, but the secure hash is *also* resistant to intentional manipulation. The latter is a superset of the former. From hello at ezaquarii.com Fri Oct 11 21:43:03 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Fri, 11 Oct 2019 20:43:03 +0100 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <875zkvrvvo.fsf@vps.thesusis.net> References: <875zkvrvvo.fsf@vps.thesusis.net> Message-ID: On 11/10/2019 19:15, Phillip Susi wrote: > Why the heck don't they just run gpg the way enigmail did? They don't want to bundle GnuPG because of GnuPG licence: https://wiki.mozilla.org/Thunderbird:OpenPGP:2020#OpenPGP_engine Requiring user to set up GnuPG separately is out of question if they want to achieve any sensible level of adoption. There is another matter of key distribution and I guess they plan on taking control over it to provide acceptable level of UX. Cheers, Chris From hello at ezaquarii.com Fri Oct 11 21:49:47 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Fri, 11 Oct 2019 20:49:47 +0100 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: <09e6bc36-cb68-f017-9bb1-814e15ad51f4@ezaquarii.com> On 09/10/2019 08:06, Tony Lane via Gnupg-users wrote:> It doesn't do that? Why would they choose to tightly couple TB with > OpenPGP? If I have to maintain two key databases, that's a dealbreaker for me. Dealing with GnuPG complexity is a deal breaker for ordinary users, preventing adoption. You need to look at it from product/business development perspective and it makes perfect sense that they want to ship their own UX. Also, they mention that the key management workflow is something they plan to address. Cheers, Chris From pkk at spth.de Fri Oct 11 20:18:23 2019 From: pkk at spth.de (Philipp Klaus Krause) Date: Fri, 11 Oct 2019 20:18:23 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <875zkvrvvo.fsf@vps.thesusis.net> References: <875zkvrvvo.fsf@vps.thesusis.net> Message-ID: <3ca59f25-bdac-a319-00bb-939fc4b16ad0@spth.de> Am 11.10.19 um 20:15 schrieb Phillip Susi: > Why the heck don't they just run gpg the way enigmail did? > They don't want users to require to install gpg first. And they don't want to ship gpg with Windows installers, since it isn't MPL. Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From alejacortez69 at gmail.com Fri Oct 11 20:53:03 2019 From: alejacortez69 at gmail.com (alejandro Cortez) Date: Fri, 11 Oct 2019 14:53:03 -0400 Subject: Cannot decrypt from smartcard using gnupg-2.2, can from 2.0 Message-ID: Working version: Ubuntu-14.04 gpg (GnuPG) 2.0.22 libgcrypt 1.5.3 Not working version: Ubuntu-18.04 gpg (GnuPG) 2.2.4 libgcrypt 1.8.1 I put the same subkey on all 3 slots of a Nitrokey Pro maybe about a year ago and have been encrypting/decrypting (sometimes signing, sometimes not) for myself and for/from other people during that time. I've used the smartcard on 3 different hosts (also 14.04) by using fetch and running card-status. On gnupg-2.2, whether signed or not, attempting to decrypt a file with me as the recipient fails with: gpg: public key decryption failed: Invalid ID gpg: decryption failed: No secret key It shows that the file was encrypted with my subkey fingerprint. I can encrypt and sign with gnupg-2.2, just not the reverse. It does not matter if the file I am trying to decrypt was created from one of my 14.04 hosts or with the 18.04 host. The 18.04 host simply cannot decrypt it. To be complete about how I set up the card: I imported the subkey into a fresh .gnupg, ran card-edit, toggle, key 1, keytocard, chose the slot, saved, wiped .gnupg (and restarted the agent) and repeated the process for the other 2 slots and finally wiping .gnupg and using card-edit, fetch, and card-status to re-initialize. Both 2.0 and 2.2 show sec#, uid, and ssb> when running -K. show-unusable-uids,show-unusable-subkeys does not change the output. There are no other UIDs or subkeys and both master and sub are set to never expire. If I import the master or the detached subkey by themselves into a clean 18.04 environment, it works. Only the smartcard does not work. Can anyone help debug this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mistave at countermail.com Fri Oct 11 21:48:35 2019 From: mistave at countermail.com (qwrd) Date: Fri, 11 Oct 2019 21:48:35 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: > >> On 9 Oct 2019, at 04:47, Philipp Klaus Krause wrote: >> >> It would be really nice, if Thunderbird could add an option to use the >> gpg key storage instead of its own, but so far the developers want to >> always keep the Thunderbird key storage separately (thoug they are >> considering functionality to import keys from gpg to Thunderbird): > > Agreed. Such functionality is vital for those of us who use smartcards. > > A > I would like to second this. Storing private keys on a smartcard is a noteworthy security enhancement, and I would like to see smartcard support being available in Thunderbird. Either via GnuPG or some other mechanism. Mis > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From rjh at sixdemonbag.org Sat Oct 12 08:23:48 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 12 Oct 2019 02:23:48 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <875zkvrvvo.fsf@vps.thesusis.net> References: <875zkvrvvo.fsf@vps.thesusis.net> Message-ID: <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> > Why the heck don't they just run gpg the way enigmail did? Three major reasons: 1. License incompatibility. GnuPG is GPLv3, and Mozilla uses the Mozilla Public License. They're not compatible. Arguably (and I believe _correctly_) distributing GnuPG with Moz wouldn't be a dealbreaker, as mere aggregation is different from actually linking, but lawyers are by nature conservative. Moz has already said their lawyers won't let them do this. 2. Dependencies. Mozilla will not accept responsibility for users doing foolish things with their gpg.conf files, because those users will expect Mozilla to fix it for them. It's a dealbreaker. This is also why Mozilla has declared they won't even support using GnuPG keyrings -- they're going to insist on running their own keyring internal to Thunderbird which isn't shared with anything else. (I imagine *importing* from a GnuPG keyring will be supported, but *sharing* a keyring is right out.) 3. Enigmail has shown them the limitations of GnuPG. The Efail attack on Enigmail was very real. It was created by an ambiguity in how GnuPG returns error states: just because GnuPG says "decryption OK" doesn't mean it was decrypted okay. (Whether Enigmail should've understood this, or whether GnuPG should have not returned such an ambiguous message, is an open question and not one I'm interested in discussing.) Rather than repeat Enigmail's interface, which historically had its fair share of security problems, Mozilla has decided to go a different route. More power to 'em. I love Enigmail, but it's the nature of all software that at some point we learn how to do things better. When we learn how to do things better, we should elect to do them better rather than stay mired in the past. (... and that principle, applied to OpenPGP, suggests throwing out a whole lot of cruft. Which is another open question I'm not interested in discussing, except to throw it out there for people to think about.) From tlikonen at iki.fi Sat Oct 12 09:13:59 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Sat, 12 Oct 2019 10:13:59 +0300 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: <87imouigg8.fsf@iki.fi> Philipp Klaus Krause [2019-10-08T15:34:28+02] wrote: > It would be really nice, if Thunderbird could add an option to use the > gpg key storage instead of its own, [...] I agree with that even though I have never really used Thunderbird. But using a custom key storage and implementation (or do they use Sequoia PGP library?) is an interesting choice in the world of Unix-like systems. It's pretty much the normal way elsewhere, though. PGP and GnuPG and the related communities have tried really hard to build a system based on person's long-term identity keys. All that web of trust thing relies on keys that are used relatively long time. But as we know this doesn't work for most people. People are really bad at maintaining long-term identity keys. I think this is the most important reason why other software just auto-generate "device keys" or "application keys" and exchange them. They just forget about the identity part and keys' usage in the long term. Change your phone or just reinstall the application and you'll have new keys. Keys come and go and it's perfectly normal. Thunderbird seems to be going to that direction and it is probably a good thing. From the mindset of crypto nerds (like us) or Unixy tool box this can be a barrier, obviously. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 694 bytes Desc: not available URL: From jan-peter at ruehmann.name Sat Oct 12 08:30:00 2019 From: jan-peter at ruehmann.name (=?UTF-8?Q?Jan-Peter_R=c3=bchmann?=) Date: Sat, 12 Oct 2019 08:30:00 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <09e6bc36-cb68-f017-9bb1-814e15ad51f4@ezaquarii.com> References: <09e6bc36-cb68-f017-9bb1-814e15ad51f4@ezaquarii.com> Message-ID: <5aca6c44-65c4-f9ca-045e-36a743deacb6@ruehmann.name> An HTML attachment was scrubbed... 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 rjh at sixdemonbag.org Sat Oct 12 11:19:33 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 12 Oct 2019 05:19:33 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <87imouigg8.fsf@iki.fi> References: <87imouigg8.fsf@iki.fi> Message-ID: <092389e7-9d2b-6953-aa9e-4a06daedcfd6@sixdemonbag.org> > PGP and GnuPG and the related communities have tried really hard to > build a system based on person's long-term identity keys. All that web > of trust thing relies on keys that are used relatively long time. But as > we know this doesn't work for most people. People are really bad at > maintaining long-term identity keys. A few years ago at Circumvention (the first Internet Freedom Festival), I was asked to give an impromptu talk on Things You're Doing Wrong With OpenPGP. The first thing on my list was certificate lifetime. We teach people the importance of maintaining their certificate for the long haul, but we also know very few people are capable of doing that. What we *don't* teach them is how to rebuild their trust network after a loss-of-certificate event. So when someone loses their cert, or has a system compromise, or their YubiKey goes through the laundry, or what-have-you, they get a double whammy of failure: they feel like a failure because they didn't do this thing that was expected of them (keep the cert for 20+ years, never mind how unreasonable that it), and they feel like a failure for not knowing how to recover from it. So instead: teach people that it's okay to lose a cert, so long as you have a plan to come back from it. Then if their Yubi goes through the laundry they (a) don't feel like a failure and (b) already have a plan for how to move forward. Seriously, ending the Cult of the Long-Term Certificate is one of the simple but good things I think we should be embracing for the sake of users. From bruderb at cation.de Sat Oct 12 10:43:31 2019 From: bruderb at cation.de (BruderB) Date: Sat, 12 Oct 2019 10:43:31 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> Message-ID: <77631f89-8efe-0a3e-d52d-6699d22c6f02@cation.de> Hej all, Am 12.10.19 um 08:23 schrieb Robert J. Hansen: > they're going to insist on running their own keyring internal to > Thunderbird which isn't shared with anything else. (I imagine > *importing* from a GnuPG keyring will be supported, but *sharing* a > keyring is right out.) _They_ can insist on whatever they want. If they close their shop towards external built keys (for example with xca), they hopefully won't find much acceptance..... regards, B. From wk at gnupg.org Sat Oct 12 12:55:38 2019 From: wk at gnupg.org (Werner Koch) Date: Sat, 12 Oct 2019 12:55:38 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <3ca59f25-bdac-a319-00bb-939fc4b16ad0@spth.de> (Philipp Klaus Krause's message of "Fri, 11 Oct 2019 20:18:23 +0200") References: <875zkvrvvo.fsf@vps.thesusis.net> <3ca59f25-bdac-a319-00bb-939fc4b16ad0@spth.de> Message-ID: <87a7a6p711.fsf@wheatstone.g10code.de> On Fri, 11 Oct 2019 20:18, Philipp Klaus Krause said: > They don't want users to require to install gpg first. And they don't > want to ship gpg with Windows installers, since it isn't MPL. The latter is just plain bullshit. There are even many proprietary products which bundle gpg or other GPL code with their proprietary or MPL licensed code. Not just small companies but large ones with huge and conservative legal departments. The actual requirements for distribution are easy to fulfill and are actually easier with the GPLv3 than with the v2. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Sat Oct 12 13:14:24 2019 From: wk at gnupg.org (Werner Koch) Date: Sat, 12 Oct 2019 13:14:24 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> (Robert J. Hansen's message of "Sat, 12 Oct 2019 02:23:48 -0400") References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> Message-ID: <875zkup65r.fsf@wheatstone.g10code.de> On Sat, 12 Oct 2019 02:23, Robert J. Hansen said: > on Enigmail was very real. It was created by an ambiguity in how GnuPG > returns error states: just because GnuPG says "decryption OK" doesn't Nope. They did not read the documentation and did not checked error codes. We suggest for a reason to use GPGME to make error checking easy. You can't just code things down along some specs without thinking over the implications. Still, TB is still subject to those attacks because their primary encryption protocol is S/MIME and the last time I checked S/MIME (well, CMS for the nitpickers) does not supoport any kind of authenticated encryption. In contarst OpenPGP provides this nearly for 2 decades. Mozilla has not even stepped forward and implemented one of the meanwhile old proposal to move to AE. So Microsoft had to take the lead to do this (rumors are that the next OL version will allow for GCM mode) After 20 years of strong resistance against implementing OpenPGP [1], they finally seem to do it. That is a good move. Shalom-Salam, Werner [1] Back in ~1999, when Mozilla rewrote the entire mail engine, I implemented a first version of PGP/MIME code which was rejected due to their policy of only supporting S/MIME. For a term paper a German student later took up on my code, extended and cleaned it up. Again it was rejected. About 2005 we had a meeting with them to propose that we implement S/MIME again in a way that would comply to the strong policy requirements here in Germany and also to implement OpenPGP as an additional protocol. It was again rejected. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Sat Oct 12 13:16:31 2019 From: wk at gnupg.org (Werner Koch) Date: Sat, 12 Oct 2019 13:16:31 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: (qwrd's message of "Fri, 11 Oct 2019 21:48:35 +0200") References: Message-ID: <871rvip628.fsf@wheatstone.g10code.de> On Fri, 11 Oct 2019 21:48, qwrd said: > Storing private keys on a smartcard is a noteworthy security > enhancement, and I would like to see smartcard support being available > in Thunderbird. Either via GnuPG or some other mechanism. Take a Yubikey or an OpenPGP smartcard, install Scute (pcks#11 provider) and GnuPG and you are done. Either S/MIME or OpenPGP. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From hello at ezaquarii.com Sat Oct 12 13:43:05 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Sat, 12 Oct 2019 12:43:05 +0100 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <875zkup65r.fsf@wheatstone.g10code.de> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> Message-ID: <31521daf-ddeb-9395-18cb-6982ff514563@ezaquarii.com> On 12/10/2019 12:14, Werner Koch via Gnupg-users wrote: > After 20 years of strong resistance against implementing OpenPGP [1], they > finally seem to do it. That is a good move. Do you know why they resited OpenPGP adoption it so much? Cheers, Chris From mwood at iupui.edu Sat Oct 12 14:07:58 2019 From: mwood at iupui.edu (Mark H. Wood) Date: Sat, 12 Oct 2019 08:07:58 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <87imouigg8.fsf@iki.fi> References: <87imouigg8.fsf@iki.fi> Message-ID: <20191012120758.GA13136@IUPUI.Edu> On Sat, Oct 12, 2019 at 10:13:59AM +0300, Teemu Likonen via Gnupg-users wrote: > Philipp Klaus Krause [2019-10-08T15:34:28+02] wrote: > > > It would be really nice, if Thunderbird could add an option to use the > > gpg key storage instead of its own, [...] > > I agree with that even though I have never really used Thunderbird. > > But using a custom key storage and implementation (or do they use > Sequoia PGP library?) is an interesting choice in the world of Unix-like > systems. It's pretty much the normal way elsewhere, though. > > PGP and GnuPG and the related communities have tried really hard to > build a system based on person's long-term identity keys. All that web > of trust thing relies on keys that are used relatively long time. But as > we know this doesn't work for most people. People are really bad at > maintaining long-term identity keys. I think this is the most important > reason why other software just auto-generate "device keys" or > "application keys" and exchange them. They just forget about the > identity part and keys' usage in the long term. Change your phone or > just reinstall the application and you'll have new keys. Keys come and > go and it's perfectly normal. That would be one of the reasons why I tend to avoid "other software". My primary use-case is identity, not secrecy. I am not alone: quite a few employers are at last discovering crypto signatures in their efforts to combat spear-phishing, and spending quite a bit of money and effort to deploy them. (I accept that most of them are using S/MIME rather than OpenPGP, but that's a detail; identity is important.) > Thunderbird seems to be going to that direction and it is probably a > good thing. From the mindset of crypto nerds (like us) or Unixy tool box > this can be a barrier, obviously. Humph, I was already grumpy about Mozilla products' insistence on having their own insular X.509 store, meaning that I have to install certificates twice (once for Firefox, again for *everything else*.) Maybe there will be an add-on, so that those who care can choose to integrate Thunderbird into their systems rather than having it still standing off to one side haughtily awaiting special treatment. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From dgouttegattat at incenp.org Sat Oct 12 21:26:31 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 12 Oct 2019 20:26:31 +0100 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <20191012120758.GA13136@IUPUI.Edu> References: <87imouigg8.fsf@iki.fi> <20191012120758.GA13136@IUPUI.Edu> Message-ID: <20191012192630.q7g5eylbcly4ygng@aurora.local.incenp.org> On Sat, Oct 12, 2019 at 08:07:58AM -0400, Mark H. Wood wrote: >Humph, I was already grumpy about Mozilla products' insistence on >having their own insular X.509 store, meaning that I have to install >certificates twice (once for Firefox, again for *everything else*.) Slightly off-topic for this list, but on unix-like systems, you can force Firefox to use the system store of X.509 certificates (in /etc/ssl/certs) by replacing Firefox?s libnssckbi.so library by the libp11-kit.so library from the p11-kit project [1,2]. This also works with Thunderbird and with LibreOffice. - Damien [1] https://p11-glue.github.io/p11-glue/p11-kit.html [2] https://askubuntu.com/questions/244582/add-certificate-authorities-system-wide-on-firefox/1036637#1036637 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From patrick at enigmail.net Sun Oct 13 08:21:35 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 13 Oct 2019 08:21:35 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> Message-ID: BruderB wrote on 12.10.2019 10:43: > Hej all, > > Am 12.10.19 um 08:23 schrieb Robert J. Hansen: >> they're going to insist on running their own keyring internal to >> Thunderbird which isn't shared with anything else. (I imagine >> *importing* from a GnuPG keyring will be supported, but *sharing* a >> keyring is right out.) > > _They_ can insist on whatever they want. If they close their shop > towards external built keys (for example with xca), they hopefully won't > find much acceptance..... The vast majority of users of Enigmail (somewhere around 98%) don't use external built keys. The vast majority of users also don't use GnuPG for anything else than email. These users don't care where their key is stored, nor which software under the hood is used for the crypto. All they care is that encryption works smoothly. I'm sorry, but everything written here is pure speculation. We are still in the phase of considering our options. Depending on the chosen approach, we may just as well end up with something completely different than what you'd imagine. The most important aspects from our side are the following: The chosen solution must run smoothly for the ~20M users of Thunderbird without causing a large amount of support/setup issues. We want to have something that satisfies as many users of Enigmail as possible. We certainly don't want to have people run away from Thunderbird because of OpenPGP. -Patrick From wk at gnupg.org Sun Oct 13 11:56:19 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 13 Oct 2019 11:56:19 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <31521daf-ddeb-9395-18cb-6982ff514563@ezaquarii.com> (Chris Narkiewicz via Gnupg-users's message of "Sat, 12 Oct 2019 12:43:05 +0100") References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <31521daf-ddeb-9395-18cb-6982ff514563@ezaquarii.com> Message-ID: <87o8ylnf3w.fsf@wheatstone.g10code.de> On Sat, 12 Oct 2019 12:43, Chris Narkiewicz said: > Do you know why they resited OpenPGP adoption it so much? iirc, they said that they want to support only one protocol and settled for S/MIME. This still did not explain why they rejected our proposal to clean up their S/MIME code and implement missing stuff so that TB could be used for tasks of the German administrative and to be compatible with a wider range of S/MIME implementations. The plan was to do that all within TB and without external dependencies. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jan-peter at ruehmann.name Sun Oct 13 08:31:34 2019 From: jan-peter at ruehmann.name (=?UTF-8?Q?Jan-Peter_R=c3=bchmann?=) Date: Sun, 13 Oct 2019 08:31:34 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> Message-ID: An HTML attachment was scrubbed... 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 patrick at enigmail.net Sun Oct 13 18:04:32 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 13 Oct 2019 18:04:32 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <87o8ylnf3w.fsf__15993.5990160861$1570963543$gmane$org@wheatstone.g10code.de> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <31521daf-ddeb-9395-18cb-6982ff514563@ezaquarii.com> <87o8ylnf3w.fsf__15993.5990160861$1570963543$gmane$org@wheatstone.g10code.de> Message-ID: Werner Koch via Gnupg-users wrote on 13.10.2019 11:56: > On Sat, 12 Oct 2019 12:43, Chris Narkiewicz said: > >> Do you know why they resited OpenPGP adoption it so much? > > iirc, they said that they want to support only one protocol and settled > for S/MIME. This still did not explain why they rejected our proposal > to clean up their S/MIME code and implement missing stuff so that TB > could be used for tasks of the German administrative and to be > compatible with a wider range of S/MIME implementations. The plan was > to do that all within TB and without external dependencies. I think there are two reasons why TB changed their minds: 1. there are different people working on Thunderbird than years ago. 2. in the past, TB was a direct part of Mozilla. Now, Thunderbird is an independent organization under the umbrella of the Mozilla Foundation, with an independent council and their own independent financial income stream. These two factors lead to a completely different mindset towards what is good for TB. -Patrick From lists at binarus.de Sun Oct 13 18:27:59 2019 From: lists at binarus.de (Binarus) Date: Sun, 13 Oct 2019 18:27:59 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: On 08.10.2019 09:08, Patrick Brunschwig wrote: > The Thunderbird developers have announced that they will implement > OpenPGP support in Thunderbird 78 [1]. Support for Thunderbird in > Enigmail will therefore be discontinued. > > [Snip] > > I will continue to support and maintain Enigmail for Thunderbird 68 > until 6 months after Thunderbird 78 will have been released (i.e. a few > months beyond Thunderbird 68 EOL). Enigmail will not run anymore on > Thunderbird 72 beta and newer. IMHO, integrating PGP into TB in general is a good decision. However, I have two concerns (being a naive user, and being far away from understanding the technical aspects). 1) The schedule We have all been educated to update our applications (notably, "internet applications" like browser and email clients) as soon as updates are available; at least, this is true for security updates. Despite release plans, I think nobody knows for sure how much time actually will pass between TB 72's predecessor and TB 78, and how many security updates will be released between these versions. During that time, I either can't use Enigmail (if I decide to install the security updates), or I have to ignore the security updates (possibly putting me to risk). Did I understand this correctly? I am not on a level that I would use GnuPG on the command line to encrypt or authenticate my messages (encryption is fascinating, and if I had the time, it would be a pleasure to dive deeply into this subject, but for the time being, I just need it working), so I am dependent on the TB / Enigmail duo (at least until TB 78). 2) The features When integrating PGP into TB, IMHO great attention must be paid that none of the important features of Enigmail / GnuPG get lost, not even in the first version. The statement that the first implementation probably will be "less feature-rich" than Enigmail (let alone GnuPG) really frightens me and lets me expect all sorts of problems. For example, even I (as a non-advanced user) recently had an issue where I could not use PGP keys which were generated by Enigmail, because the keys' IDs were formally wrong so that key servers didn't accept the keys. The easiest possible solution was to re-generate these keys using GnuPG on the command line (despite my statement above ...) and import them into Enigmail. This simple case shows that we actually need the full functionality of a mature software package like GnuPG from the beginning on (note that my problem was ridiculously simple, but even then I couldn't easily solve it using Enigmail alone). My feeling is that TB (and probably email encryption / authentication per se) will lose a lot of users (including me) if the first implementation lacks essential features, makes the encryption setup fail due to common problems (like mine), or makes encryption unusable or difficult in any other way. By the way, being able to encrypt the subject of an encrypted message also is one of the essential features (thanks, Patrick, and thanks, Werner, that you finally have made this possible a while ago!) ... Just my 2 cents ... Regards, Binarus From wk at gnupg.org Sun Oct 13 18:51:11 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 13 Oct 2019 18:51:11 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: (Binarus's message of "Sun, 13 Oct 2019 18:27:59 +0200") References: Message-ID: <87k198oagw.fsf@wheatstone.g10code.de> On Sun, 13 Oct 2019 18:27, Binarus said: > keys' IDs were formally wrong so that key servers didn't accept the > keys. The easiest possible solution was to re-generate these keys using For the records: Not /keyservers/ but one specific keyserver which runs on a not yet matured enough code base and is thus expected to have bugs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lists at binarus.de Sun Oct 13 19:15:07 2019 From: lists at binarus.de (Binarus) Date: Sun, 13 Oct 2019 19:15:07 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <87k198oagw.fsf@wheatstone.g10code.de> References: <87k198oagw.fsf@wheatstone.g10code.de> Message-ID: <4089f9e9-ab52-c5b8-f2dc-dee2eea4162a@binarus.de> On 13.10.2019 18:51, Werner Koch wrote: > On Sun, 13 Oct 2019 18:27, Binarus said: > >> keys' IDs were formally wrong so that key servers didn't accept the >> keys. The easiest possible solution was to re-generate these keys using > > For the records: Not /keyservers/ but one specific keyserver which runs > on a not yet matured enough code base and is thus expected to have bugs. > Thank you very much for your remark. Actually, I have meant this to be just an example for the problems to expect if too many features are missing. Secondly, I suspect that there are more keyservers out there (running other software) which also would reject those keys (I didn't try, though, so this is speculation). Thirdly, this is the keyserver which is preset in Enigmail (I didn't change the default). For naive users like me, it is not possible to check a keyserver's software version and to analyze how mature / stable it is. I even wouldn't come to that idea, because this is the default keyserver in a well-known software package :-) If I wouldn't have been able to generate correct keys / IDs using GnuPG directly, I eventually would have given up on encryption. Regards, Binarus From jrallen at runbox.com Sun Oct 13 22:27:23 2019 From: jrallen at runbox.com (Jeff Allen) Date: Sun, 13 Oct 2019 16:27:23 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> Message-ID: <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> On 10/13/19 2:21 AM, Patrick Brunschwig wrote: > The vast majority of users of Enigmail (somewhere around 98%) don't use > external built keys. How do you know this? > The vast majority of users also don't use GnuPG for > anything else than email. These users don't care where their key is > stored, nor which software under the hood is used for the crypto. All > they care is that encryption works smoothly. And this? > The most important aspects from our side are the following: The chosen > solution must run smoothly for the ~20M users of Thunderbird without > causing a large amount of support/setup issues. Presumably those ~20,000,000 will have to opt-in to use Thunderbird encryption. Most won't for the same reason they don't install and use Enigmail now. They don't particularly care about privacy, and the few who do care correspond with people who don't. > We want to have > something that satisfies as many users of Enigmail as possible. We > certainly don't want to have people run away from Thunderbird because of > OpenPGP. If responses to my posts in the "We have GOT TO make things simpler" thread are any indication, you'll be looking at quite a few back sides. Is there any reason to think that folks who object to easy-to-use proprietary encrypted email solutions from ProtonMail and Tutanota will embrace a proprietary encrypted email solution from Thunderbird? Jeff Allen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Mon Oct 14 06:17:58 2019 From: gniibe at fsij.org (Niibe Yutaka) Date: Mon, 14 Oct 2019 13:17:58 +0900 Subject: Cannot decrypt from smartcard using gnupg-2.2, can from 2.0 In-Reply-To: References: Message-ID: <87d0f0vu2x.fsf@jumper.gniibe.org> alejandro Cortez wrote: > gpg: public key decryption failed: Invalid ID This means that something goes wrong in your private key file for your token, I suppose. > Can anyone help debug this? You can see more information, by following command line: $ gpg-connect-agent "KEYINFO --list" /bye This doesn't reveal secret (but your serial number). The example output (of mine) is like: ========================== $ gpg-connect-agent "KEYINFO --list" /bye S KEYINFO A97A7983102513844456E5B687E46B936B14155C D - - - P - - - S KEYINFO 65F67E742101C7FE6D5B33FCEFCF4F65EAF0688C T D276000124010200F517000000010000 OPENPGP.2 - - - - - S KEYINFO 101DE7B639FE29F4636BDEECF442A9273AFA6565 T D276000124010200F517000000010000 OPENPGP.1 - - - - - S KEYINFO 5D6C89682D07CCFC034AF508420BF2276D8018ED T D276000124010200F517000000010000 OPENPGP.3 - - - - - OK $ ========================== The third column is a keygrip. The fifth column is an application ID (vendor id + serial number) of the card. The sixth column is the key identifier. The key identifier "OpenPGP.2" is used for decription process. I suspect you have some different string there, for some reason. -- From patrick at enigmail.net Mon Oct 14 09:17:49 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 14 Oct 2019 09:17:49 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: Message-ID: <43b27f0f-645f-dbf1-1be0-cc9ef27921a9@enigmail.net> Binarus wrote on 13.10.2019 18:27: [...] > 1) The schedule > > We have all been educated to update our applications (notably, "internet > applications" like browser and email clients) as soon as updates are > available; at least, this is true for security updates. > > Despite release plans, I think nobody knows for sure how much time > actually will pass between TB 72's predecessor and TB 78, and how many > security updates will be released between these versions. > > During that time, I either can't use Enigmail (if I decide to install > the security updates), or I have to ignore the security updates > (possibly putting me to risk). > > Did I understand this correctly? The current stable version of Thunderbird is 68 (and 60 for a few more weeks); the next stable version will be 78. Users of Enigmail staying on the stable version of Thunderbird will receive all security updates until TB 78 will be available. Thunderbird 69 ... 77 are only released as beta versions that are not intended for end users. -Patrick From lists at binarus.de Mon Oct 14 09:40:30 2019 From: lists at binarus.de (Binarus) Date: Mon, 14 Oct 2019 09:40:30 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> Message-ID: On 13.10.2019 22:27, Jeff Allen via Gnupg-users wrote: > On 10/13/19 2:21 AM, Patrick Brunschwig wrote: >> The vast majority of users of Enigmail (somewhere around 98%) don't use >> external built keys. > > How do you know this? > I don't know either, but perhaps it is in the debug logs the Enigmail team analyzes? >> The vast majority of users also don't use GnuPG for >> anything else than email. These users don't care where their key is >> stored, nor which software under the hood is used for the crypto. All >> they care is that encryption works smoothly. > > And this? > I am also not sure about this. As far as it concerns Windows, the first part of the statement may be true. There is plenty of software to encrypt single files or directories for Windows, including the software which is part of the O/S. People probably tend to go the easiest way, even if another solution would be safer and technically superior. I don't know the situation under Linux well enough to comment. I disagree with the second part of the statement, though. Most of the people who think about privacy and email encryption / authentication at all are educated, non-average users who want to be sure that there are no backdoors in their software and that they use it as safely as possible (meaning that they care about software, algorithms and ciphers), and who want to backup their keys (meaning that they care where the keys are stored). And yes, I want to decide on my own if my key is ED25519, RSA1024 or RSA4096 :-) >> The most important aspects from our side are the following: The chosen >> solution must run smoothly for the ~20M users of Thunderbird without >> causing a large amount of support/setup issues. > > Presumably those ~20,000,000 will have to opt-in to use Thunderbird > encryption. Most won't for the same reason they don't install and use > Enigmail now. They don't particularly care about privacy, and the few > who do care correspond with people who don't. > I am not sure where this will lead to. It sounds as if you were suggesting to give up on privacy, encryption and authentication for that reason. While I agree with you that this problem exists and is quite difficult to solve (eventually it needs another decade), I am absolutely sure that bad and difficult software will make it worse, but good and usable software will help in solving it. The fact that the problem exists does not mean that nobody should try to solve it by providing easier-to-use, fully integrated software with reasonable default settings. >> We want to have >> something that satisfies as many users of Enigmail as possible. We >> certainly don't want to have people run away from Thunderbird because of >> OpenPGP. > > [Snip] > > Is there any reason to think that folks who object to easy-to-use > proprietary encrypted email solutions from ProtonMail and Tutanota will > embrace a proprietary encrypted email solution from Thunderbird? > There are many reasons to think so (the following applies to ProtonMail as well as Tutanota): 1) To actually use those services in a reasonable manner, you have to opt-in for a paid contract. For most of us, this is a matter of principle. Why should we pay for a thing that used to be free all the time? (Note: I don't want to judge that attitude - I am just stating how it is). 2) None of that services supports IMAP or POP3. I would be totally crazy if I would make myself totally dependent on companies or services which won't let me download my messages and integrate them into my email client. What happens if those companies suddenly stop their service and you haven't downloaded your messages yet (which anyway seems to be impossible)? Or if you decide that you want to use another service? How long will you be able to access your messages after you have stopped paying your old service? Will they delete your messages until the quota for free usage is reached again? I insist on having all important data, including email messages, in-house and under my complete control, and I strongly advise each of my customers to do the same. So far, all of them are following that advice. Therefore, such services never will have any chance to do business with my customers. 3) I have several email addresses. I am definitely not ready to use a different website or different software for each of them. That is, there is absolutely no chance that I ever will use a service which does not provide POP3 or IMAP (or, for the protocol, their successors). I want *one* MUA (like Thunderbird) to be able to manage *all* of my email messages in *one* place (For example, ever needed to search for a message for which you can't remember the account it was received on? - The global search in TB is very handy here. Further reasons: junk filtering, action filters (automatically moving certain messages in subfolders) and so on, all managed at one place, public folders, shared folders and so on). 4) I doubt that these services can be legally used by businesses in Germany. We are having some weird rules here, one of them saying that we have to keep *each* (electronic) message we are receiving and sending in a separate archive where users don't have access to. That is, users of course may do anything they want in their normal email account, but all messages which are ever sent or received must first be copied somewhere where they cannot be manipulated or deleted. I can't imagine how this could be achieved when using those services. These are only a few of the many reasons against using a purely cloud-based email system. Regards, Binarus From lists at binarus.de Mon Oct 14 09:45:06 2019 From: lists at binarus.de (Binarus) Date: Mon, 14 Oct 2019 09:45:06 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <43b27f0f-645f-dbf1-1be0-cc9ef27921a9@enigmail.net> References: <43b27f0f-645f-dbf1-1be0-cc9ef27921a9@enigmail.net> Message-ID: <3cf58fd1-4f77-5653-bbb4-1f5760074c37@binarus.de> On 14.10.2019 09:17, Patrick Brunschwig wrote: > Binarus wrote on 13.10.2019 18:27: > [...] >> 1) The schedule >> >> We have all been educated to update our applications (notably, "internet >> applications" like browser and email clients) as soon as updates are >> available; at least, this is true for security updates. >> >> Despite release plans, I think nobody knows for sure how much time >> actually will pass between TB 72's predecessor and TB 78, and how many >> security updates will be released between these versions. >> >> During that time, I either can't use Enigmail (if I decide to install >> the security updates), or I have to ignore the security updates >> (possibly putting me to risk). >> >> Did I understand this correctly? > > The current stable version of Thunderbird is 68 (and 60 for a few more > weeks); the next stable version will be 78. Users of Enigmail staying on > the stable version of Thunderbird will receive all security updates > until TB 78 will be available. Thunderbird 69 ... 77 are only released > as beta versions that are not intended for end users. > I see. Thank you very much for the clarification. This relieves a lot of tension. Regards, Binarus From jrallen at runbox.com Mon Oct 14 16:15:21 2019 From: jrallen at runbox.com (Jeff Allen) Date: Mon, 14 Oct 2019 10:15:21 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> Message-ID: On 10/14/19 3:40 AM, Binarus wrote: > > On 13.10.2019 22:27, Jeff Allen via Gnupg-users wrote: >> On 10/13/19 2:21 AM, Patrick Brunschwig wrote: >>> The vast majority of users of Enigmail (somewhere around 98%) don't use >>> external built keys. >> >> How do you know this? >> > > I don't know either, but perhaps it is in the debug logs the Enigmail > team analyzes? I have used Enigmail since its inception and have never knowingly submitted a log or answered a survey and have always assumed Enigmail does not phone home. >>> The vast majority of users also don't use GnuPG for >>> anything else than email. These users don't care where their key is >>> stored, nor which software under the hood is used for the crypto. All >>> they care is that encryption works smoothly. >> >> And this? >> > > I am also not sure about this. As far as it concerns Windows, the first > part of the statement may be true. All the statements might be true. My question was "How do you know?" > I disagree with the second part of the statement, though. Most of the > people who think about privacy and email encryption / authentication at > all are educated, non-average users who want to be sure that there are > no backdoors in their software and that they use it as safely as > possible (meaning that they care about software, algorithms and > ciphers), and who want to backup their keys (meaning that they care > where the keys are stored). And yes, I want to decide on my own if my > key is ED25519, RSA1024 or RSA4096 :-) I agree and think Patrick underestimates the number of GnuPG/Enigmail users who care a lot about the details. My argument in the other thread was that folks who value privacy and encryption but can't be burdened by the details have reasonably secure easy-to-use options available. Enigmail is, of course, one of them. >>> The most important aspects from our side are the following: The chosen >>> solution must run smoothly for the ~20M users of Thunderbird without >>> causing a large amount of support/setup issues. >> >> Presumably those ~20,000,000 will have to opt-in to use Thunderbird >> encryption. Most won't for the same reason they don't install and use >> Enigmail now. They don't particularly care about privacy, and the few >> who do care correspond with people who don't. >> > > I am not sure where this will lead to. It sounds as if you were > suggesting to give up on privacy, encryption and authentication for that > reason. Not at all. My point was that I doubt OpenPGP's inclusion in Thunderbird will have a major impact on the number of people encrypting their email. > While I agree with you that this problem exists and is quite difficult > to solve (eventually it needs another decade), I am absolutely sure that > bad and difficult software will make it worse, but good and usable > software will help in solving it. The fact that the problem exists does > not mean that nobody should try to solve it by providing easier-to-use, > fully integrated software with reasonable default settings. Here we disagree. I believe that existing software is not that difficult to use. The problem, if there is one, is that most people simply aren't interested. Twenty years ago I thought that everyone would soon be using end-to-end encrypted email. Twenty years from now they still won't be. >>> We want to have >>> something that satisfies as many users of Enigmail as possible. We >>> certainly don't want to have people run away from Thunderbird because of >>> OpenPGP. >> >> [Snip] >> >> Is there any reason to think that folks who object to easy-to-use >> proprietary encrypted email solutions from ProtonMail and Tutanota will >> embrace a proprietary encrypted email solution from Thunderbird? >> > > There are many reasons to think so (the following applies to ProtonMail > as well as Tutanota): > > 1) To actually use those services in a reasonable manner, you have to > opt-in for a paid contract. For most of us, this is a matter of > principle. Why should we pay for a thing that used to be free all the > time? (Note: I don't want to judge that attitude - I am just stating how > it is). But "free" email has never been free from the likes of Gmail, Yahoo, GMX, etc. While you don't pay a yearly fee, you trade your privacy for a few bucks. You open yourself to tracking and targeted advertising. Your email is anything but private. A couple years back both Google and Yahoo claimed to be working on E2EE. I wonder why it never happened? The free versions of ProtonMail, Tutanota and Mailfence at least preserve your privacy. They aren't monetized through advertising and tracking. Instead they sell premium services to people who want more capacity or features. Many people I know do email exclusively on their smart phones. They don't use an MUA and don't care about POP3, IMAP or SMTP. Their view of using email services in a reasonable manner doesn't comport with yours or mine. I hope I am wrong and Thunderbird's OpenPGP implementation is a complete success encouraging many more people to encrypt their email. I would, however, personally prefer that Thunderbird directly implement GnuPG integration instead of going it alone. That would satisfy both casual and power users as Enigmail does now. Will Thunderbird OpenPGP support smart cards like my Yubikey? How about a feature like GnuPG's group line or Enigmail's per-recipient rules? In-line PGP as well as PGP/MIME? Encrypted subject and the ability to turn it on or off? As far as I know, they are all features of GnuPG or Enigmail and not required by the OpenPGP specification. Patrick and company deserve our thanks for many years splendid service to the OpenPGP community. So does Werner and his team who created and maintain a tool that has satisfied a wide range of users for decades. I doubt that yet another proprietary OpenPGP system is what the world needs. Jeff Allen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From phill at thesusis.net Mon Oct 14 16:54:58 2019 From: phill at thesusis.net (Phillip Susi) Date: Mon, 14 Oct 2019 10:54:58 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <875zkup65r.fsf@wheatstone.g10code.de> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> Message-ID: <87eezfnzr1.fsf@vps.thesusis.net> Werner Koch via Gnupg-users writes: > Still, TB is still subject to those attacks because their primary > encryption protocol is S/MIME and the last time I checked S/MIME (well, > CMS for the nitpickers) does not supoport any kind of authenticated > encryption. In contarst OpenPGP provides this nearly for 2 decades. What do you mean? S/MIME authenticates the user's identity via the CA. From wk at gnupg.org Mon Oct 14 18:34:28 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Oct 2019 18:34:28 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <87eezfnzr1.fsf@vps.thesusis.net> (Phillip Susi's message of "Mon, 14 Oct 2019 10:54:58 -0400") References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <87eezfnzr1.fsf@vps.thesusis.net> Message-ID: <87o8yjjnfv.fsf@wheatstone.g10code.de> On Mon, 14 Oct 2019 10:54, Phillip Susi said: >> encryption protocol is S/MIME and the last time I checked S/MIME (well, >> CMS for the nitpickers) does not supoport any kind of authenticated >> encryption. In contarst OpenPGP provides this nearly for 2 decades. > > What do you mean? S/MIME authenticates the user's identity via the CA. authenticated encryption is different from signed and encrypted mails. There are relative easy attacks on the encryption layer if standard encryption modes like CBC (as in S/MIME) are used. Whether this really affects users is a different question but they can be used to leverage implementation flaws in MUAs to full plaintext leaks. This is known for 20 years and made it last year again to the media under the term EFAIL. Granted, encrypted+signed mails can to a large extend also mitigate the threat. But there are still reasons why signatures can't be used or need to be verified only at a latter time in the workflow. OpenPGP had a mitigation against this since 2000 and was widely deployed by 2003. However S/MIME never implemented this despite of 10 years old RFCs describing methods for such a mitigation, called authenticated encryption (AE or AEAD). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From juergen at bruckner.tk Mon Oct 14 18:54:52 2019 From: juergen at bruckner.tk (Juergen Bruckner) Date: Mon, 14 Oct 2019 18:54:52 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <87o8yjjnfv.fsf@wheatstone.g10code.de> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <87eezfnzr1.fsf@vps.thesusis.net> <87o8yjjnfv.fsf@wheatstone.g10code.de> Message-ID: <424b334d-054b-c460-4fa6-878ee4c06ee7@bruckner.tk> Hello to all, well it's a good thing, that openPGP shall be included to TB directly. But ... as the Mozilla wiki [1] states in the FAQ-Section the following: Q: Will OpenPGP cards be supported for private key storage ? A: Probably not, because we don't use the GnuPG software that's usually required to access OpenPGP smartcards. This will not be usefull for me or my company, as we only use PGP Keys stored on smartcards. So I guess we will have to take TB down and find other solutions. m2c Juergen [1] https://wiki.mozilla.org/Thunderbird:OpenPGP:2020 -- Juergen M. 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 kristian.fiskerstrand at sumptuouscapital.com Mon Oct 14 20:43:07 2019 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 14 Oct 2019 20:43:07 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <424b334d-054b-c460-4fa6-878ee4c06ee7@bruckner.tk> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <87eezfnzr1.fsf@vps.thesusis.net> <87o8yjjnfv.fsf@wheatstone.g10code.de> <424b334d-054b-c460-4fa6-878ee4c06ee7@bruckner.tk> Message-ID: On 14.10.2019 18:54, Juergen Bruckner via Gnupg-users wrote: > Hello to all, > > well it's a good thing, that openPGP shall be included to TB directly. > > But ... as the Mozilla wiki [1] states in the FAQ-Section the following: > > > Q: Will OpenPGP cards be supported for private key storage ? > > A: Probably not, because we don't use the GnuPG software that's usually > required to access OpenPGP smartcards. I agree OpenPGP smartcard/token support is a must have, and brought this up during this during this weekend's OpenPGP summit; please see the [notes] section "Workshop: Thunderbird & OpenPGP" for some of the discussion, specifically """ Although RNP doesn't support smartcards currently, a potential solution was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC. Details need to be discussed, but it would be an optional solution, that only works if the user has installed software (scd etc.) in addition to Thunderbird. How would this work? GnuPG as an optional dependency? Outsourcing smartcard handling to scdaemon (scd), which is available cross-platform through Unix socket or TCP/IP (windows) with usual user system protection? Or... extend the RNP library to talk to scd? Needs discussion and contributors, but that should wait until we're certain what library TB will use. """ References: [notes] https://wiki.gnupg.org/OpenPGPEmailSummit201910Notes -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From anastasiareimer5 at googlemail.com Mon Oct 14 10:19:52 2019 From: anastasiareimer5 at googlemail.com (Anastasia Reimer) Date: Mon, 14 Oct 2019 10:19:52 +0200 Subject: Configuration Failure Gnugp Message-ID: Hello Team, i am not able to follow your documentation and get Gnugp up and running locally. I have already tried to download missing dependencies and libraries and move them into the right directory, but that is not working as i am getting the same error message over and over again. See my Error message below: --------------------------------------------------------------------------------------------------------- (base) anastasias-mbp:gnupg-2.2.17 anastasia.reimer$ ./configure && make && sudo make install checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... build-aux/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking build system type... x86_64-apple-darwin18.7.0 checking host system type... x86_64-apple-darwin18.7.0 configure: autobuild project... gnupg configure: autobuild revision... 2.2.17 configure: autobuild hostname... anastasias-mbp.hamburg.de.ibm.com configure: autobuild timestamp... 20191014-095950 checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether SELinux support is requested... no checking whether to allocate extra secure memory... no checking calibrated passphrase-stretching (s2k) duration... 100 milliseconds checking whether to enable trust models... yes checking whether to enable TOFU... yes checking whether to enable libdns... yes checking whether to enable the RSA public key for gpg... yes checking whether to enable the ECDH public key for gpg... yes checking whether to enable the ECDSA public key for gpg... yes checking whether to enable the EdDSA public key for gpg... yes checking whether to enable the IDEA cipher for gpg... yes checking whether to enable the CAST5 cipher for gpg... yes checking whether to enable the BLOWFISH cipher for gpg... yes checking whether to enable the AES128 cipher for gpg... yes checking whether to enable the AES192 cipher for gpg... yes checking whether to enable the AES256 cipher for gpg... yes checking whether to enable the TWOFISH cipher for gpg... yes checking whether to enable the CAMELLIA128 cipher for gpg... yes checking whether to enable the CAMELLIA192 cipher for gpg... yes checking whether to enable the CAMELLIA256 cipher for gpg... yes checking whether to enable the MD5 hash for gpg... yes checking whether to enable the RIPE-MD160 hash for gpg... yes checking whether to enable the SHA-224 hash for gpg... yes checking whether to enable the SHA-384 hash for gpg... yes checking whether to enable the SHA-512 hash for gpg... yes checking whether to enable the ZIP and ZLIB compression algorithm... yes checking whether to enable the BZIP2 compression algorithm... yes checking whether to enable external program execution... yes checking whether to enable photo ID viewing... yes checking whether to use a fixed photo ID viewer... no checking for the size of the key and uid cache... 4096 checking whether use of capabilities is requested... no checking whether smartcard support is requested... yes checking whether to enable the internal CCID driver... auto checking whether to auto start dirmngr... yes checking whether to enable maintainer-specific portions of Makefiles... no configure: checking for programs checking whether make sets $(MAKE)... (cached) yes checking whether build environment is sane... yes checking whether make supports nested variables... (cached) yes checking for gawk... (cached) awk checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking dependency style of gcc... (cached) gcc3 checking how to run the C preprocessor... gcc -E checking whether ln -s works... yes checking for ranlib... ranlib checking for ar... ar checking for perl... /usr/bin/perl checking for windres... no checking for yat2m... no checking for strerror in -lcposix... no checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for tar... /usr/bin/tar checking whether /usr/bin/tar speaks USTAR... yes checking for cc for build... gcc checking for pkg-config... no configure: checking for libraries checking for gpg-error-config... no checking for GPG Error - version >= 1.24... no checking for libgcrypt-config... no checking for LIBGCRYPT - version >= 1.7.0... no checking for libassuan-config... no checking for LIBASSUAN - version >= 2.5.0... no checking for ksba-config... no checking for KSBA - version >= 1.3.4... no checking for libusb_init in -lusb-1.0... no checking libusb include dir... not found checking for library containing dlopen... none required checking for SQLITE3... no configure: WARNING: *** *** Building without SQLite support - TOFU disabled *** *** checking for encfs... /usr/bin/encfs checking for fusermount... /usr/bin/fusermount checking for openpty in -lutil... yes checking for shred... /usr/bin/shred checking for npth-config... no checking for NPTH - version >= 1.2... no configure: WARNING: *** *** To support concurrent access for example in gpg-agent and the SCdaemon *** we need the support of the New Portable Threads Library. *** checking for ntbtls-config... no checking for NTBTLS - version >= 0.1.0... no checking for LIBGNUTLS... no configure: WARNING: *** *** Building without NTBTLS and GNUTLS - no TLS access to keyservers. *** *** configure: checking for networking options checking for gethostbyname... yes checking for setsockopt... yes checking for library containing res_query... none required checking for library containing dn_expand... none required checking for library containing res_9_dn_skipname... -lresolv checking whether the resolver is usable... no checking whether I can make the resolver usable with BIND_8_COMPAT... yes checking whether LDAP via "-lldap" is present and sane... yes checking for ldap_get_option... yes checking for ldap_set_option... yes checking for ldap_start_tls_s... yes checking for ldap_start_tls_sA... no checking for ber_free in -llber... yes checking for sendmail... /usr/sbin/sendmail checking for ld used by GCC... /Library/Developer/CommandLineTools/usr/bin/ld checking if the linker (/Library/Developer/CommandLineTools/usr/bin/ld) is GNU ld... no checking for shared library run path origin... done checking for iconv... yes checking for working iconv... yes checking how to link with libiconv... -liconv checking for iconv declaration... extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); configure: checking for gettext checking whether NLS is requested... yes checking for msgfmt... //anaconda3/bin/msgfmt checking for gmsgfmt... //anaconda3/bin/msgfmt checking for xgettext... //anaconda3/bin/xgettext checking for msgmerge... //anaconda3/bin/msgmerge checking for CFPreferencesCopyAppValue... yes checking for CFLocaleCopyCurrent... yes checking for GNU gettext in libc... no checking for iconv... (cached) yes checking for working iconv... (cached) yes checking how to link with libiconv... -liconv checking for GNU gettext in libintl... no checking whether to use NLS... no checking for strchr... yes checking for nl_langinfo and CODESET... yes checking for LC_MESSAGES... yes configure: checking for header files checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking termio.h usability... no checking termio.h presence... no checking for termio.h... no checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking pty.h usability... no checking pty.h presence... no checking for pty.h... no checking utmp.h usability... yes checking utmp.h presence... yes checking for utmp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking for inttypes.h... (cached) yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking for stdint.h... (cached) yes checking for signal.h... (cached) yes checking util.h usability... yes checking util.h presence... yes checking for util.h... yes checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking ucred.h usability... no checking ucred.h presence... no checking for ucred.h... no checking sys/ucred.h usability... yes checking sys/ucred.h presence... yes checking for sys/ucred.h... yes checking sys/sysmacros.h usability... no checking sys/sysmacros.h presence... no checking for sys/sysmacros.h... no checking sys/mkdev.h usability... no checking sys/mkdev.h presence... no checking for sys/mkdev.h... no checking whether time.h and sys/time.h may both be included... yes configure: checking for system characteristics checking for an ANSI C-conforming const... yes checking for inline... inline checking for working volatile... yes checking for size_t... yes checking for mode_t... yes checking return type of signal handlers... void checking whether sys_siglist is declared... yes checking for sys/socket.h... yes checking for socklen_t... yes checking for library containing inet_addr... none required checking endianness... little checking for byte typedef... no checking for ushort typedef... yes checking for ulong typedef... no checking for u16 typedef... no checking for u32 typedef... no checking size of unsigned short... 2 checking size of unsigned int... 4 checking size of unsigned long... 8 checking size of unsigned long long... 8 checking whether time.h and sys/time.h may both be included... (cached) yes checking size of time_t... 8 checking whether time_t is unsigned... no configure: checking for library functions checking whether getpagesize is declared... yes checking for _LARGEFILE_SOURCE value needed for large files... no checking for vprintf... yes checking for _doprnt... no checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking for atexit... yes checking for canonicalize_file_name... no checking for clock_gettime... yes checking for ctermid... yes checking for explicit_bzero... no checking for fcntl... yes checking for flockfile... yes checking for fsync... yes checking for ftello... yes checking for ftruncate... yes checking for funlockfile... yes checking for getaddrinfo... yes checking for getenv... yes checking for getpagesize... yes checking for getpwnam... yes checking for getpwuid... yes checking for getrlimit... yes checking for getrusage... yes checking for gettimeofday... yes checking for gmtime_r... yes checking for inet_ntop... yes checking for inet_pton... yes checking for isascii... yes checking for lstat... yes checking for memicmp... no checking for memmove... yes checking for memrchr... no checking for mmap... yes checking for nl_langinfo... yes checking for pipe... yes checking for raise... yes checking for rand... yes checking for setenv... yes checking for setlocale... yes checking for setrlimit... yes checking for sigaction... yes checking for sigprocmask... yes checking for stat... yes checking for stpcpy... yes checking for strcasecmp... yes checking for strerror... yes checking for strftime... yes checking for stricmp... no checking for strlwr... no checking for strncasecmp... yes checking for strpbrk... yes checking for strsep... yes checking for strtol... yes checking for strtoul... yes checking for strtoull... yes checking for tcgetattr... yes checking for timegm... yes checking for times... yes checking for ttyname... yes checking for unsetenv... yes checking for wait4... yes checking for waitpid... yes checking for library containing nanosleep... none required checking for struct sigaction... yes checking for sigset_t... yes checking for struct ucred.pid... no checking for struct ucred.cr_pid... no checking for struct sockpeercred.pid... no checking for getpeerucred... no checking for sys/stat.h... (cached) yes checking for unistd.h... (cached) yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking if mkdir takes one argument... no checking whether regular expression support is requested... yes checking for library containing regcomp... none required checking for regcomp... yes checking whether your system's regexp library is broken... no checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for deflateInit2_ in -lz... yes checking for bzlib.h... yes checking for BZ2_bzCompressInit in -lbz2... yes checking whether readline via "-lreadline" is present and sane... no checking whether readline via "-lreadline -ltermcap" is present and sane... no checking whether readline via "-lreadline -lcurses" is present and sane... no checking whether readline via "-lreadline -lncurses" is present and sane... no configure: checking for cc features checking if gcc ignores unknown -Wno-* options... no checking if gcc supports -Wno-pointer-sign... yes checking if gcc supports -Wpointer-arith... yes checking whether "make check" shall run all tests... no configure: *** *** You need libgpg-error to build this program. ** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libgpg-error *** (at least version 1.24 is required.) *** configure: *** *** You need libgcrypt to build this program. ** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libgcrypt/ *** (at least version 1.7.0 (API 1) is required.) *** configure: *** *** You need libassuan to build this program. *** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libassuan/ *** (at least version 2.5.0 (API 2) is required). *** configure: *** *** You need libksba to build this program. *** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libksba/ *** (at least version 1.3.4 using API 1 is required). *** configure: *** *** It is now required to build with support for the *** New Portable Threads Library (nPth). Please install this *** library first. The library is for example available at *** https://gnupg.org/ftp/gcrypt/npth/ *** (at least version 1.2 (API 1) is required). *** configure: error: *** *** Required libraries not found. Please consult the above messages *** and install them before running configure again. *** ----------------------------------------------------------------------------------------------------- Thank you for your help Regards Anastasia -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Oct 14 22:45:48 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Oct 2019 22:45:48 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: (Kristian Fiskerstrand's message of "Mon, 14 Oct 2019 20:43:07 +0200") References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <87eezfnzr1.fsf@vps.thesusis.net> <87o8yjjnfv.fsf@wheatstone.g10code.de> <424b334d-054b-c460-4fa6-878ee4c06ee7@bruckner.tk> Message-ID: <87eezfjbsz.fsf@wheatstone.g10code.de> On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said: > was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC. > Details need to be discussed, but it would be an optional solution, that Given that TB already has smartcard support it would be easy if the new code just makes use of that code. Of course the code then needs to touch the NSS part of Mozilla and can't just go with RNP. That would be a more integrated solution than any other hack. Right, separate software will be required but that is the usual case with smartcards. For example Scute can be used to provide card services via GnuPG (and also allow for on-disk GnuPG. Note that GnuPG 2.3 will be much more flexible in regard to smartcard use and how it can interact with TB via Scute. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue Oct 15 07:00:40 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 15 Oct 2019 01:00:40 -0400 Subject: Configuration Failure Gnugp In-Reply-To: References: Message-ID: > i am not able to follow your documentation and get Gnugp up and running > locally. I have already tried to download missing dependencies and > libraries and move them into the right directory, but that is not > working as i am getting the same error message over and over?again. You will almost certainly be better off grabbing a pre-built MacOS binary from GPGTools. Building from source is regrettably complicated due to all the prerequisites that need to be installed first. If you absolutely must have your own build we'll help you through the process, but GPGTools and/or Homebrew will give you a much easier way to get up and running with GnuPG. From rjh at sixdemonbag.org Tue Oct 15 07:13:01 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 15 Oct 2019 01:13:01 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> Message-ID: <71f23ae2-8ca0-9122-294c-9e9646272bc5@sixdemonbag.org> > I have used Enigmail since its inception and have never knowingly > submitted a log or answered a survey and have always assumed Enigmail > does not phone home. It does not. > Here we disagree. I believe that existing software is not that > difficult to use. The problem, if there is one, is that most people > simply aren't interested. There's excellent academic research into why. I heartily recommend reading this paper: "Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted Email". Shirley Gaw, Ed Felten, and Patricia Fernandez-Kelly, out of Princeton University. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.5612&rep=rep1&type=pdf From kristian.fiskerstrand at sumptuouscapital.com Tue Oct 15 10:11:38 2019 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 15 Oct 2019 10:11:38 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <87eezfjbsz.fsf@wheatstone.g10code.de> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <87eezfnzr1.fsf@vps.thesusis.net> <87o8yjjnfv.fsf@wheatstone.g10code.de> <424b334d-054b-c460-4fa6-878ee4c06ee7@bruckner.tk> <87eezfjbsz.fsf@wheatstone.g10code.de> Message-ID: <928a10a6-72f8-b286-5253-1d70a42f7fc7@sumptuouscapital.com> On 14.10.2019 22:45, Werner Koch wrote: > On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said: > >> was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC. >> Details need to be discussed, but it would be an optional solution, that > > Given that TB already has smartcard support it would be easy if the new > code just makes use of that code. Of course the code then needs to > touch the NSS part of Mozilla and can't just go with RNP. That would be > a more integrated solution than any other hack. > > Right, separate software will be required but that is the usual case > with smartcards. For example Scute can be used to provide card services > via GnuPG (and also allow for on-disk GnuPG. Note that GnuPG 2.3 will > be much more flexible in regard to smartcard use and how it can interact > with TB via Scute. Scute might very well be a good alternative to reach out to, but I'm not too optimistic regarding the likelihood of getting anything related to OpenPGP directly into NSS, hence expecting anything that requires development needs to be done through other vectors. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From bre at pagekite.net Tue Oct 15 11:06:45 2019 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Tue, 15 Oct 2019 09:06:45 -0000 Subject: A place for discussing WKD spec clarifications? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello GnuPG-users! We had some really interesting discussions about WKD at the OpenPGP e-mail summit. One of the recurring themes at many sessions was WKD: it's becoming more and more important and people are both deploying and relying on it. However, there are also a bunch of corner cases where the spec is maybe a little unclear. Where would be the best place to discuss such things? Would the GnuPG issue tracker be a good place to file "bug reports" against the spec, to work towards clarifications? Thanks, - Bjarni - -- PageKite.net lets your personal computer be part of the web -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2ljEAACgkQjgA3FgDP lJFUeAgAhGVdibkeRjQhJ8Vc73+tWiN2Tv/UMW1N9+HHUniKvBTB+J4NeJEQvGjk Eiv2yJAodWwYhQ7fS0znMS+IaS87Ux/qEFf9u4ND9gQtwYllKRAqSgcvu5iQAyuS V9qGYAcWaLIMRJ8io1GXDRiQgLhPY8Drkbzze49h8gVooFRkrWNhXrHDWI4+ugsF bShdIsMe80/h5D5NTSF/e9zb99FvxAth+NMb63RUa+vs6W6QuH2qdx8B9O5lge3G gnK4zDJtNz+SCuhqL2Rg+5NuimK3ZCvVCBwR3BR+s9ETPsQVwk98zBmYwAnvHFdY iBSv1r39cbNjcUDVLTt/NNwo1l8pbg== =2FpX -----END PGP SIGNATURE----- From chip.senkbeil at gmail.com Tue Oct 15 16:14:30 2019 From: chip.senkbeil at gmail.com (Chip Senkbeil) Date: Tue, 15 Oct 2019 09:14:30 -0500 Subject: GPG Agent discarding cache before ttl/max ttl Message-ID: <20191015141430.id2np5w2rzuribch@chipsenkbeil-fedora-PC0Y6ELM> Hey folks! Been using GPG for a couple of months to encrypt, sign, and authenticate and it's been great! I'm trying to understand the scenarios in which the GPG agent will remove an entry from its cache. I've got my default and max cache (both cache-ttl and cache-ttl-ssh) set to one day such that I don't need to enter my password upon accessing my mail on a timer, etc. This works great until my laptop goes to sleep, I close the lid, etc. At that point, it appears to me that the agent tosses out the cache regardless of the length of time. This was not the case when I had GPG configured on a Mac, but when I switched to Fedora 30, I began having this problem. It's a little frustrating because I frequently enter and exit a dock for work, closing and re-opening my laptop, as I dart between meetings, resulting in me needing to re-enter passwords through pinentry more frequently than I'd desire. Is there some separate setting for GPG agent to discard its cache earlier than the ttl/max ttl settings? I've checked the GPG agent process and its still the same instance that had been running since I booted the laptop, so I don't believe it's the case where the agent is getting killed and restarted. For reference, here's my gpg-agent.conf file: pinentry-program /usr/local/bin/my-pinentry-gui default-cache-ttl 604800 max-cache-ttl 604800 default-cache-ttl-ssh 604800 max-cache-ttl-ssh 604800 enable-ssh-support I've got a custom bash script for the pinentry program that selects an appropriate pinentry process based on OS and capabilities (GUI/terminal). And my gpg.conf file: # NOTE: Apparently does nothing with gpg2 use-agent # When outputting certificates, view user IDs distinctly from keys: # NOTE: Since 2.0.10, seems to be obsolete as always used, but no harm in # keeping it here fixed-list-mode # Long keyids are more collision-resistant than short keyids (it's trivial to # make a key with any desired short keyid) keyid-format 0xlong # When multiple digests are supported by all recipients, choose the strongest # one: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # Preferences chosen for new keys should prioritize stronger algorithms: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed # You should always know at a glance which User IDs gpg thinks are legitimately # bound to the keys in your keyring: verify-options show-uid-validity list-options show-uid-validity # When making an OpenPGP certification, use a stronger digest than the default # SHA1: cert-digest-algo SHA256 # Prevent version string from appearing in your signatures/public keys no-emit-version # Never ask to insert smartcard if it wasn't already inserted to begin with # NOTE: Currently broken as the functionality appears to have been removed by # commit 8c219602515ae1dba5bc0da31077852dab61809e when g10/gluecard.c # was removed. From the latest commit, it seems like appropriate logic # could be added back in agent/divert-scd.c in the main loop of # ask_for_card function limit-card-insert-tries 1 expert ~ Chip Senkbeil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From phill at thesusis.net Tue Oct 15 20:42:21 2019 From: phill at thesusis.net (Phillip Susi) Date: Tue, 15 Oct 2019 14:42:21 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <87o8yjjnfv.fsf@wheatstone.g10code.de> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <87eezfnzr1.fsf@vps.thesusis.net> <87o8yjjnfv.fsf@wheatstone.g10code.de> Message-ID: <87h849rgtu.fsf@vps.thesusis.net> Werner Koch writes: > authenticated encryption is different from signed and encrypted mails. > There are relative easy attacks on the encryption layer if standard > encryption modes like CBC (as in S/MIME) are used. Whether this really > affects users is a different question but they can be used to leverage > implementation flaws in MUAs to full plaintext leaks. This is known for > 20 years and made it last year again to the media under the term EFAIL. I'm confused. I thought the whole efail thing was about crafting a plain text message that says "Good signature verified" and fools the user even though it was never run through pgp or had its signature verified with s/mime. > Granted, encrypted+signed mails can to a large extend also mitigate the > threat. But there are still reasons why signatures can't be used or > need to be verified only at a latter time in the workflow. > > OpenPGP had a mitigation against this since 2000 and was widely deployed > by 2003. However S/MIME never implemented this despite of 10 years old > RFCs describing methods for such a mitigation, called authenticated > encryption (AE or AEAD). AFAICS, that is for encryption+sign. If you just want to sign, it sounds like you are saying that is broken. I don't see how. You can't modify the message and keep the hash unchanged, and you can't encrypt a new hash because you don't have the sender's private key. From rjh at sixdemonbag.org Tue Oct 15 21:09:40 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 15 Oct 2019 15:09:40 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <87h849rgtu.fsf@vps.thesusis.net> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <87eezfnzr1.fsf@vps.thesusis.net> <87o8yjjnfv.fsf@wheatstone.g10code.de> <87h849rgtu.fsf@vps.thesusis.net> Message-ID: <9d1587d3-d6ee-cae1-2636-71ca591dd49c@sixdemonbag.org> > I'm confused. I thought the whole efail thing was about crafting a > plain text message that says "Good signature verified" and fools the > user even though it was never run through pgp or had its signature > verified with s/mime. I'd suggest reading the Efail paper. The vast majority of the news coverage was shoddy. Efail included two *completely separate* attacks in their paper, which the news media overwhelmingly conflated into a single attack. I'll call them Efail-1 and Efail-2 here. Efail-1 was what Werner is talking about here. It was a pretty bad blow to S/MIME, but far less so to OpenPGP, since OpenPGP has had countermeasures in place for almost twenty years. Efail-1's impact on OpenPGP was, is, minimal. Efail-2 wasn't an attack on OpenPGP at all, but instead showed how poorly email clients and/or email plugins communicated with GnuPG. It was possible for GnuPG to give a correct warning that someone was playing games with the message, and for the email client to disregard this warning and present it to the user as authentic. Efail-1 had minimal applicability to GnuPG; Efail-2 had none whatsoever (except, arguably, some of the messages GnuPG gave were ambiguous: I think they were, but Werner disagrees). From rjh at sixdemonbag.org Tue Oct 15 21:17:58 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 15 Oct 2019 15:17:58 -0400 Subject: FAQ October 2019 update Message-ID: The last time I gave the FAQ a thorough read-and-review was in October 2017, so it was time for a review. I fought off the urge to rewrite the thing entirely -- I really don't like how it flows, but I view my job as maintainer is more about making minor incremental changes than total rewrites whenever the whim seizes me. Anyway, the major changes: * Every reference to the SKS keyserver network now points to keys.openpgp.org. Reason: the SKS attacks a few months ago. * All references to 2048-bit crypto are updated to refer to 3072-bit crypto. Reason: GnuPG now defaults to 3072-bit RSA. * PGPNET's email address has changed. ... Those were the high-priority changes that needed to be made. If anyone has other suggestions, speak up: I'm listening. :) (Note: I just committed the FAQ changes. It may take a couple of days for the documentation on the website to be regenerated.) From wk at gnupg.org Tue Oct 15 22:44:29 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 Oct 2019 22:44:29 +0200 Subject: FAQ October 2019 update In-Reply-To: (Robert J. Hansen's message of "Tue, 15 Oct 2019 15:17:58 -0400") References: Message-ID: <87imopivrm.fsf@wheatstone.g10code.de> On Tue, 15 Oct 2019 15:17, Robert J. Hansen said: > * Every reference to the SKS keyserver network now points to > keys.openpgp.org. Reason: the SKS attacks a few months ago. I have to object against this change. The SKS server network is still useful and definitely more useful than an non-matured and centralized keyserver. I am okay with removing explicit reference to the SKS network for now but suggesting the use of that specific keyserver is a no-go. > * All references to 2048-bit crypto are updated to refer to 3072-bit > crypto. Reason: GnuPG now defaults to 3072-bit RSA. Okay. But this +your certificate uses 2048-bit keys we recommend retiring them and +migrating to a new keypair of at least 3072 bits length. You can do is a no-go because we will have a hard to time to convice people that this is just a geek suggestion and that for almost all general use of gpg the existsing keys are still fine. Actually 2k keys are still allowed in Germany for restricted communication and there is no need for an immediate rush to 3k. I also wonder why you removed this -If you need more security than RSA-2048 offers, the way to go would be -to switch to elliptical curve cryptography ? not to continue using -RSA. GnuPG's future default is already ECC and some hosted mail services are already creating such keys. GnuPG will switch to that with 2.3 which is not that far away. > (Note: I just committed the FAQ changes. It may take a couple of days > for the documentation on the website to be regenerated.) That is a matter of minutes. I only had a brief look at it but I can't see that your changes are subject to frequently asked questions here. The GnuPG FAQ is for all GnuPG users and should not again start reflect the view of some crypto geeks or give advises which will lead only to trouble. I am sorry for having to write these harsh comments: In contrast to discussions on the mailing list the FAQ reflects the opinion of the GnuPG project and as such substantial changes need to be discussed first. I would suggest to create a branch and revert the changes in master until an agreement has been reached. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue Oct 15 22:59:23 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 15 Oct 2019 16:59:23 -0400 Subject: FAQ October 2019 update In-Reply-To: <87imopivrm.fsf@wheatstone.g10code.de> References: <87imopivrm.fsf@wheatstone.g10code.de> Message-ID: <9c964421-678e-c87e-7142-2cfc0b521247@sixdemonbag.org> Let's start with the most important thing: > I am sorry for having to write these harsh comments I didn't find your comments harsh, but thank you for being considerate. :) >> * Every reference to the SKS keyserver network now points to >> keys.openpgp.org. Reason: the SKS attacks a few months ago. > > I have to object against this change. The SKS server network is still > useful and definitely more useful than an non-matured and centralized > keyserver. I can't agree with this. SKS is effectively dead. Older GnuPG installations can still get utterly wedged if they pull down a poisoned certificate from SKS. There are a *lot* of these older installations out there in the wild, and what we suggest to them should not lead them into wedging their system. Should they update? Yes. Is the problem mitigated by an update? Yes. But will they? Probably not before wedging their keyring. Given that high-profile people in the community have had our certificates defaced, it's possible someone will say "I want to ask dkg a question," pull down his cert, get wedged, and... etc. I think it's dangerous to our users to continue to recommend SKS in the face of a well-known poisoning problem. > suggesting the use of that specific keyserver is a no-go. I'm fine with this. My major concern is removing SKS recommendations. >> * All references to 2048-bit crypto are updated to refer to 3072-bit >> crypto. Reason: GnuPG now defaults to 3072-bit RSA. > > Okay. But this > > +your certificate uses 2048-bit keys we recommend retiring them and > +migrating to a new keypair of at least 3072 bits length. You can do > > is a no-go because we will have a hard to time to convice people that > this is just a geek suggestion and that for almost all general use of > gpg the existsing keys are still fine. Actually 2k keys are still > allowed in Germany for restricted communication and there is no need for > an immediate rush to 3k. I agree there is no immediate rush: the US guidance says they're safe until 2030. But for many years we advised people to use 2048-bit keys, now we're generating 3072-bit keys by default. At the very least the old guidance on 2048-bit keys needs to be dropped. Whether we explain it away as "we're now using 3072-bit keys by default, in order to get a long head start on 2048's obsolescence" or "we're going to be moving to ECC in the near future" matters little to me, but we need to explain the shift away from 2048. > I also wonder why you removed this > > -If you need more security than RSA-2048 offers, the way to go would be > -to switch to elliptical curve cryptography ? not to continue using > -RSA. Because it raises an immediate question of, "then why does GnuPG default to RSA-3072, if the FAQ's guidance is past -2048 to use ECC?" The FAQ's statement collides with what GnuPG actually does. > That is a matter of minutes. I only had a brief look at it but I can't > see that your changes are subject to frequently asked questions here. There were three major changes: keyservers, key lengths, and an email address. All three existed in prior iterations of the FAQ. If you think they should be dropped, I'm all for that conversation, but please keep in mind that I'm not adding new subjects to the FAQ: in this pass I was updating existing content. From wk at gnupg.org Tue Oct 15 22:57:16 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 Oct 2019 22:57:16 +0200 Subject: GPG Agent discarding cache before ttl/max ttl In-Reply-To: <20191015141430.id2np5w2rzuribch@chipsenkbeil-fedora-PC0Y6ELM> (Chip Senkbeil via Gnupg-users's message of "Tue, 15 Oct 2019 09:14:30 -0500") References: <20191015141430.id2np5w2rzuribch@chipsenkbeil-fedora-PC0Y6ELM> Message-ID: <87eezdiv6b.fsf@wheatstone.g10code.de> On Tue, 15 Oct 2019 09:14, Chip Senkbeil said: > Is there some separate setting for GPG agent to discard its cache > earlier than the ttl/max ttl settings? I've checked the GPG agent You can follow the cache operations by adding log-file /some/log/file debug cache to gpg-agent.conf and reload it (gpgconf --reload gpg-agent). This will give you some insights on what is going on. The stadard way to flush the cache is bei sending a HUP to gpg-agent (or the above reload command). If your system has a method to run a script on suspend or lid closing it may already do just that. I consider this a good idea but we can't do that by default in GnuPG because systems differ to much on how to detect a lid closing event or similar. Thus there is also no way to avoid it using a GnuPG option. > enable-ssh-support Its the default anyway > fixed-list-mode You can remove that too it has no effect anymore. > # When making an OpenPGP certification, use a stronger digest than > the default > # SHA1: > cert-digest-algo SHA256 It is the default for a long time now. Only gpg 1.4 still defaults to SHA-1 but you are not using that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 15 23:01:33 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 Oct 2019 23:01:33 +0200 Subject: A place for discussing WKD spec clarifications? In-Reply-To: (Bjarni Runar Einarsson's message of "Tue, 15 Oct 2019 09:06:45 -0000") References: Message-ID: <87a7a1iuz6.fsf@wheatstone.g10code.de> On Tue, 15 Oct 2019 09:06, Bjarni Runar Einarsson said: > Would the GnuPG issue tracker be a good place to file "bug > reports" against the spec, to work towards clarifications? That is okay for bug reports, but often it is more important to get the opinions from more people than those who triage the bug reports. I thing gnupg-devel@ gnupg.org would be an appropriate place for discussing such topics. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From hello at ezaquarii.com Tue Oct 15 23:21:56 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Tue, 15 Oct 2019 22:21:56 +0100 Subject: FAQ October 2019 update In-Reply-To: <9c964421-678e-c87e-7142-2cfc0b521247@sixdemonbag.org> References: <87imopivrm.fsf@wheatstone.g10code.de> <9c964421-678e-c87e-7142-2cfc0b521247@sixdemonbag.org> Message-ID: On 15/10/2019 21:59, Robert J. Hansen wrote: > Should they update? Yes. Is the problem mitigated by an update? Yes. > But will they? Probably not before wedging their keyring. Given that > high-profile people in the community have had our certificates defaced, > it's possible someone will say "I want to ask dkg a question," pull down > his cert, get wedged, and... etc. I can confirm that this happens and users are being b0rked because of trolls. Street level rumour is that GnuPG key exchange is broken and you should not use it. It doesn't matter what the truth is - it is the public perception that recent SKS events made it unusable, this was advertised across the media all over the place and the image stuck. Additionally, poor handling of SKS fiasco by GnuPG community hurt it's credibility a lot, so a clear signal that this issue was treated seriously would be beneficial. Should it be advertised as a new go-to standard or as transitional standard, beta/alpha/whatever - I don't know, it's debatable. Cheers, Chris From dgouttegattat at incenp.org Wed Oct 16 00:14:36 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 15 Oct 2019 23:14:36 +0100 Subject: FAQ October 2019 update In-Reply-To: References: Message-ID: <20191015221435.eaivvuccyjryg5yx@aurora.local.incenp.org> Hi, On Tue, Oct 15, 2019 at 03:17:58PM -0400, Robert J. Hansen wrote: >... Those were the high-priority changes that needed to be made. If >anyone has other suggestions, speak up: I'm listening. :) A while ago (I can?t find the e-mail anymore) I suggested a few changes that somehow didn?t find their way to the FAQ and then I forgot about them. Allow me to submit them again. Those changes are all related to the fact that modern (? 2.1) GnuPG automatically creates a revocation certificate whenever it creates a new key pair, and stores it in $GNUPGHOME/openpgp-revocs.d. In section 7,17 (What?s a ?revocation certificate??), it?s no longer recommended to create a revocation certificate immediately after generating a new GnuPG certificate. Instead, this section may state that GnuPG already creates one when creating a GnuPG certificate, and that it can be found in $GNUPGHOME/openpgp-revocs.d. Similarly, section 8.5 (?What should I do after making my certificate?) should no longer say to generate a revocation certificate, but again may indicate where to find the one automatically generated by GnuPG, and advise to store it in a safe place. In the same section, the subsection ?How do I generate a revocation certificate? could be moved elsewhere, as it is no longer something you ?should do after making [your] certificate?. In section 10 (?What are some common bast practices??), the advice ?Generate a revocation certificate and keep it safe? should be removed and optionally replaced by ?Keep your (automatically generated) revocation certificate safe?. Cheers, - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From david at hebbeker.info Tue Oct 15 22:23:45 2019 From: david at hebbeker.info (David Hebbeker) Date: Tue, 15 Oct 2019 22:23:45 +0200 Subject: are angle brackets around email address allowed for auto-key-locate? Message-ID: <1571171025.3191.2.camel@hebbeker.info> The manual [1] says that GnuPG can automatically retrieve keys for emails in the "user at example.com" form. Does this exclude emails wrapped by angle brackets like ""? I need to ask as I have an interoperability issue with?Gnome Evolution. Evolution specifies the email with angle brackets when encrypting. [1]: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuratio n-Options.html#index-auto_002dkey_002dlocate -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From lists at binarus.de Wed Oct 16 10:47:33 2019 From: lists at binarus.de (Binarus) Date: Wed, 16 Oct 2019 10:47:33 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> Message-ID: <41d728fd-b951-874a-2665-2022bc6e4dfb@binarus.de> On 14.10.2019 16:15, Jeff Allen via Gnupg-users wrote: >> I don't know either, but perhaps it is in the debug logs the Enigmail >> team analyzes? > > I have used Enigmail since its inception and have never knowingly > submitted a log or answered a survey and have always assumed Enigmail > does not phone home. I am sure that it doesn't phone home. However, to give an example, I had a problem some years ago where Enigmail didn't work correctly any more when a certain other extension was installed, or vice versa. I published that problem somewhere (can't remember exactly) and got the advice to turn on Enigmail debugging and send the debug log to a certain email address or to publish it (again, can't remember). Of course, I followed that advice (after having examined the log file and having convinced myself that there was no critical data in it, as expected). I suppose that the Enigmail team gets quite a lot of such debug logs. But I still can't tell (and currently don't have the time to investigate) if those logs can tell which keys had been generated by Enigmail and which had been generated externally, so the whole thing was a guess anyway. >>>> The vast majority of users also don't use GnuPG for >>>> anything else than email. These users don't care where their key is >>>> stored, nor which software under the hood is used for the crypto. All >>>> they care is that encryption works smoothly. >>> >>> And this? >>> >> >> I am also not sure about this. As far as it concerns Windows, the first >> part of the statement may be true. > > All the statements might be true. My question was "How do you know?" Good point. I see. >> I am not sure where this will lead to. It sounds as if you were >> suggesting to give up on privacy, encryption and authentication for that >> reason. > > Not at all. My point was that I doubt OpenPGP's inclusion in > Thunderbird will have a major impact on the number of people encrypting > their email I think that even a minor impact would be desirable. The problem is: If it is done wrong (essential features missing, e.g. subject encryption, no exchange of keys with external tools, no hardware token support etc.), it could prevent a large part of today's encryption users from using encryption in the future, i.e. it even could reduce encryption prevalence. Personally, I am not sure what I'd do if the integration of PGP in TB would be broken (i.e. no subject encryption, no control over key generation and so on). Theoretically, I could move to another MUA which provides a reasonable workflow for PGP, but due to pressure of time and due to flaws or missing features in other MUAs I eventually would have to stick with TB, even if I couldn't reasonably use PGP any more. >> While I agree with you that this problem exists and is quite difficult >> to solve (eventually it needs another decade), I am absolutely sure that >> bad and difficult software will make it worse, but good and usable >> software will help in solving it. The fact that the problem exists does >> not mean that nobody should try to solve it by providing easier-to-use, >> fully integrated software with reasonable default settings. > > Here we disagree. I believe that existing software is not that > difficult to use. The problem, if there is one, is that most people > simply aren't interested. Twenty years ago I thought that everyone > would soon be using end-to-end encrypted email. Twenty years from now > they still won't be. Here the integration could really help. For example, keys could be automatically generated whenever a new email account is created in TB. Then, when sending the first message using that account, a dialog could popup asking the user: "We already have completely setup your PGP keys. Do you want to authenticate this and further messages, and do you want to attach your public key to each message so that the correspondents can encrypt their replies to you, and do you want to upload your public key to server x.y.z so that everybody can send you encrypted messages and can verify your signature?" I bet that 80% of users would answer this dialog by clicking "Yes", and I think this would really help. But once again, if too many features are missing in the integration, this will throw back email encryption prevalence by one or two decades because TB / Enigmail presumably is the most widespread software for email encryption, and I am not sure how many users could move to another MUA if PGP is broken / not fully usable in TB. >> There are many reasons to think so (the following applies to ProtonMail >> as well as Tutanota): >> >> 1) To actually use those services in a reasonable manner, you have to >> opt-in for a paid contract. For most of us, this is a matter of >> principle. Why should we pay for a thing that used to be free all the >> time? (Note: I don't want to judge that attitude - I am just stating how >> it is). > > > > But "free" email has never been free from the likes of Gmail, Yahoo, > GMX, etc. While you don't pay a yearly fee, you trade your privacy for > a few bucks. You open yourself to tracking and targeted advertising. > Your email is anything but private. A couple years back both Google and > Yahoo claimed to be working on E2EE. I wonder why it never happened? > > The free versions of ProtonMail, Tutanota and Mailfence at least > preserve your privacy. They aren't monetized through advertising and > tracking. Instead they sell premium services to people who want more > capacity or features. Many people I know do email exclusively on their > smart phones. They don't use an MUA and don't care about POP3, IMAP or > SMTP. Their view of using email services in a reasonable manner doesn't > comport with yours or mine. Correct, but (as I wrote) I didn't want to judge the attitude; I just wanted to show how it works. Many users reflexively close web pages immediately as soon as they recognize a $ sign (except online shops and TV / movie / music sites, of course). > I hope I am wrong and Thunderbird's OpenPGP implementation is a complete > success encouraging many more people to encrypt their email. I would, > however, personally prefer that Thunderbird directly implement GnuPG > integration instead of going it alone. That would satisfy both casual > and power users as Enigmail does now. > > Will Thunderbird OpenPGP support smart cards like my Yubikey? How about > a feature like GnuPG's group line or Enigmail's per-recipient rules? > In-line PGP as well as PGP/MIME? Encrypted subject and the ability to > turn it on or off? As far as I know, they are all features of GnuPG or > Enigmail and not required by the OpenPGP specification. > > Patrick and company deserve our thanks for many years splendid service > to the OpenPGP community. So does Werner and his team who created and > maintain a tool that has satisfied a wide range of users for decades. I > doubt that yet another proprietary OpenPGP system is what the world needs. You are speaking out of my heart. Many years ago, I appreciated Mozilla's decision to provide their own root certificates and certificate management, because I trusted them much more than Microsoft. But when it comes to PGP integration, making their own thing for sure is counter-productive. What Werner and Patrick have created is mature and completely trustworthy and surely can't be outranked in the foreseeable time. Not wanting to make users install additional software isn't a reasonable argument for re-inventing the wheel, because AFAIK nothing prevents people from bundling GnuPG with TB in the same installer, and I bet that even installing these two packages into the same directory and letting them use the same registry subkeys technically wouldn't be a problem (I am speaking of Windows here). So why not take Enigmail, integrate it into TB, and bundle Gpg4Win setup with TB setup? All software they ever could develop themselves will be inferior compared to that package, at least in the first time. Regards, Binarus From martijn.list at gmail.com Wed Oct 16 10:46:38 2019 From: martijn.list at gmail.com (Martijn Brinkers) Date: Wed, 16 Oct 2019 10:46:38 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <9d1587d3-d6ee-cae1-2636-71ca591dd49c@sixdemonbag.org> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <87eezfnzr1.fsf@vps.thesusis.net> <87o8yjjnfv.fsf@wheatstone.g10code.de> <87h849rgtu.fsf@vps.thesusis.net> <9d1587d3-d6ee-cae1-2636-71ca591dd49c@sixdemonbag.org> Message-ID: <5ec95f0a-fd58-4c3a-fa11-9ff14abb7bdf@gmail.com> > Efail-1 was what Werner is talking about here. It was a pretty bad > blow to S/MIME, but far less so to OpenPGP, since OpenPGP has had > countermeasures in place for almost twenty years. Efail-1's impact > on OpenPGP was, is, minimal. I actually spend a lot of time investigating the impact of EFAIL on S/MIME and it's my opinion that the real impact has been overblown. In all my experiments, and I can tell you I have done a lot of them, I have not been able to force a mail client to actually forward the decrypted content to a remote system. The CBC attack is serious because modifying encrypted content is not something you expect from a security point of view. But the real life impact is not as big as they wanted us to believe (IMHO). I have asked the EFAIL authors for examples on real life attacks (of the CBC problem related to S/MIME) but I never got a real answer whether they were able to use the attack in real life situation. I think the problem with the paper was that they discusses two separate issues. The issue with Efail-2 was serious but that was more an mail client issue. Kind regards, Martijn From daniel.bossert at dabo.ch Wed Oct 16 13:02:10 2019 From: daniel.bossert at dabo.ch (Daniel Bossert) Date: Wed, 16 Oct 2019 13:02:10 +0200 Subject: Android Message-ID: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> Hi Is anybody using pgp on Android? I did some years ago, would like to, but am afraid of security reason. I have safed my keys on my laptop only. How are you handling it in ages of mobiles? Regards Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at enigmail.net Wed Oct 16 13:07:39 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 16 Oct 2019 13:07:39 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> Message-ID: Binarus wrote on 16.10.2019 10:47: > > On 14.10.2019 16:15, Jeff Allen via Gnupg-users wrote: >>> I don't know either, but perhaps it is in the debug logs the Enigmail >>> team analyzes? >> >> I have used Enigmail since its inception and have never knowingly >> submitted a log or answered a survey and have always assumed Enigmail >> does not phone home. > > I am sure that it doesn't phone home. However, to give an example, I had You can be certain that I'd never implement that. [...] > I suppose that the Enigmail team gets quite a lot of such debug logs. > But I still can't tell (and currently don't have the time to > investigate) if those logs can tell which keys had been generated by > Enigmail and which had been generated externally, so the whole thing was > a guess anyway. Yes, I did and do get quite a lot of debugging log files, and even more support requests. And I really speak from experience when I say that the vast majority of the users of Enigmail don't store their private keys on external devices. [...] > So why not take Enigmail, integrate it into TB, and bundle Gpg4Win setup > with TB setup? All software they ever could develop themselves will be > inferior compared to that package, at least in the first time. I have almost 17 years of experience with supporting Enigmail. About 90% of all support requests that I get turn out to be setup issues with GnuPG. Interestingly, most of them are on Linux, even though all Linux distributions I know ship GnuPG. The bundling/shipping would not be a worry for me. The main problem is the additional complexity that it brings if you require an external component that you cannot *fully* control. This covers topics like different behavior of different versions, but also configuration issues, users rights to install something on their PC and more. Gpgme may handle some of these issues, but the fact remains: an external component makes things a lot more complex, especially for support. -Patrick From wk at gnupg.org Wed Oct 16 13:54:16 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 Oct 2019 13:54:16 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: (Patrick Brunschwig's message of "Wed, 16 Oct 2019 13:07:39 +0200") References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> Message-ID: <87o8ygx5w7.fsf@wheatstone.g10code.de> On Wed, 16 Oct 2019 13:07, Patrick Brunschwig said: > something on their PC and more. Gpgme may handle some of these issues, > but the fact remains: an external component makes things a lot more > complex, especially for support. Right GPGME handles this all pretty well and I have suggested often enough that you should move to GPGME so that we can better support Enigmail. Your comment about external components is right from a company POV; however Enigmail is also an external component to TB and thus TB suffers from very similar problem. GpgOL and GnuPG both are maintained by us and thus I know very well this helps to reduce friction. The move to integrate OpenPGP in TB is important but also pretty risky if it won't work for everyone right away from the start. The big advantage of TB/Enigmail is that it is cross-platform and often the only way to have encrypted mail on macOS. I know several media companies who badly suffered when GpgTools were not able to get their plugin working on a new macOS version. Their journalists were then forced to use TB and not their, for whatever reason, beloved apple mailer. Let's hope that at least of one is always working. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 16 14:06:29 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 Oct 2019 14:06:29 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <5ec95f0a-fd58-4c3a-fa11-9ff14abb7bdf@gmail.com> (Martijn Brinkers via Gnupg-users's message of "Wed, 16 Oct 2019 10:46:38 +0200") References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <875zkup65r.fsf@wheatstone.g10code.de> <87eezfnzr1.fsf@vps.thesusis.net> <87o8yjjnfv.fsf@wheatstone.g10code.de> <87h849rgtu.fsf@vps.thesusis.net> <9d1587d3-d6ee-cae1-2636-71ca591dd49c@sixdemonbag.org> <5ec95f0a-fd58-4c3a-fa11-9ff14abb7bdf@gmail.com> Message-ID: <87k194x5bu.fsf@wheatstone.g10code.de> On Wed, 16 Oct 2019 10:46, Martijn Brinkers said: > I actually spend a lot of time investigating the impact of EFAIL on > S/MIME and it's my opinion that the real impact has been overblown. In > all my experiments, and I can tell you I have done a lot of them, I have > not been able to force a mail client to actually forward the decrypted > content to a remote system. I recall that you mentioned this in the past and I have not seen any statement to the contrary. In fact the whole attack is nearly 20 years old and even back then it was hard to construct a case where the non-authenticated encryption could be abused. When the PGP folks and me discussed the attack around the year 2000, we knew that and suggested signed mails as a solid counter-measurement. The MDC was then introduced mainly to counter the more or less theoretical attack and to be on the safe side in case better attacks would be developed. The media and political coverage (we had working groups and internal meetings) of the efail paper however required some extra measurements to take. > I think the problem with the paper was that they discusses two separate > issues. The issue with Efail-2 was serious but that was more an mail > client issue. I fully agree here. As usual reports about the MUA failures spread for months without mentioning that all the major MUAs fixed the bug within a few days or weeks or even had fixed it at the time the paper was published. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 16 14:19:59 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 Oct 2019 14:19:59 +0200 Subject: are angle brackets around email address allowed for auto-key-locate? In-Reply-To: <1571171025.3191.2.camel@hebbeker.info> (David Hebbeker's message of "Tue, 15 Oct 2019 22:23:45 +0200") References: <1571171025.3191.2.camel@hebbeker.info> Message-ID: <87blugx4pc.fsf@wheatstone.g10code.de> On Tue, 15 Oct 2019 22:23, David Hebbeker said: > The manual [1] says that GnuPG can automatically retrieve keys for > emails in the "user at example.com" form. Does this exclude emails wrapped > by angle brackets like ""? That is fine. Find below our test addresses. Salam-Shalom, Werner ps. Here is our test data set. The second string is the exepcted result, if it is NULL we can't extract a mail address from the string: { "Werner Koch ", "wk at gnupg.org" }, { "", "wk at gnupg.org" }, { "wk at gnupg.org", "wk at gnupg.org" }, { "wk at gnupg.org ", NULL }, { " wk at gnupg.org", NULL }, { "Werner Koch (test) ", "wk at gnupg.org" }, { "Werner Koch (test)", "wk at gnupg.org" }, { "Werner Koch ", NULL }, { "Werner Koch ", NULL }, { "", "foo at example.org" }, { "", "foo. at example.org" }, { "<.foo. at example.org>", ".foo. at example.org" }, { "", "foo.. at example.org" }, { "", "foo..bar at example.org" }, { "", NULL }, { "", NULL }, { "", NULL }, { "<@example.org>", NULL }, { "", NULL }, { "<@foo at example.org>", NULL }, { " ()", "foo at example.org" }, { " ()", "fo()o at example.org" }, { " ()", "fo()o at example.org" }, { "fo()o at example.org", NULL}, { "Mr. Foo ", "foo at example.org"}, { "Surname, Forename | company ", "foo at example.org"}, /* The next one is for sure not RFC-822 correct but nevertheless * the way gpg does it. We won't change it because the user-id * is only rfc-822 alike and not compliant (think only of our * utf-8 requirement). */ { "\"\" ", "foo at example.org"}, -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From johanw at vulcan.xs4all.nl Wed Oct 16 14:08:33 2019 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 16 Oct 2019 14:08:33 +0200 Subject: Android In-Reply-To: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> References: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> Message-ID: <333e9062-138e-7551-db14-c0ae8e56ee30@vulcan.xs4all.nl> On 16-10-2019 13:02, Daniel Bossert wrote: > Is anybody using pgp on Android? I did some years ago, would like to, > but am afraid of security reason. I use APG for old pgp 2.x keys and OpenKeyChain integrated in k9 mail for modern keys. The secret keys are protected by a password, that's my key protection. When I loose my phone, or when it gets stolen or confiscated, I'll revoke the key and create a new one. I don't believe anyone can protect a file on a phone against a skilled forensics lab. Even the best protected mobiles get cracked eventually (see the recent bootrom exploit in almost all iPhones for example). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From simon.brennecke at sap.com Wed Oct 16 15:41:38 2019 From: simon.brennecke at sap.com (Brennecke, Simon) Date: Wed, 16 Oct 2019 13:41:38 +0000 Subject: SSH CA + gpg-agent + gnuk => error Message-ID: Hi guys, I have a question regarding the interaction of SSH with gpg-agent (and possibly also gnuk). I started out with the following setup: Every admin has his own ssh private key. All private keys are signed with an SSH CA. The server trust the CA, and thus the admins can login. No need to deploy individual keys, only the CA. Great. Now I wanted to store my private key in gnuk to protect it better. So I generated a new ECC key in gnuk, imported the public keys in gpg. Added the keygrip everything to "~/.gnupg/sshcontrol" "ssh-add -L" shows me the key. I signed it with the CA. ssh tries to use the key... ... and this is where the error pops up. ssh tells me: sign_and_send_pubkey: signing failed: agent refused operation and gpg-agent tells me: gpg-agent[21629]: ssh request handler for sign_request (13) started gpg-agent[21629]: DBG: detected card with S/N D276000124010200FFFE430322340000 gpg-agent[21629]: smartcard signing failed: General error gpg-agent[21629]: ssh sign request failed: General error Without the CA (when I deploy my key explicitly on the server) it works fine. I'm not sure where the issue comes from. >From my understanding of ssh's internal workings, gnupg should not even get informed that now a CA is used. Out of curiosity I tried the hole thing again, but without gnuk. Instead I stored the private key in gpg. And that works even with the SSH CA. Any ideas? Am I missing something obvious here? Or could this be a bug? Thanks & Regards Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at enigmail.net Wed Oct 16 16:39:40 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 16 Oct 2019 16:39:40 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <87o8ygx5w7.fsf@wheatstone.g10code.de> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> <87o8ygx5w7.fsf@wheatstone.g10code.de> Message-ID: <9d4037c8-bbaf-faed-7b94-592f7ede8f8d@enigmail.net> Werner Koch wrote on 16.10.2019 13:54: > On Wed, 16 Oct 2019 13:07, Patrick Brunschwig said: > >> something on their PC and more. Gpgme may handle some of these issues, >> but the fact remains: an external component makes things a lot more >> complex, especially for support. > > Right GPGME handles this all pretty well and I have suggested often > enough that you should move to GPGME so that we can better support > Enigmail. Your comment about external components is right from a > company POV; however Enigmail is also an external component to TB and > thus TB suffers from very similar problem. GpgOL and GnuPG both are Which is why the step to implement OpenPGP in Thunderbird is the right way to go. > maintained by us and thus I know very well this helps to reduce > friction. We're getting slightly off-topic, but still: You're perfectly right with everything you say. But you seem to underestimate the difference between zipping an extension that is pure JavaScript, and preparing an extension that needs to contain compiled libraries for multiple platforms in order to cater for all variants of pre-installed GnuPG installations and all variations of Thunderbird installations (to be precise, at the very least I'd have to ship for 6 platforms: Win/mac/Linux * 32/64 bit). Frankly speaking, if I would consider to switch to a library instead of calling GnuPG directly, I would at first evaluate OpenPGP.js in Enigmail -- that would be a lot more natural. -Patrick From hello at ezaquarii.com Wed Oct 16 17:01:15 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Wed, 16 Oct 2019 15:01:15 +0000 Subject: Android In-Reply-To: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> References: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> Message-ID: YubiKeys are supported. You can use NFC key to perform crypto gimmicks or plug USB one. OpenKeychain does support quite large palette of hardware tokens. Paired with K-9 it actually provides relatively good UX. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jc.gnupg18a at unser.net Wed Oct 16 14:11:21 2019 From: jc.gnupg18a at unser.net (Juergen Christoffel) Date: Wed, 16 Oct 2019 14:11:21 +0200 Subject: Android In-Reply-To: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> References: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> Message-ID: <20191016121121.GA1541@unser.net> On Wed, Oct 16, 2019 at 01:02:10PM +0200, Daniel Bossert wrote: > >Is anybody using pgp on Android? I did some years ago, would like to, but am afraid of security reason. Hi Daniel, I'm using gnupg with Termux (Linux as app) on Android. And ssh for file transfers too. Works for me, as I'm comfortable with commandline interfaces, even on mobiles. Cheers, JC -- Doctorow's Law: Anytime someone puts a lock on something you own, against your wishes, and doesn't give you the key, they're not doing it for your benefit. From mgorny at gentoo.org Wed Oct 16 15:45:49 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Wed, 16 Oct 2019 15:45:49 +0200 Subject: Android In-Reply-To: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> References: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> Message-ID: On Wed, 2019-10-16 at 13:02 +0200, Daniel Bossert wrote: > Hi > > Is anybody using pgp on Android? I did some years ago, would like to, but am afraid of security reason. > > I have safed my keys on my laptop only. > > How are you handling it in ages of mobiles? > Get yourself a hardware key, and use that. I've been successfully using USB NitroKey with OpenKeychain (for mail) and TermBot, though I admit it's not the most convenient solution. FWIH, NFC keys are more convenient; that is, if someone considers it safe to keep NFC enabled with Google Pay installed. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From lists at binarus.de Wed Oct 16 17:37:51 2019 From: lists at binarus.de (Binarus) Date: Wed, 16 Oct 2019 17:37:51 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> Message-ID: On 16.10.2019 13:07, Patrick Brunschwig wrote: > worry for me. The main problem is the additional complexity that it > brings if you require an external component that you cannot *fully* > control. This covers topics like different behavior of different > versions, but also configuration issues, users rights to install > something on their PC and more. Gpgme may handle some of these issues, > but the fact remains: an external component makes things a lot more > complex, especially for support. I think this is the usual trade-off. One has to put time - either in understanding the APIs and command line parameters of a library / utility, and to keep up with changes, or - in re-inventing the wheel, which in this case for sure will cost much more time and eventually produce catastrophic security breaches and software which is drastically inferior compared to what we have now. After all, everybody uses libraries and utilities. It is just reasonable to have an expert work on a library or utility which uses techniques and mathematical stuff which non-specialists never will understand in detail, and have the non-specialists use that library or utility, instead of letting them re-develop the same stuff, probably introducing all sorts of security flaws and producing inferior software. When I have a bash script under Linux which invokes a compiler using a complicated command line, I wouldn't come to the idea to re-develop that compiler and integrate it directly into bash because that compiler's command line switches could change in the next version ... I am still convinced that re-writing GnuPG (including all functions like hardware tokens, subject encryption etc.) in a secure manner is a hundred times more complex and a million times more error-prone than tracking a few changes to its command line switches or error codes ever could be. Apart from that, there is GpgME, as already has been stated. Regarding the user rights to install software: That was the reason why I thought about bundling the installers and installing both parts in the same directory. Even updates to GnuPG then could be handled by TB's update system (this is only an educated guess - I don't know if the licenses would allow this). If TB would use GpgME, this problem even would not exist in the first place. GpgME would just be another library lying around in TB's installation directory (under Windows, probably a DLL) and for sure could be updated via TB's update system. Just my 2 cents ... Regards, Binarus From johndoe65534 at mail.com Wed Oct 16 17:50:04 2019 From: johndoe65534 at mail.com (john doe) Date: Wed, 16 Oct 2019 17:50:04 +0200 Subject: Android In-Reply-To: References: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> Message-ID: On 10/16/2019 3:45 PM, Micha? G?rny via Gnupg-users wrote: > On Wed, 2019-10-16 at 13:02 +0200, Daniel Bossert wrote: >> Hi >> >> Is anybody using pgp on Android? I did some years ago, would like to, but am afraid of security reason. >> >> I have safed my keys on my laptop only. >> >> How are you handling it in ages of mobiles? >> > > Get yourself a hardware key, and use that. I've been successfully using > USB NitroKey with OpenKeychain (for mail) and TermBot, though I admit > it's not the most convenient solution. FWIH, NFC keys are more > convenient; that is, if someone considers it safe to keep NFC enabled > with Google Pay installed. > On AndroidI use k9mail with openkeychain and one subkey which has only the sign capability. The use of subkey makes it possible to revoke only that subkey incase of lost of theft without having to revoked all your key. -- John Doe From david at hebbeker.info Wed Oct 16 20:26:52 2019 From: david at hebbeker.info (David Hebbeker) Date: Wed, 16 Oct 2019 20:26:52 +0200 Subject: are angle brackets around email address allowed for auto-key-locate? In-Reply-To: <87blugx4pc.fsf@wheatstone.g10code.de> References: <1571171025.3191.2.camel@hebbeker.info> <87blugx4pc.fsf@wheatstone.g10code.de> Message-ID: <1571250412.1920.2.camel@hebbeker.info> On Wed, 2019-10-16 at 14:19 +0200, Werner Koch wrote: > On Tue, 15 Oct 2019 22:23, David Hebbeker said: > > The manual [1] says that GnuPG can automatically retrieve keys for > > emails in the "user at example.com" form. Does this exclude emails > > wrapped by angle brackets like ""? > > That is fine. Hi Werner and everyone, thank you for your response, I was hoping that this would be possible. On the other hand, I have experienced a behavior I could only explain with auto-key-locate being restricted to the pure form. Maybe you can enlighten me on this case. I demonstrate this behavior on a system which uses the attached configuration file gpg.conf. I tested this with GnuPG 2.1.18 and 2.2.12. Preparation =========== rm msg.* echo "hello world" > msg.txt gpg --batch --yes --delete-keys edward-en at fsf.org Bad Case (does not work) ======================== gpg --always-trust -e -r "" msg.txt gpg: : skipped: No public key gpg: msg.txt: encryption failed: No public key Good Case (works) ================= gpg --always-trust -e -r "edward-en at fsf.org" msg.txt gpg: key 9FF2194CC09A61E8: 7454 signatures not checked due to missing keys gpg: key 9FF2194CC09A61E8: public key "Edward, the GPG Bot " imported gpg: no need for a trustdb check with 'always' trust model gpg: Total number processed: 1 gpg:???????????????imported: 1 gpg: automatically retrieved 'edward-en at fsf.org' via keyserver Note: The only difference is the missing angle brackets. Can you please explain the difference? That would be of great help! Thanks David -------------- next part -------------- keyserver hkp://keyserver.ubuntu.com:80 # Used for encryption auto-key-locate keyserver # Used for verifying signatures auto-key-retrieve -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From burks at burks.de Thu Oct 17 00:19:00 2019 From: burks at burks.de (Burkhard Schroeder) Date: Thu, 17 Oct 2019 00:19:00 +0200 Subject: Android In-Reply-To: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> References: <12F41C82-3EC1-4E39-892C-7AAA334928F1@dabo.ch> Message-ID: Am 16.10.19 um 13:02 schrieb Daniel Bossert: > Is anybody using pgp on Android? I did some years ago, would like to, > but am afraid of security reason. > > I have safed my keys on my laptop only. > > How are you handling it in ages of mobiles? I use K-Mail and Openkeychain https://www.openkeychain.org/ If you want to store something safely you may use https://play.google.com/store/apps/details?id=com.sovworks.eds.android&hl=en I imported my key pair from a Linux PC. BurkS -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From alejacortez69 at gmail.com Thu Oct 17 01:52:21 2019 From: alejacortez69 at gmail.com (alejandro Cortez) Date: Wed, 16 Oct 2019 19:52:21 -0400 Subject: Fwd: Cannot decrypt from smartcard using gnupg-2.2, can from 2.0 In-Reply-To: References: <87d0f0vu2x.fsf@jumper.gniibe.org> Message-ID: I just realized my reply did not go to the list. ---------- Forwarded message --------- From: alejandro Cortez Date: Tue, Oct 15, 2019 at 9:43 AM Subject: Re: Cannot decrypt from smartcard using gnupg-2.2, can from 2.0 To: Niibe Yutaka On Mon, Oct 14, 2019 at 12:18 AM Niibe Yutaka wrote: > $ gpg-connect-agent "KEYINFO --list" /bye > On 2.0, this only prints OK. On 2.2, only one KEYINFO line is printed and the 4th to final column looks like: D - - - P - - - I have two different smartcards (both nitrokey pro). One of them is for a different key and does not experience any problems (it is loaded with a master key instead of a subkey). The output of KEYINFO is two lines and the 4th - final column looks like this: T OPENPGP.3 - - - - - D - - - P - - - So neither a working nor broken smartcard shows output like yours. Are there any other methods to debug this perhaps? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Oct 16 20:49:50 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 16 Oct 2019 14:49:50 -0400 Subject: GPG Agent discarding cache before ttl/max ttl In-Reply-To: <87eezdiv6b.fsf@wheatstone.g10code.de> References: <20191015141430.id2np5w2rzuribch@chipsenkbeil-fedora-PC0Y6ELM> <87eezdiv6b.fsf@wheatstone.g10code.de> Message-ID: <875zko7cfl.fsf@fifthhorseman.net> On Tue 2019-10-15 22:57:16 +0200, Werner Koch via Gnupg-users wrote: > If your system has a method to run a script > on suspend or lid closing it may already do just that. I consider this > a good idea but we can't do that by default in GnuPG because systems > differ to much on how to detect a lid closing event or similar. Thus > there is also no way to avoid it using a GnuPG option. It would be great to learn what the most common lid-closing events on popular platforms are, so that gpg-agent can do this cache-flushing behavior automagically at least for users on those platforms. On systems with D-Bus, following the freedesktop.org IPC standards, it looks like the following signal appears on the system bus when the machine goes to sleep: destination=(null destination) path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean true Debian systems these days typically use the dbus standard -- and i'd be happy to try to integrate detection of this signal into the debian gpg-agent packaging, if anyone wants to propose a way to do it. i'm not a D-Bus guru by any stretch of the imagination, so i'm not sure what the right next step is, guidance is definitely welcome. > On Tue, 15 Oct 2019 09:14, Chip Senkbeil said: >> enable-ssh-support > > Its the default anyway This is the default, but its presence in gpg-agent's configuration file is also used as a signal in some OSes (debian at least) as for whether to export an SSH_AUTH_SOCK that points to gpg-agent's ssh-agent emulation socket. See /etc/X11/Xsession.d/90gpg-agent for more details. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 16 20:30:09 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 16 Oct 2019 14:30:09 -0400 Subject: A place for discussing WKD spec clarifications? In-Reply-To: <87a7a1iuz6.fsf@wheatstone.g10code.de> References: <87a7a1iuz6.fsf@wheatstone.g10code.de> Message-ID: <878spk7dce.fsf@fifthhorseman.net> On Tue 2019-10-15 23:01:33 +0200, Werner Koch via Gnupg-users wrote: > On Tue, 15 Oct 2019 09:06, Bjarni Runar Einarsson said: > >> Would the GnuPG issue tracker be a good place to file "bug >> reports" against the spec, to work towards clarifications? > > That is okay for bug reports, but often it is more important to get the > opinions from more people than those who triage the bug reports. > > I thing gnupg-devel@ gnupg.org would be an appropriate place for > discussing such topics. WKD is a useful spec, and an increasingly important part of the OpenPGP ecosystem. If we want general e-mail discussion about WKD concerns, i'd suggest using the openpgp at ietf.org mailing list, as it will reach implementers of more WKD clients than just gnupg-users. That said, e-mail discussion is not the same as a tracker that allows us to keep a list of currently-known issues and concerns. If https://dev.gnupg.org/ is not appropriate for that sort of issue tracking, perhaps we could set up an issue tracker on gitlab associated with the WKD spec? I'd be happy to set up such a tracker at (say) https://gitlab.com/openpgp-wg/web-key-directory/issues if folks are OK with it. Werner, does that sound OK to you? As usual for any IETF-related interoperability discussion, i'd expect any major issues to *also* go to the mailing list for visibility and robust archiving, but i think that having an actively-maintained, publicly-accessible issue tracker related to this important work would be concretely useful. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bre at pagekite.net Thu Oct 17 13:08:46 2019 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Thu, 17 Oct 2019 11:08:46 -0000 Subject: A place for discussing WKD spec clarifications? In-Reply-To: <878spk7dce.fsf@fifthhorseman.net> References: <878spk7dce.fsf@fifthhorseman.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello! Thanks for the comments, guys! Daniel Kahn Gillmor wrote: > > > > I thing gnupg-devel@ gnupg.org would be an appropriate place for > > discussing such topics. > ... > If we want general e-mail discussion about WKD concerns, i'd > suggest using the openpgp at ietf.org mailing list, as it will > reach implementers of more WKD clients than just gnupg-users. I'm fine with any of the named venues for discussion; I agree that it would be good to have an issue tracker as well. There were many different minor issues raised at the summit and sometimes mailing list discussions meander a bit. Having a tracker where conclusions are summarized (linking back to mailing list archives) is very useful. > I'd be happy to set up such a tracker at (say) > https://gitlab.com/openpgp-wg/web-key-directory/issues if folks > are OK with it. > > Werner, does that sound OK to you? This sounds good to me, but I agree it's important Werner is onboard. He's the author of the spec, after all, an issue tracker without his participation seems unlikely to achieve its goals. I made a bunch of minor tweaks to Mailpile's WKD implementation at and after the summit, I'm keen to share that as soon as I know what the best venue is. Ideally I'd like to create some "bug reports" against the spec, and then write a post to the appropriate list where I summarize. Cheers, - Bjarni - -- PageKite.net lets your personal computer be part of the web -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2oS6cACgkQjgA3FgDP lJHUgAf/aeLK4/gN9emM/98eIYeTR0WBxFRmzCUT2PU94XGx1DNavCY/GbCToJy2 zn7PkIlMllEtFtzgCkKWjy8JCJxP8lS3dc4C6OCJfKyMh668Ugp4uDUfwWnYWInp acfXuI5F6+aTQoEZ28fxiKgck4EACeA3kEJoy3qa6CJtGtyEl9l1pxbYJEnyrFW6 pJ592k7m2q6aLI8oxqRm6m/YnbcOrWru6M7rhpJwGCiB0YW1OF3wykFguVOFz4Yd seUid2Do5fPKNMPcFaRqX2767zP5x1yzaqeoP8iMz7+KCTqwrsZ6TQ81baPIaIbl a6uZRZMMcCPZ67Oy5XQHmw9sZMu0Ew== =tkt3 -----END PGP SIGNATURE----- From patrick at enigmail.net Thu Oct 17 17:40:03 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 17 Oct 2019 17:40:03 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> Message-ID: <6e551bbd-21ba-a0f8-58ef-fc8567267d13@enigmail.net> Binarus wrote on 16.10.2019 17:37: > > > On 16.10.2019 13:07, Patrick Brunschwig wrote: >> worry for me. The main problem is the additional complexity that it >> brings if you require an external component that you cannot *fully* >> control. This covers topics like different behavior of different >> versions, but also configuration issues, users rights to install >> something on their PC and more. Gpgme may handle some of these issues, >> but the fact remains: an external component makes things a lot more >> complex, especially for support. > > I think this is the usual trade-off. One has to put time > > - either in understanding the APIs and command line parameters of a > library / utility, and to keep up with changes, or > > - in re-inventing the wheel, which in this case for sure will cost much > more time and eventually produce catastrophic security breaches and > software which is drastically inferior compared to what we have now. > > After all, everybody uses libraries and utilities. It is just reasonable > to have an expert work on a library or utility which uses techniques and > mathematical stuff which non-specialists never will understand in > detail, and have the non-specialists use that library or utility, > instead of letting them re-develop the same stuff, probably introducing > all sorts of security flaws and producing inferior software. > > When I have a bash script under Linux which invokes a compiler using a > complicated command line, I wouldn't come to the idea to re-develop that > compiler and integrate it directly into bash because that compiler's > command line switches could change in the next version ... > > I am still convinced that re-writing GnuPG (including all functions like > hardware tokens, subject encryption etc.) in a secure manner is a > hundred times more complex and a million times more error-prone than > tracking a few changes to its command line switches or error codes ever > could be. Apart from that, there is GpgME, as already has been stated. In all cases, we certainly won't re-write GnuPG or similar. The question on the table is: do we continue to use GnuPG (be it directly or via gpgme), or do we use a different OpenPGP implementation (and if yes which one). There are certainly good arguments for both. -Patrick From johanw at vulcan.xs4all.nl Thu Oct 17 21:03:24 2019 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 17 Oct 2019 21:03:24 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> Message-ID: <823da590-009c-3ef9-7e05-bd52860810a1@vulcan.xs4all.nl> On 16-10-2019 17:37, Binarus wrote: > - either in understanding the APIs and command line parameters of a > library / utility, and to keep up with changes, or > > - in re-inventing the wheel, which in this case for sure will cost much > more time and eventually produce catastrophic security breaches and > software which is drastically inferior compared to what we have now. There is a 3rd option: build the library (open source anyway) and build it directly into the product. That has the advantage of using existing, tested code, allows to dump a lot of complexity for unused edge cases and prevents the problems with different library versions with changes between versions. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Thu Oct 17 21:18:07 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 17 Oct 2019 15:18:07 -0400 Subject: FAQ: seeking consensus Message-ID: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> Unless there's no objection, I'll be making the edit to PGPNET's mailing list address, as that seems uncontroversial. I'd like to get a sense of the community on the other two changes I made. Werner and I disagree on certain things (which is understandable and okay!), and I'd really like to get a sense of where the community lies. Obviously, Werner gets the final decision. But I do think community feedback is essential, so please speak up! ===== 1. How should we handle the SKS keyserver attacks? One school of thought says "SKS is tremendously diminished as a resource, because using it can wedge older GnuPG installations and we can't make people upgrade. We should recommend people use other methods than SKS." If you think this is correct, please let me know what you think the alternate method should be. Another says, "with a recent GnuPG release SKS may be used productively and we should keep the current advice." Is there another solution I'm overlooking? Please don't think I'm limiting the discussion to just those two. If you've got a third way (or a fourth, or a fifth) I'd love to hear them. ===== 2. What should be done about the FAQ's guidance to use RSA-2048? First, I think everyone agrees it should be removed, as it's just not accurate any more; we've defaulted to RSA-3072 for some time. One option is, "remove it and update the text to refer to RSA-3072, our current default." Another is, "remove it and update the text to refer to ECC, which will be our next default." (If so: which curve and which lengths do you think should be the default?) (Again, third, fourth, and fifth ways are welcomed.) ===== 3. What should we advise people about their existing RSA-2048 keys? "There's no rush, but migrating them to [whatever our new guidance is] at a deliberate pace is advised, since RSA-2048 isn't expected to be generally safe past 2030" or "Your existing RSA-2048 keys are fine, you don't need to take any action" (Again, third, fourth, and fifth ways are welcomed.) From johanw at vulcan.xs4all.nl Thu Oct 17 21:28:44 2019 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 17 Oct 2019 21:28:44 +0200 Subject: FAQ: seeking consensus In-Reply-To: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> References: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> Message-ID: <198ee3ba-0077-1b95-cf33-de28ddbae0f2@vulcan.xs4all.nl> On 17-10-2019 21:18, Robert J. Hansen wrote: > 1. How should we handle the SKS keyserver attacks? > > One school of thought says "SKS is tremendously diminished as a > resource, because using it can wedge older GnuPG installations and we > can't make people upgrade. We should recommend people use other methods > than SKS." If you think this is correct, please let me know what you > think the alternate method should be. > > Another says, "with a recent GnuPG release SKS may be used productively > and we should keep the current advice." I'd say split it: if there are reasons to use gpg 1.4 for compatibility or other reasons, don't use sks. If you're using gpg 2.2.17 or newer, you can use it. The people who knowingly use 1.4 will know they're in that category. > "Your existing RSA-2048 keys are fine, you don't need to take any action" Yet. Please look again in 5 years (estimate is till 2030 but some unexpected attack might appear). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From steffen at sdaoden.eu Thu Oct 17 21:38:18 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 17 Oct 2019 21:38:18 +0200 Subject: FAQ: seeking consensus In-Reply-To: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> References: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> Message-ID: <20191017193818.SGM8K%steffen@sdaoden.eu> Robert J. Hansen wrote in <99710af5-92ac-dbdd-afe9-d60d89614a76 at sixdemon\ bag.org>: ... |1. How should we handle the SKS keyserver attacks? ... |Another says, "with a recent GnuPG release SKS may be used productively |and we should keep the current advice." I am using them, and have had the sks-keyservers.net in my own cacert pool for a long time. I do only import rarely, very specific keys, and only with supervision, however. It has always been like that, and i also always clean keys, since i personally never really had a glue onto the PGP approach of that web of trust. I still whimper that the new German passports did not ship with SSL and PGP keys/certificates. But that is something different. ... |2. What should be done about the FAQ's guidance to use RSA-2048? | |First, I think everyone agrees it should be removed, as it's just not |accurate any more; we've defaulted to RSA-3072 for some time. | |One option is, "remove it and update the text to refer to RSA-3072, our |current default." | |Another is, "remove it and update the text to refer to ECC, which will |be our next default." (If so: which curve and which lengths do you |think should be the default?) | |(Again, third, fourth, and fifth ways are welcomed.) This mail only because i want to point out that, if i remember this correctly, the majority of FreeBSD committers who had a PGP key used RSA 4096 already in 2002, or around that time. (4.7 times i think these were.) |3. What should we advise people about their existing RSA-2048 keys? | |"There's no rush, but migrating them to [whatever our new guidance is] |at a deliberate pace is advised, since RSA-2048 isn't expected to be |generally safe past 2030" | |or | |"Your existing RSA-2048 keys are fine, you don't need to take any action" | |(Again, third, fourth, and fifth ways are welcomed.) You know, i would say people should be advised to use the most compatible, most secure keys available for their "very key". Regardless of computing cost that is. And use specific "weaker", "faster" or whatever keys for specific purposes, like tarball signing, or whatever. I have never understood any other advise, actually. I have vague memories of a very "conservative" sentence on the use of PGP keys on the mentioned FreeBSD handbook page, it must be more than 15 years, and i have only read it once. I adhered to that, and i now that all the RSA 4096 things i have produced ever since will be safe for quite some time, maybe even until i die (which could happen anytime though), unless the quantum thing explodes somehow (not a mathematician here). I still have to log into SSH hosts which do not support anything but RSA (i have only ever used RSA keys, not DSA i think it was, and am using ED25519 for an increasing number of other hosts). (P.S.: personally i am also still using GnuPG v1.4.23, in my private path, even though i have 2.2.17 in /usr here, and the rotating head of ArchLinux also ships the new one, etc. etc.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From codeguro at gmail.com Fri Oct 18 00:30:02 2019 From: codeguro at gmail.com (Tony Lane) Date: Thu, 17 Oct 2019 18:30:02 -0400 Subject: FAQ: seeking consensus In-Reply-To: <20191017193818.SGM8K%steffen@sdaoden.eu> References: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> <20191017193818.SGM8K%steffen@sdaoden.eu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/17/19 3:38 PM, Steffen Nurpmeso wrote: > You know, i would say people should be advised to use the most > compatible, most secure keys available for their "very key". > Regardless of computing cost that is. And use specific "weaker", > "faster" or whatever keys for specific purposes, like tarball > signing, or whatever. I have never understood any other advise, > actually. I have vague memories of a very "conservative" sentence > on the use of PGP keys on the mentioned FreeBSD handbook page, it > must be more than 15 years, and i have only read it once. > I adhered to that, and i now that all the RSA 4096 things i have > produced ever since will be safe for quite some time, maybe even > until i die (which could happen anytime though), unless the > quantum thing explodes somehow (not a mathematician here). If you absolutely, positively, _need_ the most bits of security then RSA4096 shouldn't be your go-to anymore. RSA4096 doesn't actually provide 4096 bits of security. The _key_ sizes may be 4096 bits, but you must understand the security comes from the the cardinality of prime numbers, so the actual amount of security is only 131 bits of security. Compare this to RSA's 3072 bit keys providing 125 bits of security. Unlike RSA, ECC keys don't scale logarithmically. For ECC, the fields need to be a prime modulus, but that's about it. As a result, the key sizes scale linearly with the bits of security by a factor of 2. So, if you want the most security possible with GPG _today_ you won't beat curve P-521, which provides ~261 bits of security, and to get an equivalent in RSA your key size would need to be at least 15360. But you have to understand, even 128 bits of security is so incredibly large that even the combined computing power of every processor we have now won't be enough to crack it. See: https://crypto.stackexchange.com/a/48669 for just how effort it'd take. By the way, 256 bits of security isn't twice the amount of 128 bits. 129 bits is twice the amount of security of 128 bits. Get it? If you are curious just how much effort it'd take to break a 256 bit key, I'd argue that it's physically impossible because there simply isn't enough energy in the universe to break it... see: https://youtu.be/S9JGmA5_unY But I digress. It's not the bits of security that matter anymore. You have a far bigger chance of being insecure with side-channel attacks etc, than you are with not enough bits of security. That is a far bigger security hole... Being on a device that is exposed to the internet. That's where you'd get cracked. Not the key size being too small. -----BEGIN PGP SIGNATURE----- iLkEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXajragAKCRDo8fj9gx4T 01GGAgkB8tgtFHtx91tvWxKzKdlFoceY68lzw968aWRqnv/ObRVUKDp/GVD/ykdj Zagk6D+t6V0ua7eUONo9j37/zmwOIfcCCQF4xvT4Mlaqfr2RUqt9Wyp+TEhLtrhJ GjmOOzrUcfjPT/ckvAk9Rl12gzuorIcbuwrCisN0r3htCwECJLz8s6r69A== =Rek+ -----END PGP SIGNATURE----- From tlikonen at iki.fi Fri Oct 18 07:12:39 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Fri, 18 Oct 2019 08:12:39 +0300 Subject: FAQ: seeking consensus In-Reply-To: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> References: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> Message-ID: <877e5263i0.fsf@iki.fi> Robert J. Hansen [2019-10-17T15:18:07-04] wrote: > 1. How should we handle the SKS keyserver attacks? > > One school of thought says "SKS is tremendously diminished as a > resource, because using it can wedge older GnuPG installations and we > can't make people upgrade. We should recommend people use other methods > than SKS." If you think this is correct, please let me know what you > think the alternate method should be. > > Another says, "with a recent GnuPG release SKS may be used productively > and we should keep the current advice." > > Is there another solution I'm overlooking? Please don't think I'm > limiting the discussion to just those two. If you've got a third way > (or a fourth, or a fifth) I'd love to hear them. I think the FAQ should briefly discuss the attack and weaknesses of SKS keyservers. The FAQ could then say that with GnuPG version user is quite safe. Then mention that there is also alternative, keys.openpgp.org, with different features. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 694 bytes Desc: not available URL: From mgorny at gentoo.org Fri Oct 18 08:20:30 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Fri, 18 Oct 2019 08:20:30 +0200 Subject: FAQ: seeking consensus In-Reply-To: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> References: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> Message-ID: On Thu, 2019-10-17 at 15:18 -0400, Robert J. Hansen wrote: > 1. How should we handle the SKS keyserver attacks? > > One school of thought says "SKS is tremendously diminished as a > resource, because using it can wedge older GnuPG installations and we > can't make people upgrade. We should recommend people use other methods > than SKS." If you think this is correct, please let me know what you > think the alternate method should be. > > Another says, "with a recent GnuPG release SKS may be used productively > and we should keep the current advice." > > Is there another solution I'm overlooking? Please don't think I'm > limiting the discussion to just those two. If you've got a third way > (or a fourth, or a fifth) I'd love to hear them. I think right now the FAQ has a bit of redundancy with mentioning SKS all the time. My suggestion would be to start by deduplicating that. Try to make most of it keyserver-agnostic. Then, possibly in 'Is there any particular keyserver I should use?' discuss both SKS and keys.openpgp.org. I suppose comparing them would be good, and mentioning which GnuPG versions are vulnerable to poisoning. That said, given that this is a more generic design problem than specific SKS vulnerability, it would probably use its own answer in the FAQ. > ===== > > 2. What should be done about the FAQ's guidance to use RSA-2048? > > First, I think everyone agrees it should be removed, as it's just not > accurate any more; we've defaulted to RSA-3072 for some time. > > One option is, "remove it and update the text to refer to RSA-3072, our > current default." > > Another is, "remove it and update the text to refer to ECC, which will > be our next default." (If so: which curve and which lengths do you > think should be the default?) > > (Again, third, fourth, and fifth ways are welcomed.) Well, if it's still meant to say 'Why does GnuPG default...', then obviously it needs to be updated. Probably it is worthwhile to explicitly indicate when the default has changed, and why. Probably the question below it 'Do other high-security...' would also need to be updated, maybe make it more generic, like what sizes do other applications use. > ===== > > 3. What should we advise people about their existing RSA-2048 keys? > > "There's no rush, but migrating them to [whatever our new guidance is] > at a deliberate pace is advised, since RSA-2048 isn't expected to be > generally safe past 2030" > > or > > "Your existing RSA-2048 keys are fine, you don't need to take any action" > > (Again, third, fourth, and fifth ways are welcomed.) > The latter. Let's wait a bit how things emerge. It would be silly to have people redo their keys just to have them redo them for ECC again soonish. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From trap at mailfence.com Fri Oct 18 06:47:09 2019 From: trap at mailfence.com (trap trip) Date: Fri, 18 Oct 2019 06:47:09 +0200 (CEST) Subject: 2FA gpg authentification? Message-ID: <1363107572.105100.1571374028989@ichabod.co-bxl> Hello I use linux, ubuntu budgie.For my mail i use thunderbird 60.3.0 and also mailfence, would like to know how to use gnupg in case of 2FA gpg authentification? Let me explain, i need to read a message crypted with my public key,i didn' receved this message by email it is online and i just need to read it to finish the 2FA gpg authentification. so my question is how to import this message an read it with my private key? Thank you for all help --? Envoy? via https://mailfence.com Email priv? et s?curis? From sac at 300baud.de Fri Oct 18 09:19:05 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 18 Oct 2019 09:19:05 +0200 Subject: FAQ: seeking consensus In-Reply-To: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> References: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> Message-ID: <20191018091905.00004071.sac@300baud.de> Robert J. Hansen wrote: > 1. How should we handle the SKS keyserver attacks? I would list in the FAQ the kind of attacks possible, to educate users, before they choose one for uploading their key. > One school of thought says "SKS is tremendously diminished as a > resource, because using it can wedge older GnuPG installations and we > can't make people upgrade. We should recommend people use other methods > than SKS." If you think this is correct, please let me know what you > think the alternate method should be. > > Another says, "with a recent GnuPG release SKS may be used productively > and we should keep the current advice." > > Is there another solution I'm overlooking? Please don't think I'm > limiting the discussion to just those two. If you've got a third way > (or a fourth, or a fifth) I'd love to hear them. It would be nice if you can add to the keyserver list also the mailvelope.com keyserver, because it requires users to authenticate their keys against the keyserver with an received encrypted email and it also allows keeping third party signatures, compared to Hagrid. https://keys.mailvelope.com Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From look at my.amazin.horse Fri Oct 18 12:02:05 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Fri, 18 Oct 2019 12:02:05 +0200 Subject: FAQ: seeking consensus // SKS plans In-Reply-To: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> References: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> Message-ID: <2G1TB0ARW796R.2ZA5XNV6N7BXU@my.amazin.horse> > 1. How should we handle the SKS keyserver attacks? Worth mentioning that at the openpgp summit recently, Kristian announced some plans that the SKS pool would: 1) Move implementation from SKS to Hockeypuck 2) Disable search by user id entirely 3) Filter out third party signatures, at least for a while None of those seemed set in stone, and there is no timeline as far as I'm aware. But be aware those things are being planned. - V From look at my.amazin.horse Fri Oct 18 12:24:43 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Fri, 18 Oct 2019 12:24:43 +0200 Subject: FAQ: seeking consensus In-Reply-To: <20191018091905.00004071.sac@300baud.de> References: <20191018091905.00004071.sac@300baud.de> <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> Message-ID: <2B2VCREHPU25O.3QPWNT24XMUC0@my.amazin.horse> > It would be nice if you can add to the keyserver list also the > mailvelope.com keyserver, I concur keys.mailvelope.com is a fine keyserver today. However, you might want to consider: > because it requires users to authenticate their keys against the keyserver > with an received encrypted email An "encrypted" verification email in no way, shape or form "authenticates" a key any more than an unencrypted email. It may seem like it should at first glance, but it really doesn't if you think through the attack scenarios. > and it also allows keeping third party signatures, compared to Hagrid. This property also makes it susceptible to flooding attacks, and Mailvelope doesn't make use of third party sigs itself. I talked to Thomas (from Mailvelope) the other day, and he said he would either want to make their implementation more abuse resistant (which I assume means dropping third party sigs as well), or decommissioning it altogether in favor of Hagrid. Cheers - V From mgorny at gentoo.org Fri Oct 18 12:25:08 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Fri, 18 Oct 2019 12:25:08 +0200 Subject: FAQ: seeking consensus In-Reply-To: <20191018091905.00004071.sac@300baud.de> References: <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> <20191018091905.00004071.sac@300baud.de> Message-ID: <1196f40b0b549f00e2bc22d51d5dbcdc314b85da.camel@gentoo.org> On Fri, 2019-10-18 at 09:19 +0200, Stefan Claas via Gnupg-users wrote: > Robert J. Hansen wrote: > > > 1. How should we handle the SKS keyserver attacks? > > I would list in the FAQ the kind of attacks possible, > to educate users, before they choose one for uploading > their key. > > > One school of thought says "SKS is tremendously diminished as a > > resource, because using it can wedge older GnuPG installations and we > > can't make people upgrade. We should recommend people use other methods > > than SKS." If you think this is correct, please let me know what you > > think the alternate method should be. > > > > Another says, "with a recent GnuPG release SKS may be used productively > > and we should keep the current advice." > > > > Is there another solution I'm overlooking? Please don't think I'm > > limiting the discussion to just those two. If you've got a third way > > (or a fourth, or a fifth) I'd love to hear them. > > It would be nice if you can add to the keyserver list also the > mailvelope.com keyserver, because it requires users to authenticate > their keys against the keyserver with an received encrypted email > and it also allows keeping third party signatures, compared to > Hagrid. > > https://keys.mailvelope.com > This domain seems not to resolve with DNSSEC-capable resolvers. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From sac at 300baud.de Fri Oct 18 13:27:48 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 18 Oct 2019 13:27:48 +0200 Subject: FAQ: seeking consensus In-Reply-To: <2B2VCREHPU25O.3QPWNT24XMUC0@my.amazin.horse> References: <20191018091905.00004071.sac@300baud.de> <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemonbag.org> <2B2VCREHPU25O.3QPWNT24XMUC0@my.amazin.horse> Message-ID: <20191018132748.000079bb.sac@300baud.de> Vincent Breitmoser wrote: > > It would be nice if you can add to the keyserver list also the > > mailvelope.com keyserver, > > I concur keys.mailvelope.com is a fine keyserver today. However, you might > want to consider: > > > because it requires users to authenticate their keys against the keyserver > > with an received encrypted email > > An "encrypted" verification email in no way, shape or form "authenticates" > a key any more than an unencrypted email. It may seem like it should at first > glance, but it really doesn't if you think through the attack scenarios. Well, at least than it is an additional protection layer, which is nice to have. > > and it also allows keeping third party signatures, compared to Hagrid. > > This property also makes it susceptible to flooding attacks, and Mailvelope > doesn't make use of third party sigs itself. I think they changed it a while ago. Before one could submit keys, once they were already on the keyserver. Now it requires again a comformation email. And it is true while you can't sign keys with Mailvelope the Key Manager however shows them. > I talked to Thomas (from Mailvelope) the other day, and he said he would > either want to make their implementation more abuse resistant (which I assume > means dropping third party sigs as well), or decommissioning it altogether in > favor of Hagrid. I think that the Mailvelope keyserver is a nice for people who are in need of CA or classic WoT signatures. So they should IMHO keep it. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From gniibe at fsij.org Fri Oct 18 13:50:21 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 18 Oct 2019 20:50:21 +0900 Subject: SSH CA + gpg-agent + gnuk => error In-Reply-To: References: Message-ID: <87pniuuvb6.fsf@jumper.gniibe.org> Brennecke, Simon wrote: > I have a question regarding the interaction of SSH with gpg-agent > (and possibly also gnuk). [...] > So I generated a new ECC key in gnuk, imported the public keys in gpg. > Added the keygrip everything to "~/.gnupg/sshcontrol" Just FYI, for smartcard, adding a keygrip in sshcontrol is not needed, if it is OK for your gpg-agent to just fail for signing request when smartcard is not available. > "ssh-add -L" shows me the key. > I signed it with the CA. > ssh tries to use the key... > ... and this is where the error pops up. > > ssh tells me: > sign_and_send_pubkey: signing failed: agent refused operation > > and gpg-agent tells me: > gpg-agent[21629]: ssh request handler for sign_request (13) started > gpg-agent[21629]: DBG: detected card with S/N D276000124010200FFFE430322340000 > gpg-agent[21629]: smartcard signing failed: General error > gpg-agent[21629]: ssh sign request failed: General error I don't think it is related to OpenSSH certificate. For some reason, possibly a bug, smartcard singing failed. You can configure .gnupg/scdaemon.conf with something like: ==================== debug-level guru debug-all verbose log-file /run/user/1000/scd.log ==================== to see what's going on. * * * Here is another information, related. OpenSSH certificate authentication doesn't work well with gpg-agent (yet). Ideally, OpenSSH certificate should be under control of gpg-agent. For detail, you can see: https://dev.gnupg.org/T1756 https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031479.html Protocol-wise, for gpg-agent, it is expected that the ssh does: * ssh askes ssh-agent (in our case, gpg-agent) to get OpenSSH certificate by REQUEST_IDENTITIES command * (only after) REQUEST_IDENTITIES command, ssh askes ssh-agent challenge-response by SIGN_REQUEST command But the first part does not occur by current OpenSSH client. The client by itself answers back to the server using the certificate on disk (under .ssh/), without asking ssh-agent. -- From jrallen at runbox.com Fri Oct 18 16:02:51 2019 From: jrallen at runbox.com (Jeff Allen) Date: Fri, 18 Oct 2019 10:02:51 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <6e551bbd-21ba-a0f8-58ef-fc8567267d13@enigmail.net> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> <6e551bbd-21ba-a0f8-58ef-fc8567267d13@enigmail.net> Message-ID: <2f227e6d3627d81868ff751b17abf04f300f00a5.camel@runbox.com> On Thu, 2019-10-17 at 17:40 +0200, Patrick Brunschwig wrote: > In all cases, we certainly won't re-write GnuPG or similar. The > question > on the table is: do we continue to use GnuPG (be it directly or via > gpgme), or do we use a different OpenPGP implementation (and if yes > which one). There are certainly good arguments for both. > I am a GnuPG user, not an expert and certainly not a developer, so you may take my suggestions with a grain of salt. Following this thread about future OpenPGP support in Thunderbird prompted me to begin trying other MUAs. Why? Because if Thunderbird implements its own OpenPGP scheme, I wonder whether it will include features I consider important like smartcard support. It is unlikely to have a configuration file like gpg.conf that enables me to fine-tune both email and file encryption. For the past couple of days I have been using Evolution. It just works with GnuPG. I don't know or care how. It encrypts, decrypts and verifies signatures. There was no set-up required. My Yubikey works because Evolution calls GnuPG instead of using a proprietary implementation. AFAIK only GPG does that. Protonmail, Mailvelope, FlowCrypt, and Mailfence do not. You could probably build in smartcard support and any other feature I can name, but why grapple with what GnuPG already does well? Why spend your time trying to head off the next security threat when Werner & Co. will do it for you? Enigmail has great features like the key manager and per-recipient rules. Focus on those. Make Thunderbird encryption easy to use for novices without driving off more experienced users. Like Enigmail, I use only a tiny fraction of GPG's commands and options. The fact that GPG can do things I find esoteric is of little concern to me, but I'm glad those features are there for people who need them. The complexity of GnuPG does not make its use complex the average users or for apps providing GPG front-ends. They simply ignore what they don't need. The only thing I see that internal OpenPGP accomplishes is saving the Windows user the task of installing GnuPG. Anyone who uses Thunderbird knows how to install software. You can probably arrange with Werner for a permanent link to the latest simple installer. Automatically check for GnuPG when Thunderbird is installed on Windows. If it isn't there, offer one-click installation. I started using Thunderbird because of Enigmail, not the other way around. I haven't been a fan of some recent developments like pEp and defaulting to "junior" mode, but I recognize their usefulness to new users and can easily work around them myself. My take on your original explanation of the reason for Enigmail's pending demise is that a changed Thunderbird plug-in scheme makes it more efficient to build Enigmail functionality into the MUA. Why not stick with that and focus on what has made Enigmail successful? Jeff Allen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: This is a digitally signed message part URL: From steffen at sdaoden.eu Fri Oct 18 20:12:24 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 18 Oct 2019 20:12:24 +0200 Subject: FAQ: seeking consensus In-Reply-To: References: Message-ID: <20191018181224.sGL2m%steffen@sdaoden.eu> Tony Lane via Gnupg-users wrote in : |-----BEGIN PGP SIGNED MESSAGE----- |Hash: SHA512 That seems to be a good choice. |On 10/17/19 3:38 PM, Steffen Nurpmeso wrote: |> You know, i would say people should be advised to use the most |> compatible, most secure keys available for their "very key". |> Regardless of computing cost that is. And use specific "weaker", |> "faster" or whatever keys for specific purposes, like tarball |> signing, or whatever. I have never understood any other advise, |> actually. I have vague memories of a very "conservative" sentence |> on the use of PGP keys on the mentioned FreeBSD handbook page, it |> must be more than 15 years, and i have only read it once. |> I adhered to that, and i now that all the RSA 4096 things i have |> produced ever since will be safe for quite some time, maybe even |> until i die (which could happen anytime though), unless the |> quantum thing explodes somehow (not a mathematician here). | |If you absolutely, positively, _need_ the most bits of security then |RSA4096 shouldn't be your go-to anymore. RSA4096 doesn't actually |provide 4096 bits of security. The _key_ sizes may be 4096 bits, but |you must understand the security comes from the the cardinality of |prime numbers, so the actual amount of security is only 131 bits of |security. Compare this to RSA's 3072 bit keys providing 125 bits of |security. Unlike RSA, ECC keys don't scale logarithmically. For ECC, |the fields need to be a prime modulus, but that's about it. As a |result, the key sizes scale linearly with the bits of security by |a factor of 2. So, if you want the most security possible with GPG |_today_ you won't beat curve P-521, which provides ~261 bits of |security, and to get an equivalent in RSA your key size would need |to be at least 15360. | |But you have to understand, even 128 bits of security is so I might a bit if i follow this road long enough. |incredibly large that even the combined computing power of every |processor we have now won't be enough to crack it. See: |https://crypto.stackexchange.com/a/48669 for just how effort |it'd take. |By the way, 256 bits of security isn't twice the amount of 128 bits. |129 bits is twice the amount of security of 128 bits. Get it? |If you are curious just how much effort it'd take to break a 256 bit |key, I'd argue that it's physically impossible because there simply |isn't enough energy in the universe to break it... see: |https://youtu.be/S9JGmA5_unY My download is excessed until the 22nd. But will throw an eye. |But I digress. It's not the bits of security that matter anymore. For me the fascinating thing in this area are all those ideas which human minds had to not have a need to do brute force searching. Regarding my GPG passwords i think nothing much can be done about that though, except restricting the search to the bytes that pass "tr -cd 'a-zA-Z0-9_.,=@%^+-'", but which is already a significant reduction. |You have a far bigger chance of being insecure with side-channel |attacks etc, than you are with not enough bits of security. That is |a far bigger security hole... Being on a device that is exposed Yeah, the passwords which were stolen by talking in my sleep are a real problem. |to the internet. That's where you'd get cracked. Not the key size |being too small. Actually i do not think that is really true, or only by accident. I think the problems are theft, trojan horses, threat of force, and that unfortunately includes coercive detention also (maybe also only and even) in our western first world. So even with what for example FreeBSD has, where you can have some space on your harddisk which looks like random data but actually contains an encrypted partition, (i am pretty sure in the Linux world this is also doable somehow), there are drugs and other specialists which can make you talk and reveal that presence. At some later time i would expect a court order to access log etc. data in and of the brain implant will increase personal rights and freedom. And not the key size being too small may likely be true, but shortly after Y2K i am pretty sure to remember right that the "usual defaults" where 1024 bits for RSA or so, and whoever followed that advise and had some records protected by such a key, and there are records which are of real value, might have or look forward to problems if they got lost. Which thus brings me back to the FreeBSD developer handbook entry which talked about 4096 bit keys around that time. So yes, an excursion like yours is pretty cool and of value, and experts do know, but for "normal people" i would always favour the best thinkable default. For that audience that EC stuff may also just work, then. I mean, the thing is that "normal people" usually never get to use GnuPG directly anyway, and having the best defaults if gpg gets used indirectly by application programs is possibly better than having lots of configurations in this app and that app. (Like the central OpenSSL configuration file that is now possible, with sections for individual programs. Though programs need adjustments to use that.) Btw., you use autocrypt headers, in this mail of yours there are thus two certificate keys included. Unfortunately my MUA not yet can either of them, and will not before next spring. At that time we will support PGP/MIME and inline signed/encrypted messages (even though it will not be nice until some later time). And will have a look into OpenPGP: headers. But not autocrypt, no. |-----BEGIN PGP SIGNATURE----- | |iLkEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXajragAKCRDo8fj9gx4T |01GGAgkB8tgtFHtx91tvWxKzKdlFoceY68lzw968aWRqnv/ObRVUKDp/GVD/ykdj |Zagk6D+t6V0ua7eUONo9j37/zmwOIfcCCQF4xvT4Mlaqfr2RUqt9Wyp+TEhLtrhJ |GjmOOzrUcfjPT/ckvAk9Rl12gzuorIcbuwrCisN0r3htCwECJLz8s6r69A== |=Rek+ |-----END PGP SIGNATURE----- --End of --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From codeguro at gmail.com Sat Oct 19 01:40:28 2019 From: codeguro at gmail.com (Tony Lane) Date: Fri, 18 Oct 2019 19:40:28 -0400 Subject: FAQ: seeking consensus In-Reply-To: <20191018181224.sGL2m%steffen@sdaoden.eu> References: <20191018181224.sGL2m%steffen@sdaoden.eu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/18/19 2:12 PM, Steffen Nurpmeso wrote: > (redacted)... there are drugs and other specialists which > can make you talk and reveal that presence. At some later time > i would expect a court order to access log etc. data in and of the > brain implant will increase personal rights and freedom. Not exactly. Actually, this is precisely why I find public key cryptography so cool. If you do not explicitly add your own address to the list of recipients, you will not be able to decrypt the message! This may sound silly, but you may want to write something to someone that you cannot ever possibly be compelled to decrypt. It will be impossible for you to decrypt, even though you wrote it and encrypted it and even if you have the file in your possession and even if you have all your secret keys and you know all of your own passwords and have them written down. You can smile serenely while they're beating you with a rubber hose, knowing that you can't endanger the lives of your sources, nor give up your rights, even if you felt like that might be entertaining for a change. This is also exactly why governments find it such threat - the idea we have a way to truly, securely communicate in a way they cannot prove who sent what terrifies them. It's also what lead to the US trying to classify such crypto as a military munition, which was later repealed in court in Bernstein vs US Department of State. They're trying to bring it back though (hah, fat chance)! > Btw., you use autocrypt headers, in this mail of yours there are > thus two certificate keys included. Unfortunately my MUA not yet > can either of them, and will not before next spring. > At that time we will support PGP/MIME and inline signed/encrypted > messages (even though it will not be nice until some later > time). And will have a look into OpenPGP: headers. But not > autocrypt, no. I didn't realize there were people in this mailing list who didn't use it. Well, I turned it off here... that better? -----BEGIN PGP SIGNATURE----- iLcEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXapNbAAKCRDo8fj9gx4T 02M3AgifbiLAywfj+K8T0LujTLhyVAFy6UAkP7q+4SQjUuhN510K3RH7Z4WC0/h/ KugrLdV0W+SMPv0jRTuzXyIkAWCAHwIIkYC5/+n85ualrY9WF3Kpk6o2Yws5CWxW yTmM1wcnNN7uzXOXafLPTxGyca9uqil158OEbfX6GktAc2mrQkFLUNc= =8nMs -----END PGP SIGNATURE----- From patrick at enigmail.net Sat Oct 19 17:20:59 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 19 Oct 2019 17:20:59 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <2f227e6d3627d81868ff751b17abf04f300f00a5.camel__40239.0670192958$1571407506$gmane$org@runbox.com> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> <6e551bbd-21ba-a0f8-58ef-fc8567267d13@enigmail.net> <2f227e6d3627d81868ff751b17abf04f300f00a5.camel__40239.0670192958$1571407506$gmane$org@runbox.com> Message-ID: Jeff Allen via Gnupg-users wrote on 18.10.2019 16:02: [...] > My take on your original explanation of the reason for Enigmail's > pending demise is that a changed Thunderbird plug-in scheme makes it > more efficient to build Enigmail functionality into the MUA. That's only the 2nd half of the explanation. 1st and foremost, the changed plugin scheme comes along with a completely new API (that does not even exist completely by now). This would require me to rewrite almost all of Enigmail from scratch. I don't have enough free time for doing that, nor would I be interested in it. This, and nothing else, was initially the reason why we started the discussion with the Thunderbird team. > Why not stick with that and focus on what has made Enigmail > successful? What is the reason in your eyes that made Enigmail successful? -Patrick From steffen at sdaoden.eu Sat Oct 19 22:46:43 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 19 Oct 2019 22:46:43 +0200 Subject: FAQ: seeking consensus In-Reply-To: References: <20191018181224.sGL2m%steffen@sdaoden.eu> Message-ID: <20191019204643.ZeeO7%steffen@sdaoden.eu> Hello Tony. Tony Lane via Gnupg-users wrote in : |On 10/18/19 2:12 PM, Steffen Nurpmeso wrote: |> (redacted)... there are drugs and other specialists which |> can make you talk and reveal that presence. At some later time |> i would expect a court order to access log etc. data in and of the |> brain implant will increase personal rights and freedom. | |Not exactly. Actually, this is precisely why I find public key |cryptography so cool. If you do not explicitly add your own address |to the list of recipients, you will not be able to decrypt the message! But wait, that is a frantic scenario. |This may sound silly, but you may want to write something to someone |that you cannot ever possibly be compelled to decrypt. It will be |impossible for you to decrypt, even though you wrote it and encrypted |it and even if you have the file in your possession and even if you |have all your secret keys and you know all of your own passwords |and have them written down. You can smile serenely while they're |beating you with a rubber hose, knowing that you can't endanger the |lives of your sources, nor give up your rights, even if you felt like |that might be entertaining for a change. This is also exactly why |governments find it such threat - the idea we have a way to truly, I find that overly optimistic. It brought two visual film impressions, one is the poor guy from within the crate in Pulp Fiction, that is how you end if you run out of hopes at some time, it seems. The other was a French film of a Basque revel (or freedom fighter if you want to), who was finally caught and interrogated under drugs. The drugs made him see (he was a host before), unfortunately the film ends thereafter with him in a straitjacket hammering the back of his head against the pad in some cave cell, trying to get rid of a lot of side channel attacks (my impression, entirely others may have seen a man gone grazy). |securely communicate in a way they cannot prove who sent what |terrifies them. It's also what lead to the US trying to classify |such crypto as a military munition, which was later repealed in court |in Bernstein vs US Department of State. They're trying to bring it |back though (hah, fat chance)! Oh yes, i also have the impression that hysteria gains currency. A lot of which surely is tactics to gain momentum against chinese made and designed communication hardware, nevermind the extra costs of kindling. (I for one think it is just undemocratic and antisocial if only one party can spy. And they all do, more or less, right.) And we see ambitions to forbid crypto, or to allow only crypto with backdoors. I personally think this will come some day, just like the implant will, the benefits are too large, just think about the possibility to get the entire medical history and current state of a person in an emergency situation. Criminals which go to prison by themselves, what do i know :) |> Btw., you use autocrypt headers, in this mail of yours there are |> thus two certificate keys included. Unfortunately my MUA not yet |> can either of them, and will not before next spring. |> At that time we will support PGP/MIME and inline signed/encrypted |> messages (even though it will not be nice until some later |> time). And will have a look into OpenPGP: headers. But not |> autocrypt, no. | |I didn't realize there were people in this mailing list who didn't |use it. Well, I turned it off here... that better? "Thank you" ^_^. I think yes! No, i would not, i think it is a strange thing, of course public keys must come from somewhere, but passing several hundred or so bytes in each and every mail message seems like a weird thing to do. Especially if the key is shipped alongside the message already, and then headers can be spoofed, so autocrypt makes sense alongside dkim and such third party signing environments, which i also dislike, in the form they come. (I would prefer a CMS message envelope i think, but sure, this requires MIME messages.) I mean, if i want to have signed communication with someone, i could very well just send her or him a signed message saying so, and then the key is also where it belongs, no? Strange thing... --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From 400thecat at gmx.ch Sun Oct 20 07:22:46 2019 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Sun, 20 Oct 2019 07:22:46 +0200 Subject: gpg on read-only filesystem Message-ID: <57576be4-5c15-9503-4862-b6672d91a78d@gmx.ch> Hello, how can I use gpg without agent ? Also, how can I use gpg as root, when / is mounted read-only? I understand the advantages of gpg agent, and I am happily using it as user on my desktop. But, on my remote server , I don't want to use any agent. I don't need any program remembering my passwords, and I don't need any fancy password prompts. I just need basic function (decrypt .gpg file) Also, I consider it good practice to have / mounted read-only, and I don't understand why gpg would need to open trustdb.gpg in rw mode, when using simple operations such as gpg --verify. gpg: Fatal: can't open '/root/.gnupg/trustdb.gpg': Operation not permitted In older versions of gpg, it complained abut missing agent and readonly filesystem, but it still worked. Now on gpg 2.2.12 I am unable to use it even for the simplest operations. In short, it seems to me very bad design decisions have been made, which have rendered gpg basically unusable. Has this been done intentionally? gpg is part of core infrastructure. It should be simple and functional. Any fancy "features" should be implemented as option, not forced. How am I supposed to use gpg now ? I would appreciate any feedback from this community. Below are the errors I am getting. # gpg --batch -d zz.gpg gpg: failed to create temporary file '/root/.gnupg/.#lk0x00005608d3406ed0.buster64-dev.14763': Read-only file system gpg: keyblock resource '/root/.gnupg/pubring.kbx': Read-only file system gpg: AES256 encrypted data gpg: failed to create temporary file '/root/.gnupg/.#lk0x00005608d3407f60.buster64-dev.14763': Read-only file system gpg: can't connect to the agent: Read-only file system gpg: problem with the agent: No agent running gpg: encrypted with 1 passphrase gpg: decryption failed: No secret key thanks, From jrallen at runbox.com Sun Oct 20 14:51:24 2019 From: jrallen at runbox.com (Jeff Allen) Date: Sun, 20 Oct 2019 08:51:24 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> <6e551bbd-21ba-a0f8-58ef-fc8567267d13@enigmail.net> <2f227e6d3627d81868ff751b17abf04f300f00a5.camel__40239.0670192958$1571407506$gmane$org@runbox.com> Message-ID: On Sat, 2019-10-19 at 17:20 +0200, Patrick Brunschwig wrote: > Jeff Allen via Gnupg-users wrote on 18.10.2019 16:02: > [...] > > My take on your original explanation of the reason for Enigmail's > > pending demise is that a changed Thunderbird plug-in scheme makes > > it > > more efficient to build Enigmail functionality into the MUA. > > That's only the 2nd half of the explanation. 1st and foremost, the > changed plugin scheme comes along with a completely new API (that > does > not even exist completely by now). This would require me to rewrite > almost all of Enigmail from scratch. I don't have enough free time > for > doing that, nor would I be interested in it. This, and nothing else, > was > initially the reason why we started the discussion with the > Thunderbird > team. I understand not wanting to rewrite Enigmail from scratch using a new API. If you have neither the time nor the desire to do it, I'm glad the Thunderbird team is willing to take over. My concern is how OpenPGP support is to be implemented. IIRC, you stated that it is too soon to know how much of Enigmail's functionality will be included. To me that is less important than how much of GnuPG's functionality will be incorporated. I can live without Enigmail's key manager and per- recipient rules if there is smartcard support and the ability to encrypt to multiple keys and to keys without a UID that matches the recipient's email address. If Thunderbird uses another OpenPGP library instead of calling GnuPG, I suspect some of those capabilites will vanish. > > > Why not stick with that and focus on what has made Enigmail > > successful? > > What is the reason in your eyes that made Enigmail successful? > Enigmail enabled a popular cross-platform email client to interface with GnuPG with all its capabilities. I've been trying out Evolution for the past few days. It doesn't have the special features Enigmail provides, but it does support GPG-encrypted email. It uses the keys on my Yubikey and aliases in my gpg.conf group lines. It is quite similar to using the earliest versions of Enigmail. Evolution's main limitation is that it is Linux only, not cross-platform. Windows and Mac users are out of luck. Jeff Allen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: This is a digitally signed message part URL: From look at my.amazin.horse Sun Oct 20 17:11:14 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sun, 20 Oct 2019 17:11:14 +0200 Subject: FAQ: seeking consensus In-Reply-To: <20191019204643.ZeeO7%steffen@sdaoden.eu> References: <20191019204643.ZeeO7%steffen@sdaoden.eu> <20191018181224.sGL2m%steffen@sdaoden.eu> Message-ID: <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse> > Especially if the key is shipped alongside the message already Are you sure that it is though? Seems to me you're giving out ill-informed advice here. - V From oub at mat.ucm.es Sun Oct 20 16:20:41 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Sun, 20 Oct 2019 17:20:41 +0300 Subject: a new free smime service, but... Message-ID: <87a79vsdl2.fsf@mat.ucm.es> Hi I just found that https://extrassl.actalis.it/portal/uapub/doProcess Provides a free smime certificate. However the process is strange. Usually in comodo, I generated the certificate with my browser, received an email with a link, which I had to open with the browser I applied the certificate. But this time not, I just obtained a pfx file which I could import, but does somebody know whether there is a security breach, the way this certificate was generated? Thanks Uwe Brauer From oub at mat.ucm.es Sun Oct 20 16:24:45 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Sun, 20 Oct 2019 17:24:45 +0300 Subject: a new free smime service, but... Message-ID: <8736fnsdea.fsf@mat.ucm.es> Hi I just found that https://extrassl.actalis.it/portal/uapub/doProcess Provides a free smime certificate. However the process is strange. Usually in comodo, I generated the certificate with my browser, received an email with a link, which I had to open with the browser I applied the certificate. But this time not, I just obtained a pfx file which I could import, but does somebody know whether there is a security breach, the way this certificate was generated? Thanks Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5025 bytes Desc: not available URL: From abbot at monksofcool.net Mon Oct 21 01:45:05 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Mon, 21 Oct 2019 01:45:05 +0200 Subject: a new free smime service, but... In-Reply-To: <8736fnsdea.fsf@mat.ucm.es> References: <8736fnsdea.fsf@mat.ucm.es> Message-ID: <875zkj3rsu.fsf@wedjat.horus-it.com> * Uwe Brauer via Gnupg-users: > I just obtained a pfx file which I could import, but does somebody > know whether there is a security breach, the way this certificate was > generated? Any process in which I do not create my private key, or in which a third party asks me to provide them with my private key, is a process I would refuse participating in. -Ralph From rjh at sixdemonbag.org Mon Oct 21 07:09:17 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 21 Oct 2019 01:09:17 -0400 Subject: FAQ change Message-ID: Due to Yahoo! Groups closing, the PGPNET mailing list has moved to groups.io; the FAQ has been updated with the change. Nobody objected to this, so it seems like a safe change. Due to a lack of any consensus for how the existing text should change, I've made no other edits at this time. This is a problem for us, because we need to figure out whether we wish to continue advocating SKS and how we ought adjust the RSA-2K language in the FAQ in light of the fact we currently default to -3K and will soon move to ECC. From markr at signal100.com Mon Oct 21 08:21:15 2019 From: markr at signal100.com (Mark Rousell) Date: Mon, 21 Oct 2019 07:21:15 +0100 Subject: FAQ change In-Reply-To: References: Message-ID: <5DAD4E5B.1030709@signal100.com> On 21/10/2019 06:09, Robert J. Hansen wrote: > Due to Yahoo! Groups closing I know it doesn't really matter here and now but Yahoo Groups is not closing. It's only the ancillary services that are being deleted. Yahoo Groups continues in service as a very basic mail list service (with no archive), i.e. the core service continues as it does now. (Yes, I can well imagine that the death of the Yahoo Groups mail list service could well happen soon but it has not been announced as yet). Reference: https://help.yahoo.com/kb/groups/SLN31010.html -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at binarus.de Mon Oct 21 11:42:45 2019 From: lists at binarus.de (Binarus) Date: Mon, 21 Oct 2019 11:42:45 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> <6e551bbd-21ba-a0f8-58ef-fc8567267d13@enigmail.net> <2f227e6d3627d81868ff751b17abf04f300f00a5.camel__40239.0670192958$1571407506$gmane$org@runbox.com> Message-ID: <1cfd55e9-8864-629d-9c3f-4e25dc3704cf@binarus.de> On 19.10.2019 17:20, Patrick Brunschwig wrote: > >> Why not stick with that and focus on what has made Enigmail >> successful? > What is the reason in your eyes that made Enigmail successful? > It is the ingenious mixture of integration / ease-of-use on one hand (setting it up (normally) is a no-brainer, including key generation and key upload, it allows for per-recipient rules, it provides a nice GUI for a task which actually is complex, it allows subject encryption, it allows using hardware tokens, it provides PGP/MIME and PGP/inline, and it integrates fantastically; heck, the PGP settings even are integrated into the account settings, exactly where they belong!) and on the other hand the unlimited possibilities of GnuPG (command line, configuration). Last, but not least, we must not forget security issues. Implementing PGP correctly is a hairy task, given the long history of security problems in different implementations. Werner's implementation has an excellent reputation, and it's the only one I personally trust completely. It is exactly the division of tasks which may have contributed to Enigmail's success more than one would imagine. After all, email encryption users do care about the underlying engine. We all know what we would have to expect if the TB team would rewrite the thing itself (which you have ruled out) or would use some library which hasn't been tested as rigorously as GnuPG. Actually, the Enigmail / GnuPG duo is one of the best examples of how different software parts could work together, thus increasing the prevalence of both parts by magnitudes, pushing a technique which the world really needs, and making it usable for the masses. Enigmail / GnuPG is by fare more than its sum. Each of the above reasons has made Enigmail such successful (and GnuPG, or course). Regards, Binarus From rjh at sixdemonbag.org Mon Oct 21 11:57:54 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 21 Oct 2019 05:57:54 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <1cfd55e9-8864-629d-9c3f-4e25dc3704cf@binarus.de> References: <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> <6e551bbd-21ba-a0f8-58ef-fc8567267d13@enigmail.net> <2f227e6d3627d81868ff751b17abf04f300f00a5.camel__40239.0670192958$1571407506$gmane$org@runbox.com> <1cfd55e9-8864-629d-9c3f-4e25dc3704cf@binarus.de> Message-ID: > Actually, the Enigmail / GnuPG duo is one of the best examples of how > different software parts could work together, thus increasing the > prevalence of both parts by magnitudes, pushing a technique which the > world really needs, and making it usable for the masses. Enigmail / > GnuPG is by fare more than its sum. And at the same time, less. Remember what Efail showed us: that the interface between GnuPG and clients calling it is remarkably subtle and prone to misinterpretation. It isn't just Enigmail which got bit by this, either: a *lot* of email clients got hit. GnuPG has steadfastly refused to create an OpenPGP library programmers can use directly, on the grounds that security is improved by adding process separation between the application process and the GnuPG process. There's a lot to be said for this argument. There's a lot to be said for the counterargument: that the additional complexity involved in communicating across a process boundary turns it into a false savings. I'm not sure which one I believe, myself. From mgorny at gentoo.org Mon Oct 21 15:36:54 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Mon, 21 Oct 2019 15:36:54 +0200 Subject: Using WKD via http_proxy without DNS server available Message-ID: <998a1ddf9560b4d0e12dcbb7619e18d73039a534.camel@gentoo.org> Hello, We received a report from one of our users who was unable to get GnuPG to fetch keys from behind a HTTP proxy [1]. From our investigation, it seems that GnuPG does not even try to use the proxy if the system does not have a DNS server configured. In particular, the log posted at [2] states: 2019-10-17 16:28:05 dirmngr[17549.6] DBG: chan_6 <- WKD_GET -- infrastructure at gentoo.org 2019-10-17 16:28:05 dirmngr[17549.6] DBG: dns: libdns initialized 2019-10-17 16:28:05 dirmngr[17549.6] DBG: dns: resolve_dns_name(openpgpkey.gentoo.org): Server indicated a failure 2019-10-17 16:28:05 dirmngr[17549.6] DBG: dns: getsrv(_openpgpkey._tcp.gentoo.org): Server indicated a failure 2019-10-17 16:28:05 dirmngr[17549.6] command 'WKD_GET' failed: Server indicated a failure 2019-10-17 16:28:05 dirmngr[17549.6] DBG: chan_6 -> ERR 219 Server indicated a failure 2019-10-17 16:28:05 dirmngr[17549.6] DBG: chan_6 <- BYE 2019-10-17 16:28:05 dirmngr[17549.6] DBG: chan_6 -> OK closing connection 2019-10-17 16:28:05 dirmngr[17549.6] handler for fd 6 terminated FWICS the problem is that dirmngr aborts immediately upon getting DNS error. Could it be changed to proceed as if no DNS records were received, and attempt to perform the request via proxy? TIA. [1] https://bugs.gentoo.org/661376 [2] https://bugs.gentoo.org/661376#c31 -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From steffen at sdaoden.eu Mon Oct 21 18:09:08 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 21 Oct 2019 18:09:08 +0200 Subject: FAQ: seeking consensus In-Reply-To: <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse> References: <20191019204643.ZeeO7%steffen@sdaoden.eu> <20191018181224.sGL2m%steffen@sdaoden.eu> <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse> Message-ID: <20191021160908.4_HGk%steffen@sdaoden.eu> Vincent Breitmoser wrote in <2UJQOP6NMJE80.2FS52GC36TCEU at my.amazin.horse>: | |> Especially if the key is shipped alongside the message already | |Are you sure that it is though? Seems to me you're giving out ill-informed |advice here. Bad advice of mine yes, PGP does not do it the way S/MIME does it. Sorry, this was not truly intended, i am more used to CMS and S/MIME, it just came "naturally" out of me. Side-channel free, so to say ;} But you could send a signed message with the public key attached (as application/pgp-keys even?) to the person you want to henceforth communicate encrypted and/or signed. You need some kind of web of trust to make this fly, however. But it would make it clear that you have the private counterpart. I do stand to my opinion on the Autocrypt header beside that. I think the OpenPGP: header with a reference to safe transport for fetching possibilities is more kind and social, and safer, too. | - V --End of <2UJQOP6NMJE80.2FS52GC36TCEU at my.amazin.horse> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Mon Oct 21 18:32:30 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 21 Oct 2019 18:32:30 +0200 Subject: FAQ: seeking consensus In-Reply-To: <20191021160908.4_HGk%steffen@sdaoden.eu> References: <20191019204643.ZeeO7%steffen@sdaoden.eu> <20191018181224.sGL2m%steffen@sdaoden.eu> <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse> <20191021160908.4_HGk%steffen@sdaoden.eu> Message-ID: <20191021163230.3sJoi%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20191021160908.4_HGk%steffen at sdaoden.eu>: 'Just want to add that the DKIM i refer to in my first message is in my eyes not a solution but a desastrous demolition ball of the mail standard, and as such hatred by me, and the reply-to: that was pointing to Tony Lane's real address is gone if one does not answer him as a primary and at first glance. To: Vincent Breitmoser Cc: Tony Lane via Gnupg-users Brain damaged that too. And i wonder how many archives will be mutilated and soiled. What will the next generation think, definetely not the same that "we" do when we look at messages from the 80s, for example. That is the worst business cr.p in a long time. (And i apologise shall some g's be missing, my six month old Lenovo IdeaPad 530S has a keyboard defect; for now i use a Mode_switch overfay for f, but it's kinda sick.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Mon Oct 21 18:55:17 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 21 Oct 2019 18:55:17 +0200 Subject: FAQ: seeking consensus In-Reply-To: <20191021160908.4_HGk%steffen@sdaoden.eu> References: <20191019204643.ZeeO7%steffen@sdaoden.eu> <20191018181224.sGL2m%steffen@sdaoden.eu> <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse> <20191021160908.4_HGk%steffen@sdaoden.eu> Message-ID: <20191021165517.adZH0%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20191021160908.4_HGk%steffen at sdaoden.eu>: |Vincent Breitmoser wrote in <2UJQOP6NMJE80.2FS52GC36TCEU at my.amazin.horse>: ||> Especially if the key is shipped alongside the message already || ||Are you sure that it is though? Seems to me you're giving out ill-informed ||advice here. | |Bad advice of mine yes, PGP does not do it the way S/MIME does it. ... |But you could send a signed message with the public key attached |(as application/pgp-keys even?) to the person you want to |henceforth communicate encrypted and/or signed. You need some |kind of web of trust to make this fly, however. But it would |make it clear that you have the private counterpart. Ok, that "clear" is only true if you then just send an encrypted messae right afterwards. But that should be it, or am i confused? I would say that is not an effort too much to gain safe communication when it is desired. And then there are other ways of fetching keys, as long as there are keyservers which one can use. Thanks for the sks pool is due at that time. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From guru at unixarea.de Mon Oct 21 19:32:48 2019 From: guru at unixarea.de (Matthias Apitz) Date: Mon, 21 Oct 2019 19:32:48 +0200 Subject: gpg: There is no assurance this key belongs to the named user Message-ID: <20191021173248.GA3634@c720-r342378> Hello, I wanted to insert a new password into my password store, but I can't do so anymore. It says: $ pass insert -m web/test3 Enter contents of web/test3 and press Ctrl+D when finished: gpg: 61F1ECB625C9A6C3: There is no assurance this key belongs to the named user gpg: [stdin]: encryption failed: Unusable public key Password encryption aborted. I can decrypt fine anything in the password store: $ gpg2 -d ~/.password-store/web/test2.gpg gpg: encrypted with 4096-bit RSA key, ID 61F1ECB625C9A6C3, created 2017-05-14 "Matthias Apitz (GnuPG CCID) " 4711 0815 but encryption seems to be the problem: $ gpg2 -ea -r "Matthias Apitz (GnuPG CCID) " file gpg: 61F1ECB625C9A6C3: There is no assurance this key belongs to the named user sub rsa4096/61F1ECB625C9A6C3 2017-05-14 Matthias Apitz (GnuPG CCID) Primary key fingerprint: 5E69 FBAC 1618 562C B3CB FBC1 47CC F7E4 76FE 9D11 Subkey fingerprint: EB62 00DA 13A1 9E80 679B 1A13 61F1 ECB6 25C9 A6C3 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) What might be the problem in my $GNUPGHOME: $ ls -l $GNUPGHOME total 456 srwx------ 1 guru wheel 0 Oct 21 18:16 S.gpg-agent srwx------ 1 guru wheel 0 Oct 21 18:16 S.gpg-agent.browser srwx------ 1 guru wheel 0 Oct 21 18:16 S.gpg-agent.extra srwx------ 1 guru wheel 0 Oct 21 18:16 S.gpg-agent.ssh srwx------ 1 guru wheel 0 Oct 21 18:16 S.scdaemon drwx------ 2 guru wheel 1024 Sep 21 10:08 crls.d -rw------- 1 guru wheel 2649 May 12 2017 dirmngr.conf -rw-r--r-- 1 guru wheel 95 Jan 1 2019 gpg-agent.conf -rw------- 1 guru wheel 5191 May 12 2017 gpg.conf drwx------ 2 guru wheel 512 May 14 2017 openpgp-revocs.d drwx------ 2 guru wheel 512 May 14 2017 private-keys-v1.d -rw------- 1 guru wheel 38835 Oct 11 14:02 pubring.gpg -rw------- 1 guru wheel 38835 Oct 11 14:02 pubring.gpg~ -rw------- 1 guru wheel 159155 Sep 30 16:46 pubring.kbx -rw------- 1 guru wheel 157316 Sep 21 10:07 pubring.kbx~ -rw------- 1 guru wheel 600 Oct 5 16:57 random_seed -rw-r--r-- 1 guru wheel 7 Oct 21 19:01 reader_0.status -rwxr-xr-x 1 guru wheel 3386 Mar 15 2018 scd-event -rw-r--r-- 1 guru wheel 123 Jan 5 2019 scdaemon.conf -rw-r--r-- 1 guru wheel 141 Mar 13 2018 scdaemon.conf.away -rw------- 1 guru wheel 0 Dec 28 2017 secring.gpg -r-------- 1 guru wheel 1865 May 14 2017 sk_61F1ECB625C9A6C3.gpg -rw-r----- 1 guru wheel 676 May 15 2017 sshcontrol -rw------- 1 guru wheel 1280 Oct 11 14:02 trustdb.gpg -rw-r----- 1 guru wheel 1900 Jul 22 21:52 trustlist.txt I have enough older backups of this part of my $HOME, but would like to understand what is missing or damaged, and how it happened, and how to fix it. Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From guru at unixarea.de Mon Oct 21 20:38:04 2019 From: guru at unixarea.de (Matthias Apitz) Date: Mon, 21 Oct 2019 20:38:04 +0200 Subject: gpg: There is no assurance this key belongs to the named user In-Reply-To: <20191021173248.GA3634@c720-r342378> References: <20191021173248.GA3634@c720-r342378> Message-ID: <20191021183803.GA5409@c720-r342378> El d?a lunes, octubre 21, 2019 a las 07:32:48p. m. +0200, Matthias Apitz escribi?: > > Hello, > > I wanted to insert a new password into my password store, but I can't do > so anymore. It says: > > $ pass insert -m web/test3 > Enter contents of web/test3 and press Ctrl+D when finished: > > gpg: 61F1ECB625C9A6C3: There is no assurance this key belongs to the named user > gpg: [stdin]: encryption failed: Unusable public key > Password encryption aborted. The culprit was this file: $ ls -l ~/.gnupg-ccid/trustdb* -rw------- 1 guru wheel 1280 23 may. 2017 /home/guru/.gnupg-ccid/trustdb.gpg -rw------- 1 guru wheel 1280 11 oct. 14:02 /home/guru/.gnupg-ccid/trustdb.gpg.20191011 after renaming it and restoring the previous version (not modified for ages) of trustdb.gpg all is fine again. What caused the change on October 11 remains unclear so far. matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php From rjh at sixdemonbag.org Mon Oct 21 21:11:50 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 21 Oct 2019 15:11:50 -0400 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <20191021144337.GA8110@pops-mintonw10.globe.nemgint.com> References: <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> <6e551bbd-21ba-a0f8-58ef-fc8567267d13@enigmail.net> <2f227e6d3627d81868ff751b17abf04f300f00a5.camel__40239.0670192958$1571407506$gmane$org@runbox.com> <1cfd55e9-8864-629d-9c3f-4e25dc3704cf@binarus.de> <20191021144337.GA8110@pops-mintonw10.globe.nemgint.com> Message-ID: <2564b434-9837-00fe-9033-fc69221e1a6a@sixdemonbag.org> >> GnuPG has steadfastly refused to create an OpenPGP library programmers >> can use directly, > > I was under the impression that gpgme is just such a library. It is not. Under the hood, GPGME works by launching an entirely new process and directing it via interprocess communication. Hopefully this puts the rest of my paragraph in perspective: "... on the grounds that security is improved by adding process separation between the application process and the GnuPG process. There's a lot to be said for this argument. There's a lot to be said for the counterargument: that the additional complexity involved in communicating across a process boundary turns it into a false savings." Regardless of whether you interface with GnuPG directly (as Enigmail does) or through a library (as GPGME-using applications do), you're still running GnuPG in a separate process and communicating across a process boundary. From look at my.amazin.horse Mon Oct 21 21:39:03 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Mon, 21 Oct 2019 21:39:03 +0200 Subject: Future OpenPGP Support in Thunderbird In-Reply-To: <1cfd55e9-8864-629d-9c3f-4e25dc3704cf@binarus.de> References: <1cfd55e9-8864-629d-9c3f-4e25dc3704cf@binarus.de> <875zkvrvvo.fsf@vps.thesusis.net> <2ded34ef-dd7c-2f76-6022-88dc406b9b5d@sixdemonbag.org> <77631f89-8efe-0a3e-d52d-6699d22c6f02__6580.46547775797$1570876493$gmane$org@cation.de> <800a8fdf-37d2-9bf4-113b-e6f46a839ba7@runbox.com> <41d728fd-b951-874a-2665-2022bc6e4dfb__19811.6837231041$1571215802$gmane$org@binarus.de> <6e551bbd-21ba-a0f8-58ef-fc8567267d13@enigmail.net> <2f227e6d3627d81868ff751b17abf04f300f00a5.camel__40239.0670192958$1571407506$gmane$org@runbox.com> Message-ID: <29UOY4LB1WLJP.2IBHLHWRHNMCJ@my.amazin.horse> > Werner's implementation has an excellent reputation, and it's the only one > I personally trust completely. You state this so matter-of-factly, I feel compelled to point out that among cryptographers, libgcrypt's reputation is not all that great... https://twitter.com/ciphergoth/status/1179959883589771265 - V From sac at 300baud.de Mon Oct 21 22:59:57 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 21 Oct 2019 22:59:57 +0200 Subject: Help needed - for a binary to words encoder/decoder for GnuPG Message-ID: <20191021225957.00007581.sac@300baud.de> Hi all, I was wondering if native English speakers can help me out in finding 'the right' 5 letter words which can be used in an binary to words encoder/decoder, which then can be used with GnuPG encrypted binary files, so that these (preferably small binary blobs) messages can then be send over telephone, radio or as letter/fax. I already contacted my Golang programmer who wrote me yesterday such an encoder/decoder and I have already created a dictionary with German 5 letter words, which are IMHO easy to speak and they contain no 'offensive' etc. words. The encoder uses for every byte combination [0-255] a single 5 letter word. For sure, this is not so effective as codegroups[1] but IMHO faster to speak and to write down. Here is a very small GnuPG symmetrically encrypted message, run through the encoder: Leser Aroma Algen Angel Album Ahorn Fasan Folie Geste Insel Kreis Umzug Xenia Katze Rille Sinus Gummi Adler Lende Torte Mappe Balsa Sorte Album Insel Venus Quote Lampe Onkel Sinus Laube Anzug Heike Hitze Lager Knauf Gitta Mensa Hitze Haube Wonne Ruder Maler Ampel Mulde Platz Alina Alina Eimer Hecht Blatt Biene Nebel Kraut Erbse Zweig Stadt Zweig Natur Stoff Fleck Pferd Sinus Pudel Wange Wagen Index Leser Teich Pferd Album Seide Tempo Pokal Couch Dauer Nadel Knopf Nager Suppe Boden Anton Ziege Musik Platz Serie Geist Xenia Lurch Platz Sirup Gleis Felge Musik Platz Henne Adler Dogge Kugel Forum Salto Gabel What I need now is kind folks looking here at the 'alpha' wordlist: https://github.com/dwyl/english-words and sieve out with this small Python program, or something else |import fileinput |N = 5 |for line in fileinput.input(): | for word in line.split(): | if len(word) == N: | print word 5 letter words and then manually select the best ones, which native English speakers could easily listen to and write down. Once I have the list I will then create the English version of the software and publish it, along with the German version, on my keybase page. [1] https://www.fourmilab.ch/codegroup/ Best regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From 2017-r3sgs86x8e-lists-groups at riseup.net Tue Oct 22 01:40:56 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Tue, 22 Oct 2019 00:40:56 +0100 Subject: a new free smime service, but... In-Reply-To: <87a79vsdl2.fsf@mat.ucm.es> References: <87a79vsdl2.fsf@mat.ucm.es> Message-ID: <1171562612.20191022004056@my_localhost_AR> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 20 October 2019 at 3:20:41 PM, in , Uwe Brauer via Gnupg-users wrote:- > I just found that > https://extrassl.actalis.it/portal/uapub/doProcess > Provides a free smime certificate. [...] > does somebody know whether there is a security > breach, the way this > certificate was generated? I'm no expert but their Certificate Policy reads to me that the private key is compromised right from the start. I think usually the keys are generated on the subscriber's device and only the public key goes to the CA to be certified. https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx 3.2.2 Proving possession of private key The private cryptographic key corresponding to the public key within the certificate is generated by the CA (with a suitable algorithm, size, etc.) and subsequently sent to the subscriberin PKCS#12 for-mat[PFX], via email, thereby insuring that the subscriber does possess the private key.The password needed to import the PKCS#12 file isprovided to the subscriber out-of-band (via web), therefore protecting it from unwanted disclosure to third parties. The CA does not retain such pass-word, so that the legitimate subscriber ?assuming that he/she keeps such password confidential ?remains the only person able to import the PKCS#12. And 4.1Certificate Application, Processing and Issuance To apply for a certificate pursuant to this CP, after accepting the quote, the requestor shall fill in and submit aweb-basedrequest formto be found on the CA web site.Before the requestor can actually submit the certificate request form to the CA, he/she must read and accept this Certificate Policy and the Terms & Conditions; both documents are made available for download in the same web form. The requestor?s acceptance is expressed by ?point & click?, as allowed by Italian and European legislation on distance contracts. Furthermore, before the certificate request is accepted, the CA shall perform I&A according to ?3.2.Upon submission of the certificate request form, the CA shall issue the certificateand send this latter to the Subscriber via email.The certificate is sent to the Subscriber requestor together with the corresponding private key, both bundled into a PKCS#12 file[PFX]. The password needed to decipher the PKCS#12 file is shown to the requestor in the browser, at the end of the certificate request procedure. It is up to the Subscriber to keep that password confidential and protect it from unwanted loss - -- Best regards MFPA The cure for anything is salt water - sweat, tears, or the sea. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXa5Apl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +hLrAQDX3kiS9p18mUhVAnRBKf7feFGwxuY5AJR4sDXLNLIvaAD9FMxw2WwwSxSf oUu2nNF725xRn2Ntz32fWx1LwrPWpwyJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXa5Apl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/71GD/4kRUTdsHkJzBgmNue/KY9DEw5S +LYPZU01uI3f4x+x5ECbXUhb5SmBiENKshhH1OcrGiZAV974scCJF2sjnZUfjHTX IzXVbTKDI51WF1osGcLaHlrykNJ7HoV+qoZXrIUGts8KUipfUqqC9Zq7ZMHlDt/U vjoUQxO9Akj7mBat4nWHO0f2bydULyxGwyLwdOKj3P/BoWQyG6eqHODr9iTceFnM KZY6/Nabc9GO9HIRLQ48vMj+ElJNDefhyjg7P14GwGYRdzTxm1WaLCZNnz5aCfKo rtRDvP6l/KiTTwezkIoBy3/YfwYYXlrJe7aklnhJVLnKGW+gpQrD2MYUztu+9r0J doWEQnk8J6jIX47LaVC5KKoopD0ZSv4FGCSCRioqefVMQttSm5uPqim1zSZFNJBA KIPXMlNbMTpoMvXjWGyYhEhkyg2GJeJeq84Qh9+D2SNCzglO7R1PCR7p/+JAX/Mi CUG4s8MzRFH/9z0fRYXjrxxAX/aDX7hzInkw9Srw1L4n7JRJ5VQ/BO/wGGFFwmcq uaJH4MFINSp6OgUppojGEGJaSLUsdGHVDxcmJMOg1047rjrf78aT1qhK6twSvMpv aRtjZ/NJQDZt3eTdRVcb3aLvYzuha6A/mnSgH8KtrSlBZWRtRZtF+dEnP8o97sHN hRogUjEPkCqkgFWzag== =BJGA -----END PGP SIGNATURE----- From 2017-r3sgs86x8e-lists-groups at riseup.net Tue Oct 22 01:41:10 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Tue, 22 Oct 2019 00:41:10 +0100 Subject: a new free smime service, but... In-Reply-To: <87a79vsdl2.fsf@mat.ucm.es> References: <87a79vsdl2.fsf@mat.ucm.es> Message-ID: <12763564.20191022004110@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 20 October 2019 at 3:20:41 PM, in , Uwe Brauer via Gnupg-users wrote:- > I just found that > https://extrassl.actalis.it/portal/uapub/doProcess > Provides a free smime certificate. [...] > does somebody know whether there is a security > breach, the way this > certificate was generated? I'm no expert but their Certificate Policy reads to me that the private key is compromised right from the start. I think usually the keys are generated on the subscriber's device and only the public key goes to the CA to be certified. https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx 3.2.2 Proving possession of private key The private cryptographic key corresponding to the public key within the certificate is generated by the CA (with a suitable algorithm, size, etc.) and subsequently sent to the subscriberin PKCS#12 for-mat[PFX], via email, thereby insuring that the subscriber does possess the private key.The password needed to import the PKCS#12 file isprovided to the subscriber out-of-band (via web), therefore protecting it from unwanted disclosure to third parties. The CA does not retain such pass-word, so that the legitimate subscriber ?assuming that he/she keeps such password confidential ?remains the only person able to import the PKCS#12. And 4.1Certificate Application, Processing and Issuance To apply for a certificate pursuant to this CP, after accepting the quote, the requestor shall fill in and submit aweb-basedrequest formto be found on the CA web site.Before the requestor can actually submit the certificate request form to the CA, he/she must read and accept this Certificate Policy and the Terms & Conditions; both documents are made available for download in the same web form. The requestor?s acceptance is expressed by ?point & click?, as allowed by Italian and European legislation on distance contracts. Furthermore, before the certificate request is accepted, the CA shall perform I&A according to ?3.2.Upon submission of the certificate request form, the CA shall issue the certificateand send this latter to the Subscriber via email.The certificate is sent to the Subscriber requestor together with the corresponding private key, both bundled into a PKCS#12 file[PFX]. The password needed to decipher the PKCS#12 file is shown to the requestor in the browser, at the end of the certificate request procedure. It is up to the Subscriber to keep that password confidential and protect it from unwanted loss - -- Best regards MFPA The cure for anything is salt water - sweat, tears, or the sea. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXa5CFl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +v+iAQCE1htzI++iZGPw3aWSdvYOtStbg/+RCOq/55iUo4AkXwD+Mpeawj+TjNNK Kj7Bp9ciiGgtlsxqPeVtls8tMSNFDgaJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXa5CFl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/+xoD/9rTd1kVPIlVjk9Worhv07MxsJ1 jLfWWifiLApgVG08JhOdjOSY8T3W4Ew/HbuvfS4/Xc1keGja7ZgEw7cSQf6LZxSz GWH55I3y6zzh5B0JYqu+DWnsRjU3oxQhwWW2rwJFXEiEDBraerA28/8XO3CXBctm 0jjOAAA0VEfwJEJda7W32PqcSqfL+iRcoZc1vC3o6YjOdvpK/tHDNPL4KzAqt+rV N4IraP1N/3oGKGT303G1U6eAR6Pvmsd7YSb0yLFKUVIsYzYW7GuhTiX65QvHC3ov ss1vVDjTPxV8a7+0B1QuNlFRBpdrDAdG9t2ecblG5FcIeDrEaigabdN9QQG7RWtr KPKv2E47bMUGgC3wqgeCO7qiCf6gSIdrI3aEi7Jvfpdu0vq4myf8ysuRL1yywaWJ OD/taEJ50SNTwT38qWq2KWDEWo4jupPqqHfcWNLFG8ARa0mVu84GwkM7bB1bDsaF DQKKukXsywq2EhE4CHgjWq/0jUbr6oDjxu7PIwxTdo7f/NWdOxqk9GPDMkIIsut/ fej/L6Rm0NgJfXmvWJAQ9ghCwGE3A+MoOoCWS30Czqz5+P3GpKpLyv54QEc1LrRz CF8VNvEhMyRPlmlnns6QLvZmoYspXkygRho8xAYIqWQ/fS/ZufkS6FS82TY58fvf rBJ7qMIUewF91bEIEQ== =uB21 -----END PGP SIGNATURE----- From 2017-r3sgs86x8e-lists-groups at riseup.net Tue Oct 22 01:59:02 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Tue, 22 Oct 2019 00:59:02 +0100 Subject: FAQ change In-Reply-To: References: Message-ID: <459834023.20191022005902@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 21 October 2019 at 6:09:17 AM, in , Robert J. Hansen wrote:- > Due to Yahoo! Groups closing, the PGPNET mailing list > has moved to > groups.io; I thought PGPNET's move was prompted by degraded performance on the yahoogroups platform, which lead some group members to look around and find something that worked better. - -- Best regards MFPA It is not necessary to have enemies if you go out of your way to make friends hate you. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXa5GR18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +sxNAQC2r0cGSgs/GEy2e3ALVc2Uj2VPjCJpkS69x9f60ry0GwEApHOw99gHDT8i OTsAIubrd/l7L6jVmkQZAK5K6PvtvwiJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXa5GR18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/12LEACpnzblfWb95Ih+Nv2tz+70408Q Oa8FEIRd0Dfxa83YcdM7prwCrU0xDPinEOslDU7WkUs/QqUCkX5a7NmWb+O64/Of b3MqEQa6FlKH5xY0XEtfR78Ldv5p17MumJVSC6PJFtDzN1UB0MK239YNAfizcBIF EjravY6PCqcQ0zpPwutI+yZAeOHyuDCU5Hb1Cxw+rg+rTCz84fQm+wg9o3/idj9b hZwyHyoFwoI5PHw1V8I/sxEDSn7jFp84YH3eMW/PyOadan/V8t3c7ySB9/7HEq57 ZEo+AJRLEa5KJJFxw75DqcraOJC1PYeDio13dbSwK5ygiXEyzNT9PKZ+uJ0DQFS0 0vKm7w7MpAJU2Ps9x39WOLjyvpoXFmiDrtceVzmyPCpEsU04+IzU8iRAbqthUryf 1JJgKUIGWXkBv7PNKEi/vzmHbsdNBCx9V9bQvVltT+EDxOtGECLp0Mt89RlXNCsd WbFWDw3J9Yvvd9B5W3V6jJUs2QEmFxOD3VUcCTGEU7vC7JC8xhJftMO7svhxERUw 4SojXLI01fDtWFL8tXqKN9MLLc7jjrCQiQEkRBV4qySLP1Yy7KrN8XPLMTAveE5b 5Bvdiw+7n+nUhINX4GI9p1ALo0fhwNMogmBQ539S3+3SDeMF+ItxLcAyvOzTkoA/ kQdejA/zpKJCURk6vg== =Y9v3 -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Oct 22 03:21:42 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 21 Oct 2019 21:21:42 -0400 Subject: FAQ change In-Reply-To: <459834023.20191022005902@my_localhost_LG> References: <459834023.20191022005902@my_localhost_LG> Message-ID: <4be44577-881f-0dc4-2dde-057ce3d31442@sixdemonbag.org> > I thought PGPNET's move was prompted by degraded performance on the > yahoogroups platform, which lead some group members to look around and > find something that worked better. What I know is this: I was asked by a PGPNET member to change the address, and the cause for the change was the imminent closure of the Yahoo! Groups version of PGPNET. That's all. Beyond that, discuss it on PGPNET, please. :) From jrallen at runbox.com Tue Oct 22 04:01:36 2019 From: jrallen at runbox.com (Jeff Allen) Date: Mon, 21 Oct 2019 22:01:36 -0400 Subject: FAQ change In-Reply-To: <459834023.20191022005902@my_localhost_LG> References: <459834023.20191022005902@my_localhost_LG> Message-ID: On Tue, 2019-10-22 at 00:59 +0100, MFPA via Gnupg-users wrote: > Hi > > On Monday 21 October 2019 at 6:09:17 AM, in > , Robert J. > Hansen wrote:- > > > Due to Yahoo! Groups closing, the PGPNET mailing list > > has moved to > > groups.io; > > I thought PGPNET's move was prompted by degraded performance on the > yahoogroups platform, which lead some group members to look around > and > find something that worked better. > It was, but that's quibbling. Yahoo! Groups performance, on the platform and as a simple mailing list relay, has been deteriorating for years. Hundreds of lists formerly hosted on Yahoo! Groups have moved to other platforms because Yahoo!'s current ownership has made it clear that the groups they inherited are not part of their corporate future. The elimination of of hosted content is just the latest manifestation. Like others, we looked around and found something that worked better. My thanks to Mr. Hansen for updating our listing. Jeff Allen, PGPNET moderator From hrohir167 at gmail.com Tue Oct 22 05:27:43 2019 From: hrohir167 at gmail.com (Fuse Hiroaki) Date: Tue, 22 Oct 2019 12:27:43 +0900 Subject: libgcrypt license Message-ID: Hello I have a question about libgcrypt license We can find following license notice Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. And I also found following commit https://github.com/gpg/libgcrypt/commit/915570db198f2cf15db5c034096a444a8a79476e#diff-c55728a8e1162a431e4754734d27a041 This mean that only dumpsexp is GPLv3? BR, -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at hebbeker.info Tue Oct 22 06:48:44 2019 From: david at hebbeker.info (David Hebbeker) Date: Tue, 22 Oct 2019 06:48:44 +0200 Subject: are angle brackets around email address allowed for auto-key-locate? In-Reply-To: <1571250412.1920.2.camel@hebbeker.info> References: <1571171025.3191.2.camel@hebbeker.info> <87blugx4pc.fsf@wheatstone.g10code.de> <1571250412.1920.2.camel@hebbeker.info> Message-ID: <1571719724.3316.2.camel@hebbeker.info> On Wed, 2019-10-16 at 20:26 +0200, David Hebbeker wrote: > On Wed, 2019-10-16 at 14:19 +0200, Werner Koch wrote: > > On Tue, 15 Oct 2019 22:23, David Hebbeker said: > > > The manual [1] says that GnuPG can automatically retrieve keys > > > for emails in the "user at example.com" form. Does this exclude > > > emails wrapped by angle brackets like ""? > > > > That is fine. > > I have experienced a behavior I could only explain with auto-key- > locate being restricted to the pure form. I still have the problem described in my previous e-mail. Can it be that this is faulty behavior of the GnuPG? I would create a bug report at [1] so it does not get lost. Does something speak against it? David [1]: https://dev.gnupg.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From alejacortez69 at gmail.com Tue Oct 22 07:49:35 2019 From: alejacortez69 at gmail.com (alejandro Cortez) Date: Tue, 22 Oct 2019 01:49:35 -0400 Subject: Cannot decrypt from smartcard using gnupg-2.2, can from 2.0 In-Reply-To: <87imop1jwh.fsf@iwagami.gniibe.org> References: <87d0f0vu2x.fsf@jumper.gniibe.org> <87imop1jwh.fsf@iwagami.gniibe.org> Message-ID: On Tue, Oct 15, 2019 at 10:52 PM NIIBE Yutaka wrote: > Hello, > > I think that your configuration of smartcard is somehow broken. > The only thing I have been able to confirm is that gpg, at some point after 2.0.22, stopped allowing the use of the same subkey in multiple slots. As soon as I created a new signing subkey and put that one into the signing slot and the SEA subkey into the encryption slot, everything started working. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sac at 300baud.de Tue Oct 22 08:24:18 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 22 Oct 2019 08:24:18 +0200 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: References: <20191021225957.00007581.sac@300baud.de> Message-ID: <20191022082418.000049df.sac@300baud.de> Ajax wrote: > Are there enough five letter words in the word lists available at > eff.org/dice? Thanks a lot! The short list has 782 five letter words, perfect! So I will then select 256 of them which are easy (for me) to read ... :-) Best regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Tue Oct 22 18:03:13 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 22 Oct 2019 18:03:13 +0200 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: <20191022082418.000049df.sac@300baud.de> References: <20191021225957.00007581.sac@300baud.de> <20191022082418.000049df.sac@300baud.de> Message-ID: <20191022180313.00007597.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Ajax wrote: > > > Are there enough five letter words in the word lists available at > > eff.org/dice? > > Thanks a lot! The short list has 782 five letter words, perfect! > > So I will then select 256 of them which are easy (for me) to > read ... :-) O.k., I have uploaded the German version and would like to ask if ML members can test it a bit. I already did that under Win7 Pro and Win10 Pro and would like to hear if it works fine under macOS and Linux. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From guru at unixarea.de Tue Oct 22 20:18:36 2019 From: guru at unixarea.de (Matthias Apitz) Date: Tue, 22 Oct 2019 20:18:36 +0200 Subject: gpg: There is no assurance this key belongs to the named user In-Reply-To: <20191021183803.GA5409@c720-r342378> References: <20191021173248.GA3634@c720-r342378> <20191021183803.GA5409@c720-r342378> Message-ID: <20191022181836.GA3992@c720-r342378> El d?a lunes, octubre 21, 2019 a las 08:38:04p. m. +0200, Matthias Apitz escribi?: > El d?a lunes, octubre 21, 2019 a las 07:32:48p. m. +0200, Matthias Apitz escribi?: > > > > > Hello, > > > > I wanted to insert a new password into my password store, but I can't do > > so anymore. It says: > > > > $ pass insert -m web/test3 > > Enter contents of web/test3 and press Ctrl+D when finished: > > > > gpg: 61F1ECB625C9A6C3: There is no assurance this key belongs to the named user > > gpg: [stdin]: encryption failed: Unusable public key > > Password encryption aborted. > > The culprit was this file: > > $ ls -l ~/.gnupg-ccid/trustdb* > -rw------- 1 guru wheel 1280 23 may. 2017 /home/guru/.gnupg-ccid/trustdb.gpg > -rw------- 1 guru wheel 1280 11 oct. 14:02 /home/guru/.gnupg-ccid/trustdb.gpg.20191011 > > after renaming it and restoring the previous version (not modified for > ages) of trustdb.gpg all is fine again. What caused the change on > October 11 remains unclear so far. I exported both files which gives the same export: $ ls -l trustdb.gp* -rw------- 1 guru wheel 1280 23 may. 2017 trustdb.gpg -rw------- 1 guru wheel 1280 11 oct. 14:02 trustdb.gpg.20191011 $ diff trustdb.gp* Binary files trustdb.gpg and trustdb.gpg.20191011 differ $ gpg2 --trustdb-name trustdb.gpg.20191011 --export-ownertrust # List of assigned trustvalues, created Tue Oct 22 20:14:22 2019 CEST # (Use "gpg --import-ownertrust" to restore them) 5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11:6: $ gpg2 --export-ownertrust # List of assigned trustvalues, created Tue Oct 22 20:14:27 2019 CEST # (Use "gpg --import-ownertrust" to restore them) 5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11:6: What does this mean? Why gpg2 was unwilling to use the file trustdb.gpg.20191011? matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From steffen at sdaoden.eu Tue Oct 22 20:20:23 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 22 Oct 2019 20:20:23 +0200 Subject: a new free smime service, but... In-Reply-To: <1171562612.20191022004056@my_localhost_AR> References: <87a79vsdl2.fsf@mat.ucm.es> <1171562612.20191022004056@my_localhost_AR> Message-ID: <20191022182023.4RZzH%steffen@sdaoden.eu> MFPA via Gnupg-users wrote in <1171562612.20191022004056 at my_localhost_AR>: |On Sunday 20 October 2019 at 3:20:41 PM, in |, Uwe Brauer via Gnupg-users wrote:- | |> I just found that |> https://extrassl.actalis.it/portal/uapub/doProcess | |> Provides a free smime certificate. ... |> does somebody know whether there is a security |> breach, the way this |> certificate was generated? | |I'm no expert but their Certificate Policy reads to me that the |private key is compromised right from the start. I think usually the I think it is common that S/MIME and SSL certificates are delivered via PKCS12, including the private key. You then seem to extract the individual things like $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes $ # Alternatively $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes |keys are generated on the subscriber's device and only the public key |goes to the CA to be certified. This is possible via CACert.org, at least still (out of money). You create your local signing request, and the private key.pem never leaves your own box: $ openssl req -nodes -newkey rsa:4096 -keyout key.pem -out creq.pem (Ensure all email addresses of desire are included in the web form.) Unfortunate that besides Comodo there seems no other provider of free S/MIME certificates. You can only self-sign, and provide a safe transport for a certificate to compare with. Which is why PGP is so nice. |https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-polic\ |y.aspx | | 3.2.2 Proving possession of private key | | The private cryptographic key corresponding to the public key | within the certificate is generated by the CA (with a suitable | algorithm, size, etc.) and subsequently sent to the subscriberin | PKCS#12 for-mat[PFX], via email, thereby insuring that the | subscriber does possess the private key.The password needed to | import the PKCS#12 file isprovided to the subscriber out-of-band | (via web), therefore protecting it from unwanted disclosure to | third parties. The CA does not retain such pass-word, so that the | legitimate subscriber ?assuming that he/she keeps such password | confidential ?remains the only person able to import the PKCS#12. Better than nothing. Sometimes the browser is used to create thins, i have done that once for StartSSL i think it was (now defunct). I would not use this service, however, because why do they want to do it like that? They could very well just offer the one-liner and allow pasting of the signing request, then the private key would never have been exposed to anyone but the user. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From wk at gnupg.org Tue Oct 22 20:50:11 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Oct 2019 20:50:11 +0200 Subject: libgcrypt license In-Reply-To: (Fuse Hiroaki via Gnupg-users's message of "Tue, 22 Oct 2019 12:27:43 +0900") References: Message-ID: <87eez4ehss.fsf@wheatstone.g10code.de> On Tue, 22 Oct 2019 12:27, Fuse Hiroaki said: > https://github.com/gpg/libgcrypt/commit/915570db198f2cf15db5c034096a444a8a79476e#diff-c55728a8e1162a431e4754734d27a041 I don't known what you found on github, which seems to be an inofficial mirror of GnuPG (and I do not want to check that specific commit). However, dumpsexp.c is indeed under the GPLv3. There is no real reason for this and we could change the license if that really makes a difference for you. You can also distribute without that debug helper. > This mean that only dumpsexp is GPLv3? I have not checked but in case you find another GPL tool, please let us know via a feature request on our bug tracker. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From arbiel.perlacremaz at gmx.fr Tue Oct 22 16:44:15 2019 From: arbiel.perlacremaz at gmx.fr (Arbiel Perlacremaz) Date: Tue, 22 Oct 2019 16:44:15 +0200 Subject: Reading or extracting the initial file from a signed file Message-ID: An HTML attachment was scrubbed... URL: From gnupgmlusers.fwnsp at xoxy.net Tue Oct 22 17:54:38 2019 From: gnupgmlusers.fwnsp at xoxy.net (Friedhelm Waitzmann) Date: Tue, 22 Oct 2019 17:54:38 +0200 Subject: gpg on read-only filesystem In-Reply-To: <57576be4-5c15-9503-4862-b6672d91a78d@gmx.ch> References: <57576be4-5c15-9503-4862-b6672d91a78d@gmx.ch> Message-ID: <20191022155437.GB25336@kugelfisch.zuhause.test> Hello! Fourhundred Thecat: >Also, I consider it good practice to have / mounted read-only, and I >don't understand why gpg would need to open trustdb.gpg in rw mode, when >using simple operations such as gpg --verify. >gpg: Fatal: can't open '/root/.gnupg/trustdb.gpg': Operation not permitted A solution for the verify use case: Just read the manual () and use ?--no-auto-check-trustdb?. HTH Friedhelm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Digital signature URL: From codeguro at gmail.com Wed Oct 23 02:34:13 2019 From: codeguro at gmail.com (Tony Lane) Date: Tue, 22 Oct 2019 20:34:13 -0400 Subject: Reading or extracting the initial file from a signed file In-Reply-To: References: Message-ID: <957b3094-1cf3-03ba-ebed-2e332e929a6b@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/22/19 10:44 AM, Arbiel Perlacremaz wrote: > I read the gpg man page, but I haven't been able to find the appropriate commands, either to decompress the file or to extract the original file. gpg -o -d "man gpg" is your friend. -----BEGIN PGP SIGNATURE----- iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXa+gBQAKCRDo8fj9gx4T 05uuAgiJEdAoDbaXzFbExxUO+5SOTPjdmv3Ghpm1mYipPne4vtiDQumvnzzNuWmB KBbvtcBUezAc928SNR9YAoqq/O1eBAIJAXI9j7tOb+N/K1V8JTIAv++mLLU8KLR5 1BEs/O/RfCQ6kRkmsRE/ydP2fZu1Stl5HUAUzEwRAV+Ui5AoL03w91X6 =yoSb -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Wed Oct 23 03:25:15 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 22 Oct 2019 21:25:15 -0400 Subject: are angle brackets around email address allowed for auto-key-locate? In-Reply-To: <1571719724.3316.2.camel@hebbeker.info> References: <1571171025.3191.2.camel@hebbeker.info> <87blugx4pc.fsf@wheatstone.g10code.de> <1571250412.1920.2.camel@hebbeker.info> <1571719724.3316.2.camel@hebbeker.info> Message-ID: <87tv80mex0.fsf@fifthhorseman.net> On Tue 2019-10-22 06:48:44 +0200, David Hebbeker wrote: > On Wed, 2019-10-16 at 20:26 +0200, David Hebbeker wrote: >> On Wed, 2019-10-16 at 14:19 +0200, Werner Koch wrote: >> > On Tue, 15 Oct 2019 22:23, David Hebbeker said: >> > > The manual [1] says that GnuPG can automatically retrieve keys >> > > for emails in the "user at example.com" form. Does this exclude >> > > emails wrapped by angle brackets like ""? >> > >> > That is fine. >> >> I have experienced a behavior I could only explain with auto-key- >> locate being restricted to the pure form. > > I still have the problem described in my previous e-mail. Can it be > that this is faulty behavior of the GnuPG? Yes, i can confirm the same misbehavior with GnuPG 2.2.17 (though i don't think that edward-en at fsf.org is actually correctly published via WKD, so i tested with dkg at fifthhorseman.net): 130 dkg at alice:/tmp/cdtemp.pipIPp$ gpg -e -r '' foo.txt gpg: : skipped: No public key gpg: foo.txt: encryption failed: No public key 2 dkg at alice:/tmp/cdtemp.pipIPp$ gpg -e -r 'dkg at fifthhorseman.net' foo.txt gpg: removing stale lockfile (created by 29177) gpg: key F20691179038E5C6: "Daniel Kahn Gillmor " 1 new user ID gpg: key F20691179038E5C6: "Daniel Kahn Gillmor " 8 new signatures gpg: Total number processed: 1 gpg: new user IDs: 1 gpg: new signatures: 8 gpg: no ultimately trusted keys found gpg: B0A9B7B2D8D2CE47: There is no assurance this key belongs to the named user sub cv25519/B0A9B7B2D8D2CE47 2019-01-19 Daniel Kahn Gillmor Primary key fingerprint: C4BC 2DDB 38CC E964 85EB E9C2 F206 9117 9038 E5C6 Subkey fingerprint: 88DE 0083 5288 C784 E73A C940 B0A9 B7B2 D8D2 CE47 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) y 0 dkg at alice:/tmp/cdtemp.pipIPp$ > I would create a bug report at [1] so it does not get lost. Does > something speak against it? Yes, in the future, please report this sort of bug directly so that we can track the problem. i've opened https://dev.gnupg.org/T4726 now -- please add any additional information there! Thanks for the report, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 23 03:28:53 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 22 Oct 2019 21:28:53 -0400 Subject: A place for discussing WKD spec clarifications? In-Reply-To: References: <878spk7dce.fsf@fifthhorseman.net> Message-ID: <87r234meqy.fsf@fifthhorseman.net> On Thu 2019-10-17 11:08:46 +0000, Bjarni Runar Einarsson wrote: > Daniel Kahn Gillmor wrote: >> I'd be happy to set up such a tracker at (say) >> https://gitlab.com/openpgp-wg/web-key-directory/issues if folks >> are OK with it. >> >> Werner, does that sound OK to you? > > This sounds good to me, but I agree it's important Werner is > onboard. Werner, can you give some indication of whether this sounds reasonable to you? This is an important spec, and i'd like to have a place where we can keep track of implementer concerns. Thanks, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bre at pagekite.net Wed Oct 23 10:27:21 2019 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Wed, 23 Oct 2019 08:27:21 -0000 Subject: Automatically changing/removing key passphrase Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello GnuPG users! Background: I'm working a bit on Mailpile's Autocrypt support these days. Mailpile creates OpenPGP keys for its users, which are protected by a strong passphrase, but generally manages those passphrases on the user's behalf to guarantee a seamless user experience. I don't want my users to be locked in to Mailpile, and I wanted to implement the Autocrypt Setup Message (ASM) spec so users had a standardized, semi-automated way to migrate their keys from Mailpile to another mail agent. For better or worse, the ASM defines a password protection scheme for the key material which is different from a passphrase on the key itself. So when syncing the keys, I need to remove the passphrase. I cannot figure out an elegant way to do this using GnuPG or GPGME. The GPGME manual's "Changing Passphrases" section 7.5.10 states: "The backend engine will usually popup a window to ask for the old and the new passphrase. Thus this function is not useful in a server application (where passphrases are not required anyway)." I guess from the point of view of GnuPG and GPGME, Mailpile is behaving like a server application. But I would still rather not store the secret keys unprotected, so I need an automated way to manage the key's passphrase. How do I square this circle? Any hints on how to automatically remove the passphrase using gnupg without direct user interaction? A Google search showed that this is a question that comes up every now and then, but I have only seen manual procedures for resolving it. Is this perhaps a feature which should be added? Thanks in advance, - Bjarni - -- PageKite.net lets your personal computer be part of the web -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2wDukACgkQjgA3FgDP lJFCYAf/R+mKR92lZN5kaE5d81cP2oGqJ8AGuWzTulI42LubyRezoAg939OVijwo 2+sVcqL2Xk8uPBtu+gq+/ZvN31NuG1PfEE35s4+G4n4YqkLx+NC18HCffuMJ+515 unjHmrQ+ID08kbp/xQNE/jqXqFDTGUo25pGlSI4ecqZumtkK9SBEI9JSsW0jR11L N/SC9JXh2ksD2j9azYKsbj9fgDO+8Lg2vXpaWTjv+BFe1vKaDfQzGw7DSUVtzsD4 PT8HlFvWucUmhGv5A7SKUWEMG4VC7J33YjPK5KMe8TCBA+agmRw93JMiVPVUEzaw 8iFw9haK8zQawgYmC9Ja/qI9CuohyA== =Cpmt -----END PGP SIGNATURE----- From mmorfikov at gmail.com Wed Oct 23 11:51:10 2019 From: mmorfikov at gmail.com (Mikhail Morfikov) Date: Wed, 23 Oct 2019 11:51:10 +0200 Subject: Should gpg try to connect to TCP/993? Message-ID: <48cc5e58-433f-48ce-de85-958dec26325b@gmail.com> I'm filtering OUTPUT traffic on my Debian via nftables+cgroups(net_cls)+cgrulesengd, and all apps, which want to connect to the network, I have to assign some cgroups class and add a rule in the FW. The gpg binary wants TCP/443 to speak with keyservers (optionally TCP/80). I thought that's all what gpg wants to connect to the network, but it looks like it wants also TCP/993 (IMAPS). This happens when I use Thunderbird as a mail clinet + Enigmail extension, which make some use of gpg. Basically when I start Thunderbird, only it wants to connect to the TCP/993 port, but when I clear the conntrack table via `conntrack -F`, then also gpg wants to connect to that port. This is not always the case though -- it only happens when the clearing of the conntrack table is issued some time after Thunderbird has been stared (an hour or so). So it looks like the keepalive packets can play some role here. When I `lsof -i :993`, I can see some entries pointing to Thunderbird. Also nftables reports some NEW-notSYN packets destined to my machine (which is understood because the conntrack mechanism doesn't know about the established connections now,and everything that comes from the mail servers is in this NEW-notSYN state). I can see some blocked OUTPUT packets as well, and when compared src/dst ports/ips I can tell that the packets were sent by Thunderbird (they match to the `lsof` output). Also `lsof` doesn't show anything that points to gpg. When I prevent gpg from connecting to this port, I can't access my mail account in Thunderbird -- it just tries to refresh the inbox, but it just stalls. When I restart Thunderbird at this point, then everything backs to normal, and I don't see any drops in OUTPUT traffic. Could anyone explain what's going on here? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Oct 23 13:54:51 2019 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 23 Oct 2019 13:54:51 +0200 Subject: libgcrypt license In-Reply-To: <87eez4ehss.fsf@wheatstone.g10code.de> References: <87eez4ehss.fsf@wheatstone.g10code.de> Message-ID: On 22.10.2019 20:50, Werner Koch via Gnupg-users wrote: > There is no real reason > for this and we could change the license if that really makes a > difference for you. It would help me as a downstream packager at least; to the extent that otherwise we'll have to update license acceptance information in the package. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From oub at mat.ucm.es Wed Oct 23 14:38:23 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Wed, 23 Oct 2019 14:38:23 +0200 Subject: a new free smime service, but... References: <87a79vsdl2.fsf@mat.ucm.es> <12763564.20191022004110__8723.49973521835$1571701389$gmane$org@my_localhost_LG> Message-ID: <87a79r1vsw.fsf@mat.ucm.es> > Hi > On Sunday 20 October 2019 at 3:20:41 PM, in > , Uwe Brauer via Gnupg-users wrote:- > [...] > I'm no expert but their Certificate Policy reads to me that the > private key is compromised right from the start. I think usually the > keys are generated on the subscriber's device and only the public key > goes to the CA to be certified. > https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx > 3.2.2 Proving possession of private key > The private cryptographic key corresponding to the public key > within the certificate is generated by the CA (with a suitable > algorithm, size, etc.) and subsequently sent to the subscriberin > PKCS#12 for-mat[PFX], via email, thereby insuring that the > subscriber does possess the private key.The password needed to > import the PKCS#12 file isprovided to the subscriber out-of-band > (via web), therefore protecting it from unwanted disclosure to > third parties. The CA does not retain such pass-word, so that the > legitimate subscriber ?assuming that he/she keeps such password > confidential ?remains the only person able to import the PKCS#12. Oops this is really bad. I should have read this. Thanks for pointing it out. I am wondering why they do such a bizarre thing? Maybe it is easier to implement? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5025 bytes Desc: not available URL: From oub at mat.ucm.es Wed Oct 23 14:49:16 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Wed, 23 Oct 2019 14:49:16 +0200 Subject: a new free smime service, but... References: <87a79vsdl2.fsf@mat.ucm.es> <1171562612.20191022004056@my_localhost_AR> <20191022182023.4RZzH%steffen__42655.3339626238$1571768479$gmane$org@sdaoden.eu> Message-ID: <874kzz1var.fsf@mat.ucm.es> > MFPA via Gnupg-users wrote in <1171562612.20191022004056 at my_localhost_AR>: > |On Sunday 20 October 2019 at 3:20:41 PM, in > |, Uwe Brauer via Gnupg-users wrote:- > | > |> I just found that > |> https://extrassl.actalis.it/portal/uapub/doProcess > | > |> Provides a free smime certificate. > ... > |> does somebody know whether there is a security > |> breach, the way this > |> certificate was generated? > | > |I'm no expert but their Certificate Policy reads to me that the > |private key is compromised right from the start. I think usually the > I think it is common that S/MIME and SSL certificates are > delivered via PKCS12, including the private key. You then seem to > extract the individual things like I think this is a severe security breach. The private key should never leave your computer. > $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes > $ # Alternatively > $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys > $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes > |keys are generated on the subscriber's device and only the public key > |goes to the CA to be certified. > This is possible via CACert.org, at least still (out of money). > You create your local signing request, and the private key.pem never > leaves your own box: > $ openssl req -nodes -newkey rsa:4096 -keyout key.pem -out creq.pem > (Ensure all email addresses of desire are included in the web > form.) > Unfortunate that besides Comodo there seems no other provider of > free S/MIME certificates. You can only self-sign, and provide Comodo does not offer this any more. At the beginning of the year they reduced the smime cerificates validity from 1 year to 1 month, now they withdraw it all together. > a safe transport for a certificate to compare with. Which is why > PGP is so nice. Well yes sort of, but I can tell you from my own experience PGP is more for hackers while smime is not. I have convinced 6 of my friends to use smime, but only one to pgp. Self signed smime certificates are basically useless, because then you have to tell the other user either to install a root certificate or to trust the certificate, in which case smime looses its convenience (compared to pgp) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5025 bytes Desc: not available URL: From bre at pagekite.net Wed Oct 23 15:12:17 2019 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Wed, 23 Oct 2019 13:12:17 -0000 Subject: Should gpg try to connect to TCP/993? In-Reply-To: <48cc5e58-433f-48ce-de85-958dec26325b@gmail.com> References: <48cc5e58-433f-48ce-de85-958dec26325b@gmail.com> Message-ID: <9p2Nr5DGgC6gWsLFrwX4F4gbyNPm49Vwjrwxu8VG2388@mailpile> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Mikhail, What follows is an educated guess, but only a guess... Mikhail Morfikov via Gnupg-users wrote: > gpg wants to connect to the network, but it looks like it wants > also TCP/993 (IMAPS). This happens when I use Thunderbird as a > mail clinet + Enigmail extension, which make some use of gpg. ... > doesn't show anything that points to gpg. When I prevent gpg > from connecting to this port, I can't access my mail account in > Thunderbird -- it just tries to refresh the inbox, but it just > stalls. When I restart Thunderbird at this point, then > everything backs to normal, and I don't see any drops in OUTPUT > traffic. Could anyone explain what's going on here? The way processes are spawned on Unix, fork()/exec() will by default inherit open file descriptors. Thunderbird/Enigmail will fork()/exec() to launch gpg. Each active TCP/IP connection has an open file descriptor. So, if Enigmail's gpg launcher hasn't taken care to close unneeded file descriptors after fork() and before exec(), gpg will inherit the connections Thunderbird had open at the time of invocation. Since gpg doesn't actually know anything about these connections, it likely won't close them, they'll stay open (potentially even after Thunderbird has closed them, although that doesn't match all the symptoms you've described). If your firewall then sends RST packets to close connections which gpg isn't supposed to be making, it will actually be shutting down the connections Thunderbird was using and you won't be able to access your mail. (This scenario matches what you have described, but I haven't reproduced your problem to verify it is indeed the case.) Hope this helps! - Bjarni - -- PageKite.net lets your personal computer be part of the web -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2wUdYACgkQjgA3FgDP lJH11ggAk3SujXyDYqzLdDkbDksZwkdZEE5fhMPfukMGrs6/N2L08yzUxKYTx9v4 QdTY5BmUVl2sG21eUY+y90Y0YK3lpHJNrfe9Rrw5QnHXjB4B1fuzQCuUfwVv3YGt kHtj95clWgHsWWqIh5AWnt4LDk4inZ6+SVhj0k49eyea3GIelL/iJxxQ9wFjbPVY sbxiUP83qtTgKDVW98rneVS8mgJ6/d0Qf+RQFRmR3E+6RYPDo0FoNhpKGodTN4BO Ph+GuwuHBu0o7cjxdsgNdFY8v1GgcpQOtJ9gbZs5ysBeG4nrejxwK1EFbiAh+YX/ cZTfoE7/g0PJ877299r5C1uPAUTXHg== =5yoS -----END PGP SIGNATURE----- From brian at minton.name Wed Oct 23 15:20:45 2019 From: brian at minton.name (Brian Minton) Date: Wed, 23 Oct 2019 09:20:45 -0400 Subject: trying to get dirmngr to honor auto-key-retrieve Message-ID: <20191023132022.GA4638@pops-mintonw10.globe.nemgint.com> I'm trying to configure dirmngr.conf so gpg automatically retrieves keys from the keyserver when verifying a signature. In the past, this was done by gpg --keyserver-options auto-key-retrieve. The documentation for dirmngr [https://www.gnupg.org/documentation/manuals/gnupg/Dirmngr-Options.html#Dirmngr-Options] indicates that options specified after the keyserver should match the keyserver-options from gpg. However, it doesn't seem to be attempting to retrieve the key. $ gpg --verify sha256sum.txt.asc gpg: Signature made Tue 17 Sep 2019 08:27:43 AM EDT gpg: using RSA key 24C6A8A7F4A80EB5 gpg: Can't check signature: No public key Here's my dirmngr config file: $ cat ~/.gnupg/dirmngr.conf #keyserver https://keyserver.brian.minton.name/ #keyserver x-hkp://horowitz.surfnet.nl #keyserver mailto:pgp-public-keys at keys.nl.pgp.net #keyserver ldap://pgp.surfnet.nl:11370 #keyserver ldap://keyserver.pgp.com keyserver x-hkp://the.earth.li auto-key-retrieve keyserver hkps://keys.mailvelope.com auto-key-retrieve keyserver hkps://keys.openpgp.org auto-key-retrieve keyserver hkp://jirk5u4osbsr34t5.onion auto-key-retrieve verbose debug-level guru debug-all log-file /home/bminton/.gnupg/dirmngr.log Here's the content of the log file: 2019-10-23 09:16:26 dirmngr[5043.0] permanently loaded certificates: 121 2019-10-23 09:16:26 dirmngr[5043.0] runtime cached certificates: 0 2019-10-23 09:16:26 dirmngr[5043.0] trusted certificates: 121 (120,0,0,1) 2019-10-23 09:16:26 dirmngr[5043.6] handler for fd 6 started 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 -> # Home: /home/bminton/.gnupg 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 -> # Config: /home/bminton/.gnupg/dirmngr.conf 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 -> OK Dirmngr 2.2.17 at your service 2019-10-23 09:16:26 dirmngr[5043.6] connection from process 5042 (1000:2009) 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 <- GETINFO version 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 -> D 2.2.17 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 -> OK 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 <- KEYSERVER --clear hkp://jirk5u4osbsr34t5.onion 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 -> OK 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 <- KEYSERVER 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 -> S KEYSERVER hkp://jirk5u4osbsr34t5.onion 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 -> OK 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 <- BYE 2019-10-23 09:16:26 dirmngr[5043.6] DBG: chan_6 -> OK closing connection 2019-10-23 09:16:26 dirmngr[5043.6] handler for fd 6 terminated As you can see, it is looking at the correct keyserver (side note, I have 4 keyservers specified, it would be nice if I could configure dirmngr to try all of them, but that's a separate issue), but it doesn't try to retrieve the key. If I manually retrieve the key using the same keyserver, it works. $ gpg --keyserver hkp://jirk5u4osbsr34t5.onion --recv 24C6A8A7F4A80EB5 gpg: key 24C6A8A7F4A80EB5: public key "CentOS-7 Key (CentOS 7 Official Signing Key) " imported gpg: Total number processed: 1 gpg: imported: 1 and then I can verify the signature. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 390 bytes Desc: not available URL: From mmorfikov at gmail.com Wed Oct 23 18:45:35 2019 From: mmorfikov at gmail.com (Mikhail Morfikov) Date: Wed, 23 Oct 2019 18:45:35 +0200 Subject: Should gpg try to connect to TCP/993? In-Reply-To: <9p2Nr5DGgC6gWsLFrwX4F4gbyNPm49Vwjrwxu8VG2388@mailpile> References: <48cc5e58-433f-48ce-de85-958dec26325b@gmail.com> <9p2Nr5DGgC6gWsLFrwX4F4gbyNPm49Vwjrwxu8VG2388@mailpile> Message-ID: <8628619b-02fa-a453-6d84-4c24e8e75d5d@gmail.com> Let's assume you are right, and it's because of the way the linux works. When I clear the conntrack table, the following messages appear in the FW log (I don't block the gpg packets for now, just log and accept them in its rule): Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \ SRC=192.168.1.150 DST=64.233.165.108 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=63468 DF PROTO=TCP \ SPT=41414 DPT=993 SEQ=50635057 ACK=2111326021 WINDOW=501 RES=0x00 ACK PSH URGP=0 \ OPT (0101080A1268C9EA725E3175) UID=1000 GID=1000 Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \ SRC=192.168.1.150 DST=64.233.165.108 LEN=86 TOS=0x00 PREC=0x00 TTL=64 ID=29858 DF PROTO=TCP \ SPT=41416 DPT=993 SEQ=4217185545 ACK=3828226663 WINDOW=501 RES=0x00 ACK PSH URGP=0 \ OPT (0101080A1268CA10E67D9F27) UID=1000 GID=1000 Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \ SRC=192.168.1.150 DST=64.233.165.108 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=35167 DF PROTO=TCP \ SPT=41510 DPT=993 SEQ=2292653331 ACK=2720180704 WINDOW=501 RES=0x00 ACK PSH URGP=0 \ OPT (0101080A1268CAFEB48EC039) UID=1000 GID=1000 So it's an ACK packet (possibly one per already opened connection, since src ports differ), and not SYN. So it's not a new connection for sure. Also, someone once gave me the following audit rule: -a exit,always -F arch=b64 -S connect -k MYCONNECT to find what actually is trying to connect to the net. Each time I see some blocked OUTPUT packets in the FW logs, I usually run `audit` to find out what that might be. In all cases so far, in the audit log I was able to match the dst IP or dst port that I saw in the FW logs. But in the case of gpg, there's no entry that would match anything that was printed above. So will this match to your idea? > The way processes are spawned on Unix, fork()/exec() will by > default inherit open file descriptors. Thunderbird/Enigmail will > fork()/exec() to launch gpg. > > Each active TCP/IP connection has an open file descriptor. So, if > Enigmail's gpg launcher hasn't taken care to close unneeded file > descriptors after fork() and before exec(), gpg will inherit the > connections Thunderbird had open at the time of invocation. Should the `Enigmail's gpg launcher` take care of that? Maybe is a bug or something? > Since gpg doesn't actually know anything about these connections, > it likely won't close them, they'll stay open (potentially even > after Thunderbird has closed them, although that doesn't match > all the symptoms you've described). So what doesn't match the symptoms I've described? Maybe I have to pay attention to certain things, and than it will match. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From bre at pagekite.net Wed Oct 23 21:35:00 2019 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Wed, 23 Oct 2019 19:35:00 -0000 Subject: Should gpg try to connect to TCP/993? In-Reply-To: <8628619b-02fa-a453-6d84-4c24e8e75d5d@gmail.com> References: <8628619b-02fa-a453-6d84-4c24e8e75d5d@gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello! Mikhail Morfikov wrote: > Let's assume you are right, and it's because of the way the > linux works. > > When I clear the conntrack table, the following messages appear [...] > So it's an ACK packet (possibly one per already opened > connection, since src ports differ), and not SYN. So it's not a > new connection for sure. [...] > But in the case of gpg, > there's no entry that would match anything that was printed > above. So will this match to your idea? I think yes, it does. The assumption here is that gpg inherits the file descriptor after the connection is opened - so the SYN is already sent and recorded as having come from Thunderbird. The other assumption is that the firewalling systems are confused about which process owns the packets, because after the fork()/exec() there are actually two possibilities. Without keeping expensive historic state about which process *created* the connection, it's impossible for the kernel to know which is the owner and some connections will get misreported. All pretty plausible, no? > > Each active TCP/IP connection has an open file descriptor. So, if > > Enigmail's gpg launcher hasn't taken care to close unneeded file > > descriptors after fork() and before exec() [...] > Should the `Enigmail's gpg launcher` take care of that? Maybe > is a bug or something? IMO, yes, if this is what is going on it is almost certainly a bug. Whatever code is calling exec() should be closing file descriptors first. Not doing so can lead to all sorts of wasted resources and even deadlocks if processes depend on file descriptors getting properly closed in a timely fashion. > > Since gpg doesn't actually know anything about these connections, > > it likely won't close them, they'll stay open (potentially even > > after Thunderbird has closed them, although that doesn't match > > all the symptoms you've described). > So what doesn't match the symptoms I've described? Maybe I have > to pay attention to certain things, and than it will match. Since (I think) Enigmail's gpg processes are usually short-lived, you're unlikely to see this happen, and if it does it's likely to be harmless. If the gpg processes were long-lived, it could over time lead to resource exhaustion (running out of file descriptors or RAM). The symptoms that didn't match this, was that Thunderbird was unable to download mail. If this was *only* happening with connections that Thunderbird thought it had closed, then your firewall rules wouldn't have impacted TB's operations. Again, I'll stress that this is all educated guesswork. But the symptoms match. I've created bugs like this myself in the past. Of course, maybe GnuPG does like to connect to port 993. I haven't ruled that out, but if that were the case, you'd probably have seen SYN packets in your logs. :-D - Bjarni - -- PageKite.net lets your personal computer be part of the web -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2wq2QACgkQjgA3FgDP lJE3KAgAtVKIkBlAXRXhtvsuWvPUFoygc/LF7ice2PWKbBada8yIiY3U0F8YtbSJ bmtm+bqPhPijBuAH8O0RdGkFQsvyUFSYzvXKE92Tb6jZF5NEdOktVkIRbwurNOAS 0MreNosHaV9wPx5mm1DtY5UkDF9ccZzdQXdXRGvoMz5uKBdRgxtHaaBWS1+0pwey VsAqmjeSB8UOdJDpnqIXRxxyoZ7Ti/Aru4KweKoYVnIac39fFg2GRY3mRD0D0pIL nI+Znnm0nAi64wLQ6/hVEJ2175TN6g/XgRtCCPyjytmrFrIMnOwB6t+ZmSWADUH9 QzQpKFwoW1mC/+/7aDT0unQlUtDGDg== =j1yU -----END PGP SIGNATURE----- From abbot at monksofcool.net Wed Oct 23 22:56:39 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Wed, 23 Oct 2019 22:56:39 +0200 Subject: a new free smime service, but... In-Reply-To: <20191022182023.4RZzH%steffen@sdaoden.eu> References: <87a79vsdl2.fsf@mat.ucm.es> <1171562612.20191022004056@my_localhost_AR> <20191022182023.4RZzH%steffen@sdaoden.eu> Message-ID: <87pninuqns.fsf@wedjat.horus-it.com> * Steffen Nurpmeso: > I think it is common that S/MIME and SSL certificates are delivered > via PKCS12, including the private key. You then seem to extract the > individual things [...] Nope, that is the wrong way round. The correct sequence to obtain an S/MIME certificate is as follows: 1. User X creates a private key *locally*. This private key must never be handed to anybody else. 2. User X creates a certificate signing request (CSR) and sends it to a certificate authority (CA). 3. The CA uses the CSR to create a signed certificate, and sends that certificate back to user X. 4. User X can then optionally combine private key and signed certificate in a .p12 file to ease importing the data *locally* in his MUA (it is usually more convenient to deal with a single file that combines both private key and certificate). If the process is altered in any way in which a third party gets hold of user X's private key, security is broken, no matter if the private key is password protected or not. -Ralph From steffen at sdaoden.eu Thu Oct 24 00:43:23 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 24 Oct 2019 00:43:23 +0200 Subject: a new free smime service, but... In-Reply-To: <874kzz1var.fsf@mat.ucm.es> References: <87a79vsdl2.fsf@mat.ucm.es> <1171562612.20191022004056@my_localhost_AR> <20191022182023.4RZzH%steffen__42655.3339626238$1571768479$gmane$org@sdaoden.eu> <874kzz1var.fsf@mat.ucm.es> Message-ID: <20191023224323.KAODd%steffen@sdaoden.eu> Hello, please excuse the late reply. Uwe Brauer via Gnupg-users wrote in <874kzz1var.fsf at mat.ucm.es>: |> MFPA via Gnupg-users wrote in <1171562612.20191022004056 at my_localhost_AR\ |> >: |>|On Sunday 20 October 2019 at 3:20:41 PM, in |>|, Uwe Brauer via Gnupg-users wrote:- |>| |>|> I just found that |>|> https://extrassl.actalis.it/portal/uapub/doProcess |>| |>|> Provides a free smime certificate. |> ... |>|> does somebody know whether there is a security |>|> breach, the way this |>|> certificate was generated? |>| |>|I'm no expert but their Certificate Policy reads to me that the |>|private key is compromised right from the start. I think usually the | |> I think it is common that S/MIME and SSL certificates are |> delivered via PKCS12, including the private key. You then seem to |> extract the individual things like | |I think this is a severe security breach. The private key should never |leave your computer. | |> $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes |> $ # Alternatively |> $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys |> $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes | |>|keys are generated on the subscriber's device and only the public key |>|goes to the CA to be certified. With StartSSL it was like that, the browser generated the signing request i hope. But i do not know. And, the above i inherited in the manual of the software i maintain. I have not seen this in the wild on my own. |> This is possible via CACert.org, at least still (out of money). |> You create your local signing request, and the private key.pem never |> leaves your own box: | |> $ openssl req -nodes -newkey rsa:4096 -keyout key.pem -out creq.pem | |> (Ensure all email addresses of desire are included in the web |> form.) |> Unfortunate that besides Comodo there seems no other provider of |> free S/MIME certificates. You can only self-sign, and provide That i have done myself. |Comodo does not offer this any more. At the beginning of the year they |reduced the smime cerificates validity from 1 year to 1 month, now they |withdraw it all together. I did not know that. It was the only free service that i found when i searched for a free S/MIME certificate last, but i kept using CACert.org. (Until i support PGP, when i will switch.) |> a safe transport for a certificate to compare with. Which is why |> PGP is so nice. | |Well yes sort of, but I can tell you from my own experience PGP is more for |hackers while smime is not. I have convinced 6 of my friends to use |smime, but only one to pgp. | |Self signed smime certificates are basically useless, because then you |have to tell the other user either to install a root certificate or to |trust the certificate, in which case smime looses its convenience |(compared to pgp) Well, hm, yes. What should i say. It depends a bit, once you know a certificate is correct some software allow to just agree to the checksum of a certificate, for example, no need for a root certificate no more. To know it is correct you need the certificate which signed it in what you use as your local pool of certificate authorities, of course. I do have GPG keys in may keyring which were not signed by anyone (when i downloaded them), too, i saw the fingerprint in some announcement mail or on some website, searched SKS, and downloaded the one key which did match. (I think Postfix releases are still shipped with a gpg1 key sign that is revoked, last i looked, i always have to look how i can actually use a revoked key nonetheless.) Personally i like S/MIME more, because it comes from the same pool of standards etc. that TLS uses, and the same library can be used to deal with it, than what i use for TLS anyway. In theory file signing and all the other things would be possible via it, too, the primitives are there, it is just not used in that there are no omnipresent tools available, like GPG is. There is no other reason really, except that for mail different standards for MIME are used, and here i like the PGP one more ;) That is just how it is, and having said that, i do use PGP since many years, but only very rarely and mostly automatized (after having had immense loss due to lost passwords of encrypted backups). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Thu Oct 24 00:49:19 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 24 Oct 2019 00:49:19 +0200 Subject: a new free smime service, but... In-Reply-To: <87pninuqns.fsf@wedjat.horus-it.com> References: <87a79vsdl2.fsf@mat.ucm.es> <1171562612.20191022004056@my_localhost_AR> <20191022182023.4RZzH%steffen@sdaoden.eu> <87pninuqns.fsf@wedjat.horus-it.com> Message-ID: <20191023224919.d_A9Q%steffen@sdaoden.eu> Hello, sorry for the late reply. Ralph Seichter wrote in <87pninuqns.fsf at wedjat.horus-it.com>: |* Steffen Nurpmeso: |> I think it is common that S/MIME and SSL certificates are delivered |> via PKCS12, including the private key. You then seem to extract the |> individual things [...] | |Nope, that is the wrong way round. The correct sequence to obtain an |S/MIME certificate is as follows: | |1. User X creates a private key *locally*. This private key must never |be handed to anybody else. | |2. User X creates a certificate signing request (CSR) and sends it to a |certificate authority (CA). | |3. The CA uses the CSR to create a signed certificate, and sends that |certificate back to user X. Ok, but that is exactly what i have written a few lines later for the CACert example that i posted, right. So not nope, Mr. Where "user X" meant "browser of user X" when i did so for a StartSSL certificate. I assume it did the right thing. But i do not know. |4. User X can then optionally combine private key and signed certificate |in a .p12 file to ease importing the data *locally* in his MUA (it is |usually more convenient to deal with a single file that combines both |private key and certificate). | |If the process is altered in any way in which a third party gets hold of |user X's private key, security is broken, no matter if the private key |is password protected or not. That is surely right. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Thu Oct 24 00:51:40 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 24 Oct 2019 00:51:40 +0200 Subject: a new free smime service, but... In-Reply-To: <20191023224323.KAODd%steffen@sdaoden.eu> References: <87a79vsdl2.fsf@mat.ucm.es> <1171562612.20191022004056@my_localhost_AR> <20191022182023.4RZzH%steffen__42655.3339626238$1571768479$gmane$org@sdaoden.eu> <874kzz1var.fsf@mat.ucm.es> <20191023224323.KAODd%steffen@sdaoden.eu> Message-ID: <20191023225140.A2TpN%steffen@sdaoden.eu> P.S.: Steffen Nurpmeso wrote in <20191023224323.KAODd%steffen at sdaoden.eu>: ... ||> I think it is common that S/MIME and SSL certificates are ||> delivered via PKCS12, including the private key. You then seem to ||> extract the individual things like || ||I think this is a severe security breach. The private key should never ||leave your computer. (Yes.) ||> $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes ||> $ # Alternatively ||> $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys ||> $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes || ||>|keys are generated on the subscriber's device and only the public key ||>|goes to the CA to be certified. | |With StartSSL it was like that, the browser generated the signing |request i hope. But i do not know. | |And, the above i inherited in the manual of the software |i maintain. I have not seen this in the wild on my own. This is actually only half true. The original manual only contains the first of the three. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From abbot at monksofcool.net Thu Oct 24 04:20:15 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Thu, 24 Oct 2019 04:20:15 +0200 Subject: a new free smime service, but... In-Reply-To: <20191023224919.d_A9Q%steffen@sdaoden.eu> References: <87a79vsdl2.fsf@mat.ucm.es> <1171562612.20191022004056@my_localhost_AR> <20191022182023.4RZzH%steffen@sdaoden.eu> <87pninuqns.fsf@wedjat.horus-it.com> <20191023224919.d_A9Q%steffen@sdaoden.eu> Message-ID: <87lftaevfk.fsf@wedjat.horus-it.com> * Steffen Nurpmeso: > > * Steffen Nurpmeso: > > > I think it is common that S/MIME and SSL certificates are delivered > > > via PKCS12, including the private key. You then seem to extract the > > > individual things [...] > > > > Nope, that is the wrong way round. [...] > > Ok, but that is exactly what i have written a few lines later for the > CACert example that i posted, right. So not nope, Mr. What you describe in the "I think..." paragraph is *not* the common way to deliver certificates. Hence, nope. -Ralph From patrick at enigmail.net Thu Oct 24 08:21:45 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 24 Oct 2019 08:21:45 +0200 Subject: Should gpg try to connect to TCP/993? In-Reply-To: References: <8628619b-02fa-a453-6d84-4c24e8e75d5d@gmail.com> Message-ID: Bjarni Runar Einarsson wrote on 23.10.2019 21:35: [...] >>> Each active TCP/IP connection has an open file descriptor. So, if >>> Enigmail's gpg launcher hasn't taken care to close unneeded file >>> descriptors after fork() and before exec() > [...] >> Should the `Enigmail's gpg launcher` take care of that? Maybe >> is a bug or something? > > IMO, yes, if this is what is going on it is almost certainly a > bug. Whatever code is calling exec() should be closing file > descriptors first. Not doing so can lead to all sorts of wasted > resources and even deadlocks if processes depend on file > descriptors getting properly closed in a timely fashion. Your guess is perfectly right, that's exactly what happens. Enigmail uses a standard library provided by Mozilla for add-ons to execute processes. Earlier versions of the library did close all file descriptors correctly. But the library is written in JavaScript, and closing all file descriptors could sometimes lead to Thunderbird/Firefox crashes. Therefore that part has been disabled. It's therefore not surprising to see such open connections from gpg processes, but I don't consider this bad. -Patrick From gnupgpacker at on.yourweb.de Thu Oct 24 08:29:42 2019 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Thu, 24 Oct 2019 08:29:42 +0200 Subject: a new free smime service, but... Message-ID: <000701d58a34$6e8af2b0$4ba0d810$@on.yourweb.de> So a trustful CA issueing free S/Mime certificates > 3 month and acceptance in major browsers / mail tools is wanted. Why doesn't Let's Encrypt offer this service? https://letsencrypt.org/ Why isn't CAcert after years of participation listed as trusted CA in root stores? http://www.cacert.org/ kind regards Chris From mmorfikov at gmail.com Thu Oct 24 14:56:08 2019 From: mmorfikov at gmail.com (Mikhail Morfikov) Date: Thu, 24 Oct 2019 14:56:08 +0200 Subject: Should gpg try to connect to TCP/993? In-Reply-To: References: <8628619b-02fa-a453-6d84-4c24e8e75d5d@gmail.com> Message-ID: On 24/10/2019 08:21, Patrick Brunschwig wrote: > Your guess is perfectly right, that's exactly what happens. Enigmail > uses a standard library provided by Mozilla for add-ons to execute > processes. Earlier versions of the library did close all file > descriptors correctly. But the library is written in JavaScript, and > closing all file descriptors could sometimes lead to Thunderbird/Firefox > crashes. Therefore that part has been disabled. > > It's therefore not surprising to see such open connections from gpg > processes, but I don't consider this bad. Thanks for the info -- at least I know what's going on. Now I'm just wonder how I'm supposed to write my FW policy when apps can behave like this one... Fortunately it's just TB so far (from ~150 apps), so making one exception isn't that big of a deal. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Oct 24 15:19:14 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 24 Oct 2019 09:19:14 -0400 Subject: a new free smime service, but... In-Reply-To: <000701d58a34$6e8af2b0$4ba0d810$@on.yourweb.de> References: <000701d58a34$6e8af2b0$4ba0d810$@on.yourweb.de> Message-ID: <7e1208e4-aa1b-2e4c-3b3b-b74901456101@sixdemonbag.org> > Why doesn't Let's Encrypt offer this service? Because it's outside the scope of what Let's Encrypt exists to do, which is make it easy to provide HTTPS support to small websites. SMTP is *totally* outside of Let's Encrypt's mission. If you've got a problem with that, take it up with Let's Encrypt. They're pretty responsive on Twitter at https://twitter.com/letsencrypt. > Why isn't CAcert after years of participation listed as trusted CA in root > stores? Because CACert hasn't been able to comply with Mozilla's Root Store Policy. Chrome has its own root store policy, as does Internet Explorer. CACert hasn't been able to dot the is and cross the ts for any of them, AFAIK. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ From abbot at monksofcool.net Fri Oct 25 00:52:26 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Fri, 25 Oct 2019 00:52:26 +0200 Subject: a new free smime service, but... In-Reply-To: <000701d58a34$6e8af2b0$4ba0d810$@on.yourweb.de> References: <000701d58a34$6e8af2b0$4ba0d810$@on.yourweb.de> Message-ID: <87lft9u579.fsf@wedjat.horus-it.com> * gnupgpacker at on.yourweb.de: > Why doesn't Let's Encrypt offer this service? S/MIME certificates have been repeatedly discussed and rejected in the LE community, pretty much since LE's inception. There even used to be a related FAQ entry. One reason is that LE's self declared goal is to provide certificates for web servers, and email communication between individuals is quite a different beast. -Ralph From steffen at sdaoden.eu Fri Oct 25 20:02:40 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 25 Oct 2019 20:02:40 +0200 Subject: a new free smime service, but... In-Reply-To: <7e1208e4-aa1b-2e4c-3b3b-b74901456101@sixdemonbag.org> References: <000701d58a34$6e8af2b0$4ba0d810$@on.yourweb.de> <7e1208e4-aa1b-2e4c-3b3b-b74901456101@sixdemonbag.org> Message-ID: <20191025180240.hBjz3%steffen@sdaoden.eu> Robert J. Hansen wrote in <7e1208e4-aa1b-2e4c-3b3b-b74901456101 at sixdemon\ bag.org>: |> Why doesn't Let's Encrypt offer this service? | |Because it's outside the scope of what Let's Encrypt exists to do, which |is make it easy to provide HTTPS support to small websites. | |SMTP is *totally* outside of Let's Encrypt's mission. If you've got a |problem with that, take it up with Let's Encrypt. They're pretty |responsive on Twitter at https://twitter.com/letsencrypt. If i recall correctly Melnikov made a draft how the ACME stuff could be extended to S/MIME, but it never left draft state. I do not listen to the according IETF working groups, ... Wait, it is still an active draft, version 6, last updated this year July: [1] Unfortunately it wants DKIM/SPF/DMARC and a single MIME message body, which counteracts my desire to vanquish that in favour of a nice CMS thing that puts list addresses in From:, or so. Sigh. [1] https://tools.ietf.org/html/draft-ietf-acme-email-smime-05 |> Why isn't CAcert after years of participation listed as trusted CA \ |> in root |> stores? | |Because CACert hasn't been able to comply with Mozilla's Root Store |Policy. Chrome has its own root store policy, as does Internet |Explorer. CACert hasn't been able to dot the is and cross the ts for |any of them, AFAIK. | |https://www.mozilla.org/en-US/about/governance/policies/security-group/c\ |erts/policy/ --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From jays at panix.com Fri Oct 25 18:23:29 2019 From: jays at panix.com (Jay Sulzberger) Date: Fri, 25 Oct 2019 12:23:29 -0400 (EDT) Subject: Should gpg try to connect to TCP/993? In-Reply-To: References: <8628619b-02fa-a453-6d84-4c24e8e75d5d@gmail.com> Message-ID: On Thu, 24 Oct 2019, Patrick Brunschwig wrote: > Bjarni Runar Einarsson wrote on 23.10.2019 21:35: > [...] >>>> Each active TCP/IP connection has an open file descriptor. So, if >>>> Enigmail's gpg launcher hasn't taken care to close unneeded file >>>> descriptors after fork() and before exec() >> [...] >>> Should the `Enigmail's gpg launcher` take care of that? Maybe >>> is a bug or something? >> >> IMO, yes, if this is what is going on it is almost certainly a >> bug. Whatever code is calling exec() should be closing file >> descriptors first. Not doing so can lead to all sorts of wasted >> resources and even deadlocks if processes depend on file >> descriptors getting properly closed in a timely fashion. > > Your guess is perfectly right, that's exactly what happens. Enigmail > uses a standard library provided by Mozilla for add-ons to execute > processes. Earlier versions of the library did close all file > descriptors correctly. But the library is written in JavaScript, and > closing all file descriptors could sometimes lead to Thunderbird/Firefox > crashes. Therefore that part has been disabled. > > It's therefore not surprising to see such open connections from gpg > processes, but I don't consider this bad. > > -Patrick Is the following correct: When I use gpg to just encrypt or decrypt a file already on my computer/OS's file system, then gpg does not open any formal channels of communication going outside my computer/OS. oo--JS. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > From guru at unixarea.de Fri Oct 25 20:17:22 2019 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 25 Oct 2019 20:17:22 +0200 Subject: gpg: There is no assurance this key belongs to the named user In-Reply-To: <20191022181836.GA3992@c720-r342378> References: <20191021173248.GA3634@c720-r342378> <20191021183803.GA5409@c720-r342378> <20191022181836.GA3992@c720-r342378> Message-ID: <20191025181721.GA8881@c720-r342378> El d?a martes, octubre 22, 2019 a las 08:18:36p. m. +0200, Matthias Apitz escribi?: > El d?a lunes, octubre 21, 2019 a las 08:38:04p. m. +0200, Matthias Apitz escribi?: > > > El d?a lunes, octubre 21, 2019 a las 07:32:48p. m. +0200, Matthias Apitz escribi?: > > > > > > > > Hello, > > > > > > I wanted to insert a new password into my password store, but I can't do > > > so anymore. It says: > > > > > > $ pass insert -m web/test3 > > > Enter contents of web/test3 and press Ctrl+D when finished: > > > > > > gpg: 61F1ECB625C9A6C3: There is no assurance this key belongs to the named user > > > gpg: [stdin]: encryption failed: Unusable public key > > > Password encryption aborted. > > > > The culprit was this file: > > > > $ ls -l ~/.gnupg-ccid/trustdb* > > -rw------- 1 guru wheel 1280 23 may. 2017 /home/guru/.gnupg-ccid/trustdb.gpg > > -rw------- 1 guru wheel 1280 11 oct. 14:02 /home/guru/.gnupg-ccid/trustdb.gpg.20191011 > > > > after renaming it and restoring the previous version (not modified for > > ages) of trustdb.gpg all is fine again. What caused the change on > > October 11 remains unclear so far. > > I exported both files which gives the same export: > > $ ls -l trustdb.gp* > -rw------- 1 guru wheel 1280 23 may. 2017 trustdb.gpg > -rw------- 1 guru wheel 1280 11 oct. 14:02 trustdb.gpg.20191011 > $ diff trustdb.gp* > Binary files trustdb.gpg and trustdb.gpg.20191011 differ > $ gpg2 --trustdb-name trustdb.gpg.20191011 --export-ownertrust > # List of assigned trustvalues, created Tue Oct 22 20:14:22 2019 CEST > # (Use "gpg --import-ownertrust" to restore them) > 5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11:6: > > $ gpg2 --export-ownertrust > # List of assigned trustvalues, created Tue Oct 22 20:14:27 2019 CEST > # (Use "gpg --import-ownertrust" to restore them) > 5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11:6: > > What does this mean? Why gpg2 was unwilling to use the file > trustdb.gpg.20191011? Is this a FAQ or otherwise stupid question, or what's the reason that nobody wants to give me some hint about this? Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From sac at 300baud.de Fri Oct 25 20:27:48 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 25 Oct 2019 20:27:48 +0200 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: <20191022082418.000049df.sac@300baud.de> References: <20191021225957.00007581.sac@300baud.de> <20191022082418.000049df.sac@300baud.de> Message-ID: <20191025202748.0000496b.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Ajax wrote: > > > Are there enough five letter words in the word lists available at > > eff.org/dice? > > Thanks a lot! The short list has 782 five letter words, perfect! > > So I will then select 256 of them which are easy (for me) to > read ... :-) Due to a lenghtly discussion in Usenet, with native English speakers, I decided againt an English version and will go instead for NATO/HEX, which allows for faster and error free transfer via phone, radio, etc. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Sat Oct 26 14:51:06 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 26 Oct 2019 14:51:06 +0200 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: <20191025202748.0000496b.sac@300baud.de> References: <20191021225957.00007581.sac@300baud.de> <20191022082418.000049df.sac@300baud.de> <20191025202748.0000496b.sac@300baud.de> Message-ID: <20191026145106.00003abd.sac@300baud.de> Stefan Claas wrote: > Due to a lenghtly discussion in Usenet, with native English speakers, > I decided againt an English version and will go instead for NATO/HEX, > which allows for faster and error free transfer via phone, radio, etc. Here is an output from a small encrypted NaCl secretbox blob with 'sender.exe': Seven-One Nine-Foxtrot One-Nine Bravo-Two Echo-Five Eight-Zero Five-Zero Delta-Six Delta-Alfa Four-Delta Bravo-Three Charlie-One Delta-Foxtrot Bravo-Delta Zero-Bravo Foxtrot-Four Delta-Six Three-Four Charlie-One Three-Four Bravo-Two Five-Eight Bravo-Seven Charlie-Three Two-Four Bravo-Three Five-Two Echo-Nine Three-Zero Four-Echo Zero-Foxtrot Echo-Foxtrot Zero-Alfa Zero-Delta Bravo-Six Eight-Echo Echo-Six Foxtrot-Two Three-Three Charlie-Four Seven-Five Alfa-Nine Echo-Six Charlie-Six Nine-Nine Seven-Two Five-Three Seven-Delta Four-Alfa Five-Foxtrot Bravo-Alfa The listener then simply types the values as HEX into his editor of choice, like so: 71 9F 19 B2 E5 80 50 D6 DA 4D B3 C1 DF BD 0B F4 D6 34 C1 34 B2 58 B7 C3 24 B3 52 E9 30 4E 0F EF 0A 0D B6 8E E6 F2 33 C4 75 A9 E6 C6 99 72 53 7D 4A 5F BA Then he / she uses the 'receiver.exe' program to convert the HEX values back into a binary blob. :-) Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From rjh at sixdemonbag.org Sat Oct 26 15:36:06 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 26 Oct 2019 09:36:06 -0400 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: <20191026145106.00003abd.sac@300baud.de> References: <20191021225957.00007581.sac@300baud.de> <20191022082418.000049df.sac@300baud.de> <20191025202748.0000496b.sac@300baud.de> <20191026145106.00003abd.sac@300baud.de> Message-ID: > Due to a lenghtly discussion in Usenet, with native English > speakers, I decided againt an English version and will go instead for > NATO/HEX, which allows for faster and error free transfer via phone, > radio, etc. You can do a *lot* better than that. This is a solved problem. https://en.wikipedia.org/wiki/PGP_word_list From sac at 300baud.de Sat Oct 26 15:48:27 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 26 Oct 2019 15:48:27 +0200 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: References: <20191021225957.00007581.sac@300baud.de> <20191022082418.000049df.sac@300baud.de> <20191025202748.0000496b.sac@300baud.de> <20191026145106.00003abd.sac@300baud.de> Message-ID: <20191026154827.00000f3d.sac@300baud.de> Robert J. Hansen wrote: > > Due to a lenghtly discussion in Usenet, with native English > > speakers, I decided againt an English version and will go instead for > > NATO/HEX, which allows for faster and error free transfer via phone, > > radio, etc. > > You can do a *lot* better than that. This is a solved problem. > > https://en.wikipedia.org/wiki/PGP_word_list > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users I don't agree with you, because due to dialects spoken in every country (even in the US) the PGP wordlist is not suitable IMHO for non-native English speakers and international comms, which the NATO alphabet is perfect for! There's also mnemonicode available which I first considered to translate into German language but I gave up because it is to much work. https://github.com/singpolyma/mnemonicode Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From rjh at sixdemonbag.org Sat Oct 26 16:11:42 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 26 Oct 2019 10:11:42 -0400 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: <20191026154827.00000f3d.sac@300baud.de> References: <20191021225957.00007581.sac@300baud.de> <20191022082418.000049df.sac@300baud.de> <20191025202748.0000496b.sac@300baud.de> <20191026145106.00003abd.sac@300baud.de> <20191026154827.00000f3d.sac@300baud.de> Message-ID: <5e7685c2-4b44-3689-c429-9b700cab2e0a@sixdemonbag.org> > I don't agree with you, because due to dialects spoken in every > country (even in the US) the PGP wordlist is not suitable IMHO > for non-native English speakers and international comms, which > the NATO alphabet is perfect for! It was designed by a computational linguist specifically to be resistant to these concerns. There's an academic paper written about it. You should read it. From sac at 300baud.de Sat Oct 26 16:38:28 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 26 Oct 2019 16:38:28 +0200 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: <5e7685c2-4b44-3689-c429-9b700cab2e0a@sixdemonbag.org> References: <20191021225957.00007581.sac@300baud.de> <20191022082418.000049df.sac@300baud.de> <20191025202748.0000496b.sac@300baud.de> <20191026145106.00003abd.sac@300baud.de> <20191026154827.00000f3d.sac@300baud.de> <5e7685c2-4b44-3689-c429-9b700cab2e0a@sixdemonbag.org> Message-ID: <20191026163828.0000523f.sac@300baud.de> Robert J. Hansen wrote: > > I don't agree with you, because due to dialects spoken in every > > country (even in the US) the PGP wordlist is not suitable IMHO > > for non-native English speakers and international comms, which > > the NATO alphabet is perfect for! > > It was designed by a computational linguist specifically to be resistant > to these concerns. There's an academic paper written about it. You > should read it. Yes, for native English speakers ... Let's assume the following, I would use the PGP wordlist and give my software for a test to a German user and let's say a Japanese user. Both of them have basic English skills. If one person then speaks the words from the PGP wordlist to the other and he / she has to write down these words you can be sure that this is *not* 100 percent error free and fast, in comparison to my approach, which requires only to learn six easy words and ten digits (which can be accomplished by a six year old kid). Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From rjh at sixdemonbag.org Sat Oct 26 17:34:37 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 26 Oct 2019 11:34:37 -0400 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: <20191026163828.0000523f.sac@300baud.de> References: <20191021225957.00007581.sac@300baud.de> <20191022082418.000049df.sac@300baud.de> <20191025202748.0000496b.sac@300baud.de> <20191026145106.00003abd.sac@300baud.de> <20191026154827.00000f3d.sac@300baud.de> <5e7685c2-4b44-3689-c429-9b700cab2e0a@sixdemonbag.org> <20191026163828.0000523f.sac@300baud.de> Message-ID: > Let's assume the following... Let's not assume anything. You either have users in such conditions or you don't. Design for the users you do have, not the hypothetical users you imagine having. I can tell you from bitter experience, hypothetical users virtually never appear in real life. The users who *do* appear normally have use cases you've never even imagined. From bre at pagekite.net Sat Oct 26 17:55:12 2019 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Sat, 26 Oct 2019 15:55:12 -0000 Subject: Automatically changing/removing key passphrase: python-pgp_passtool In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello again! Since GnuPG appears to be designed not to handle this use-case, I wrote a tool (a Python 2/3 library) to solve my problem: https://github.com/BjarniRunar/python-pgp_passtool It's also in PyPI, so `pip install pgp_passtool` should work. To sum up: this is a tool for changing the passphrase on a secret key, or removing the passphrase entirely. It can be used from the shell, or from within Python code. It is my hope that this will help folks like myself who need a level of automation, but don't want just use unprotected keys all the time. The tool has some support for coping with unusual character encodings, and also allows the user to specify they want fast (insecure) key derivation, for when we know the passphrase is already very strong. It's not a complete implementation, it's not well tested. There are probably many keys out there which it cannot handle. So, I very much welcome comments and bug reports and pull requests, either here or in the issue tracker. Cheers, - Bjarni - -- PageKite.net lets your personal computer be part of the web -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl20bG0ACgkQjgA3FgDP lJHIDQf/YCDzxEuoyAA9IM6zkoE+371sDjzarvO1iK1MqUn+MXE6IrQBkjLEqaFh Y7toab2ZBU0n4CIObCX18qtNg9eMbPqRc9Zwb8e/GbwmI2VqUNteYGzUzIUSxvg6 3/p6Aw/eiTqJyujfYFNUOUrNmYPeujaKvmbm13nsf4/gnW/mlYs7UlYUmsGcTuQH NUOekRuvSra9UqNRq3SndWyuQYmdlv1k6PfccB+FMzQROCofVDOXwUmk2FiEMXRl KHHLkrCqujzqllnrQ/YD5qNcsEODyLxbtw1F4TwSDX539ejvgKp0YSXC3GUAh4Yj EMh1S+CK8HTiyCLNUjO6lCAffnTaGA== =6ENQ -----END PGP SIGNATURE----- From sac at 300baud.de Sat Oct 26 18:44:12 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 26 Oct 2019 18:44:12 +0200 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: References: <20191021225957.00007581.sac@300baud.de> <20191022082418.000049df.sac@300baud.de> <20191025202748.0000496b.sac@300baud.de> <20191026145106.00003abd.sac@300baud.de> <20191026154827.00000f3d.sac@300baud.de> <5e7685c2-4b44-3689-c429-9b700cab2e0a@sixdemonbag.org> <20191026163828.0000523f.sac@300baud.de> Message-ID: <20191026184412.00007a6e.sac@300baud.de> Robert J. Hansen wrote: > > Let's assume the following... > > Let's not assume anything. You either have users in such conditions or > you don't. Design for the users you do have, not the hypothetical users > you imagine having. I can tell you from bitter experience, hypothetical > users virtually never appear in real life. The users who *do* appear > normally have use cases you've never even imagined. Well, o.k., at least users using my software have to possibilty to change the wordlist to their liking ... ;-) Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Sat Oct 26 20:12:15 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 26 Oct 2019 20:12:15 +0200 Subject: Help needed - for a binary to words encoder/decoder for GnuPG In-Reply-To: <20191026145106.00003abd.sac@300baud.de> References: <20191021225957.00007581.sac@300baud.de> <20191022082418.000049df.sac@300baud.de> <20191025202748.0000496b.sac@300baud.de> <20191026145106.00003abd.sac@300baud.de> Message-ID: <20191026201215.00001261.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Stefan Claas wrote: > > > Due to a lenghtly discussion in Usenet, with native English speakers, > > I decided againt an English version and will go instead for NATO/HEX, > > which allows for faster and error free transfer via phone, radio, etc. > > Here is an output from a small encrypted NaCl secretbox blob with > 'sender.exe': > > Seven-One Nine-Foxtrot One-Nine Bravo-Two > Echo-Five Eight-Zero Five-Zero Delta-Six Delta-Alfa > Four-Delta Bravo-Three Charlie-One Delta-Foxtrot Bravo-Delta > Zero-Bravo Foxtrot-Four Delta-Six Three-Four Charlie-One > Three-Four Bravo-Two Five-Eight Bravo-Seven Charlie-Three > Two-Four Bravo-Three Five-Two Echo-Nine Three-Zero > Four-Echo Zero-Foxtrot Echo-Foxtrot Zero-Alfa Zero-Delta > Bravo-Six Eight-Echo Echo-Six Foxtrot-Two Three-Three > Charlie-Four Seven-Five Alfa-Nine Echo-Six Charlie-Six > Nine-Nine Seven-Two Five-Three Seven-Delta Four-Alfa > Five-Foxtrot Bravo-Alfa > > > The listener then simply types the values as HEX into his editor of choice, > like so: > > 71 9F 19 B2 E5 > 80 50 D6 DA 4D > B3 C1 DF BD 0B > F4 D6 34 C1 34 > B2 58 B7 C3 24 > B3 52 E9 30 4E > 0F EF 0A 0D B6 > 8E E6 F2 33 C4 > 75 A9 E6 C6 99 > 72 53 7D 4A 5F > BA > > Then he / she uses the 'receiver.exe' program to convert the HEX values back > into a binary blob. :-) O.k. the software is uploaded to my keybase account. https://keybase.pub/stefan_claas/software/bin2nato/ Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From 400thecat at gmx.ch Sun Oct 27 17:55:50 2019 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Sun, 27 Oct 2019 17:55:50 +0100 Subject: gpg on read-only filesystem In-Reply-To: <20191022155437.GB25336@kugelfisch.zuhause.test> References: <57576be4-5c15-9503-4862-b6672d91a78d@gmx.ch> <20191022155437.GB25336@kugelfisch.zuhause.test> Message-ID: <7f1c24b3-39b2-3768-2bfd-70e217133686@gmx.ch> On 22/10/2019 17.54, Friedhelm Waitzmann wrote: > A solution for the verify use case: Just read the manual > () > and use ?--no-auto-check-trustdb?. thanks, but using the "--no-auto-check-trustdb" does not help. I still get the error: $ gpg --verify --no-auto-check-trustdb file.sig gpg: assuming signed data in 'file' gpg: Signature made 2019-10-24T21:33:21 CEST gpg: using RSA key 88B5AAEE121345AA gpg: Fatal: can't open '/home/testuser/.gnupg/trustdb.gpg': Operation not permitted From sac at 300baud.de Sun Oct 27 20:25:10 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 27 Oct 2019 20:25:10 +0100 Subject: Question about symmetric AES cipher in GnuPG Message-ID: <20191027202510.000077ee.sac@300baud.de> Hi Werner and all, I was wondering why the binary file size when using symmetric AES encryption with GnuPG is larger than with other apps, I have tested so far. As an example encrypting a text file containing 'Hello World': gpg --symmetric --cipher-algo AES256 hw.txt gives me a file size of 87 Bytes. Doing the same with openssl, for example: openssl enc -aes-256-cbc -pbkdf2 -in hw.txt -out hw.enc results in 32 Bytes. Can you please, or somebody else, explain in laymen terms why this is so? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From dgouttegattat at incenp.org Sun Oct 27 21:40:17 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 27 Oct 2019 20:40:17 +0000 Subject: Question about symmetric AES cipher in GnuPG In-Reply-To: <20191027202510.000077ee.sac@300baud.de> References: <20191027202510.000077ee.sac@300baud.de> Message-ID: <20191027204017.5ddwp3ufwk6drpgj@aurora.local.incenp.org> Hi, On Sun, Oct 27, 2019 at 08:25:10PM +0100, Stefan Claas via Gnupg-users wrote: >Can you please, or somebody else, explain in laymen terms why this is >so? Simply put, gpg and openssl enc don?t use the same file formats. Different formats may encode the same data differently, so you can?t expect the two outputs to be similar or to be of a similar size. In GnuPG?s case, the format is the one defined by the RFC 4880 standard [1]. I don?t know what is the format used by OpenSSL, but some of the differences with GnuPG?s format include: * GnuPG adds a ?Modification Detection Code? to the encrypted data; * GnuPG also adds some metadata, including the name of the original file. Those differences alone already explain easily why the file generated by GnuPG is bigger. Cheers, - Damien [1] https://tools.ietf.org/html/rfc4880 -------------- 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 Sun Oct 27 21:51:24 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 27 Oct 2019 21:51:24 +0100 Subject: Question about symmetric AES cipher in GnuPG In-Reply-To: <20191027204017.5ddwp3ufwk6drpgj@aurora.local.incenp.org> References: <20191027202510.000077ee.sac@300baud.de> <20191027204017.5ddwp3ufwk6drpgj@aurora.local.incenp.org> Message-ID: <20191027215124.00007e20.sac@300baud.de> Damien Goutte-Gattat wrote: > Hi, > > On Sun, Oct 27, 2019 at 08:25:10PM +0100, Stefan Claas via Gnupg-users wrote: > >Can you please, or somebody else, explain in laymen terms why this is > >so? > > Simply put, gpg and openssl enc don?t use the same file formats. > Different formats may encode the same data differently, so you can?t > expect the two outputs to be similar or to be of a similar size. > > In GnuPG?s case, the format is the one defined by the RFC 4880 standard > [1]. I don?t know what is the format used by OpenSSL, but some of the > differences with GnuPG?s format include: > > * GnuPG adds a ?Modification Detection Code? to the encrypted data; > > * GnuPG also adds some metadata, including the name of the original > file. > > Those differences alone already explain easily why the file generated by > GnuPG is bigger. > > Cheers, > > - Damien > > > [1] https://tools.ietf.org/html/rfc4880 Thanks for the explanation! I will then check the RFC to see if I can find how many bytes the 'Modification Detection Code' and the meta data consumes. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From wk at gnupg.org Mon Oct 28 08:18:03 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Oct 2019 08:18:03 +0100 Subject: Should gpg try to connect to TCP/993? In-Reply-To: (Jay Sulzberger's message of "Fri, 25 Oct 2019 12:23:29 -0400 (EDT)") References: <8628619b-02fa-a453-6d84-4c24e8e75d5d@gmail.com> Message-ID: <87a79lcp90.fsf@wheatstone.g10code.de> On Fri, 25 Oct 2019 12:23, Jay Sulzberger said: > Is the following correct: > > When I use gpg to just encrypt or decrypt a file already on my > computer/OS's file system, then gpg does not open any formal > channels of communication going outside my computer/OS. No. By default gpg may go out for key discovery, CRLs, version checks etc. If you do not want this you can use the gpg option --disable-dirmngr or, to be 100%, do not install dirmngr. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From animarketnews at gmail.com Mon Oct 28 16:53:24 2019 From: animarketnews at gmail.com (Anil Kumar Pippalapalli) Date: Mon, 28 Oct 2019 10:53:24 -0500 Subject: gpg encrypt always creates a new encrypted file Message-ID: Hello, I am trying to encrypt a file on my system using gpg ?encrypt command but it always creates a new encrypted file I want to overwrite the original file instead so that I can only open it using passphrase. Is this possible. Thanks, Anil From phill at thesusis.net Mon Oct 28 20:40:12 2019 From: phill at thesusis.net (Phillip Susi) Date: Mon, 28 Oct 2019 15:40:12 -0400 Subject: gpg encrypt always creates a new encrypted file In-Reply-To: References: Message-ID: <87pnigek0z.fsf@vps.thesusis.net> Anil Kumar Pippalapalli via Gnupg-users writes: > Hello, > I am trying to encrypt a file on my system using gpg ?encrypt command but it always creates a new encrypted file I want to overwrite the original file instead so that I can only open it using passphrase. Is this possible. gpg -encrypt foo && mv foo.gpg foo From vedaal at nym.hush.com Mon Oct 28 21:40:09 2019 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Mon, 28 Oct 2019 16:40:09 -0400 Subject: gpg encrypt always creates a new encrypted file In-Reply-To: <87pnigek0z.fsf@vps.thesusis.net> References: <87pnigek0z.fsf@vps.thesusis.net> Message-ID: <20191028204010.06BA9C0731@smtp.hushmail.com> On 10/28/2019 at 3:43 PM, "Phillip Susi" wrote:Anil Kumar Pippalapalli via Gnupg-users writes: > Hello, > I am trying to encrypt a file on my system using gpg ?encrypt command but it always creates a new encrypted file I want to overwrite the original file instead so that I can only open it using passphrase. Is this possible. gpg -encrypt foo && mv foo.gpg foo ===== Alternatively, if you want no record of the plaintext written to a file at all, you can type it into the command line, and have only the encrypted output written: printf "whatever you write as plaintext" | gpg -a -e -r -o -filename.gpg | more (obviously not intended for big files, or non-text files, but occasionally a useful workaround if you aren't comfortable with your system's 'wipe' process.) vedaal From brianc1969 at gmail.com Mon Oct 28 22:45:01 2019 From: brianc1969 at gmail.com (Brian C) Date: Mon, 28 Oct 2019 15:45:01 -0600 Subject: gpg encrypt always creates a new encrypted file In-Reply-To: <20191028204010.06BA9C0731@smtp.hushmail.com> References: <87pnigek0z.fsf@vps.thesusis.net> <20191028204010.06BA9C0731@smtp.hushmail.com> Message-ID: <5a4cb6c5-23b0-1d68-0adb-db1436ddb2fa@gmail.com> Writing over the original file as "gpg -encrypt foo && mv foo.gpg foo" would do will also :potentially: leave remnants of the original unencrypted file around. The encrypted file will most likely be smaller (if plain text) than the original, thus not as many blocks may be used... also, I don't think a file system would ensure the :same: blocks will be used, so writing over the original file may not actually overwrite the original at all. I would suggest after creating the encrypted file, use a command such as "wipe" to securely delete the original file rather than trying to overwrite it. Brian On 10/28/19 2:40 PM, vedaal via Gnupg-users wrote: > On 10/28/2019 at 3:43 PM, "Phillip Susi" wrote:Anil Kumar Pippalapalli via Gnupg-users writes: > >> Hello, >> I am trying to encrypt a file on my system using gpg ?encrypt command but it always creates a new encrypted file I want to overwrite the original file instead so that I can only open it using passphrase. Is this possible. > > gpg -encrypt foo && mv foo.gpg foo > > ===== > > Alternatively, if you want no record of the plaintext written to a file at all, you can type it into the command line, and have only the encrypted output written: > > printf "whatever you write as plaintext" | gpg -a -e -r -o -filename.gpg | more > > (obviously not intended for big files, or non-text files, but occasionally a useful workaround if you aren't comfortable with your system's 'wipe' process.) > > > vedaal > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gnupg at raf.org Wed Oct 30 01:33:31 2019 From: gnupg at raf.org (raf) Date: Wed, 30 Oct 2019 11:33:31 +1100 Subject: How to improve our GUIs (was: We have GOT TO make things simpler) Message-ID: <20191030003331.stgm7magl7kpjwul@raf.org> Hi, Sorry if this was mentioned before but I've just come across a novel approach to email encryption that doesn't do end-to-end encryption, but rather it encrypts email upon receipt so that an individual can encrypt the email that is stored in their IMAP account as it arrives without the need for every sender to encrypt and without the need for any service provider's involvement (you just need an IMAP account), and it supports reading email from multiple devices, each with their own local private key. Most importantly, it doesn't require the user to know anything about encryption except that they want some. It might not address all threats but it certainly seems to solve some very real threats, mainly the threat of someone hacking into your IMAP account and accessing every email you ever received. Making It Easier to Encrypt Your Emails Authors: John S. Koh, Steven M. Bellovin, and Jason Nieh https://www.usenix.org/publications/login/fall2019/koh [paywall, usenix] Why Joanie Can Encrypt: Easy Email Encryption with Easy Key Management EuroSys '19 Proceedings of the Fourteenth EuroSys Conference 2019 Authors: John S. Koh, Steven M. Bellovin, Jason Nieh https://doi.org/10.1145/3302424.3303980 [paywall, acm] http://nieh.net/pubs/eurosys2019_e3.pdf [free] Easy Email Encryption with Easy Key Management Authors: John S. Koh, Steven M. Bellovin, Jason Nieh https://mice.cs.columbia.edu/getTechreport.php?techreportID=1639 [free] Automatically and invisibly encrypt email as soon as it is received on any trusted device https://www.helpnetsecurity.com/2019/04/01/easy-email-encryption/ [free] I know this doesn't help with the discussion of improving GUIs to make it easier to encrypt emails that you want to send, but it looks like a promising improvement in privacy that could help many more people than just those that want to encrypt emails that they send. And it's still relevant. I expect that those that want to encrypt any emails that they send might also like all the emails that they receive to be encrypted as well. cheers, raf From ryan at digicana.com Wed Oct 30 14:47:49 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Wed, 30 Oct 2019 13:47:49 +0000 Subject: How to improve our GUIs (was: We have GOT TO make things simpler) In-Reply-To: <20191030003331.stgm7magl7kpjwul@raf.org> References: <20191030003331.stgm7magl7kpjwul@raf.org> Message-ID: I might be missing something really obvious here but... what is this trying to protect against?? It's not protecting against interception in transit, since the message already transits the internet either in cleartext or encrypted via TLS that your email service provider can definitely read.? So if your goal is to protect the privacy of your email in transit, then this doesn't seem to do anything; if your goal is to protect the privacy of your email from your service provider snooping it, then this doesn't seem to do anything.? Your service provider can certainly (and probably does certainly) retain archive or backup copies of all emails that enter into and exit your account, so encrypting them after reception only means that the copy you are accessing is encrypted and non-accessible to the provider, but the copy that they archived or backed up is just as plaintext as always (or is, more likely, encrypted with a key that only they know).? The only time encrypting your email storage with a key only you have makes sense is if your provider pinkie promises to not store or archive anything on their servers other than what you see live in your email inbox.? Or, for example, if it's something like Protonmail does, which is never store anything on their servers that isn't encrypted with the user's private key that they don't have, so even their backups are something they can't access the plaintext from.? And even then you are relying on their pinke-promise that they are doing this, it is not E2E unless you are sending messages to and from Protonmail users or you are PGP encrypting messages before they leave or arrive at the service.?? And E2E is really the only solution that keeps your email provably private from all parties concerned other than the recipients.? On 10/29/2019 7:33 PM, raf via Gnupg-users wrote: > Hi, > > Sorry if this was mentioned before but I've just come > across a novel approach to email encryption that > doesn't do end-to-end encryption, but rather it > encrypts email upon receipt so that an individual can > encrypt the email that is stored in their IMAP account > as it arrives without the need for every sender to > encrypt and without the need for any service provider's > involvement (you just need an IMAP account), and it > supports reading email from multiple devices, each with > their own local private key. Most importantly, it > doesn't require the user to know anything about > encryption except that they want some. > > It might not address all threats but it certainly seems > to solve some very real threats, mainly the threat of > someone hacking into your IMAP account and accessing > every email you ever received. > > Making It Easier to Encrypt Your Emails > Authors: John S. Koh, Steven M. Bellovin, and Jason Nieh > https://www.usenix.org/publications/login/fall2019/koh [paywall, usenix] > > Why Joanie Can Encrypt: Easy Email Encryption with Easy Key Management > EuroSys '19 Proceedings of the Fourteenth EuroSys Conference 2019 > Authors: John S. Koh, Steven M. Bellovin, Jason Nieh > https://doi.org/10.1145/3302424.3303980 [paywall, acm] > http://nieh.net/pubs/eurosys2019_e3.pdf [free] > > Easy Email Encryption with Easy Key Management > Authors: John S. Koh, Steven M. Bellovin, Jason Nieh > https://mice.cs.columbia.edu/getTechreport.php?techreportID=1639 [free] > > Automatically and invisibly encrypt email as soon as it is received on any trusted device > https://www.helpnetsecurity.com/2019/04/01/easy-email-encryption/ [free] > > I know this doesn't help with the discussion of > improving GUIs to make it easier to encrypt emails that > you want to send, but it looks like a promising > improvement in privacy that could help many more people > than just those that want to encrypt emails that they > send. And it's still relevant. I expect that those that > want to encrypt any emails that they send might also > like all the emails that they receive to be encrypted > as well. > > cheers, > raf > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- -Ryan McGinnis https://bigstormpicture.com Sent via ProtonMail -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 839 bytes Desc: OpenPGP digital signature URL: From jays at panix.com Wed Oct 30 17:04:14 2019 From: jays at panix.com (Jay Sulzberger) Date: Wed, 30 Oct 2019 12:04:14 -0400 (EDT) Subject: Should gpg try to connect to TCP/993? In-Reply-To: <87a79lcp90.fsf@wheatstone.g10code.de> References: <8628619b-02fa-a453-6d84-4c24e8e75d5d@gmail.com> <87a79lcp90.fsf@wheatstone.g10code.de> Message-ID: On Mon, 28 Oct 2019, Werner Koch wrote: > On Fri, 25 Oct 2019 12:23, Jay Sulzberger said: > >> Is the following correct: >> >> When I use gpg to just encrypt or decrypt a file already on my >> computer/OS's file system, then gpg does not open any formal >> channels of communication going outside my computer/OS. > > No. By default gpg may go out for key discovery, CRLs, version checks > etc. If you do not want this you can use the gpg option > --disable-dirmngr or, to be 100%, do not install dirmngr. > > > Salam-Shalom, > > Werner Dear Werner, thank you for answer! And for work on GNUpg! oo--JS. > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From brian at minton.name Wed Oct 30 22:19:51 2019 From: brian at minton.name (Brian Minton) Date: Wed, 30 Oct 2019 17:19:51 -0400 Subject: Question about symmetric AES cipher in GnuPG In-Reply-To: <20191027202510.000077ee.sac@300baud.de> References: <20191027202510.000077ee.sac@300baud.de> Message-ID: <0b687218-2c60-c9a3-09d4-8677a7ca405d@minton.name> On 10/27/19 3:25 PM, Stefan Claas via Gnupg-users wrote: > gpg --symmetric --cipher-algo AES256 hw.txt gives me a file > size of 87 Bytes. > > Doing the same with openssl, for example: > > openssl enc -aes-256-cbc -pbkdf2 -in hw.txt -out hw.enc > > results in 32 Bytes. > > Can you please, or somebody else, explain in laymen terms why this is so? My guess is, the gpg one also is doing MDC, so you'd have to add the equivalent HMAC code to openssl, but that's just a complete guess.?? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 456 bytes Desc: OpenPGP digital signature URL: