From stefan.claas at posteo.de Tue May 1 10:55:52 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 1 May 2018 10:55:52 +0200 Subject: gpgsm --verify In-Reply-To: <6ea51451-8d60-ec7a-d9a8-d2470c02e9ca@posteo.de> References: <8be13dfe-d0a9-65e2-0123-377e1df44266@posteo.de> <87zi1uctut.fsf@wheatstone.g10code.de> <6ea51451-8d60-ec7a-d9a8-d2470c02e9ca@posteo.de> Message-ID: <46c46600-2554-d209-2c3e-949a208d8272@posteo.de> Am 23.04.18 um 08:50 schrieb Stefan Claas: > Am 23.04.18 um 08:36 schrieb Werner Koch: >> On Sun, 22 Apr 2018 20:26, stefan.claas at posteo.de said: >> >>> i was wondering when receiving an S/MIME >>> message created with Thunderbird, how do >>> i properly verify the message with gpgsm? >> You need to de-compose the S/MIME message to get the CMS objects. >> Despit ethe name, gpgsm does not known about S/MIME (or MIME at all) and >> thus can't parse it.? That is actually the same as with PGP/MIME which >> can't be handled directly by gpg [1]. >> >> In gnupg/tools/ you can find a basic MIME parser but it is not well >> documented and only used for manual testing. >> > Thank you very much for the information! > > I will check out the MIME parser. Just for the record... I was not able to successfully compile the parser and did therefore the following: I saved in Thunderbird my original message from this thread. Edited out the additional headers the list server has added, so that the saved message looks like this: [snip] Sender: "Gnupg-users" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070707040603000709040508" This is a cryptographically signed message in MIME format. --------------ms070707040603000709040508 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: de-DE Hi all, i was wondering when receiving an S/MIME message created with Thunderbird, how do i properly verify the message with gpgsm? As an example i sign now this message and would appreciate any tips! P.S. when i do a verify on a Thunderbird S/MIME message i always get: gpgsm: enabled debug flags: ipc gpgsm: ksba_cms_parse failed: Dateiende secmem usage: 0/16384 bytes in 0 blocks Best regards Stefan --------------ms070707040603000709040508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC [snip] pfXbwE0DHTM+Fp8xjnGXHBD+8Jfp/R5pAVZehZXh6UYzFMjdS6LzWWM+c2/M9Cum2GS49Q8d g82Q6zqwFZp4LvVfAAAAAAAA --------------ms070707040603000709040508-- and for de-composing the message i used openssl, so that i had the content ready to be verified by gpgsm. IMHO not the smartest way, i assume, but for me as a Mac dummie it works. openssl cms -verify -in original.eml > message.txt && \ openssl cms -cmsout -in original.eml | \ sed "1,4d" | base64 -d > file.sig && \ gpgsm --verify file.sig message.txt Regards Stefan From wk at gnupg.org Wed May 2 07:29:59 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 May 2018 07:29:59 +0200 Subject: CRL server error with gpgsm In-Reply-To: <20180429202742.smkuoh2w2nflrveo@hades> ("Marvin =?utf-8?Q?G?= =?utf-8?Q?=C3=BClker=22's?= message of "Sun, 29 Apr 2018 22:27:42 +0200") References: <20180429202742.smkuoh2w2nflrveo@hades> Message-ID: <87tvrqaalk.fsf@wheatstone.g10code.de> On Sun, 29 Apr 2018 22:27, m-guelker at phoenixmail.de said: > gpgsm: checking the CRL failed: Server indicated a failure > gpgsm: error creating signature: Server indicated a failure Dirmngr (the network access component of GnuPG) got an DNS error; that is it can't find the IP of the requested server with the CRL. > gpgsm (GnuPG) 2.1.18 We have fixed quite a bit since 2.1.18 and I don't know how much of that has been backported by Debian. > gpgsm version on the Gentoo system: > > $ gpgsm --version > gpgsm (GnuPG) 2.2.4 As you wrote it does not happen in this version; so updating to the latest version will fix the problem. For Debian specific bugs, dkg might be able to help. As a possible workaround you can try to add standard-resolver to ~/.gnupg/dirmngr.conf Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed May 2 07:35:59 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 May 2018 07:35:59 +0200 Subject: gpgsm --verify In-Reply-To: <46c46600-2554-d209-2c3e-949a208d8272@posteo.de> (Stefan Claas's message of "Tue, 1 May 2018 10:55:52 +0200") References: <8be13dfe-d0a9-65e2-0123-377e1df44266@posteo.de> <87zi1uctut.fsf@wheatstone.g10code.de> <6ea51451-8d60-ec7a-d9a8-d2470c02e9ca@posteo.de> <46c46600-2554-d209-2c3e-949a208d8272@posteo.de> Message-ID: <87po2eaabk.fsf@wheatstone.g10code.de> On Tue, 1 May 2018 10:55, stefan.claas at posteo.de said: > openssl cms -verify -in original.eml > message.txt && \ > openssl cms -cmsout -in original.eml | \ > sed "1,4d" | base64 -d > file.sig && \ > gpgsm --verify file.sig message.txt Adding --verbose to the gpgsm invocation may give you additional hints. IIRC, "--debug x509" may be helpful to. Is file.sig a valid CMS file; that is can you parse it with dumpasn1 or the openssl sub-command? BTW, gpgsm has an option --assume-base64 so that you don't need the base64 tool. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From stefan.claas at posteo.de Wed May 2 08:28:51 2018 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 2 May 2018 08:28:51 +0200 Subject: gpgsm --verify In-Reply-To: <87po2eaabk.fsf@wheatstone.g10code.de> References: <8be13dfe-d0a9-65e2-0123-377e1df44266@posteo.de> <87zi1uctut.fsf@wheatstone.g10code.de> <6ea51451-8d60-ec7a-d9a8-d2470c02e9ca@posteo.de> <46c46600-2554-d209-2c3e-949a208d8272@posteo.de> <87po2eaabk.fsf@wheatstone.g10code.de> Message-ID: Am 02.05.18 um 07:35 schrieb Werner Koch: > On Tue, 1 May 2018 10:55, stefan.claas at posteo.de said: > >> openssl cms -verify -in original.eml > message.txt && \ >> openssl cms -cmsout -in original.eml | \ >> sed "1,4d" | base64 -d > file.sig && \ >> gpgsm --verify file.sig message.txt > Adding --verbose to the gpgsm invocation may give you additional hints. > IIRC, "--debug x509" may be helpful to. Is file.sig a valid CMS file; > that is can you parse it with dumpasn1 or the openssl sub-command? > > BTW, gpgsm has an option --assume-base64 so that you don't need the base64 > tool. > Thank you very much for the addional information, much appreciated! Yes, file.sig can be parsed with dumpasn1. Regards Stefan From m-guelker at phoenixmail.de Wed May 2 08:45:38 2018 From: m-guelker at phoenixmail.de (Marvin =?utf-8?Q?G=C3=BClker?=) Date: Wed, 2 May 2018 08:45:38 +0200 Subject: CRL server error with gpgsm In-Reply-To: <87tvrqaalk.fsf@wheatstone.g10code.de> References: <20180429202742.smkuoh2w2nflrveo@hades> <87tvrqaalk.fsf@wheatstone.g10code.de> Message-ID: <20180502064538.buvladvpb4l2ivrn@hades> Hi, Am 02. Mai 2018 um 07:29 Uhr +0200 schrieb Werner Koch: > Dirmngr (the network access component of GnuPG) got an DNS error; that > is it can't find the IP of the requested server with the CRL. Ah, thanks. That's something I can work with. > As a possible workaround you can try to add > > standard-resolver > > to ~/.gnupg/dirmngr.conf I have to admit that I can't reproduce the problem today anymore. Maybe it was some temporary error in my network configuration then as I'm just setting up this machine and fiddled around the network configuration quite a bit. Thank you anyway! Marvin -- Blog: https://mg.guelker.eu PGP/GPG ID: F1D8799FBCC8BC4F From stefan.claas at t-online.de Wed May 2 08:20:05 2018 From: stefan.claas at t-online.de (Stefan Claas) Date: Wed, 2 May 2018 08:20:05 +0200 Subject: gpgsm --verify In-Reply-To: <87po2eaabk.fsf@wheatstone.g10code.de> References: <8be13dfe-d0a9-65e2-0123-377e1df44266@posteo.de> <87zi1uctut.fsf@wheatstone.g10code.de> <6ea51451-8d60-ec7a-d9a8-d2470c02e9ca@posteo.de> <46c46600-2554-d209-2c3e-949a208d8272@posteo.de> <87po2eaabk.fsf@wheatstone.g10code.de> Message-ID: <63d5db1e-6d7d-23d2-6cf3-908e37eaa64a@t-online.de> Am 02.05.18 um 07:35 schrieb Werner Koch: > On Tue, 1 May 2018 10:55, stefan.claas at posteo.de said: > >> openssl cms -verify -in original.eml > message.txt && \ >> openssl cms -cmsout -in original.eml | \ >> sed "1,4d" | base64 -d > file.sig && \ >> gpgsm --verify file.sig message.txt > Adding --verbose to the gpgsm invocation may give you additional hints. > IIRC, "--debug x509" may be helpful to. Is file.sig a valid CMS file; > that is can you parse it with dumpasn1 or the openssl sub-command? > > BTW, gpgsm has an option --assume-base64 so that you don't need the base64 > tool. > Thank you very much for the additional information, much appreciated! Yes, file.sig can be parsed with dumpasn1. Regards Stefan From wk at gnupg.org Wed May 2 22:10:52 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 May 2018 22:10:52 +0200 Subject: [Announce] GnuPG 2.2.7 released Message-ID: <87vac5es37.fsf@wheatstone.g10code.de> Hello! We are is pleased to announce the availability of a new GnuPG release: version 2.2.7. This is a maintenance release; see below for a list of fixed bugs. About GnuPG =========== The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. As an Universal Crypto Engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.7 =================================== * gpg: New option --no-symkey-cache to disable the passphrase cache for symmetrical en- and decryption. * gpg: The ERRSIG status now prints the fingerprint if that is part of the signature. * gpg: Relax emitting of FAILURE status lines * gpg: Add a status flag to "sig" lines printed with --list-sigs. * gpg: Fix "Too many open files" when using --multifile. [#3951] * ssh: Return an error for unknown ssh-agent flags. [#3880] * dirmngr: Fix a regression since 2.1.16 which caused corrupted CRL caches under Windows. [#2448,#3923] * dirmngr: Fix a CNAME problem with pools and TLS. Also use a fixed mapping of keys.gnupg.net to sks-keyservers.net. [#3755] * dirmngr: Try resurrecting dead hosts earlier (from 3 to 1.5 hours). * dirmngr: Fallback to CRL if no default OCSP responder is configured. * dirmngr: Implement CRL fetching via https. Here a redirection to http is explictly allowed. * dirmngr: Make LDAP searching and CRL fetching work under Windows. This stopped working with 2.1. [#3937] * agent,dirmngr: New sub-command "getenv" for "getinfo" to ease debugging. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.7 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.7.tar.bz2 (6475k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.7.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.7_20180502.exe (3814k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.7_20180502.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new Gpg4win installer featuring this version of GnuPG will be available soon. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.7.tar.bz2 you would use this command: gpg --verify gnupg-2.2.7.tar.bz2.sig gnupg-2.2.7.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.7.tar.bz2, you run the command like this: sha1sum gnupg-2.2.7.tar.bz2 and check that the output matches the next line: e222cda63409a86992369df8976f6c7511e10ea0 gnupg-2.2.7.tar.bz2 a00f7119c85dd837336f13be3174178d0cf8d85e gnupg-w32-2.2.7_20180502.exe 46ac3b8e95f49a602c3f4b447803d80509867d11 gnupg-w32-2.2.7_20180502.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details availabale only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and one contractor. Both work exclusively on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We are planning to extend our team again and to help developers to improve integration of crypto in their applications. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu May 3 10:14:09 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 May 2018 10:14:09 +0200 Subject: Quick commands documentation In-Reply-To: <6d6ea158-b0d0-ab8e-c38d-e2b768d3184a@andrewg.com> (Andrew Gallagher's message of "Thu, 26 Apr 2018 10:05:59 +0100") References: <6d6ea158-b0d0-ab8e-c38d-e2b768d3184a@andrewg.com> Message-ID: <87muxhdulq.fsf@wheatstone.g10code.de> On Thu, 26 Apr 2018 11:05, andrewg at andrewg.com said: > There's a suspiciously empty documentation page on the main site: I agree that it is pretty terse but it refers to another section with the actual description of the commands. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Thu May 3 11:03:29 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 3 May 2018 10:03:29 +0100 Subject: Quick commands documentation In-Reply-To: <87muxhdulq.fsf@wheatstone.g10code.de> References: <6d6ea158-b0d0-ab8e-c38d-e2b768d3184a@andrewg.com> <87muxhdulq.fsf@wheatstone.g10code.de> Message-ID: <7deee16e-6cec-2e54-b595-7a2b9c371084@andrewg.com> On 2018/05/03 09:14, Werner Koch wrote: > On Thu, 26 Apr 2018 11:05, andrewg at andrewg.com said: > >> There's a suspiciously empty documentation page on the main site: > > I agree that it is pretty terse but it refers to another section with > the actual description of the commands. Aha, I was misreading that reference as one to "Programmatic use of GnuPG". Perhaps it would be clearer if that section was refactored a little, from: ``` Recent versions of GnuPG have an interface to manipulate keys without using the interactive command --edit-key. This interface was added mainly for the benefit of GPGME (please consider using GPGME, see the manual subsection ?Programmatic use of GnuPG?). This interface is described in the subsection ?How to manage your keys?. ``` to: ``` Recent versions of GnuPG have an interface to manipulate keys without using the interactive command --edit-key. The non-interactive --quick-* commands are described in the subsection ?How to manage your keys?. The non-interactive interface was added mainly for the benefit of GPGME, which is described in the manual subsection ?Programmatic use of GnuPG?. ``` A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jonas.hegemann at tu-dortmund.de Thu May 3 10:09:33 2018 From: jonas.hegemann at tu-dortmund.de (Jonas Hegemann) Date: Thu, 3 May 2018 10:09:33 +0200 Subject: use gpg-agent for ssh login Message-ID: <6adcba51673bb6dfe61409ba9f8fb900.squirrel@webmail.tu-dortmund.de> Hi, I'm trying to configure gpg-agent and SSH with a GnuPG Key Card Version 3.3, but ssh only drops the message: "the agent has no identities." in response to "ssh-add -L". My system: Linux (K)ubuntu 16.04 My software versions: gpg 1.4.20 gpg-agent 2.1.11 libgcrypt 1.6.5 My configuration: Starting the agent: killall scdaemon killall gpg-agent eval $( gpg-agent --daemon --enable-ssh-support ) Setting the environment variables: SSH_AGENT_PID=2588 GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent:2588:1 SSH_AUTH_SOCK=$HOME/.gnupg/S.gpg-agent.ssh GPG_TTY=/dev/pts/1 (corresponding to used terminal) note that 2588 is the PID of the gpg-agent here. scdaemon is running (started by gpg-agent) pcscd is NOT running. .gnupg/gpg.conf: use-agent .gnupg/gpg-agent.conf: enable-ssh-support default-cache-ttl 21600 default-cache-ttl-ssh 21600 pinentry-program /usr/bin/pinentry-gtk-2 After carefully reviewing my configuration and restarting my agent I still get a message "The agent has no identities." in response to "ssh-add -L". However, the status of the smart-card looks fine and all the keys are present on the card. Why does ssh not see the keys? Does anyone have a suggestion for changes? Are there specific issues with the card version 3.3? Thanks in advance Jonas From alex at nitrokey.com Thu May 3 11:42:27 2018 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Thu, 3 May 2018 11:42:27 +0200 Subject: use gpg-agent for ssh login In-Reply-To: <6adcba51673bb6dfe61409ba9f8fb900.squirrel@webmail.tu-dortmund.de> References: <6adcba51673bb6dfe61409ba9f8fb900.squirrel@webmail.tu-dortmund.de> Message-ID: <771a8ac2-2066-ec7d-b399-5eca66cdbfe4@nitrokey.com> Hi, did you install gnupg2 as well? OpenPGP Card 3.3 is not supported by oldoldold version 1.4 ... I don't know if gnupg2 is installed by default on Kubuntu and I don't know if gnupg2 is recent enough on 16.04 either. You may install the stable debian ones if needed. They should be able to work with the card. Kind regards Alex On 03.05.2018 10:09, Jonas Hegemann wrote: > Hi, > > I'm trying to configure gpg-agent and SSH with a GnuPG Key Card Version > 3.3, but ssh only drops the message: "the agent has no identities." in > response to "ssh-add -L". > > My system: > Linux (K)ubuntu 16.04 > > My software versions: > gpg 1.4.20 > gpg-agent 2.1.11 > libgcrypt 1.6.5 > > My configuration: > Starting the agent: > killall scdaemon > killall gpg-agent > eval $( gpg-agent --daemon --enable-ssh-support ) > Setting the environment variables: > SSH_AGENT_PID=2588 > GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent:2588:1 > SSH_AUTH_SOCK=$HOME/.gnupg/S.gpg-agent.ssh > GPG_TTY=/dev/pts/1 (corresponding to used terminal) > > note that 2588 is the PID of the gpg-agent here. > scdaemon is running (started by gpg-agent) > pcscd is NOT running. > > .gnupg/gpg.conf: > use-agent > > .gnupg/gpg-agent.conf: > enable-ssh-support > default-cache-ttl 21600 > default-cache-ttl-ssh 21600 > pinentry-program /usr/bin/pinentry-gtk-2 > > After carefully reviewing my configuration and restarting my agent I still > get a message "The agent has no identities." in response to "ssh-add -L". > However, the status of the smart-card looks fine and all the keys are > present on the card. Why does ssh not see the keys? Does anyone have a > suggestion for changes? Are there specific issues with the card version > 3.3? > > Thanks in advance > Jonas > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From demfloro at demfloro.ru Fri May 4 08:58:40 2018 From: demfloro at demfloro.ru (Dmitrii Tcvetkov) Date: Fri, 4 May 2018 09:58:40 +0300 Subject: use gpg-agent for ssh login In-Reply-To: <6adcba51673bb6dfe61409ba9f8fb900.squirrel@webmail.tu-dortmund.de> References: <6adcba51673bb6dfe61409ba9f8fb900.squirrel@webmail.tu-dortmund.de> Message-ID: <20180504095809.7bfbdbe8@job> > Hi, > > I'm trying to configure gpg-agent and SSH with a GnuPG Key Card > Version 3.3, but ssh only drops the message: "the agent has no > identities." in response to "ssh-add -L". > > My system: > Linux (K)ubuntu 16.04 > > My software versions: > gpg 1.4.20 > gpg-agent 2.1.11 > libgcrypt 1.6.5 > > My configuration: > Starting the agent: > killall scdaemon > killall gpg-agent > eval $( gpg-agent --daemon --enable-ssh-support ) > Setting the environment variables: > SSH_AGENT_PID=2588 > GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent:2588:1 > SSH_AUTH_SOCK=$HOME/.gnupg/S.gpg-agent.ssh > GPG_TTY=/dev/pts/1 (corresponding to used terminal) > > note that 2588 is the PID of the gpg-agent here. > scdaemon is running (started by gpg-agent) > pcscd is NOT running. > > .gnupg/gpg.conf: > use-agent > > .gnupg/gpg-agent.conf: > enable-ssh-support > default-cache-ttl 21600 > default-cache-ttl-ssh 21600 > pinentry-program /usr/bin/pinentry-gtk-2 > > After carefully reviewing my configuration and restarting my agent I > still get a message "The agent has no identities." in response to > "ssh-add -L". However, the status of the smart-card looks fine and > all the keys are present on the card. Why does ssh not see the keys? > Does anyone have a suggestion for changes? Are there specific issues > with the card version 3.3? gpg-agent will list identity only if key has Authenticate capability and it's keygrip is listed in ${HOME}/.gnupg/sshcontrol To get key's keygrip you can use "gpg -K --with-keygrip". You want to list keygrip of the specific subkey with the Authenticate capability, not it's primary key. From peter at digitalbrains.com Fri May 4 10:41:21 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 4 May 2018 10:41:21 +0200 Subject: use gpg-agent for ssh login In-Reply-To: <20180504095809.7bfbdbe8@job> References: <6adcba51673bb6dfe61409ba9f8fb900.squirrel@webmail.tu-dortmund.de> <20180504095809.7bfbdbe8@job> Message-ID: <82d886fb-b07d-1ac6-e629-33ba3c5fd058@digitalbrains.com> On 04/05/18 08:58, Dmitrii Tcvetkov wrote: > gpg-agent will list identity only if key has Authenticate capability > and it's keygrip is listed in ${HOME}/.gnupg/sshcontrol That's incorrect. If you insert an OpenPGP smartcard with a key in the Authenticate slot, it will make that key available to the SSH agent system. That is regardless of listing in sshcontrol. The difference is that if you list it in sshcontrol, and a server indicates acceptance of that key, the pinentry will prompt you to insert that smartcard for authentication even when the smartcard is not inserted. Whereas if it is not in sshcontrol and not currently inserted either, the key will never be offered to the server in the first place. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From demfloro at demfloro.ru Fri May 4 10:51:34 2018 From: demfloro at demfloro.ru (Dmitrii Tcvetkov) Date: Fri, 4 May 2018 11:51:34 +0300 Subject: use gpg-agent for ssh login In-Reply-To: <82d886fb-b07d-1ac6-e629-33ba3c5fd058@digitalbrains.com> References: <6adcba51673bb6dfe61409ba9f8fb900.squirrel@webmail.tu-dortmund.de> <20180504095809.7bfbdbe8@job> <82d886fb-b07d-1ac6-e629-33ba3c5fd058@digitalbrains.com> Message-ID: <20180504115121.3158d0b1@job> > On 04/05/18 08:58, Dmitrii Tcvetkov wrote: > > gpg-agent will list identity only if key has Authenticate capability > > and it's keygrip is listed in ${HOME}/.gnupg/sshcontrol > > That's incorrect. If you insert an OpenPGP smartcard with a key in the > Authenticate slot, it will make that key available to the SSH agent > system. That is regardless of listing in sshcontrol. > > The difference is that if you list it in sshcontrol, and a server > indicates acceptance of that key, the pinentry will prompt you to > insert that smartcard for authentication even when the smartcard is > not inserted. Whereas if it is not in sshcontrol and not currently > inserted either, the key will never be offered to the server in the > first place. Interesting, thanks you. From jonas.hegemann at tu-dortmund.de Fri May 4 13:03:19 2018 From: jonas.hegemann at tu-dortmund.de (Jonas Hegemann) Date: Fri, 4 May 2018 13:03:19 +0200 Subject: use gpg-agent for ssh login Message-ID: <014936a5e00f2141587c1514fb081743.squirrel@webmail.tu-dortmund.de> Thanks all for your suggestions! Alexander's suggestion worked! Installing the newest software versions solved the Problem for me! GPG 2.2.7 libgpg-error 1.31 libgcrypt 1.82 libassuan 2.51 libksba 1.35 npth 1.5 -- Jonas Hegemann Technische Universitaet Dortmund Lehrstuhl fuer Theoretische Physik I D-44221 Dortmund, Germany From kothariyugesh at gmail.com Tue May 8 06:16:36 2018 From: kothariyugesh at gmail.com (Yugesh Kothari) Date: Tue, 8 May 2018 09:46:36 +0530 Subject: Python Bindings for GPGME Message-ID: Hello all, I'm looking to write a GUI around the existing philosophy-of-use of EasyGnuPG (https://github.com/EasyGnuPG/egpg) as part of my GSoC project this summers. I was therefore looking to find the best ways to wrap GnuPG from Python scripts rather than using outputs from gpg2 binary. I see there are two principal bindings available PyMe and PyGPGME. Both seem to be relatively un-maintained for the past few years now (2008 for PyMe and 2012 for PyGPGME): http://pyme.sourceforge.net/https://launchpad.net/pygpgme Some of the features I'd like to be working with are: 1. Encrypting/Decrypting files. Decryption done using user's default keyrings. 2. Listing keys and encryption sub-keys. 3. Maintaining contacts 4. Generating new keys So, my question is - has anyone worked with Python and GPGME? Which bindings are better in your opinion? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tookmund at gmail.com Tue May 8 17:49:05 2018 From: tookmund at gmail.com (Jacob Adams) Date: Tue, 8 May 2018 11:49:05 -0400 Subject: Python Bindings for GPGME In-Reply-To: References: Message-ID: > On May 8, 2018, at 00:16, Yugesh Kothari wrote: > > Hello all, > > I'm looking to write a GUI around the existing philosophy-of-use of EasyGnuPG (https://github.com/EasyGnuPG/egpg) as part of my GSoC project this summers. I was therefore looking to find the best ways to wrap GnuPG from Python scripts rather than using outputs from gpg2 binary. I see there are two principal bindings available PyMe and PyGPGME. > > Both seem to be relatively un-maintained for the past few years now (2008 for PyMe and 2012 for PyGPGME): > > http://pyme.sourceforge.net/ > https://launchpad.net/pygpgme > > Some of the features I'd like to be working with are: > > 1. Encrypting/Decrypting files. Decryption done using user's default keyrings. > > 2. Listing keys and encryption sub-keys. > > 3. Maintaining contacts > > 4. Generating new keys > > So, my question is - has anyone worked with Python and GPGME? Which bindings are better in your opinion? > I?m a GSoC student as well and I asked a similar question on the pki-clean-room-devel list. The relevant part of the response I got from Debian?s GPGME maintainer is quoted below, the full message can be found here: https://alioth-lists.debian.net/pipermail/pki-clean-room-devel/Week-of-Mon-20180108/000071.html ?If you want to use GnuPG with python3, please use python3-gpg (for python2, use python-gpg). These packages are built and shipped as part of gpgme, which is maintained by the GnuPG developers.? I?m not sure what platform you?re developing on but the python3-gpg package in Debian corresponds to the official Python GPGME bindings which are shipped with recent versions of GPGME. Hope this helps, Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From dima at stopel.org Thu May 10 21:23:17 2018 From: dima at stopel.org (Dima Stopel) Date: Thu, 10 May 2018 19:23:17 +0000 Subject: Setting up two identical Yubikeys - specific error In-Reply-To: References: Message-ID: The issue is solved by using gpg2. Didn't work with: gpg (GnuPG) 1.4.20 Works with: gpg (GnuPG) 2.1.11 Thanks and sorry for the spam ________________________________ From: Dima Stopel Sent: Thursday, May 10, 2018 9:43:07 PM To: gnupg-users at gnupg.org Subject: Setting up two identical Yubikeys - specific error Hi all My goal is to set up two Yubikeys (YK1 and YK2) with the same GPG keys (one to use daily and one for backup). Following this (https://gist.github.com/ageis/14adc308087859e199912b4c79c4aaa4) tutorial I created a signing key and two subkeys, one for encryption and one for authorization. Keys were moved to YKs successfully and I backed up everything including stubs for both YKs. Stubs were exported using: gpg --armor --output stubs.asc --export-secret-keys Then I did the following: 1. Import public key and stubs(YK1) on another computer: gpg --import public.asc stubs1.asc 2. Encrypt a message with the public key: gpg -e -r file.txt 3. Decrypt the message with: gpg -d file.txt.gpg 4. Being asked to insert YK1 and insert PIN 5. Decryption went successfully Then I wanted to test YK2 and I used the same file.txt.gpg, as I used before (didn't encrypt a new one). So I did the following: 1. Delete private stubs: gpg --delete-secret-keys 2. Import stubs (YK2): gpg --import stubs2.asc 3. Decrypt the message with: gpg -d file.txt.gpg 4. Being asked to insert *YK2* and insert PIN 5. While I insert PIN I see the error below (I am sure the PIN is correct): $ gpg -d text.txt.gpg Please enter the PIN gpg: verify CHV2 failed: invalid passphrase gpg: encrypted with 2048-bit RSA key, ID 701E4F69, created 2018-05-10 "Dima Stopel " gpg: public key decryption failed: invalid passphrase gpg: decryption failed: secret key not available What am I doing wrong? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From dima at stopel.org Thu May 10 20:43:07 2018 From: dima at stopel.org (Dima Stopel) Date: Thu, 10 May 2018 18:43:07 +0000 Subject: Setting up two identical Yubikeys - specific error Message-ID: Hi all My goal is to set up two Yubikeys (YK1 and YK2) with the same GPG keys (one to use daily and one for backup). Following this (https://gist.github.com/ageis/14adc308087859e199912b4c79c4aaa4) tutorial I created a signing key and two subkeys, one for encryption and one for authorization. Keys were moved to YKs successfully and I backed up everything including stubs for both YKs. Stubs were exported using: gpg --armor --output stubs.asc --export-secret-keys Then I did the following: 1. Import public key and stubs(YK1) on another computer: gpg --import public.asc stubs1.asc 2. Encrypt a message with the public key: gpg -e -r file.txt 3. Decrypt the message with: gpg -d file.txt.gpg 4. Being asked to insert YK1 and insert PIN 5. Decryption went successfully Then I wanted to test YK2 and I used the same file.txt.gpg, as I used before (didn't encrypt a new one). So I did the following: 1. Delete private stubs: gpg --delete-secret-keys 2. Import stubs (YK2): gpg --import stubs2.asc 3. Decrypt the message with: gpg -d file.txt.gpg 4. Being asked to insert *YK2* and insert PIN 5. While I insert PIN I see the error below (I am sure the PIN is correct): $ gpg -d text.txt.gpg Please enter the PIN gpg: verify CHV2 failed: invalid passphrase gpg: encrypted with 2048-bit RSA key, ID 701E4F69, created 2018-05-10 "Dima Stopel " gpg: public key decryption failed: invalid passphrase gpg: decryption failed: secret key not available What am I doing wrong? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk.gottschalk1980 at googlemail.com Fri May 11 00:42:25 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Fri, 11 May 2018 00:42:25 +0200 Subject: Where to send a "patch" to scute. Message-ID: <3f1a6f35de5fe18ab028814ad4017291b9fc9966.camel@googlemail.com> Hi. I use scute to sign my documents in LibreOffice and I was in need to be able to use a cert based upon my signature key. So I changed scute tu build 2 shared objects. The usual scute.so, which uses the authentication key, and scutrsig.so, which uses the signature key, for use with LibreOffice. Where shoult I send this a suggested feature? Is somebody interested in this out there? I append my patch to this mail, if somebody is interested in this "feature". There are only a few really small modigications, but it works fine for me. By the way, I forked the GitHub mirror of scute and made the changes there. The appendet file is the output of "git diff" relative to the latest commit in the official repository. My repository can be found at: https://github.com/Dirk1980ac/scute Regards, Dirk PS: The changes were made in some kind of dirty way, because I was in a hurry to get this working. If somebody has suggestions to make this in a cleaner way, feel free to comment. -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- next part -------------- A non-text attachment was scrubbed... Name: use-sig.patch Type: text/x-patch Size: 30438 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From borahparinita123 at gmail.com Fri May 11 06:57:34 2018 From: borahparinita123 at gmail.com (arinit) Date: Fri, 11 May 2018 10:27:34 +0530 Subject: Hi ,request help on a problem with gnupg that gpg decryption does not return after creating the decrypted file Message-ID: <5af522bf.1c69fb81.a194a.83b2@mx.google.com> Hello , Requesting inputs from anyone , if you have faced any issues on GPG decryption which is done uninteractively The version used is : gpg (GnuPG) Version: 2.2.4 / libgcrypt 1.8.2 windows And automated job is scheduled from controlM to run on a Windows Edition - Windows Server 2016 Datacenter. The return code is empty for decryption, even if it is handled at shell level , it looks GPG agent hangs and the job does not exit The automated job uses commands like below along with other housekeeping functionality gpg --debug-all -vvv --batch --pinentry-mode loopback --passphrase-file -o ?ouputfile? --yes ?decrypt ?file to decrypt? if it is made to kill the gpg ajent uninteractively after the outputs are generated then only the job exits with ok status Thanks , Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Fri May 11 13:17:22 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 11 May 2018 12:17:22 +0100 Subject: Where to send a "patch" to scute. In-Reply-To: <3f1a6f35de5fe18ab028814ad4017291b9fc9966.camel@googlemail.com> References: <3f1a6f35de5fe18ab028814ad4017291b9fc9966.camel@googlemail.com> Message-ID: Hi, On 05/10/2018 11:42 PM, Dirk Gottschalk via Gnupg-users wrote: > Where shoult I send this a suggested feature? Patches should be sent to gnupg-devel at gnupg.org, prefixing the subject with a "[PATCH scute]" tag. Same for feature requests. Alternatively, you may also create a Task in the GnuPG project's bug tracking system at https://dev.gnupg.org/. > Is somebody interested in this out there? As the maintainer of Scute, I am. :) > PS: The changes were made in some kind of dirty way, because I was in a > hurry to get this working. I just had a cursory look at the patch. Although I kind of like the idea, my main concern with it is the duplication of the entire src/slots.c file. I will not merge anything like that. > If somebody has suggestions to make this in a cleaner way, feel free to comment. Right now, my first idea would be to avoid duplicating src/slots.c and instead use info.grip1 or info.grip3 depending on the value of the ENABLE_SIGKEY flag. But I have to give it a little bit more thoughts. In the meantime, you might want to bring the topic to the gnupg-devel list, which is more appropriate for development-related discussions. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From franek.wiertara at onet.eu Sat May 12 18:09:45 2018 From: franek.wiertara at onet.eu (franek.wiertara) Date: Sat, 12 May 2018 18:09:45 +0200 Subject: Web of Trust and validation of keys Message-ID: <182529463-54d99b0932ea8f80cf7e5f3d58601405@pmq2v.m5r2.onet> Hi ? I am sorry if you find my comment a little less understanding. English is not my first language. Hopefully, I have described my problem clearly enough :) ? I have two problems. 1. I am not entirely sure what exactly marginally valid keys do and when they become marginally valid. I thought keys would either be valid or not! 2. I am also not fully confident in understanding Web of Trust. I have just got some bits today :) ? I realised, after reading the The GNU Privacy Handbook, if a key becomes valid due to the Web of Trust or signed personally, it can "participate" in validation of next keys, depending on my trust. What exactly happen if a key is marginally valid? ? I also provided some scenarios based on the website and an example of a network: ? ????????? .---> Blake ---. ???????? /??????????????? \ Alice ---?????????????????? ---> Chloe ---> Elena ---> Geoff ???????? \??????????????? /????????? \ ????????? *---> Dharma --*??????????? \ ????????????????????????? \??????????? \ ?????????????????????????? *----------->*---> Francis. ? Let's say Blake's and Dharma's keys are always valid because they are signed by Alice. In case any of those keys are fully trusted, Chloe's and Francis' keys will be fully validated. If Both Blake's and Dharma's keys are marginally trusted, Chloe's key will be still fully validated but Franci's will only be marginally validated. ? Now, when Chloe's key is fully valid, what happen to Elenaa's key? Will it become a fully or marginally valid key? I think it depends on whether I fully or marginally trust Chloe's key. ? There is lot of situations when keys can become marginally valid. I am guessing, marginal validation sort of blocks a further validation on the path. I am wondering why we are not simply to say that a key can be either valid or not? What am I missing? What is the consequence of a marginal validation? ? Thanks ? PS. For the example, I followed the assumptions from the website: "... two marginally-trusted keys or one fully-trusted key is needed to validate another key. The maximum path length is three." ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Sat May 12 21:58:49 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 12 May 2018 21:58:49 +0200 Subject: Web of Trust and validation of keys In-Reply-To: <182529463-54d99b0932ea8f80cf7e5f3d58601405@pmq2v.m5r2.onet> References: <182529463-54d99b0932ea8f80cf7e5f3d58601405@pmq2v.m5r2.onet> Message-ID: On 05/12/2018 06:09 PM, franek.wiertara wrote: > Hi > ? > I am sorry if you find my comment a little less understanding. English > is not my first language. Hopefully, I have described my problem clearly > enough :) > ? > I have two problems. > 1. I am not entirely sure what exactly marginally valid keys do and when > they become marginally valid. I thought keys would either be valid or not! marginally trusted isn't valid, the threshold is set using --marginals-needed n Number of marginally trusted users to introduce a new key signer (defaults to 3) i.e you need 3 signatures by default on a keyblock/uid for it to be treated as valid, if you don't have that it isn't. > 2. I am also not fully confident in understanding Web of Trust. I have > just got some bits today :) > ? > I realised, after reading the The GNU Privacy Handbook, if a key becomes > valid due to the Web of Trust or signed personally, it can "participate" > in validation of next keys, depending on my trust. What exactly happen > if a key is marginally valid? marginally valid -> not valid -> trust level doesn't matter (excluding ultimate trust that isn't to be used for other people's keys in these scenarios anyways) > ? > I also provided some scenarios based on the website and an example of a > network: > ? > ????????? .---> Blake ---. > ???????? /??????????????? \ > Alice ---?????????????????? ---> Chloe ---> Elena ---> Geoff > ???????? \??????????????? /????????? \ > ????????? *---> Dharma --*??????????? \ > ????????????????????????? \??????????? \ > ?????????????????????????? *----------->*---> Francis. > ? > Let's say Blake's and Dharma's keys are always valid because they are > signed by Alice. In case any of those keys are fully trusted, Chloe's > and Francis' keys will be fully validated. If Both Blake's and Dharma's > keys are marginally trusted, Chloe's key will be still fully validated > but Franci's will only be marginally validated. For Chloe's key to be validated in this scenario you'd require a direct path from Alice since there isn't 3 marginally trusted signatories (unless you introduce one from outside the schema). > ? > Now, when Chloe's key is fully valid, what happen to Elenaa's key? Will > it become a fully or marginally valid key? I think it depends on whether > I fully or marginally trust Chloe's key. Presuming Chloe's key is valid, yes, what happens down the chain depends on the trust level of this keyblock. > ? > There is lot of situations when keys can become marginally valid. I am > guessing, marginal validation sort of blocks a further validation on the > path. I am wondering why we are not simply to say that a key can be Blocks, how? > either valid or not? What am I missing? What is the consequence of a > marginal validation? It has the potential of becoming valid if signed by more marginally trusted people (or directly by someone with full trust) > ? > Thanks > ? > PS. For the example, I followed the assumptions from the website: "... > two marginally-trusted keys or one fully-trusted key is needed to > validate another key. The maximum path length is three." > ? > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- ---------------------------- 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 ---------------------------- "If you are successful, you may win false friends and true enemies. Succeed anyway." (Mother Teresa) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupgmlusers.fwnsp at xoxy.net Sat May 12 23:33:41 2018 From: gnupgmlusers.fwnsp at xoxy.net (Friedhelm Waitzmann) Date: Sat, 12 May 2018 23:33:41 +0200 Subject: Hi ,request help on a problem with gnupg that gpg decryption does not return after creating the decrypted file In-Reply-To: <5af522bf.1c69fb81.a194a.83b2@mx.google.com> References: <5af522bf.1c69fb81.a194a.83b2@mx.google.com> Message-ID: <20180512213341.GC30195@kugelfisch.zuhause.test> arinit: >gpg --debug-all -vvv --batch --pinentry-mode loopback --passphrase-file -o ?ouputfile? --yes ?decrypt ?file to decrypt? Doesn't ?--passphrase-file? need an argument, does it? If so, gpg looks for a passphrase file named ?-o?. Friedhelm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: Digital signature URL: From tookmund at gmail.com Mon May 14 00:26:04 2018 From: tookmund at gmail.com (Jacob Adams) Date: Sun, 13 May 2018 18:26:04 -0400 Subject: smartcards and GPGME Message-ID: <7caacadd-5b4f-9ff4-4678-39ed793fc5cf@gmail.com> Hello all, As part of a program I'm writing this summer for GSoC, I'd like to be able to both move gpg private keys to a smartcard and generate keys on the smartcard from an application. While this can be done from gpg, it doesn't look like I can do so from GPGME or any other wrappers that exist. Have I missed something or is this simply not possible yet? While I could wrap this functionality of gpg, I'd really prefer not to and I'd rather not drop the user to a gpg prompt if I don't have to. Thanks, Jacob From dirk.gottschalk1980 at googlemail.com Mon May 14 02:53:26 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Mon, 14 May 2018 02:53:26 +0200 Subject: smartcards and GPGME In-Reply-To: <7caacadd-5b4f-9ff4-4678-39ed793fc5cf@gmail.com> References: <7caacadd-5b4f-9ff4-4678-39ed793fc5cf@gmail.com> Message-ID: Hello Jacob. Am Sonntag, den 13.05.2018, 18:26 -0400 schrieb Jacob Adams: > Hello all, > > As part of a program I'm writing this summer for GSoC, I'd like to be > able to both move gpg private keys to a smartcard and generate keys > on > the smartcard from an application. While this can be done from gpg, > it > doesn't look like I can do so from GPGME or any other wrappers that > exist. Have I missed something or is this simply not possible yet? GPGsm does not do anything with GPG keys directly. The Keys it creates are stored inside GPGsm and are derived from GPG keys, AFAIU. For your purpose you have to use the GPGme library. > While I could wrap this functionality of gpg, I'd really prefer not > to > and I'd rather not drop the user to a gpg prompt if I don't have to. GPGme does what you are trying to do, without prompting, except for cases where PIN or password are required. This events are handled by gpg-agent. GPGsm is for managing X.509 certificates. I'm not sure if it can handle moved keys. It should, if it interaqcts with gpg-agent. That's something I'm not really sure of. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From aheinecke at intevation.de Mon May 14 07:49:53 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 14 May 2018 07:49:53 +0200 Subject: Hi , request help on a problem with gnupg that gpg decryption does not return after creating the decrypted file In-Reply-To: <5af522bf.1c69fb81.a194a.83b2@mx.google.com> References: <5af522bf.1c69fb81.a194a.83b2@mx.google.com> Message-ID: <2153480.g5tDCd7OmG@esus> Hi, On Friday, May 11, 2018 10:27:34 AM CEST arinit wrote: > Requesting inputs from anyone , if you have faced any issues on GPG decryption which is done uninteractively > > The version used is : gpg (GnuPG) Version: 2.2.4 / libgcrypt 1.8.2 windows > And automated job is scheduled from controlM to run on a Windows Edition - Windows Server 2016 Datacenter. > The return code is empty for decryption, even if it is handled at shell level , it looks GPG agent hangs and the job does not exit > The automated job uses commands like below along with other housekeeping functionality > gpg --debug-all -vvv --batch --pinentry-mode loopback --passphrase-file -o ?ouputfile? --yes ?decrypt ?file to decrypt? > if it is made to kill the gpg ajent uninteractively after the outputs are generated then only the job exits with ok status In addition to the note about the missing argument to passphrase-file, it might also be that you are running into: https://wiki.gnupg.org/TroubleShooting#Windows_. 3E_8_and_Server_2012_Task_Scheduler_Problems Using the task scheduler GNUPG has a different Home Directory, so you might want to parse the --homedir parameter to specify directly which home directory (the directory with the keys etc.) should be used. Best Regards, Andre Heinecke -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From aheinecke at intevation.de Mon May 14 08:02:19 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 14 May 2018 08:02:19 +0200 Subject: smartcards and GPGME In-Reply-To: <7caacadd-5b4f-9ff4-4678-39ed793fc5cf@gmail.com> References: <7caacadd-5b4f-9ff4-4678-39ed793fc5cf@gmail.com> Message-ID: <1526308442.npA4dopvpy@esus> Hi, On Sunday, May 13, 2018 6:26:04 PM CEST Jacob Adams wrote: > As part of a program I'm writing this summer for GSoC, I'd like to be > able to both move gpg private keys to a smartcard and generate keys on > the smartcard from an application. While this can be done from gpg, it > doesn't look like I can do so from GPGME or any other wrappers that > exist. Have I missed something or is this simply not possible yet? > > While I could wrap this functionality of gpg, I'd really prefer not to > and I'd rather not drop the user to a gpg prompt if I don't have to. This is both pretty complicated thorugh GPGME, as there is indeed not a direct interface. Kleopatra and GPA use the "AssuanEngine" of GPGME to connect to the gpg-agent's assuan interface and issue / parse commands directly through that connection. You might want to take a look at GPA's implementation: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpa.git;a=blob;f=src/cm-openpgp.c Alternatively instead of wrapping gpg (and using the complicated edit interface) you could also wrap "gpg-connect-agent" and issue commands to scdaemon through that. Best Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon May 14 08:23:08 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 May 2018 08:23:08 +0200 Subject: smartcards and GPGME In-Reply-To: <7caacadd-5b4f-9ff4-4678-39ed793fc5cf@gmail.com> (Jacob Adams's message of "Sun, 13 May 2018 18:26:04 -0400") References: <7caacadd-5b4f-9ff4-4678-39ed793fc5cf@gmail.com> Message-ID: <87wow692nn.fsf@wheatstone.g10code.de> On Mon, 14 May 2018 00:26, tookmund at gmail.com said: > the smartcard from an application. While this can be done from gpg, it > doesn't look like I can do so from GPGME or any other wrappers that > exist. Have I missed something or is this simply not possible yet? GPGME allows to do that. For example GPA has a card manager which can manage different types of cards and for some cards it is able to create keys. IIRC, moving keys to the card is not yet implemented but GPGME allows you to do implement that as well. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon May 14 09:45:51 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 May 2018 09:45:51 +0200 Subject: Efail or OpenPGP is safer than S/MIME Message-ID: <87mux28yts.fsf@wheatstone.g10code.de> Hi! Some may have noticed that the EFF has warnings about the use of PGP out which I consider pretty overblown. The GnuPG team was not contacted by the researchers but I got access to version of the paper related to KMail. It seems to be the complete paper with just the names of the other MUAs redacted. Given that the EFF suggests to deinstall GpgOL, we know tha it is not vulnerable; see see https://dev.gnupg.org/T3714.). Here is a response I wrote on the weekend to a reporter who inquired on this problem. ============= The topic of that paper is that HTML is used as a back channel to create an oracle for modified encrypted mails. It is long known that HTML mails and in particular external links like are evil if the MUA actually honors them (which many meanwhile seem to do again; see all these newsletters). Due to broken MIME parsers a bunch of MUAs seem to concatenate decrypted HTML mime parts which makes it easy to plant such HTML snippets. There are two ways to mitigate this attack - Don't use HTML mails. Or if you really need to read them use a proper MIME parser and disallow any access to external links. - Use authenticated encryption. The latter is actually easy for OpenPGP because we started to use authenticated encryption (AE) since 2000 or 2001. Our AE is called MDC (Modification detection code) and was back then introduced for a very similar attack. Unfortunately some OpenPGP implementations were late to introduce MDC and thus GPG could not fail hard on receiving a mail without an MDC. However, an error is returned during decrypting and no MDC is used: gpg: encrypted with 256-bit ECDH key, ID 7F3B7ED4319BCCA8, created 2017-01-01 "Werner Koch " [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_INFO 0 7 [GNUPG:] PLAINTEXT 62 1526109594 [GNUPG:] PLAINTEXT_LENGTH 69 There is more to life than increasing its speed. -- Mahatma Gandhi gpg: WARNING: message was not integrity protected [GNUPG:] DECRYPTION_FAILED [GNUPG:] END_DECRYPTION When giving a filename on the command line an output file is even not created. This can't be done in pipe mode because gpg allows to process huge amounts of data. MUAs are advised to consider the DECRYPTION_FAILED status code and not to show the data or at least use a proper way to display the possible corrupted mail without creating an oracle and to inform the user that the mail is fishy. For S/MIME authenticated encryption is not used or implemented in practice and thus there is no short term way to fix this in S/MIME except for not using HTML mails. The upshot of this is that OpenPGP messages are way better protected against such kind of attacks than S/MIME messages. Unless, well, the MUAs are correctly implemented and check error codes! Shalom-Salam, Werner p.s. Some cryptographers turn up their nose at the OpenPGP MDC which is an ad-hoc AE mode from a time before AE received much research. However, it does it job and protects reliable against this and other attacks. The next OpenPGP revision will bring a real AE mode (EAX or OCB depending on key preferences) which has other benefits (early detection of corrupted messages, speed) but it will takes years before it will be widely deployed and can can actually be used to create messages. -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mirimir at riseup.net Mon May 14 09:17:40 2018 From: mirimir at riseup.net (Mirimir) Date: Sun, 13 May 2018 20:17:40 -1100 Subject: Attention PGP Users: New Vulnerabilities Require You to Take Action Now Message-ID: <78646457-9473-10cb-1293-4ae291e2520b@riseup.net> | A group of European security researchers have released a warning | about a set of vulnerabilities affecting users of PGP and S/MIME. | EFF has been in communication with the research team, and can | confirm that these vulnerabilities pose an immediate risk to | those using these tools for email communication, including the | potential exposure of the contents of past messages. | | The full details will be published in a paper on Tuesday at 07:00 | AM UTC (3:00 AM Eastern, midnight Pacific). In order to reduce the | short-term risk, we and the researchers have agreed to warn the | wider PGP user community in advance of its full publication. | | Our advice, which mirrors that of the researchers, is to | immediately disable and/or uninstall tools that automatically | decrypt PGP-encrypted email. Until the flaws described in the | paper are more widely understood and fixed, users should arrange | for the use of alternative end-to-end secure channels, such as | Signal, and temporarily stop sending and especially reading | PGP-encrypted email. https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now | We'll publish critical vulnerabilities in PGP/GPG and S/MIME | email encryption on 2018-05-15 07:00 UTC. They might reveal the | plaintext of encrypted emails, including encrypted emails sent | in the past. https://twitter.com/seecurity/status/995906576170053633 From rjh at sixdemonbag.org Mon May 14 09:27:42 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 03:27:42 -0400 Subject: Don't Panic. Message-ID: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> [taps the mike] Hi. I maintain the official GnuPG FAQ. So let me start off by answering a question that is certainly about to be asked a lot: "Should we be worried about OpenPGP, GnuPG, or Enigmail? The EFF's advising us to uninstall it!" https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now Werner saw a preprint of this paper some time ago. I saw it recently. Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of respect for the paper authors I will skip further comment until such time as the paper is published. It would've been nice if EFF had reached out to us for comment, rather than apparently only talking to the paper authors. We hope they'll reach out next time. From rjh at sixdemonbag.org Mon May 14 10:27:35 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 04:27:35 -0400 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87mux28yts.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> Message-ID: The following is what I wrote to a journalist covering the story: ===== We've known about problems in OpenPGP's feedback mode for at least thirteen years. (See https://eprint.iacr.org/2005/033.pdf for an example.) The OpenPGP working group resolved these problems by adopting modification detection codes (MDCs). GnuPG properly implements MDCs and gives clear and unambiguous warnings if a message lacks an MDC. The paper authors acknowledge that if an email client handles these warnings sensibly, their attack fails. In other words, their attack is completely dependent on email clients handling our warnings in a broken way. Great: that they've found bugs in major email clients is a good thing, but where's the flaw in the OpenPGP protocol or GnuPG's implementation of it? And does this really deserve the hype-tastic title "Breaking S/MIME and OpenPGP Email Encryption" when it really doesn't do that? In grad school my adviser told me to follow Napoleon's Rule in paper titles. "If you tell the world you're going to conquer Russia, you'd better conquer Russia." This paper doesn't deliver on what its title promises. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon May 14 11:03:48 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 10:03:48 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87mux28yts.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> Message-ID: <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> On 14/05/18 08:45, Werner Koch wrote: > The topic of that paper is that HTML is used as a back channel to > create an oracle for modified encrypted mails. This confirms that my forensic analysis of the wording of the announcement was sound. ;-) The good thing is that oracle attacks are *noisy*, so you'll notice when it happens. > There are two ways to mitigate this attack > > - Don't use HTML mails. Or if you really need to read them use a > proper MIME parser and disallow any access to external links. Unfortunately HTML mail is commonplace, so never reading an HTML mail again may be too much to ask. > - Use authenticated encryption. So how do we enforce MDC checking at the receiving end? I assume this is something that has to be handled by the calling program at the moment. I see that MDC is the default for all modern ciphers, but does that imply that MDC *checking* is the default? If so, then all we would need to do is disable non-modern ciphers. Looks like S/MIME is pretty much buggered though... -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon May 14 11:03:42 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 May 2018 11:03:42 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87mux28yts.fsf@wheatstone.g10code.de> (Werner Koch's message of "Mon, 14 May 2018 09:45:51 +0200") References: <87mux28yts.fsf@wheatstone.g10code.de> Message-ID: <87o9hi7gnl.fsf@wheatstone.g10code.de> Hi! I digged in my mail archives and found a discussion with Sebastian Schinzel about a work in progress thing which turned out to not being a GnuPG problem. Here is a timeline with my messages. On 2017-11-24 we were asked for the encryption keys of the security at gnupg.org address. On the same day we received an advisory titled Efail: Full Plaintext Recovery in PGP via Chosen-Ciphertext Attack with the notice We ask you kindly to keep this advisory and the information therein confidential until we find a nearby date for coordinated public disclosure! A few hours later my reply went out: --8<---------------cut here---------------start------------->8--- Thanks for sharing the paper with us. I may have missed something but I can't see that you considered the use of MDC as specified in RFC-4880, 5.13 (Sym. Encrypted Integrity Protected Data Packet (Tag 18)). Here is the timeline of the introduction of the MDC. AES conference March 2000 * Meeting between PRZ, Jon Callas, and me to discuss how to make our encryption mode more robust without requiring signed content. GnuPG 1.0.3 (2000-09-18) * Twofish and MDC enhanced encryption is now used. PGP 7 supports this. Older versions of GnuPG don't support it, so they should be upgraded to at least 1.0.2 GnuPG 1.0.7 (2002-04-29) * The MDC feature flag is supported and can be set by using the "updpref" edit command. GnuPG 1.1.92 (2002-09-11) * The use of MDCs have increased. A MDC will be used if the recipients directly request it, if the recipients have AES, AES192, AES256, or TWOFISH in their cipher preferences, or if the chosen cipher has a blocksize not equal to 64 bits (currently this is also AES, AES192, AES256, and TWOFISH). * GnuPG will no longer automatically disable compression when processing an already-compressed file unless a MDC is being used. This is to give the message a certain amount of resistance to the chosen-ciphertext attack while communicating with other programs (most commonly PGP earlier than version 7.x) that do not support MDCs. GnuPG 2.1.9 (2015-10-09) * gpg: Fail with an error instead of a warning if a modern cipher algorithm is used without a MDC. Your attack should not work if the MDC is in use. And it is always in use for AES. In any case active content in mails should be discouraged in all mails (see my mail headers ;-). We are slowly working in the WG on RFC4880bis to introduce a new encryption mode. Unfortunately there are heavy opinions on the use of OCB mode and thus we may need to come up with the choice of two new modes. Based on the experience with MDC I expect that the deployment of a new mode will take at least 3 years. Until then I hope that the MDC hack will serve us fine. --8<---------------cut here---------------end--------------->8--- In response to that they said that they did a simple rollback to the non-MDC encryption. This is a pretty old thing which we are aware of and the reasons why a warning has always been printed in that case. In a further response the same day they noted that gpg indeed returns an error code but that Enigmail still displays the message. My reply on that went out on 2017-11-26: --8<---------------cut here---------------start------------->8--- Enigmail does something wrong the. Here is the respective code in GnuPG: else if (!result && !opt.ignore_mdc_error && !pkt->pkt.encrypted->mdc_method && openpgp_cipher_get_algo_blklen (c->dek->algo) != 8 && c->dek->algo != CIPHER_ALGO_TWOFISH) { /* The message has been decrypted but has no MDC despite that a modern cipher (blocklength != 64 bit, except for Twofish) is used and the option to ignore MDC errors is not used: To avoid attacks changing an MDC message to a non-MDC message, we fail here. */ log_error (_("WARNING: message was not integrity protected\n")); if (opt.verbose > 1) log_info ("decryption forced to fail\n"); write_status (STATUS_DECRYPTION_FAILED); which was introduced with commit 625e292108cc0fd9077769587a8c22abe7805e33 AuthorDate: Tue Oct 6 09:40:57 2015 +0200 gpg: Fail decryption for AES etc message w/o MDC. * g10/mainproc.c (proc_encrypted): Fail for modern messages w/o MDC. -- This change turns the missing MDC warning into an error if the message has been encrypted using a cipher with a non-64 bit block length cipher and it is not Twofish. We can assume that such messages are created by code which should have been able to create MDC packets. AES was introduced with 1.0.3 on 2000-09-18 shortly after MDC (1.0.2 on 2000-07-12). We need to exclude Twofish because that might have been used before MDC. GPGME based applications should get it correct because GPGME detects the STATUS_DECRYPTION_FAILED and flags the result as failed. --8<---------------cut here---------------end--------------->8--- On 2017-11-29 we got a short mail asking for a phone call. It might be that I did not reply to that but in any case my office phone number is easy to lookup. I did not get a phone call. Since then we have not seen any more communication - not even about the proposed coordinated public disclosure. Thus I closed this issue in December and forgot about it. On 2018-04-27 I received another paper via a Kmail developer which had a different title than the one from November *** DO NOT PUBLISH OR SHARE ON PUBLIC MAILING LISTS *** Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels and no author names etc. The GnuPG team discussed this but did not see that any action was required. In particular because due to the redaction we were not able to contact and help the developers of other MUAs which might be affected. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon May 14 11:15:42 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 05:15:42 -0400 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> Message-ID: > So how do we enforce MDC checking at the receiving end? I assume this is > something that has to be handled by the calling program at the moment. By default, GnuPG will scream bloody murder if a message lacks an MDC or if the MDC is invalid. At that point it's up to your email client to pay attention to the warning and do the right thing. Enigmail 2.0 and later are fine, but I can't speak for other systems. Of course, if you're crazy enough to disable the MDC check ("--no-mdc-warning") then all bets are off, but really, you'll get what you deserve. > I see that MDC is the default for all modern ciphers, but does that imply > that MDC *checking* is the default? MDC is an attribute of the packet, not the cipher. By default, all ciphers in the GnuPG suite use MDC. Hope this puts your mind at ease. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon May 14 11:30:18 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 10:30:18 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> Message-ID: <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> On 14/05/18 10:15, Robert J. Hansen wrote: >> I see that MDC is the default for all modern ciphers, but does that imply >> that MDC *checking* is the default? > MDC is an attribute of the packet, not the cipher. By default, all > ciphers in the GnuPG suite use MDC. OK, but from Werner's link earlier: > We hesitate to require the MDC also for old algorithms (3DES, CAST5> > because a lot of data has been encrypted using them in the first > years of OpenPGP. So if someone sends me a 3DES-encrypted mail it won't check the MDC? Doesn't gpg still support reading 3DES? -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon May 14 11:42:19 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 05:42:19 -0400 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> Message-ID: <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> >> We hesitate to require the MDC also for old algorithms (3DES, CAST5> >> because a lot of data has been encrypted using them in the first >> years of OpenPGP. > > So if someone sends me a 3DES-encrypted mail it won't check the MDC? > Doesn't gpg still support reading 3DES? Let's try it and find out. :) PS C:\Users\rjh> gpg --recipient 0xB44427C7 --cipher-algo 3DES --disable-mdc --encrypt --sign foo.cc gpg: 0xB44427C7: skipped: public key already present gpg: WARNING: encrypting without integrity protection is dangerous PS C:\Users\rjh> gpg foo.cc.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: encrypted with 256-bit ECDH key, ID AA24CC81B8AED08B, created 2017-04-05 "Robert J. Hansen " File 'foo.cc' exists. Overwrite? (y/N) y gpg: Signature made 05/14/18 05:40:46 Eastern Daylight Time gpg: using EDDSA key 4BF2042AE28F62B81736E8CBA83CAE94D3DC3873 gpg: Good signature from "Robert J. Hansen " [ultimate] gpg: aka "Robert J. Hansen " [ultimate] gpg: aka "Robert J. Hansen " [ultimate] gpg: WARNING: message was not integrity protected ... Yep, GnuPG will warn you the message was not integrity protected. Your email client should see this warning and refuse to render the message. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon May 14 12:56:00 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 11:56:00 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> Message-ID: <9de4a858-87a7-d79e-05c4-10143f94b429@andrewg.com> On 14/05/18 10:42, Robert J. Hansen wrote: > ... Yep, GnuPG will warn you the message was not integrity protected. > Your email client should see this warning and refuse to render the message. Yes, but that's not as serious as the error thrown for an unprotected AES message. Do mail clients treat such warnings as fatal? Should mail clients *ever* treat mere warnings as fatal? I can't test here because I'm suffering from https://dev.gnupg.org/T3576 - guess that means I'm immune! ;-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon May 14 13:13:31 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 12:13:31 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> Message-ID: <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> On 14/05/18 10:42, Robert J. Hansen wrote: > ... Yep, GnuPG will warn you the message was not integrity protected. > Your email client should see this warning and refuse to render the message. I tried again using CAST5 instead of MD5 to bypass the smartcard bug. The news is not good. ``` andrewg at fred:~$ gpg --recipient 0xFB73E21AF1163937 --cipher-algo CAST5 --disable-mdc --encrypt --sign --armor reply.txt gpg: using "00CC54C6A0C601691AF4931FFB73E21AF1163937" as default secret key for signing File 'reply.txt.asc' exists. Overwrite? (y/N) y andrewg at fred:~$ gpg reply.txt.asc gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: encrypted with 4096-bit RSA key, ID 0x6B09069314549D4B, created 2013-07-02 "Andrew Gallagher " File 'reply.txt' exists. Overwrite? (y/N) Enter new filename: foo gpg: Signature made Mon 14 May 2018 11:57:17 IST gpg: using RSA key 291E79A1DC55AE27A52EEF835C1EC404D5906629 gpg: Good signature from "Andrew Gallagher " [ultimate] gpg: aka "Andrew Gallagher " [ultimate] gpg: aka "Andrew Gallagher " [ultimate] gpg: aka "Andrew Gallagher " [ultimate] gpg: aka "[jpeg image of size 18803]" [ultimate] gpg: aka "Andrew Gallagher " [ultimate] Primary key fingerprint: 00CC 54C6 A0C6 0169 1AF4 931F FB73 E21A F116 3937 Subkey fingerprint: 291E 79A1 DC55 AE27 A52E EF83 5C1E C404 D590 6629 gpg: WARNING: message was not integrity protected ``` So far so good - gnupg correctly throws a warning. But: ``` andrewg at fred:~$ cat reply.txt.asc | mailx andrewg at andrewg.com -s "test message" ``` Now in Enigmail, I get a decrypted message with a green bar and no warnings whatsoever: ``` Enigmail Security Info Decrypted message Good signature from Andrew Gallagher Key ID: 0xF1163937 / Signed on: 14/05/18, 11:57 Key fingerprint: 00CC 54C6 A0C6 0169 1AF4 931F FB73 E21A F116 3937 Used Algorithms: RSA and SHA512 Note: The message is encrypted for the following User ID's / Keys: 0x6B09069314549D4B (Andrew Gallagher ) ``` So it would appear that Enigmail IS VULNERABLE. I have reproduced this on debian's 2:1.9.9-1~deb9u1 (v1.9.9) and 2.0.3 on Mac. By comparison, the default cipher (AES) correctly throws a decryption error in enigmail using the same test systems. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon May 14 13:18:29 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 07:18:29 -0400 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> Message-ID: Fascinating. I've thrown it over to Patrick: we'll look into it and get back in touch soon. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon May 14 13:20:00 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 12:20:00 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> Message-ID: <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> On 14/05/18 12:13, Andrew Gallagher wrote: > I tried again using CAST5 instead of MD5 to bypass the smartcard bug. Argh, I meant to say 3DES of course, not MD5. Sorry. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon May 14 13:23:25 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 07:23:25 -0400 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> Message-ID: > Argh, I meant to say 3DES of course, not MD5. Sorry. It's worth noting, incidentally, the #Efail attack flat-out requires MIME. So inline PGP messages are not vulnerable, as there's no MIME parsing pass which can be exploited. So you're *still* safe, although this is still a bug that should be fixed. ;) I can recreate the bug; I'll be bringing it up to Patrick soon. -------------- 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 Mon May 14 13:25:09 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 07:25:09 -0400 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> Message-ID: ... and Patrick, moving faster than the speed of light, already has the bug triaged and bounced back. This is actually a GnuPG bug, not an Enigmail bug. From Patrick: ===== The problem is that gpg doesn't say anything. I would expect a DECRYPTION_FAILED message here: [GNUPG:] ENC_TO 5F5FDF400616A9CF 1 0 [GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0 [GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0 gpg: WARNING: cipher algorithm CAST5 not found in recipient preferences [GNUPG:] DECRYPTION_KEY 530187ED159A04E6F53ED1385F5FDF400616A9CF 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B u [GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0 gpg: encrypted with 4096-bit RSA key, ID 5F5FDF400616A9CF, created 2018-01-17 "Patrick Brunschwig " [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_INFO 0 3 [GNUPG:] PLAINTEXT 62 1526296937 [GNUPG:] PLAINTEXT_LENGTH 4 abc [GNUPG:] NEWSIG gpg: Signature made Mon May 14 13:22:17 2018 CEST gpg: using RSA key 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B [GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0 [GNUPG:] SIG_ID Rh02jRM7bb5K0OOXQaEgmdJF+Bo 2018-05-14 1526296937 [GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0 [GNUPG:] GOODSIG DB1187B9DD5F693B Patrick Brunschwig gpg: Good signature from "Patrick Brunschwig " [ultimate] gpg: aka "Patrick Brunschwig " [ultimate] gpg: aka "[jpeg image of size 13251]" [ultimate] [GNUPG:] VALIDSIG 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 2018-05-14 1526296937 0 4 0 1 10 00 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B [GNUPG:] TRUST_ULTIMATE 0 direct [GNUPG:] VERIFICATION_COMPLIANCE_MODE 23 [GNUPG:] DECRYPTION_OKAY gpg: WARNING: message was not integrity protected [GNUPG:] END_DECRYPTION -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon May 14 13:36:59 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 12:36:59 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> Message-ID: On 14/05/18 12:23, Robert J. Hansen wrote: > It's worth noting, incidentally, the #Efail attack flat-out requires > MIME. So inline PGP messages are not vulnerable, as there's no MIME > parsing pass which can be exploited. So you're *still* safe I wouldn't be that confident. I haven't tested PGP/MIME yet simply because it's harder to construct the test message. The important point is that we can't rely on gnupg's message integrity check to prevent automatic decryption - so there's no good reason to believe that PGP mail is any less vulnerable than S/MIME. Note to anyone coming fresh to the conversation: disabling the display of HTML email is *probably* a sufficient mitigation in either case. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon May 14 13:47:12 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 07:47:12 -0400 Subject: Mailpile on Efail Message-ID: <8e8592d7-1789-18af-12ee-1c269030be55@sixdemonbag.org> https://www.mailpile.is/blog/2018-05-14_PGP_Security_Alert.html Short version: Mailpile isn't impressed, either, and is a little annoyed they were mistakenly listed as being vulnerable. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon May 14 13:49:57 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 12:49:57 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> Message-ID: <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> On 14/05/18 12:25, Robert J. Hansen wrote: > The problem is that gpg doesn't say anything. I would expect a > DECRYPTION_FAILED message here: So perhaps the solution is to throw a big warning and prompt when an integrity check failure is thrown by gnupg? That would mitigate the current issue, but allow for reading pre-MDC emails as per Werner's earlier link. The problem here is that an integrity failure is a serious error when it occurs in a context where oracle behaviour is possible (such as email), but it's much less serious when used outside that context. Just because gnupg says it's only a warning-level offence doesn't mean enigmail should agree... -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon May 14 13:52:33 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 May 2018 13:52:33 +0200 Subject: Mailpile on Efail In-Reply-To: <8e8592d7-1789-18af-12ee-1c269030be55@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 14 May 2018 07:47:12 -0400") References: <8e8592d7-1789-18af-12ee-1c269030be55@sixdemonbag.org> Message-ID: <87h8na5u9q.fsf@wheatstone.g10code.de> On Mon, 14 May 2018 13:47, rjh at sixdemonbag.org said: > Short version: Mailpile isn't impressed, either, and is a little annoyed > they were mistakenly listed as being vulnerable. Yes, all green in the table for Mailpile. GgpOL (Gpg4win's Outlook plugin) is also claimed to be vulnerable but the table shows tha this is only the case when used with Outlook 2007 - which is not anymore supported and brings up a warning when used with GpgOL. BTW, the lack of all version numbers of the plugins or crypto engines is a major flaw in the paper. With version numbers it would be much easier to see what is wrong with some claims. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon May 14 14:27:44 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 08:27:44 -0400 Subject: Efail press release Message-ID: <086c325b-19c1-52b6-bdd2-4778af1ffdca@sixdemonbag.org> Over the last few hours, Werner, Andre, and I have been working on an official statement about the Efail paper. Without further ado, here it is. An Official Statement on New Claimed Vulnerabilities == ======== ========= == === ======= =============== by the GnuPG and Gpg4Win teams (This statement is only about the susceptibility of OpenPGP, GnuPG, and Gpg4Win. It does not cover S/MIME.) Recently some security researchers published a paper named "Efail: Breaking S/MIME and OpenPGP Encryption using Exfiltration Channels". The EFF has gone so far as to recommend immediately uninstalling Enigmail. We have three things to say, and then we're going to show you why we're right. 1. This paper is misnamed. 2. This attack targets buggy email clients. 3. The authors made a list of buggy email clients. In 1999 we realized OpenPGP's symmetric cipher mode (a variant of cipher feedback) had a weakness: in some cases an attacker could modify text. As Werner Koch, the founder of GnuPG, put it: "[Phil Zimmermann] and Jon Callas asked me to attend the AES conference in Rome to discuss problems with the CFB mode which were on the horizon. That discussion was in March 1999 and PGP and GnuPG implemented a first version [of our countermeasure] about a month later. According to GnuPG's NEWS file, [our countermeasure] went live in Summer 2000." The countermeasure Werner mentions is called a Modification Detection Code, or MDC. It's been a standard part of GnuPG for almost eighteen years. For almost all that time, any message which does not have an MDC attached has caused GnuPG to throw up big, clear, and obvious warning messages. They look something like this: gpg: encrypted with 256-bit ECDH key, ID 7F3B7ED4319BCCA8, created 2017-01-01 "Werner Koch " [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_INFO 0 7 [GNUPG:] PLAINTEXT 62 1526109594 [GNUPG:] PLAINTEXT_LENGTH 69 There is more to life than increasing its speed. -- Mahatma Gandhi gpg: WARNING: message was not integrity protected [GNUPG:] DECRYPTION_FAILED [GNUPG:] END_DECRYPTION GnuPG also throws large warning messages if an MDC indicates a message has been modified. In both cases, if your email client respects this warning and does the right thing -- namely, not showing you the email -- then you are completely protected from the Efail attack, as it's just a modern spin on something we started defending against almost twenty years ago. If you're worried about the Efail attack, upgrade to the latest version of GnuPG and check with your email plugin vendor to see if they handle MDC errors correctly. Most do. You might be vulnerable if you're running an ancient version of GnuPG (the 1.0 series; the current is 2.2), or if your email plugin doesn't handle GnuPG's warning correctly. You might also have had some exposure in the past if back then you used a pre-2000 version of GnuPG, and/or an email plugin which didn't handle the warning correctly. We made three statements about the Efail attack at the beginning. We're going to repeat them here and give a little explanation. Now that we've explained the situation, we're confident you'll concur in our judgment. 1. This paper is misnamed. It's not an attack on OpenPGP. It's an attack on broken email clients that ignore GnuPG's warnings and do silly things after being warned. 2. This attack targets buggy email clients. Correct use of the MDC completely prevents this attack. GnuPG has had MDC support since the summer of 2000. 3. The authors made a list of buggy email clients. It's worth looking over their list of email clients (found at the very end) to see if yours is vulnerable. But be careful, because it may not be accurate -- for example, Mailpile says they're not vulnerable, but the paper indicates Mailpile has some susceptibility. The authors have done the community a good service by cataloguing buggy email email clients. We're grateful to them for that. We do wish, though, this thing had been handled with a little less hype. A whole lot of people got scared, and over very little. From gnupg at leo.gaspard.ninja Mon May 14 12:55:13 2018 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Mon, 14 May 2018 12:55:13 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87mux28yts.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> Message-ID: On 05/14/2018 09:45 AM, Werner Koch wrote:> The topic of that paper is that HTML is used as a back channel to create > an oracle for modified encrypted mails. It is long known that HTML > mails and in particular external links like > are evil if the MUA actually honors them (which many meanwhile seem to > do again; see all these newsletters). Due to broken MIME parsers a > bunch of MUAs seem to concatenate decrypted HTML mime parts which makes > it easy to plant such HTML snippets. The full details appear to be out [1]. If I read it correctly, it also has another attack, no longer based on user agents concatenating HTML mime parts, but also based on CFB gadgets. Which, here, looks like a flaw in the OpenPGP specification indeed (and thus GnuPG's implementation of it), and not in MUAs? [1] https://efail.de/ From rjh at sixdemonbag.org Mon May 14 14:42:35 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 08:42:35 -0400 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> Message-ID: <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> > If I read it correctly, it also has another attack, no longer based on > user agents concatenating HTML mime parts, but also based on CFB > gadgets. Which, here, looks like a flaw in the OpenPGP specification > indeed (and thus GnuPG's implementation of it), and not in MUAs? MDCs stop it dead. If a message has no MDC or an invalid MDC, GnuPG _will_ warn you about it. Now, whether your email client does the right thing upon being warned, that's between you and your email client... From Roman.Fiedler at ait.ac.at Mon May 14 14:33:03 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Mon, 14 May 2018 12:33:03 +0000 Subject: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > > On 14/05/18 12:25, Robert J. Hansen wrote: > > The problem is that gpg doesn't say anything. I would expect a > > DECRYPTION_FAILED message here: > > So perhaps the solution is to throw a big warning and prompt when an > integrity check failure is thrown by gnupg? That would mitigate the > current issue, but allow for reading pre-MDC emails as per Werner's > earlier link. > > The problem here is that an integrity failure is a serious error when it > occurs in a context where oracle behaviour is possible (such as email), > but it's much less serious when used outside that context. Just because > gnupg says it's only a warning-level offence doesn't mean enigmail > should agree... In my opinion, the problem is related to the general gnupg interface design. An optional error or warning is always somehow problematic in interfaces: 1) you have to read and understand the complete documentation to know of any message that may occur 2) if it is not here, you simply do not know, if everything is right, if you just missed the message or an attacker managed to "suppress" it somehow. Makes it easier on the attacker - like here In my opinion, gnupg would do itself a favour by avoiding optional messages - without any other reference to it. With such a protocol I would expect gnupg to end somehow like ... [END_STATUS]: Messages: 3, Valid MDCs 2, Signed Messages 2, ...., Warnings: 1, Errors: 0 ... (put here everything you deem important and document it) This would also prevent many other programming errors: e.g. if gpg claims to have processed 2 signed messages, a client has to verify, that it also received two "GOOD_SIG" messages. If just any of the numbers do not match, any good mail client should bail out immediately, e.g. if warn=1 but the client did not understand the warning. LG R PS: A end message as single line sorted JSON dictionary might make parsing less error prone and increase the number of developers really parsing and using them. From andrewg at andrewg.com Mon May 14 15:44:31 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 14:44:31 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> Message-ID: <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> On 14/05/18 13:42, Robert J. Hansen wrote: >> If I read it correctly, it also has another attack, no longer based on >> user agents concatenating HTML mime parts, but also based on CFB >> gadgets. Which, here, looks like a flaw in the OpenPGP specification >> indeed (and thus GnuPG's implementation of it), and not in MUAs? > > MDCs stop it dead. If a message has no MDC or an invalid MDC, GnuPG > _will_ warn you about it. Now, whether your email client does the right > thing upon being warned, that's between you and your email client... This all exposes one of the difficulties with trying to manage security software in a decentralised ecosystem. We end up in arguments over whose responsibility it is when the joints come apart. I would humbly suggest that we stop worrying about which side of the GPG/MUA fence the ball is on, and fix it on *both* sides. That means: 1. change the default behaviour of GPG so that any integrity failure is fatal by default, even for old ciphersuites (we could have a flag to override for those that really need it). For belt and braces, disable the obsolete ciphersuites by default (again, we can provide an override). We have assumed that so long as you don't *generate* poor crypto you're safe. That's just not true. 2. AND the MUAs need to make sure they fail hard on integrity warnings, because old versions of GPG may hang around for a while. Also ensure that links aren't followed by default, that the capabilities of encrypted HTML mail are constrained, etc. The PGP ecosystem will survive this, because the tech is in place. The enforcement has just erred a little too far on the side of compatibility. It's all fixable. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From dank at kegel.com Mon May 14 15:47:16 2018 From: dank at kegel.com (Dan Kegel) Date: Mon, 14 May 2018 06:47:16 -0700 Subject: Don't Panic. In-Reply-To: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> References: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> Message-ID: Thanks for the heads up! (The eff alert only suggests disabling tools that *automatically* decrypt messages, Stumbling around a bit on the net, this sounds like a rehash of https://sourceforge.net/p/enigmail/bugs/226/ Anyway, if you have a checkbox for 'automatically decrypt', you might consider unticking it.) - Dan On Mon, May 14, 2018 at 12:27 AM, Robert J. Hansen wrote: > [taps the mike] > > Hi. I maintain the official GnuPG FAQ. So let me start off by > answering a question that is certainly about to be asked a lot: "Should > we be worried about OpenPGP, GnuPG, or Enigmail? The EFF's advising us > to uninstall it!" > > https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now > > Werner saw a preprint of this paper some time ago. I saw it recently. > Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of > respect for the paper authors I will skip further comment until such > time as the paper is published. > > It would've been nice if EFF had reached out to us for comment, rather > than apparently only talking to the paper authors. We hope they'll > reach out next time. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From markr at signal100.com Mon May 14 17:48:31 2018 From: markr at signal100.com (Mark Rousell) Date: Mon, 14 May 2018 16:48:31 +0100 Subject: Don't Panic. In-Reply-To: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> References: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> Message-ID: <5AF9AFCF.8040100@signal100.com> On 14/05/2018 08:27, Robert J. Hansen wrote: > Werner saw a preprint of this paper some time ago. I saw it recently. > Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of > respect for the paper authors I will skip further comment until such > time as the paper is published. > > It would've been nice if EFF had reached out to us for comment, rather > than apparently only talking to the paper authors. We hope they'll > reach out next time. I see that the Inquirer is passing on the FUD. May I suggest that someone authoritative gets in touch with them to correct them. PGP is leaking your emails in plaintext and there's no known fix Amongst other things this includes the following paragraph which, as I understand it, is essentially untrue: "There are currently no reliable fixes for the vulnerability. If you use PGP/GPG or S/MIME for very sensitive communication, you should disable it in your email client for now," said Sebastian Schinzel , a professor of computer security at the University. -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Mon May 14 18:34:07 2018 From: markr at signal100.com (Mark Rousell) Date: Mon, 14 May 2018 17:34:07 +0100 Subject: Don't Panic. In-Reply-To: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> References: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> Message-ID: <5AF9BA7F.9080602@signal100.com> On 14/05/2018 08:27, Robert J. Hansen wrote: > Werner saw a preprint of this paper some time ago. I saw it recently. > Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of > respect for the paper authors I will skip further comment until such > time as the paper is published. > > It would've been nice if EFF had reached out to us for comment, rather > than apparently only talking to the paper authors. We hope they'll > reach out next time. I see that the Inquirer is passing on the FUD. May I suggest that someone authoritative gets in touch with them to correct them. PGP is leaking your emails in plaintext and there's no known fix Amongst other things this includes the following paragraph which, as I understand it, is essentially untrue: "There are currently no reliable fixes for the vulnerability. If you use PGP/GPG or S/MIME for very sensitive communication, you should disable it in your email client for now," said Sebastian Schinzel , a professor of computer security at the University. (Re-sent as my outgoing server got a "451-xx.xx.xx.xx+is+not+yet+authorized+to+deliver+mail+from" error first time round.) -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon May 14 19:32:18 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 May 2018 19:32:18 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> (Andrew Gallagher's message of "Mon, 14 May 2018 14:44:31 +0100") References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> Message-ID: <874lja5ejh.fsf@wheatstone.g10code.de> On Mon, 14 May 2018 15:44, andrewg at andrewg.com said: > This all exposes one of the difficulties with trying to manage security > software in a decentralised ecosystem. We end up in arguments over whose That is actually easy compared to a system which is also designed to protect data at rest. Some users may want to restore their 2 year old backup to fix a problem with garbled tapes; some may want to read the real documents about WMD from 2003; some may even want to be able to decrypt their old love letters at the time of their silver wedding. > 1. change the default behaviour of GPG so that any integrity failure is > fatal by default, even for old ciphersuites (we could have a flag to I am all in favor of this and even considered to that some time ago. However, not too long ago we removed support for PGP-2 keys which unfortunately resulted in lots of angry mails from people who now think they need to use gnupg 1.4 every day because they seem to read mails From the last century on a regular base. Well, they think and they were quite vocal. Now telling them they need to enable an option to read certain not that old mail (e.g. creating by other OpenPGP implementations) will a) lead to even more angry mails and b) they will keep on using that option for all mails. Thus my tentative plan was to make the next major version hard fail on messages without MDC and slowly start using our forthcoming AEAD encryption mode. Well okay, with the new support of the Ehtmlfail paper we could now point to that paper and always hard error out if no MDC is used even for old algorithms. Shall we consider this? > the obsolete ciphersuites by default (again, we can provide an They are not used by default. 3DES is a MUST algorithm and will only be deprecated with RFC_4990bis and thus GnuPG 2.3. > 2. AND the MUAs need to make sure they fail hard on integrity warnings, > because old versions of GPG may hang around for a while. Also ensure Fortunately the majority of them do. > that links aren't followed by default, that the capabilities of > encrypted HTML mail are constrained, etc. Yes please, I consider this the minimum requirement for HTML based mails. Why sending email when you need to go online for reading them. And also disallow Javascript. How you only need to convince the mail content designers that they can't simply use the web page and send it as mail. That will be the hard part. > The PGP ecosystem will survive this, because the tech is in place. The I am not so sure for S/MIME - but that is whishful thinking ;-) Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lars.nooden at gmail.com Mon May 14 19:57:36 2018 From: lars.nooden at gmail.com (=?UTF-8?Q?Lars_Nood=c3=a9n?=) Date: Mon, 14 May 2018 20:57:36 +0300 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <874lja5ejh.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <874lja5ejh.fsf@wheatstone.g10code.de> Message-ID: On 05/14/2018 08:32 PM, Werner Koch wrote: [snip] > I am all in favor of this and even considered to that some time ago. > However, not too long ago we removed support for PGP-2 keys which > unfortunately resulted in lots of angry mails from people who now think > they need to use gnupg 1.4 every day because they seem to read mails > From the last century on a regular base. [snip] How feasible would it be to strip or disable encryption in a fork of an old version and just leave it capable of decryption? And would that address their use-cases for the old mails while dealing with the security concerns arising from the outdated ciphers? So it could be a gnupg-encore fork for archival purposes. /Lars From andrewg at andrewg.com Mon May 14 22:09:45 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 21:09:45 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <874lja5ejh.fsf@wheatstone.g10code.de> Message-ID: > On 14 May 2018, at 18:57, Lars Nood?n wrote: > > How feasible would it be to strip or disable encryption in a fork of an > old version and just leave it capable of decryption? I?m sure it?s feasible, but it doesn?t address this issue or any other kind of oracle, replay or chosen-text attack. If today has taught us anything, surely it is that flaws in decryption are just as dangerous as flaws in encryption. A From andrewg at andrewg.com Mon May 14 22:43:56 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 21:43:56 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <874lja5ejh.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <874lja5ejh.fsf@wheatstone.g10code.de> Message-ID: > On 14 May 2018, at 18:32, Werner Koch wrote: > > On Mon, 14 May 2018 15:44, andrewg at andrewg.com said: > >> This all exposes one of the difficulties with trying to manage security >> software in a decentralised ecosystem. We end up in arguments over whose > > That is actually easy compared to a system which is also designed to > protect data at rest. Some users may want to restore their 2 year old > backup to fix a problem with garbled tapes; some may want to read the > real documents about WMD from 2003; some may even want to be able to > decrypt their old love letters at the time of their silver wedding. Indeed. This is why data must be treated as a living object. If tape drive technology moves on, the data must be moved on. Same with file formats, encryption systems and dying raid arrays. Librarians and archaeologists understand the process of care and feeding for physical artefacts. Digital artefacts are no exception. >> 1. change the default behaviour of GPG so that any integrity failure is >> fatal by default, even for old ciphersuites (we could have a flag to > > I am all in favor of this and even considered to that some time ago. > However, not too long ago we removed support for PGP-2 keys which > unfortunately resulted in lots of angry mails from people who now think > they need to use gnupg 1.4 every day because they seem to read mails > From the last century on a regular base. Well, they think and they were > quite vocal. Now telling them they need to enable an option to read > certain not that old mail (e.g. creating by other OpenPGP > implementations) will a) lead to even more angry mails and b) they will > keep on using that option for all mails. Thus my tentative plan was to > make the next major version hard fail on messages without MDC and slowly > start using our forthcoming AEAD encryption mode. > Well okay, with the new support of the Ehtmlfail paper we could now > point to that paper and always hard error out if no MDC is used even for > old algorithms. Shall we consider this? Yes, absolutely. I think this is the easiest and most effective technical mitigation available. If people have a problem with data archival, they should be pointed to a guide on how to re-encrypt their sensitive data in a modern format. Their data is probably horrendously insecure anyway, so we?re doing them a favour. :-) If we believe that there will be more encrypted messages in the future than there have been in the past, then protecting those future messages takes priority, especially if an upgrade pathway exists. >> the obsolete ciphersuites by default (again, we can provide an > > They are not used by default. 3DES is a MUST algorithm and will only be > deprecated with RFC_4990bis and thus GnuPG 2.3. OK. As an aside, I think we have to be careful about the meaning of ?use?. They are not used by default in encryption, but they are in decryption. I?ve had multiple conversations today over this ambiguity. >> 2. AND the MUAs need to make sure they fail hard on integrity warnings, >> because old versions of GPG may hang around for a while. Also ensure > > Fortunately the majority of them do. Yes, nevertheless I don?t think it is good practice to rely on one single layer for security protection, because then we have a single point of failure. With two interacting systems, neither should assume that the other is behaving correctly. Trust but verify, belt and braces, measure twice cut once. That means security policy should be enforced by both applications, so that a single failure doesn?t blow open the entire system. This is especially important when there are potentially unlimited kinds of systems, of varying compliance, that could be involved in any interaction. I think also that we should be mindful that ?be strict about what you send but liberal about what you receive? is great advice for interoperability, but absolutely disastrous advice for security. >> that links aren't followed by default, that the capabilities of >> encrypted HTML mail are constrained, etc. > > Yes please, I consider this the minimum requirement for HTML based > mails. Why sending email when you need to go online for reading them. > And also disallow Javascript. How you only need to convince the mail > content designers that they can't simply use the web page and send it as > mail. That will be the hard part. Another thing we need to learn from this is that HTML elements may be a privacy concern in plaintext mail, but they are a *security* concern in encrypted mail. The context changes the risk profile. So mail clients (tbird) that disable risky HTML (such as loading images) by default but provide user overrides are doing so justifiably from a privacy standpoint, where a warning about the privacy implications may be sufficient. But encryption has to change this risk analysis - in an encrypted mail there can?t be an easy override because the stakes are much higher and people are easily tempted. When we have a system like tbird+enigmail+gpg where there are *three* interacting components, this coordination becomes really difficult. At the very least, enigmail must be able to enforce a stricter content hygiene policy on encrypted HTML mail than tbird applies to plaintext HTML. How *feasible* this might be is a question aimed at the enigmail devs in the list. :-) >> The PGP ecosystem will survive this, because the tech is in place. The > > I am not so sure for S/MIME - but that is whishful thinking ;-) :-P A From andrewg at andrewg.com Mon May 14 22:49:32 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 14 May 2018 21:49:32 +0100 Subject: Don't Panic. In-Reply-To: References: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> Message-ID: <811E0CE5-3810-432A-A4AE-46F4606F4A78@andrewg.com> > On 14 May 2018, at 14:47, Dan Kegel wrote: > > Anyway, if you have a checkbox for 'automatically decrypt', you might > consider unticking it.) This may not be sufficient. It?s not just automatic decryption but any decryption at all in the client that can trigger a callback. In the PGP case the attack is noisy, so you *may* have a chance to protect yourself before the damage is done if manual decryption is required for each attempt. But that assumes that a human being can reliably distinguish the attempts, which assumes a high level of knowledge of the attack procedure. A From mirimir at riseup.net Mon May 14 23:11:01 2018 From: mirimir at riseup.net (Mirimir) Date: Mon, 14 May 2018 10:11:01 -1100 Subject: Don't Panic. In-Reply-To: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> References: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> Message-ID: On 05/13/2018 08:27 PM, Robert J. Hansen wrote: > [taps the mike] > > Hi. I maintain the official GnuPG FAQ. So let me start off by > answering a question that is certainly about to be asked a lot: "Should > we be worried about OpenPGP, GnuPG, or Enigmail? The EFF's advising us > to uninstall it!" > > https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now > > Werner saw a preprint of this paper some time ago. I saw it recently. > Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of > respect for the paper authors I will skip further comment until such > time as the paper is published. > > It would've been nice if EFF had reached out to us for comment, rather > than apparently only talking to the paper authors. We hope they'll > reach out next time. Thanks. I didn't know what to think. I'm going to add this to the HN thread. I trust that's OK. From rjh at sixdemonbag.org Mon May 14 23:24:53 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 May 2018 17:24:53 -0400 Subject: Don't Panic. In-Reply-To: References: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> Message-ID: <9216a588-d3b4-b1e4-739b-02629b1dede0@sixdemonbag.org> > I'm going to add this to the HN thread. I trust that's OK. Go for it. :) From 2017-r3sgs86x8e-lists-groups at riseup.net Tue May 15 00:13:32 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Mon, 14 May 2018 23:13:32 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> Message-ID: <1844654093.20180514231332@my_localhost_LG> Hi On Monday 14 May 2018 at 1:33:03 PM, in , Fiedler Roman wrote:- > This would also prevent many other programming > errors: e.g. if gpg > claims to have processed 2 signed messages, a client > has to verify, > that it also received two "GOOD_SIG" messages. What if a message has more than one signature? -- Best regards MFPA I think not, said Descartes, and promptly disappeared -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 1252 bytes Desc: not available URL: From vedaal at nym.hush.com Mon May 14 23:56:33 2018 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Mon, 14 May 2018 17:56:33 -0400 Subject: Efail or OpenPGP is safer than S/MIME Message-ID: <20180514215633.42F8E60093@smtp.hushmail.com> Werner Koch, wk, at gnupg.org wrote on Mon May 14 19:32:18 CEST 2018: ... I am all in favor of this and even considered to that some time ago. However, not too long ago we removed support for PGP-2 keys which unfortunately resulted in lots of angry mails from people who now think they need to use gnupg 1.4 every day because they seem to read mails >From the last century on a regular base. Well, they think and they were quite vocal. Now telling them they need to enable an option to read certain not that old mail (e.g. creating by other OpenPGP implementations) will a) lead to even more angry mails and b) they will keep on using that option for all mails. Thus my tentative plan was to make the next major version hard fail on messages without MDC and slowly start using our forthcoming AEAD encryption mode. Well okay, with the new support of the Ehtmlfail paper we could now point to that paper and always hard error out if no MDC is used even for old algorithms. Shall we consider this? ... ===== Yes. As an Old PGP 2.x user, I can say that the majority of PGP 2.x users communicating among them selves, DON'T use GnuPG at all. Those who do use GnuPG, have a new V4 key and use exclusively that, and can easily handle the hardwired MDC fail, and will even be thankful for the GnuPG 'protection'. vedaal From jerry at seibercom.net Tue May 15 03:31:52 2018 From: jerry at seibercom.net (Jerry) Date: Mon, 14 May 2018 21:31:52 -0400 Subject: US-CERT now issuing a warning for OpenPGP-SMIME-Mail-Client-Vulnerabilities Message-ID: <20180514213152.0000578d@seibercom.net> NCCIC encourages users and administrators to review CERT/CC?s Vulnerability Note VU #122919. https://www.us-cert.gov/ncas/current-activity/2018/05/14/OpenPGP-SMIME-Mail-Client-Vulnerabilities -- Jerry From bernhard at intevation.de Tue May 15 08:42:02 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 15 May 2018 08:42:02 +0200 Subject: efail -> improvements (was: Efail or OpenPGP is safer than S/MIME) In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> <874lja5ejh.fsf@wheatstone.g10code.de> Message-ID: <201805150842.09722.bernhard@intevation.de> Am Montag 14 Mai 2018 22:43:56 schrieb Andrew Gallagher: > > On 14 May 2018, at 18:32, Werner Koch wrote: > > Well okay, with the new support of the Ehtmlfail paper we could now > > point to that paper and always hard error out if no MDC is used even for > > old algorithms. Shall we consider this? > Yes, absolutely. I think this is the easiest and most effective technical > mitigation available. I completely agree, the paper shows problems with the current specifications, backend and frontend implementations. We should (help to) fix it in all three places. Best for GnuPG would be to not display contents which did not have integrity protection by either: a) MDC b) AEAD c) a signature over the whole contents from someone where it has been encrypted to (if this is feasable to detect). > With two interacting systems, neither should assume that the other > is behaving correctly. Note that it is not just email clients that are in danger. If you get a file with active contents (e.g. an HTML file, or a video reference) and you decrypt it as data on the command line it is fine up to there. But once you try to read or open it, you'll have a backchannel. > > Yes please, I consider this the minimum requirement for HTML based > > mails. Why sending email when you need to go online for reading them. > > And also disallow Javascript. How you only need to convince the mail > > content designers that they can't simply use the web page and send it as > > mail. That will be the hard part. > > Another thing we need to learn from this is that HTML elements may be a > privacy concern in plaintext mail, but they are a *security* concern in > encrypted mail. People clearly seem to want a way to send files with potentially active elements. So in my opinion the crypto standards and backends should be designed to allow this in the safest way possible. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue May 15 08:55:29 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 15 May 2018 08:55:29 +0200 Subject: S/MIME implementation that uses authenticated-data? Message-ID: <201805150855.30111.bernhard@intevation.de> Hi, do you know any S/MIME (or CMS) implementations that use authenticated-data type from STD 70 aka RFC 5652? If we wanted to implement this for GnuPG's gpgsm, it would be very cool to have implementations to test against. The ticket is https://dev.gnupg.org/T3979, you can also reply there. Thanks, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue May 15 08:52:45 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 15 May 2018 08:52:45 +0200 Subject: efail -> improvements (was: Efail or OpenPGP is safer than S/MIME) In-Reply-To: <201805150842.09722.bernhard@intevation.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <201805150842.09722.bernhard@intevation.de> Message-ID: <201805150852.45758.bernhard@intevation.de> .. to only display contents if there was integrity protection by either > a) MDC > b) AEAD > c) a signature over the whole contents from someone where it has been > encrypted to (if this is feasable to detect). if users or frontends still want to show contents, to me it seems good if * there is a very explicit disable-safety-button * ideally working only for one encryption, so it has been issued explicitely each time * a warning against active content which may become active much later * an attempt to prevent active backchannels as much as possible (e.g. by only showing plain text and saving as plain-text suffix) would need to be put in the documentation so GnuPG frontends know. Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue May 15 09:58:01 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 May 2018 09:58:01 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: (Andrew Gallagher's message of "Mon, 14 May 2018 21:43:56 +0100") References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <874lja5ejh.fsf@wheatstone.g10code.de> Message-ID: <87r2md2vw6.fsf@wheatstone.g10code.de> On Mon, 14 May 2018 22:43, andrewg at andrewg.com said: > If we believe that there will be more encrypted messages in the future than there have been in the past, then protecting those future messages takes priority, especially if an upgrade pathway exists. Unless you change the default options of gpg or you encrypt to at least one old key there is no problem at all. I assume that 99.9% of all GPG created messages are safe because they use MDC in away which allows the receiving GPG to hard fail if the MDC was stripped. > As an aside, I think we have to be careful about the meaning of ?use?. They are not used by default in encryption, but they are in decryption. I?ve had multiple conversations today over this ambiguity. Right. However, if someone sends you a message using an old algorithm you can't do anything about it. We can assume that those who do not have sane software or configuration also miss other important security precautions so that there are many other and easier ways to get to the plaintext than an active MitM or a replay of modified messages. > I think also that we should be mindful that ?be strict about what you send but liberal about what you receive? is great advice for interoperability, but absolutely disastrous advice for security. I fully agree. > But encryption has to change this risk analysis - in an encrypted mail > there can?t be an easy override because the stakes are much higher and > people are easily tempted. When we have a system like Right. When you use encryption you can make a concious decision to keep the data confidential or public. > tbird+enigmail+gpg where there are *three* interacting components, Plugins are a real problem but I think we are doing anywat great given that the native encryption stuff is not much better (Efail tested in Outlook the internal S/MIME which is vulnerable and the GpgOL plugin for OpenPGP which is not vulnerable). I would really be good if the Mozilla folks would work closer together with Enigmail and not reject the idea of including OpenPGP which they more or less did since about 2000. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Tue May 15 10:29:45 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 15 May 2018 09:29:45 +0100 Subject: efail -> improvements (was: Efail or OpenPGP is safer than S/MIME) In-Reply-To: <201805150842.09722.bernhard@intevation.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <874lja5ejh.fsf@wheatstone.g10code.de> <201805150842.09722.bernhard@intevation.de> Message-ID: On 15 May 2018, at 07:42, Bernhard Reiter wrote: >> Another thing we need to learn from this is that HTML elements may be a >> privacy concern in plaintext mail, but they are a *security* concern in >> encrypted mail. > > People clearly seem to want a way to send files with potentially active > elements. So in my opinion the crypto standards and backends should be > designed to allow this in the safest way possible I?m not saying that active elements should be banned outright, just that they should be handled more carefully in the encrypted case than they are in plaintext. So for example, I could change my thunderbird settings to display active content by default, or tbird could let me click on a handy button to load foreign images. This is reasonable UC behaviour if we are only concerned about the privacy implications. But I would argue that it may not be reasonable if we have serious security concerns, so we may want to suppress the handy ?load images? button or have a separate config setting for ?display remote content in encrypted messages by default?. The point being that the context determines the measures that we may want to take. A From patrick at enigmail.net Tue May 15 08:47:06 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 15 May 2018 08:47:06 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <874lja5ejh.fsf__48179.0004917004$1526319728$gmane$org@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <874lja5ejh.fsf__48179.0004917004$1526319728$gmane$org@wheatstone.g10code.de> Message-ID: <30297ead-ee39-2e75-46cc-51b798800657@enigmail.net> On 14.05.18 19:32, Werner Koch wrote: [...] >> 1. change the default behaviour of GPG so that any integrity failure is >> fatal by default, even for old ciphersuites (we could have a flag to > > I am all in favor of this and even considered to that some time ago. > However, not too long ago we removed support for PGP-2 keys which > unfortunately resulted in lots of angry mails from people who now think > they need to use gnupg 1.4 every day because they seem to read mails > From the last century on a regular base. Well, they think and they were > quite vocal. Now telling them they need to enable an option to read > certain not that old mail (e.g. creating by other OpenPGP > implementations) will a) lead to even more angry mails and b) they will > keep on using that option for all mails. Thus my tentative plan was to > make the next major version hard fail on messages without MDC and slowly > start using our forthcoming AEAD encryption mode. > > Well okay, with the new support of the Ehtmlfail paper we could now > point to that paper and always hard error out if no MDC is used even for > old algorithms. Shall we consider this? Yes, I think that's a good idea. -Patrick From andrewg at andrewg.com Tue May 15 11:14:20 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 15 May 2018 10:14:20 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> Message-ID: <360f1994-af7f-ed0c-8da2-23e4881cd0e1@andrewg.com> On 14/05/18 14:44, Andrew Gallagher wrote: > I would humbly suggest that we stop worrying about which side of the > GPG/MUA fence the ball is on, and fix it on *both* sides. I have just opened tickets in both GnuPG and Enigmail for the respective integrity check mitigations. https://dev.gnupg.org/T3981 https://sourceforge.net/p/enigmail/bugs/838/ Please let's avoid a finger-pointing contest. Belt and braces. :-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From Roman.Fiedler at ait.ac.at Tue May 15 11:44:39 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Tue, 15 May 2018 09:44:39 +0000 Subject: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <1844654093.20180514231332@my_localhost_LG> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> <1844654093.20180514231332@my_localhost_LG> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7B056@S0MSMAIL112.arc.local> > Von: MFPA [mailto:2017-r3sgs86x8e-lists-groups at riseup.net] > > Hi > > On Monday 14 May 2018 at 1:33:03 PM, in > local>, > Fiedler Roman wrote:- > > > This would also prevent many other programming > > errors: e.g. if gpg > > claims to have processed 2 signed messages, a client > > has to verify, > > that it also received two "GOOD_SIG" messages. > > What if a message has more than one signature? The status line format should be designed to support those variants to allow a "logical consistency check" of the communication with GnuPG like a message digest allows consistency checking for a cryptographic message. I guess it would be ease for the GnuPG-hardcore developers to define, which fields are required to perform a thorough consistency check. From bernhard at intevation.de Tue May 15 11:45:45 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 15 May 2018 11:45:45 +0200 Subject: efail -> improvements (was: Efail or OpenPGP is safer than S/MIME) In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> <201805150842.09722.bernhard@intevation.de> Message-ID: <201805151145.49866.bernhard@intevation.de> Am Dienstag 15 Mai 2018 10:29:45 schrieb Andrew Gallagher: > I?m not saying that active elements should be banned outright, just that > they should be handled more carefully in the encrypted case than they are > in plaintext. > so we may want to suppress the handy ?load images? button or have > a separate config setting for ?display remote content in encrypted messages > by default?. The point being that the context determines the measures that > we may want to take. I agree. My point is that it is legitimate to send files with potentially active contents. And they are a problem even outside of an email application. So making integrity checks a hard requirement and do not display anything in the failed case seems a good idea to me. Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Tue May 15 11:56:49 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 15 May 2018 10:56:49 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87r2md2vw6.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <874lja5ejh.fsf@wheatstone.g10code.de> <87r2md2vw6.fsf@wheatstone.g10code.de> Message-ID: <5906cb81-f38e-8728-0872-650707204ac6@andrewg.com> On 15/05/18 08:58, Werner Koch wrote: > > Unless you change the default options of gpg or you encrypt to at least > one old key there is no problem at all. I assume that 99.9% of all GPG > created messages are safe because they use MDC in away which allows the > receiving GPG to hard fail if the MDC was stripped. This is a very good point that I think has been overlooked in the chaos. There are many different things going on here that overlap and interact. The only emails that are in danger of being leaked *via the MDC issue* are those that were originally encrypted using one of the obsolete cipher suites. Anything encrypted with AES should be immune. This is because: a) gnupg only falls back to compatibility mode for messages that use obsolete ciphers, and b) If you inject an AES cipherstream into a 3DES or CAST5 message (which is how the CFB gadget trick works), you get garbage. BUT We should also be very careful to note that none of this discussion thread applies to the MIME concatenation vulnerability, which is a problem in Thunderbird and other mail clients, and which cannot be solved by gnupg. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From Roman.Fiedler at ait.ac.at Tue May 15 11:59:17 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Tue, 15 May 2018 09:59:17 +0000 Subject: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <874lja5ejh.fsf@wheatstone.g10code.de> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7B079@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > > > On 14 May 2018, at 18:32, Werner Koch wrote: > > > > On Mon, 14 May 2018 15:44, andrewg at andrewg.com said: > > > >> This all exposes one of the difficulties with trying to manage security > >> software in a decentralised ecosystem. We end up in arguments over > whose > > > > That is actually easy compared to a system which is also designed to > > protect data at rest. Some users may want to restore their 2 year old > > backup to fix a problem with garbled tapes; some may want to read the > > real documents about WMD from 2003; some may even want to be able to > > decrypt their old love letters at the time of their silver wedding. > > Indeed. This is why data must be treated as a living object. If tape drive > technology moves on, the data must be moved on. Same with file formats, > encryption systems and dying raid arrays. Librarians and archaeologists > understand the process of care and feeding for physical artefacts. Digital > artefacts are no exception. So true. By applying such procedures, the long-term costs for providing data access would not only be on the gnupg developers' side (for providing loads of backward compatibility switches in highly security critical context) but also on those users wanting to keep the data for a long time. To improve awareness on user side and also reduce their archival costs, might a "gnupg --archive" function help? It decrypts a message the same way a normal "--decrypt" would do but then reencrypts the old encrypted message plus the decrypted content and a full decryption process audit log using an "archive key". With such a function, gnupg might have it easier to argue running a more rigid scheme for retiring old features, e.g. that first normal decryption will fail (warning about deprecation, recommending sender upgrade or --archive use) and then after some years grace period removing the code completely? From bernhard at intevation.de Tue May 15 12:26:41 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 15 May 2018 12:26:41 +0200 Subject: efail -> improvements (was: Efail or OpenPGP is safer than S/MIME) In-Reply-To: <201805150852.45758.bernhard@intevation.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <201805150842.09722.bernhard@intevation.de> <201805150852.45758.bernhard@intevation.de> Message-ID: <201805151226.48575.bernhard@intevation.de> Just for information: Am Dienstag 15 Mai 2018 08:52:45 schrieb Bernhard Reiter: > .. to only display contents if there was integrity protection by either [..] I'll continue the discussion about what should technically be done to gnupg on gnupg-devel@ > if users or frontends still want to show contents, to me it seems good if [..] to frontends included with Gpg4win on https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-devel Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From seb at wirrsal.net Mon May 14 12:36:22 2018 From: seb at wirrsal.net (Sebastian =?utf-8?Q?Reu=C3=9Fe?=) Date: Mon, 14 May 2018 12:36:22 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> Message-ID: <877eo6msm1.fsf@wirrsal.net> rjh at sixdemonbag.org (Robert J. Hansen) writes: >>> We hesitate to require the MDC also for old algorithms (3DES, CAST5> >>> because a lot of data has been encrypted using them in the first >>> years of OpenPGP. >> So if someone sends me a 3DES-encrypted mail it won't check the MDC? >> Doesn't gpg still support reading 3DES? > Let's try it and find out. :) > ... Yep, GnuPG will warn you the message was not integrity protected. > Your email client should see this warning and refuse to render the message. I notice that the command currently succeeds, albeit with a warning. Would it make sense to have GnuPG return a non-zero exit code in case some MUA does not parse these warnings, or in case it does parse them but proceeds to use the result? Alternatively, perhaps invoking gpg for decryption could honor some command-line switch or gpg.conf option to turn some or all warnings into hard errors. Kind regards, SR From andrewg at andrewg.com Tue May 15 16:59:32 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 15 May 2018 15:59:32 +0100 Subject: Breaking MIME concatenation Message-ID: <8e990067-dd43-12ca-cb59-8d1719e9fea1@andrewg.com> It struck me at lunch that it might be possible for gnupg itself to scupper the MIME concatenation (direct exfiltration) technique mentioned in efail, and thereby plug the leaks in multiple vulnerable clients at once. This would however require it to be naughty with its output. MIME concatenation works because in many clients the individual MIME parts of a message are not kept isolated from each other after they are passed to the rendering engine. Instead, they are concatenated together into a single document, perhaps with some separator such as an hline. This is dangerous because an HTML parser will interpret that document as a single unit, breaking all sorts of same-origin hygiene. The primary technique for exfiltration is to wrap the target document in an active HTML tag such as . But HTML requires the quoted string to be safe, and there is no way for the efail attack to perform input sanitation on the target document before the HTML parser gets its hands on it. Bear with me, because this is *not* a fully thought-out plan, merely an idea. ;-) So gnupg could (under circumstances likely to prevail inside a mail client) prefix and/or suffix its output with an HTML content-injection string specially designed to break out of whatever active element the efail attack might be using. It could be as simple as prefacing the output document with the perfectly valid HTML tag: If this were parsed by an HTML display engine in the normal manner, it would have negligible effect. But enclosed in a tag property, the first set of quotes+angle would exit the tag safely, and then the would cause an early end to the document, with luck causing a fatal validation error, or preventing any content that came after it from being accessible via the DOM. I see a couple of problems with this. Firstly, it may not be possible to tailor a single content-injection tool that would be effective against all attacks and in all HTML engines, although And secondly, gnupg will probably not be able to tell on its own whether it has been called from an MUA context. But setting an environment variable such as GNUPG_HTML_COUNTERMEASURES=true would certainly be sufficient, providing both users and MUA developers a convenient big red switch that can just be enabled. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From patrick at enigmail.net Tue May 15 17:44:17 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 15 May 2018 17:44:17 +0200 Subject: Breaking MIME concatenation In-Reply-To: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> References: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> Message-ID: <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> On 15.05.18 16:59, Andrew Gallagher wrote: > It struck me at lunch that it might be possible for gnupg itself to > scupper the MIME concatenation (direct exfiltration) technique mentioned > in efail, and thereby plug the leaks in multiple vulnerable clients at > once. This would however require it to be naughty with its output. > > MIME concatenation works because in many clients the individual MIME > parts of a message are not kept isolated from each other after they are > passed to the rendering engine. Instead, they are concatenated together > into a single document, perhaps with some separator such as an hline. > This is dangerous because an HTML parser will interpret that document as > a single unit, breaking all sorts of same-origin hygiene. > > The primary technique for exfiltration is to wrap the target document in > an active HTML tag such as . But HTML requires the > quoted string to be safe, and there is no way for the efail attack to > perform input sanitation on the target document before the HTML parser > gets its hands on it. > > Bear with me, because this is *not* a fully thought-out plan, merely an > idea. ;-) > > So gnupg could (under circumstances likely to prevail inside a mail > client) prefix and/or suffix its output with an HTML content-injection > string specially designed to break out of whatever active element the > efail attack might be using. It could be as simple as prefacing the > output document with the perfectly valid HTML tag: > > I already tried a while ago to trick the Thunderbird HTML rendering engine with tricks like this... They don't work. The rendering engine ignores the tag (and also tags like ). I think the correct solution must be to treat each MIME part independently, i.e. it needs to be parsed independently by the HTML engine and produce its own DOM tree. At the end, you can concatenate these DOM trees and create a single correct HTML document. -Patrick -Patrick From mwood at iupui.edu Tue May 15 17:06:26 2018 From: mwood at iupui.edu (Mark H. Wood) Date: Tue, 15 May 2018 11:06:26 -0400 Subject: Don't Panic. In-Reply-To: <5AF9AFCF.8040100@signal100.com> References: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> <5AF9AFCF.8040100@signal100.com> Message-ID: <20180515150626.GB22717@IUPUI.Edu> On Mon, May 14, 2018 at 04:48:31PM +0100, Mark Rousell wrote: > Amongst other things this includes the following paragraph which, as I > understand it, is essentially untrue: > > "There are currently no reliable fixes for the vulnerability. If you > use PGP/GPG or S/MIME for very sensitive communication, you should > disable it in your email client for now," said Sebastian Schinzel > , a > professor of computer security at the University. Heh. "We've discovered that locks can be picked, so you should remove all the locks from your doors right now." -- 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 andrewg at andrewg.com Tue May 15 18:37:26 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 15 May 2018 17:37:26 +0100 Subject: Breaking MIME concatenation In-Reply-To: <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> References: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> Message-ID: <49014816-4f6a-3950-098b-e00292afb10c@andrewg.com> On 15/05/18 16:44, Patrick Brunschwig wrote: > I already tried a while ago to trick the Thunderbird HTML rendering > engine with tricks like this... They don't work. The rendering engine > ignores the tag (and also tags like ). OK, that particular trick won't work. But if content injection is possible, then counter-injection should also be possible. How about: We don't need to worry about what comes after the injected tag close unless DOM scripting is enabled, and if it is enabled, we can abuse it just as easily as the bad guys can. :-) > I think the correct solution must be to treat each MIME part > independently, i.e. it needs to be parsed independently by the HTML > engine and produce its own DOM tree. At the end, you can concatenate > these DOM trees and create a single correct HTML document. Of course that would be the most correct solution. I was trying to see if I could think up the quickest solution. ;-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From lukele at gpgtools.org Tue May 15 17:53:39 2018 From: lukele at gpgtools.org (Lukas Pitschl | GPGTools) Date: Tue, 15 May 2018 17:53:39 +0200 Subject: Breaking MIME concatenation In-Reply-To: <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> References: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> Message-ID: <7E16B6A6-7A96-49B4-B8CF-C5CCBC62646B@gpgtools.org> > Am 15.05.2018 um 17:44 schrieb Patrick Brunschwig : > > I already tried a while ago to trick the Thunderbird HTML rendering > engine with tricks like this... They don't work. The rendering engine > ignores the tag (and also tags like ). > > I think the correct solution must be to treat each MIME part > independently, i.e. it needs to be parsed independently by the HTML > engine and produce its own DOM tree. At the end, you can concatenate > these DOM trees and create a single correct HTML document. I have also already tried to implement a similar fix for Apple Mail a few days ago, using which did work, but is probably a too naive attempt to mitigate against these XSS-kind of attacks. So I absolutely concur with Patricks statement, that the Mime Parsers have to be adjusted to treat every text/html part as single DOM tree or even use different web document instances to represent the message. From tookmund at gmail.com Tue May 15 20:38:22 2018 From: tookmund at gmail.com (Jacob Adams) Date: Tue, 15 May 2018 14:38:22 -0400 Subject: smartcards and GPGME In-Reply-To: <1526308442.npA4dopvpy@esus> References: <7caacadd-5b4f-9ff4-4678-39ed793fc5cf@gmail.com> <1526308442.npA4dopvpy@esus> Message-ID: <703d1656-3db5-007d-3aaa-8e5df1325b46@gmail.com> On 05/14/2018 02:02 AM, Andre Heinecke wrote: > Hi, > > On Sunday, May 13, 2018 6:26:04 PM CEST Jacob Adams wrote: >> As part of a program I'm writing this summer for GSoC, I'd like to be >> able to both move gpg private keys to a smartcard and generate keys on >> the smartcard from an application. While this can be done from gpg, it >> doesn't look like I can do so from GPGME or any other wrappers that >> exist. Have I missed something or is this simply not possible yet? >> >> While I could wrap this functionality of gpg, I'd really prefer not to >> and I'd rather not drop the user to a gpg prompt if I don't have to. > > This is both pretty complicated thorugh GPGME, as there is indeed not a direct > interface. Kleopatra and GPA use the "AssuanEngine" of GPGME to connect to the > gpg-agent's assuan interface and issue / parse commands directly through that > connection. > > You might want to take a look at GPA's implementation: > > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpa.git;a=blob;f=src/cm-openpgp.c Awesome! That's a bit more complex than I was hoping but better than calling gpg directly. Thanks for the pointer! > > Alternatively instead of wrapping gpg (and using the complicated edit > interface) you could also wrap "gpg-connect-agent" and issue commands to > scdaemon through that. That's also an option but I'll try the AssuanEngine first. Thanks, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tookmund at gmail.com Tue May 15 20:45:25 2018 From: tookmund at gmail.com (Jacob Adams) Date: Tue, 15 May 2018 14:45:25 -0400 Subject: GPGME progress callback no current or total Message-ID: I was testing the progress callback of GPGME in python and got some strange results. I'm using GPGME v1.11.1 $ cat progresstest.py import gpg, tempfile # Borrowed from callbacks.py def progress_stdout(what, type, current, total, hook=None): print("PROGRESS UPDATE: what = %s, type = %d, current = %d, total = %d" %\ (what, type, current, total)) tmp = tempfile.TemporaryDirectory() ctx = gpg.Context(home_dir=tmp.name) ctx.set_progress_cb(progress_stdout) ctx.create_key("Test ", algorithm="rsa4096") $ python3 progresstest.py PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 46, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 Aren't current and total supposed to indicate progress? Why might they be zero? Thanks, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mirimir at riseup.net Tue May 15 22:19:17 2018 From: mirimir at riseup.net (Mirimir) Date: Tue, 15 May 2018 09:19:17 -1100 Subject: Breaking MIME concatenation In-Reply-To: <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> References: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> Message-ID: On 05/15/2018 04:44 AM, Patrick Brunschwig wrote: > I think the correct solution must be to treat each MIME part > independently, i.e. it needs to be parsed independently by the HTML > engine and produce its own DOM tree. At the end, you can concatenate > these DOM trees and create a single correct HTML document. > > -Patrick So why use HTML with gnupg? For many years, by default I compose only text, view only text, display no inline images, and never fetch remote content. On the rare occasion that I've tested a fresh Thunderbird install, and accidentally composed HTML, Enigmail has always warned about the need to fold long lines. From patrick at enigmail.net Wed May 16 06:21:42 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 16 May 2018 06:21:42 +0200 Subject: Breaking MIME concatenation In-Reply-To: <7E16B6A6-7A96-49B4-B8CF-C5CCBC62646B__9059.42430622435$1526405645$gmane$org@gpgtools.org> References: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> <7E16B6A6-7A96-49B4-B8CF-C5CCBC62646B__9059.42430622435$1526405645$gmane$org@gpgtools.org> Message-ID: <3995f7eb-1ae5-1394-42de-60e004e60c6a@enigmail.net> On 15.05.18 17:53, Lukas Pitschl | GPGTools wrote: > >> Am 15.05.2018 um 17:44 schrieb Patrick Brunschwig : >> >> I already tried a while ago to trick the Thunderbird HTML rendering >> engine with tricks like this... They don't work. The rendering engine >> ignores the tag (and also tags like ). >> >> I think the correct solution must be to treat each MIME part >> independently, i.e. it needs to be parsed independently by the HTML >> engine and produce its own DOM tree. At the end, you can concatenate >> these DOM trees and create a single correct HTML document. > > I have also already tried to implement a similar fix for Apple Mail a few days ago, > using which did work, but is probably a too naive attempt > to mitigate against these XSS-kind of attacks. > > So I absolutely concur with Patricks statement, that the Mime Parsers have > to be adjusted to treat every text/html part as single DOM tree or even use different > web document instances to represent the message. I have actually thought through this during a sleepless night, and I believe that it could work as a quick and easy to implement *short term* measure until the mail clients have fixed the HTML rendering. If we embed the complete result that we get from gpg into the following wrapper, then we should be able to mitigate at least any known form of the attack when it comes to calling a remote URL during message reading: Content-Type: mutlipart/mixed; boundary="WRAPPER" Content-Description: Efail protection wrapper --WRAPPER Content-Type: text/html --WRAPPER (result of PGP/MIME decryption) --WRAPPER-- Does anyone see a major hole in this that I may have overseen? If not, then I think I'll implement this in Enigmail until Thunderbird has fixed this properly. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed May 16 09:08:05 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 16 May 2018 08:08:05 +0100 Subject: Breaking MIME concatenation In-Reply-To: <3995f7eb-1ae5-1394-42de-60e004e60c6a@enigmail.net> References: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> <7E16B6A6-7A96-49B4-B8CF-C5CCBC62646B__9059.42430622435$1526405645$gmane$org@gpgtools.org> <3995f7eb-1ae5-1394-42de-60e004e60c6a@enigmail.net> Message-ID: <4B62CA82-A338-4400-939C-52B56B6829AD@andrewg.com> > On 16 May 2018, at 05:21, Patrick Brunschwig wrote: > > Content-Type: mutlipart/mixed; boundary="WRAPPER" > Content-Description: Efail protection wrapper > > --WRAPPER > Content-Type: text/html > > > > > > --WRAPPER > (result of PGP/MIME decryption) > --WRAPPER-- I like this. It handles the various quoting options, and does its best to display the cleartext safely. Tbird correctly disables JS, so we don?t need to worry about that. Should there be some indication that mischief is afoot? Or is it more important not to unnecessarily frighten the user? A From wk at gnupg.org Tue May 15 10:44:16 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 May 2018 10:44:16 +0200 Subject: Vulnerable clients (was: US-CERT now issuing a warning for OpenPGP-SMIME-Mail-Client-Vulnerabilities) In-Reply-To: <20180514213152.0000578d@seibercom.net> (jerry@seibercom.net's message of "Mon, 14 May 2018 21:31:52 -0400") References: <20180514213152.0000578d@seibercom.net> Message-ID: <87fu2t2tr3.fsf@wheatstone.g10code.de> On Tue, 15 May 2018 03:31, jerry at seibercom.net said: > NCCIC encourages users and administrators to review CERT/CC?s Vulnerability > Note VU #122919. Doesn't CERT read the paper before produciong a report? The table of vulnerable MUAs is easy enough to read. To better see what we are discussing, here is the table in plain text format with the check marks replaced by yes and no. --8<---------------cut here---------------start------------->8--- TABLE OF VULNERABLE MAIL CLIENTS | OS | Client | S/MIME | PGP | | | | | -MDC | +MDC | SE | |---------+-----------------+--------+------+------+-----| | Windows | Outlook 2007 | yes | yes | yes | no | | | Outlook 2010 | yes | no | no | no | | | Outlook 2013 | user | no | no | no | | | Outlook 2016 | user | no | no | no | | | Win. 10 Mail | yes | ? | ? | ? | | | Win. Live Mail | yes | ? | ? | ? | | | The Bat! | user | no | no | no | | | Postbox | yes | yes | yes | yes | | | eM Client | yes | no | yes | no | | | IBM Notes | yes | ? | ? | ? | | Linux | Thunderbird | yes | yes | yes | yes | | | Evolution | yes | no | no | no | | | Trojit? | yes | no | no | no | | | KMail | user | no | no | no | | | Claws | no | no | no | no | | | Mutt | no | no | no | no | | macOS | Apple Mail | yes | yes | yes | yes | | | MailMate | yes | no | no | no | | | Airmail | yes | yes | yes | yes | | iOS | Mail App | yes | ? | ? | ? | | | Canary Mail | ? | no | no | no | | Android | K-9 Mail | ? | no | no | no | | | R2Mail2 | yes | no | yes | no | | | MailDroid | yes | no | yes | no | | | Nine | yes | ? | ? | ? | | Webmail | United Internet | ? | no | no | no | | | Mailbox.org | ? | no | no | no | | | ProtonMail | ? | no | no | no | | | Mailfence | ? | no | no | no | | | GMail | yes | ? | ? | ? | | Webapp | Roundcube | ? | no | no | yes | | | Horde IMP | user | no | yes | yes | | | AfterLogic | ? | no | no | no | | | Rainloop | ? | no | no | no | | | Mailpile | ? | no | no | no | - = Encryption not supported no = Not vulnerable yes = Vulnerable user = Vulnerable after user consent -MDC = with stripped MDC, +MDC = with wrong MDC, SE = SE packets --8<---------------cut here---------------end--------------->8--- My conclusion is that S/MIME is vulnerable in most clients with the exception of The Bat!, Kmail, Claws, Mutt and Horde IMP. I take the requirement for a user consent as non-vulnerable. Most of the non-vulnerable clients use GnuPG as their engine. For OpenPGP I see lots of no and only a few vulnerable clients: Support for Outlook 2007 has long been dropped and Gpg4win/GpgOL gives a big warning when you try to use it with OL2007. All other Outlook versions are not vulnerable. The case for Thunderbird/Enigmail is not that clear because the researcher confirmed that Enigmail 2.0 is in general not vulnerable; we don't know which version of Enigmail was tested. I don't know Postbox, Apple mailers or Horde IMP. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From panina at nonbinary.me Wed May 16 09:04:19 2018 From: panina at nonbinary.me (eira wahlin) Date: Wed, 16 May 2018 09:04:19 +0200 Subject: Efail Message-ID: Hi. I've been looking at a vulnerability in mail clients using pgp, described at efail.de. It is a technique where an attacker would inject a HTML IMG tag in an email, enveloping the encrypted text. This would send the cleartext message to the server inticated in the IMG tag. To me, it seems that this attack would be defeated by signing the encrypted message, which (to my knowledge) most email clients does by default. Am I missing something here? How do clients generally handle partially signed messages? Would they decrypt an encrypted message, if it would be enveloped in a cleartext IMG tag? Panina, malm?, sweden -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 858 bytes Desc: not available URL: From guru at unixarea.de Wed May 16 10:02:21 2018 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 16 May 2018 10:02:21 +0200 Subject: Vulnerable clients (was: US-CERT now issuing a warning for OpenPGP-SMIME-Mail-Client-Vulnerabilities) In-Reply-To: <87fu2t2tr3.fsf@wheatstone.g10code.de> References: <20180514213152.0000578d@seibercom.net> <87fu2t2tr3.fsf@wheatstone.g10code.de> Message-ID: <20180516080221.GA13977@sh4-5.1blu.de> El d?a Tuesday, May 15, 2018 a las 10:44:16AM +0200, Werner Koch escribi?: > On Tue, 15 May 2018 03:31, jerry at seibercom.net said: > > NCCIC encourages users and administrators to review CERT/CC?s Vulnerability > > Note VU #122919. > > Doesn't CERT read the paper before produciong a report? The table of > vulnerable MUAs is easy enough to read. To better see what we are > discussing, here is the table in plain text format with the check marks > replaced by yes and no. > > --8<---------------cut here---------------start------------->8--- > TABLE OF VULNERABLE MAIL CLIENTS > > | OS | Client | S/MIME | PGP | > | | | | -MDC | +MDC | SE | > |---------+-----------------+--------+------+------+-----| > | Windows | Outlook 2007 | yes | yes | yes | no | > | | Outlook 2010 | yes | no | no | no | > | | Outlook 2013 | user | no | no | no | > | | Outlook 2016 | user | no | no | no | > | | Win. 10 Mail | yes | ? | ? | ? | > | | Win. Live Mail | yes | ? | ? | ? | > | | The Bat! | user | no | no | no | > | | Postbox | yes | yes | yes | yes | > | | eM Client | yes | no | yes | no | > | | IBM Notes | yes | ? | ? | ? | > | Linux | Thunderbird | yes | yes | yes | yes | > | | Evolution | yes | no | no | no | > | | Trojit? | yes | no | no | no | > | | KMail | user | no | no | no | > | | Claws | no | no | no | no | > | | Mutt | no | no | no | no | > | macOS | Apple Mail | yes | yes | yes | yes | > | | MailMate | yes | no | no | no | > | | Airmail | yes | yes | yes | yes | > | iOS | Mail App | yes | ? | ? | ? | > | | Canary Mail | ? | no | no | no | > | Android | K-9 Mail | ? | no | no | no | > | | R2Mail2 | yes | no | yes | no | > | | MailDroid | yes | no | yes | no | > | | Nine | yes | ? | ? | ? | > | Webmail | United Internet | ? | no | no | no | > | | Mailbox.org | ? | no | no | no | > | | ProtonMail | ? | no | no | no | > | | Mailfence | ? | no | no | no | > | | GMail | yes | ? | ? | ? | > | Webapp | Roundcube | ? | no | no | yes | > | | Horde IMP | user | no | yes | yes | > | | AfterLogic | ? | no | no | no | > | | Rainloop | ? | no | no | no | > | | Mailpile | ? | no | no | no | > > > - = Encryption not supported > no = Not vulnerable > yes = Vulnerable > user = Vulnerable after user consent > > -MDC = with stripped MDC, +MDC = with wrong MDC, SE = SE packets > --8<---------------cut here---------------end--------------->8--- > > My conclusion is that S/MIME is vulnerable in most clients with the > exception of The Bat!, Kmail, Claws, Mutt and Horde IMP. I take the > requirement for a user consent as non-vulnerable. Most of the > non-vulnerable clients use GnuPG as their engine. Werner, my conclusion in addition is that the table is incorrect. Most (if not even all) of the MUA which are noted for Linux do run on nearly any other UNIX flavor, FreeBSD, OpenBSD, ... and mutt in addition runs on Canonical Ubuntu for smartphones/tablets and UBports devices. matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From oub at mat.ucm.es Wed May 16 10:48:52 2018 From: oub at mat.ucm.es (Uwe Brauer) Date: Wed, 16 May 2018 10:48:52 +0200 Subject: Vulnerable clients References: <20180514213152.0000578d@seibercom.net> <87fu2t2tr3.fsf__35034.2568046928$1526455953$gmane$org@wheatstone.g10code.de> Message-ID: <87tvr82dfv.fsf@mat.ucm.es> Sorry for this possible double posting. I am usually using gmane, but I don't see my mail appearing so I resend it to the list, to which I subscribed now. > On Tue, 15 May 2018 03:31, jerry at seibercom.net said: > My conclusion is that S/MIME is vulnerable in most clients with the > exception of The Bat!, Kmail, Claws, Mutt and Horde IMP. I take the > requirement for a user consent as non-vulnerable. Most of the > non-vulnerable clients use GnuPG as their engine. Well what's about GNU emacs(+gnus/vm/rmail)? I asked in the emacs dev list and the default is to block external HTML images. This client(s) is not mentioned, I presume the authors consider it as being too *hackerish*, but it would be worthwhile to find out that with the blocking I mentioned, GNU emacs is in fact not vulnerable. > For OpenPGP I see lots of no and only a few vulnerable clients: Support > for Outlook 2007 has long been dropped and Gpg4win/GpgOL gives a big > warning when you try to use it with OL2007. All other Outlook versions > are not vulnerable. The case for Thunderbird/Enigmail is not that clear > because the researcher confirmed that Enigmail 2.0 is in general not > vulnerable; we don't know which version of Enigmail was tested. I don't > know Postbox, Apple mailers or Horde IMP. I presume the same is true for gnupg+ GNU emacs(+gnus/vm/rmail). BTW: RMS asked on the emacs devel list whether, and I quote, ,---- | If you allow a mail user agent to render HTML for you, you expose | yourself to various kinds of surveillance and swindles. Now, it seems, | one of those might be a decryption exploit. | | Does the exploit depend on Javascript code that the MUI will execute? `---- Any comments? 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 wk at gnupg.org Wed May 16 14:10:06 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 14:10:06 +0200 Subject: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7B056@S0MSMAIL112.arc.local> (Fiedler Roman's message of "Tue, 15 May 2018 09:44:39 +0000") References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> <1844654093.20180514231332@my_localhost_LG> <2ECE9D9EEF1F524185270138AE23265955B7B056@S0MSMAIL112.arc.local> Message-ID: <87k1s3x0m9.fsf@wheatstone.g10code.de> On Tue, 15 May 2018 11:44, Roman.Fiedler at ait.ac.at said: > The status line format should be designed to support those variants to > allow a "logical consistency check" of the communication with GnuPG There is a DECRYPTION_FAILED and that is all what it takes. If the integrity check fails there should be no easy way to circumvent this. RFC-5083 states this cleary: The recipient MUST verify the integrity of the received content before releasing any information, especially the plaintext of the content. If the integrity verification fails, the receiver MUST destroy all of the plaintext of the content. Unfortunately this can't be done by tools prepared to process huge amounts of data. And in contrast to the Efail claims this is an important feature. How would you else do your ZFS backups without having a way to stream the data to the backup system. For failsafe reasons I consider to wipe the plaintext data in GPGME's interface on decryption failure. That can only be done when memory based data or file based objects are used. But I guess that many MUAs use the memory data approach. Such a failsafe protection would avoid an attack even if the error code returned by GPGME is not checked. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed May 16 14:19:56 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 14:19:56 +0200 Subject: Breaking MIME concatenation In-Reply-To: (mirimir@riseup.net's message of "Tue, 15 May 2018 09:19:17 -1100") References: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> Message-ID: <87a7szx05v.fsf@wheatstone.g10code.de> On Tue, 15 May 2018 22:19, mirimir at riseup.net said: > So why use HTML with gnupg? Even some of the journalist kicking that EFFective hype are using encrypted mails with HTML content. 's/ From wk at gnupg.org Wed May 16 14:24:08 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 14:24:08 +0200 Subject: Don't Panic. In-Reply-To: <20180515150626.GB22717@IUPUI.Edu> (Mark H. Wood's message of "Tue, 15 May 2018 11:06:26 -0400") References: <1f29d677-e41c-a96a-7237-dfcfd6809d06@sixdemonbag.org> <5AF9AFCF.8040100@signal100.com> <20180515150626.GB22717@IUPUI.Edu> Message-ID: <87603nwzyv.fsf@wheatstone.g10code.de> On Tue, 15 May 2018 17:06, mwood at iupui.edu said: > Heh. "We've discovered that locks can be picked, so you should remove > all the locks from your doors right now." "There are lot of benefits for members of the Mechanical Frontdoor Foundation. Rely on us for your social engineering tasks. Become a MFF member now. It is just 5% or your haul." -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed May 16 14:31:12 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 14:31:12 +0200 Subject: GPGME progress callback no current or total In-Reply-To: (Jacob Adams's message of "Tue, 15 May 2018 14:45:25 -0400") References: Message-ID: <871sebwzn3.fsf@wheatstone.g10code.de> On Tue, 15 May 2018 20:45, tookmund at gmail.com said: > PROGRESS UPDATE: what = primegen, type = 43, current = 0, total = 0 > > > Aren't current and total supposed to indicate progress? Why might they > be zero? Depends on the type of progress. For prime generation we can't do any estimation. f you are processing files and pipe them to gpg (as gpgme does) it is also not possible to compute a percentage. However we have a sulution: gpg has the option --input-size-hint which is used by gpgme_data_set_flag()'s "size-hint". Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Roman.Fiedler at ait.ac.at Wed May 16 14:44:43 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Wed, 16 May 2018 12:44:43 +0000 Subject: AW: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87k1s3x0m9.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> <1844654093.20180514231332@my_localhost_LG> <2ECE9D9EEF1F524185270138AE23265955B7B056@S0MSMAIL112.arc.local> <87k1s3x0m9.fsf@wheatstone.g10code.de> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7B5B9@S0MSMAIL112.arc.local> > Von: Werner Koch [mailto:wk at gnupg.org] > > On Tue, 15 May 2018 11:44, Roman.Fiedler at ait.ac.at said: > > > The status line format should be designed to support those variants to > > allow a "logical consistency check" of the communication with GnuPG > > There is a > > DECRYPTION_FAILED > > and that is all what it takes. But this is only a single status code for a very complex decryption/validation process (considering cipher methods, signature methods, local time, trust DBs, signatures, number of messages, ...). When relying on that single code, gpg would need configuration parameters to configure each step of the whole decryption/validation process in a very fine-grained way, so that gpg will know in the end, if it should issue the FAILED or not. I am not sure, if gpg could support implementation/testing/life-cycle-efforts to establish all those parameters and different process models for most of the decryption processes gpg users envision to use gpg for. > If the integrity check fails there > should be no easy way to circumvent this. RFC-5083 states this cleary: > > The recipient MUST verify the integrity of the received content > before releasing any information, especially the plaintext of the > content. If the integrity verification fails, the receiver MUST > destroy all of the plaintext of the content. > > Unfortunately this can't be done by tools prepared to process huge > amounts of data. And in contrast to the Efail claims this is an > important feature. How would you else do your ZFS backups without > having a way to stream the data to the backup system. This is just the example of two different, complex decryption/validation processes, that should be supported both. As the definition of the "process" also has implications, what a valid "integrity check" is (see also the discussion about historic messages), I believe, that this is hard to be done by breaking it down to a single 0/1 decision for gpg (which might not know the constraints of the current process in detail). Otherwise a "--allow-non-rfc-5083-streaming-mode" flag should already exist to tell gpg more about the decryption process constraints (to distinguish between the two different process models, that should be implemented already, just for your RFC-citation from above). > ... LG Roman From wk at gnupg.org Wed May 16 14:42:03 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 14:42:03 +0200 Subject: Vulnerable clients In-Reply-To: <87tvr82dfv.fsf@mat.ucm.es> (Uwe Brauer's message of "Wed, 16 May 2018 10:48:52 +0200") References: <20180514213152.0000578d@seibercom.net> <87fu2t2tr3.fsf__35034.2568046928$1526455953$gmane$org@wheatstone.g10code.de> <87tvr82dfv.fsf@mat.ucm.es> Message-ID: <87wow3vkkk.fsf@wheatstone.g10code.de> On Wed, 16 May 2018 10:48, oub at mat.ucm.es said: > > On Tue, 15 May 2018 03:31, jerry at seibercom.net said: > > > My conclusion is that S/MIME is vulnerable in most clients with the > > exception of The Bat!, Kmail, Claws, Mutt and Horde IMP. I take the > > requirement for a user consent as non-vulnerable. Most of the > > non-vulnerable clients use GnuPG as their engine. [For clarity: the above quote is by me] > Well what's about GNU emacs(+gnus/vm/rmail)? I asked in the emacs dev > list and the default is to block external HTML images. Well Emacs user's dont view HTML mails, right? At least I don't and use W H to read html. That does not load any images etc. > This client(s) is not mentioned, I presume the authors consider it as > being too *hackerish*, but it would be worthwhile to find out that with > the blocking I mentioned, GNU emacs is in fact not vulnerable. They also don't mention that Outlook plugin which is used by a lot of people including the ACLU and thus Snowden's lawyer. What I heard is that it had sevweral flaws how it handles HTML. But they tested tools I never heard about. BTW, why didn't they test the Volksverschl?sselung. > BTW: RMS asked on the emacs devel list whether, and I quote, > > ,---- > | If you allow a mail user agent to render HTML for you, you expose > | yourself to various kinds of surveillance and swindles. Now, it seems, > | one of those might be a decryption exploit. > | > | Does the exploit depend on Javascript code that the MUI will execute? No, it does not depend on Javascript. Javascript in mails is like given out accounts to your box for free. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Wed May 16 15:55:16 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 16 May 2018 14:55:16 +0100 Subject: AW: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7B5B9@S0MSMAIL112.arc.local> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> <1844654093.20180514231332@my_localhost_LG> <2ECE9D9EEF1F524185270138AE23265955B7B056@S0MSMAIL112.arc.local> <87k1s3x0m9.fsf@wheatstone.g10code.de> <2ECE9D9EEF1F524185270138AE23265955B7B5B9@S0MSMAIL112.arc.local> Message-ID: <4A78D78D-540E-47E2-9335-6535023AC460@andrewg.com> > On 16 May 2018, at 13:44, Fiedler Roman wrote: > > I am not sure, if gpg could support implementation/testing/life-cycle-efforts to establish all those parameters and different process models for most of the decryption processes gpg users envision to use gpg for. Why do we need a plethora of configuration parameters to selectively turn off various parts of a security protocol? Why should we even encourage such a thing? With security, either everything seems to be ok, or it?s broken in such a way that it?s potentially an utter disaster. And quite probably both simultaneously. The only reasonable use case for selective disabling of security protocol features is for backwards compatibility. That doesn?t require fine grained control, just a version number. And even then, it opens up the possibility for user error. I?m going to preemptively quote RJH here before he gets around to it. Use the defaults! ;-) A From rjh at sixdemonbag.org Wed May 16 15:59:24 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 16 May 2018 09:59:24 -0400 Subject: AW: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <4A78D78D-540E-47E2-9335-6535023AC460@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> <1844654093.20180514231332@my_localhost_LG> <2ECE9D9EEF1F524185270138AE23265955B7B056@S0MSMAIL112.arc.local> <87k1s3x0m9.fsf@wheatstone.g10code.de> <2ECE9D9EEF1F524185270138AE23265955B7B5B9@S0MSMAIL112.arc.local> <4A78D78D-540E-47E2-9335-6535023AC460@andrewg.com> Message-ID: <40a91e7c-786a-c8e3-916c-800bf817ac7d@sixdemonbag.org> > I?m going to preemptively quote RJH here before he gets around to it. Use the defaults! ;-) :) From Roman.Fiedler at ait.ac.at Wed May 16 16:24:46 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Wed, 16 May 2018 14:24:46 +0000 Subject: AW: AW: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <4A78D78D-540E-47E2-9335-6535023AC460@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> <1844654093.20180514231332@my_localhost_LG> <2ECE9D9EEF1F524185270138AE23265955B7B056@S0MSMAIL112.arc.local> <87k1s3x0m9.fsf@wheatstone.g10code.de> <2ECE9D9EEF1F524185270138AE23265955B7B5B9@S0MSMAIL112.arc.local> <4A78D78D-540E-47E2-9335-6535023AC460@andrewg.com> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7B651@S0MSMAIL112.arc.local> > Von: Andrew Gallagher [mailto:andrewg at andrewg.com] > > > On 16 May 2018, at 13:44, Fiedler Roman > wrote: > > > > I am not sure, if gpg could support implementation/testing/life-cycle-efforts > to establish all those parameters and different process models for most of the > decryption processes gpg users envision to use gpg for. > > Why do we need a plethora of configuration parameters to selectively turn > off various parts of a security protocol? Why should we even encourage such > a thing? With security, either everything seems to be ok, or it?s broken in such > a way that it?s potentially an utter disaster. And quite probably both > simultaneously. In my opinion it is hard to find such a "one size fits all" solution. Like Werner's example: disabling decryption streaming operation might increase security for some use-cases (validation before decryption&output) but might make others impossible, like streaming of backups (decryption&output before final validation). So you need something on the interface to support that non-standard behavior, deviate from the default. > The only reasonable use case for selective disabling of security protocol > features is for backwards compatibility. That doesn?t require fine grained > control, just a version number. And even then, it opens up the possibility for > user error. Yes, another example for different use-cases and hence different process model requirements in software. > I?m going to preemptively quote RJH here before he gets around to it. Use the > defaults! ;-) Then why are there already so many command line options for decryption/validation gpg not just one: "--insecure"? From my point of view, monopolists might be able to push one set of defaults but the open source software ecosystem might work differently: those projects survive, that enable that many use-cases per development effort, so that they find sufficient developers/funds to support development. If they drift off, the project will fork/another project might take over. So gpg has to watch out for the optimum point between following extremes: 1) Only supporting one standard use-case with default settings (thus increasing security but loosing users) 2) Supporting many use-cases via different gpg-internal decryption/validation-process models (requiring loads of parameters, complex models, lot of implementation, risk to invoke gpg with wrong parameters) 3) Supporting one generic use-case/process model and leaving it to the caller (other side of interface) to decide what to make from it (risk, that other party just does not do it right - e.g. ignores a warning like with Efail) Assuming, that the ideal point would be somewhere in between, supporting only a single FAIL status like old-style shell commands might not be sufficient to attract sufficient users from world 1, 2, 3 above. LG Roman From martin at postzone.org Wed May 16 15:46:05 2018 From: martin at postzone.org (Martin) Date: Wed, 16 May 2018 15:46:05 +0200 Subject: Breaking MIME concatenation Message-ID: <192346920.20180516154605@postzone.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Am Dienstag, 15. Mai 2018, 22:19:17 schreiben Sie: > On 05/15/2018 04:44 AM, Patrick Brunschwig wrote: > >> I think the correct solution must be to treat each MIME part >> independently, i.e. it needs to be parsed independently by the HTML >> engine and produce its own DOM tree. At the end, you can concatenate >> these DOM trees and create a single correct HTML document. >> >> -Patrick > So why use HTML with gnupg? I think a fundamental discussion is necessary with the question: Who should / will use GnuPG in the future? Two extremes: Only these people who need really to encrypt their emails because they are persecuted. But these people learned how to handle their email client correctly and these people will write text-only also in the future. Or is Email encrypting a need for *every* email user? But there the standard today IS that mails are HTML-written and contain links and pictures and so on. If GnuPG should be a tool for "everybody" HTML mail must be encrypted and decrypted correctly by the clients and GnuPG should give any important information, - -- Regards Martin -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE92uV/w2x7WB1p4XLsdyR185C444FAlr8NjoACgkQsdyR185C 4474IAf/VBxWlV8/r5QHblhK6wUVzZFflEJH1zrE25notn3F5SNp35hoF6JkbjNU sbej2HMAaGPaSn7zoFNs6npzw/1jR0/Y8o6jgRR2XfDjCMMhMrDvfiGceoOvDNoG FJfV5llksYKUYPXzxrxQLJ+m553MItZ2VfN0SXz4cLnH+cqEcXAt9dKHYdJPJjus CxmEDe0U+noYYn+Pr7i6Lx18OGDyPot6OGt1lJ9biQhTpfn0/WuyFkHaNSRFoe8Z LnLIjyvcKbb083nsYCQWlY59QR2Kz38ulzFajwGYx8fKXwFxSptpwEM8xbD0u/vh DlGPOnzX7W8wgzvn+2AyQ/hi9kVWPg== =Gbsn -----END PGP SIGNATURE----- From martin at postzone.org Wed May 16 15:55:48 2018 From: martin at postzone.org (Martin) Date: Wed, 16 May 2018 15:55:48 +0200 Subject: Vulnerable clients (was: US-CERT now issuing a warning for OpenPGP-SMIME-Mail-Client-Vulnerabilities) Message-ID: <1097699314.20180516155528@postzone.org> Hi, Am Mittwoch, 16. Mai 2018, 10:02:21 schreiben Sie: > Werner, my conclusion in addition is that the table is incorrect. > Most (if not even all) of the MUA which are noted for Linux do run on > nearly any other UNIX flavor, FreeBSD, OpenBSD, ... and mutt in addition > runs on Canonical Ubuntu for smartphones/tablets and UBports devices. To show that developers of clients take the situation seriously one example: Today I got an update for Android R2Mail2 which fixes the #efail problem. There's still a chance ;-) -- Regards Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From farhanible at gmail.com Wed May 16 15:49:25 2018 From: farhanible at gmail.com (F Rafi) Date: Wed, 16 May 2018 09:49:25 -0400 Subject: Efail In-Reply-To: References: Message-ID: Oh man.. check a few of the previous list emails on this subject. They're fairly detailed. Farhan On Wed, May 16, 2018 at 3:04 AM, eira wahlin wrote: > Hi. > I've been looking at a vulnerability in mail clients using pgp, described > at efail.de. It is a technique where an attacker would inject a HTML IMG > tag in an email, enveloping the encrypted text. This would send the > cleartext message to the server inticated in the IMG tag. > > To me, it seems that this attack would be defeated by signing the > encrypted message, which (to my knowledge) most email clients does by > default. > > Am I missing something here? How do clients generally handle partially > signed messages? Would they decrypt an encrypted message, if it would be > enveloped in a cleartext IMG tag? > > Panina, malm?, sweden > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trinh.randy at gmail.com Wed May 16 16:54:52 2018 From: trinh.randy at gmail.com (Randy Trinh) Date: Wed, 16 May 2018 10:54:52 -0400 Subject: [GPGME] Repeated decrypt fails Message-ID: Hi everyone, I'm fairly new to GnuPG and GPGME in general and I'm currently trying to implement a process in which a file is uploaded from a website in which case my program uses GPGME to decrypt the file returning true or false. The first time I upload the file (a .tar.gz) and run "gpgme_op_decrypt_start" and then "gpgme_wait", the file is decrypted successfully in which case I can extract the contents, but if I upload the SAME original file again or any amount of times after the first instance, GPGME fails** to decrypt it. Is there anything I may be doing wrong? **Fails: GPGME returns an error of success and a "decrypted" .tar.gz file that is empty -- The uploaded file in both instances can still be decrypted by calling GnuPG from command line but the only way to get GPGME to successfully decrypt after the first decryption is to restart my program. (Is it also normal for GPGME to return an error of success for this instance as it has clearly failed/produced a corrupted file? Similarly it also returns an error result of success even when I upload a non-encrypted .tar.gz whereas GnuPG outputs that no OpenPGP data is found and the decrypt message has failed: eof) Thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed May 16 18:43:27 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 18:43:27 +0200 Subject: AW: AW: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7B651@S0MSMAIL112.arc.local> (Fiedler Roman's message of "Wed, 16 May 2018 14:24:46 +0000") References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> <1844654093.20180514231332@my_localhost_LG> <2ECE9D9EEF1F524185270138AE23265955B7B056@S0MSMAIL112.arc.local> <87k1s3x0m9.fsf@wheatstone.g10code.de> <2ECE9D9EEF1F524185270138AE23265955B7B5B9@S0MSMAIL112.arc.local> <4A78D78D-540E-47E2-9335-6535023AC460@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7B651@S0MSMAIL112.arc.local> Message-ID: <87lgcjtuts.fsf@wheatstone.g10code.de> On Wed, 16 May 2018 16:24, Roman.Fiedler at ait.ac.at said: > In my opinion it is hard to find such a "one size fits all" > solution. Like Werner's example: disabling decryption streaming The goal of the MDC is to assure that the message has been received exactly as the sender set it. Thus there is just a binary decision: Okay or Fail. Everything is like you have been dropped at boot time into manual fsck mode - you can do something about it or you just irginore things and restore the partition. > streaming of backups (decryption&output before final validation). So > you need something on the interface to support that non-standard > behavior, deviate from the default. It is already there. If you use "--output FILE" the file is either created or not. Your choice. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed May 16 18:48:59 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 18:48:59 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <5906cb81-f38e-8728-0872-650707204ac6@andrewg.com> (Andrew Gallagher's message of "Tue, 15 May 2018 10:56:49 +0100") References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <874lja5ejh.fsf@wheatstone.g10code.de> <87r2md2vw6.fsf@wheatstone.g10code.de> <5906cb81-f38e-8728-0872-650707204ac6@andrewg.com> Message-ID: <87h8n7tukk.fsf@wheatstone.g10code.de> On Tue, 15 May 2018 11:56, andrewg at andrewg.com said: > We should also be very careful to note that none of this discussion > thread applies to the MIME concatenation vulnerability, which is a > problem in Thunderbird and other mail clients, and which cannot be While we are at that point. Can we get a definive answer whether TB loads external content by default, that is honors the href, erc, etc. attributes? Form the screenshot I have seen, it says it won't do that. But I am not sure what is the default. I hesitate to achieve HTML-mail expert status (see my X-message-flag header). Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed May 16 20:00:35 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 20:00:35 +0200 Subject: Vulnerable clients In-Reply-To: <20180516080221.GA13977@sh4-5.1blu.de> (Matthias Apitz's message of "Wed, 16 May 2018 10:02:21 +0200") References: <20180514213152.0000578d@seibercom.net> <87fu2t2tr3.fsf@wheatstone.g10code.de> <20180516080221.GA13977@sh4-5.1blu.de> Message-ID: <87d0xvtr98.fsf@wheatstone.g10code.de> On Wed, 16 May 2018 10:02, guru at unixarea.de said: > Most (if not even all) of the MUA which are noted for Linux do run on > nearly any other UNIX flavor, FreeBSD, OpenBSD, ... and mutt in addition I would have written Unix instead of mentioning one specific flavor of Unix kernel software ;-) Given that they also forgot to communicate version numbers of the actual crypto engines and plugins, it is not that important. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lukele at gpgtools.org Wed May 16 21:50:52 2018 From: lukele at gpgtools.org (Lukas Pitschl | GPGTools) Date: Wed, 16 May 2018 21:50:52 +0200 Subject: Breaking MIME concatenation In-Reply-To: <3995f7eb-1ae5-1394-42de-60e004e60c6a@enigmail.net> References: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> <7E16B6A6-7A96-49B4-B8CF-C5CCBC62646B__9059.42430622435$1526405645$gmane$org@gpgtools.org> <3995f7eb-1ae5-1394-42de-60e004e60c6a@enigmail.net> Message-ID: <7BBE0ECE-06BE-4ECD-B16E-22266E5D23A7@gpgtools.org> > Am 16.05.2018 um 06:21 schrieb Patrick Brunschwig : > > Content-Type: mutlipart/mixed; boundary="WRAPPER" > Content-Description: Efail protection wrapper > > --WRAPPER > Content-Type: text/html > > > > > > --WRAPPER > (result of PGP/MIME decryption) > ?WRAPPER? Looks alright so far, does the same work for inline PGP? Is there a particular for the specific inline-styles? In macOS Mail we will disable remote content loading completely and prevent the user from re-enabling it for encrypted messages. Unfortunately the chance that Apple will fix their mime parser is probably close to none. Currently also looking if it is possible to inject a separate web document. Best, Lukas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 268 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mirimir at riseup.net Thu May 17 01:06:10 2018 From: mirimir at riseup.net (Mirimir) Date: Wed, 16 May 2018 12:06:10 -1100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87h8n7tukk.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <874lja5ejh.fsf@wheatstone.g10code.de> <87r2md2vw6.fsf@wheatstone.g10code.de> <5906cb81-f38e-8728-0872-650707204ac6@andrewg.com> <87h8n7tukk.fsf@wheatstone.g10code.de> Message-ID: <3c142e4d-baab-bc11-e9a0-ce655a042dc2@riseup.net> On 05/16/2018 05:48 AM, Werner Koch wrote: > On Tue, 15 May 2018 11:56, andrewg at andrewg.com said: > >> We should also be very careful to note that none of this discussion >> thread applies to the MIME concatenation vulnerability, which is a >> problem in Thunderbird and other mail clients, and which cannot be > > While we are at that point. Can we get a definive answer whether TB > loads external content by default, that is honors the href, erc, etc. > attributes? Form the screenshot I have seen, it says it won't do that. > But I am not sure what is the default. By default, Thunderbird displays full HTML. But it doesn't load external content, such as embedded images. I checked in an Ubuntu LiveCD. > I hesitate to achieve HTML-mail expert status (see my X-message-flag > header). > > > Salam-Shalom, > > Werner From mirimir at riseup.net Thu May 17 01:39:49 2018 From: mirimir at riseup.net (Mirimir) Date: Wed, 16 May 2018 12:39:49 -1100 Subject: Breaking MIME concatenation In-Reply-To: <192346920.20180516154605@postzone.org> References: <192346920.20180516154605@postzone.org> Message-ID: <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> On 05/16/2018 02:46 AM, Martin wrote: > Hi > > Am Dienstag, 15. Mai 2018, 22:19:17 schreiben Sie: > >> On 05/15/2018 04:44 AM, Patrick Brunschwig wrote: > >> > >>> I think the correct solution must be to treat each MIME part >>> independently, i.e. it needs to be parsed independently by the HTML >>> engine and produce its own DOM tree. At the end, you can concatenate >>> these DOM trees and create a single correct HTML document. >>> >>> -Patrick > >> So why use HTML with gnupg? > > I think a fundamental discussion is necessary with the question: Who > should / will use GnuPG in the future? > > Two extremes: Only these people who need really to encrypt their > emails because they are persecuted. But these people learned how to > handle their email client correctly and these people will write > text-only also in the future. > > Or is Email encrypting a need for *every* email user? But there the > standard today IS that mails are HTML-written and contain links and > pictures and so on. If GnuPG should be a tool for "everybody" HTML > mail must be encrypted and decrypted correctly by the clients and > GnuPG should give any important information, Yes, emails commonly contain HTML, embedded images and links. But Efail is by no means the only reason to avoid them. Tracking pixils. Malware dropping. I've avoided all that since the 90s. It's just good OPSEC. That is, this isn't really about GnuPG. It's about email OPSEC. However, I get that many users expect HTML, embedded images and links. So the best solution would be a tweak to GnuPG that breaks HTML and embedded remote content. That would protect against Efail, no matter how email clients were configured. It'd also protect against other exploits that depend on fetching remote content. And it wouldn't require users to entirely forgo HTML and embedded remote content. Just with GnuPG. From rjh at sixdemonbag.org Thu May 17 01:48:21 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 16 May 2018 19:48:21 -0400 Subject: Breaking MIME concatenation In-Reply-To: <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> References: <192346920.20180516154605@postzone.org> <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> Message-ID: > I think a fundamental discussion is necessary with the question: Who > should / will use GnuPG in the future? While y'all are having this discussion, remember that GnuPG's 95% use case is verifying Linux packages, and that number isn't expected to change a whole lot. Email users are important, but are also a very very small part of the ecosystem. Under 5% of the use, definitely; probably under 1%; I wouldn't be surprised if it was under 0.1%. From patrick at enigmail.net Thu May 17 08:59:48 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 17 May 2018 08:59:48 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> Message-ID: On 15.05.18 11:14, Andrew Gallagher wrote: > On 14/05/18 14:44, Andrew Gallagher wrote: >> I would humbly suggest that we stop worrying about which side of the >> GPG/MUA fence the ball is on, and fix it on *both* sides. > > I have just opened tickets in both GnuPG and Enigmail for the respective > integrity check mitigations. > > https://dev.gnupg.org/T3981 > https://sourceforge.net/p/enigmail/bugs/838/ > > Please let's avoid a finger-pointing contest. Belt and braces. :-) So, just that you are aware of the consequences of this change. I implemented the check for "gpg: WARNING: message was not integrity protected" in Enigmail 2.0.4. Within 12 hours after the release I got 5 bug reports/support requests from users who can't read their (old?) mails anymore. And the day in Europe has only just begun -- many users did not yet upgrade ... -Patrick From wk at gnupg.org Thu May 17 09:59:18 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 09:59:18 +0200 Subject: Breaking MIME concatenation In-Reply-To: <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> (mirimir@riseup.net's message of "Wed, 16 May 2018 12:39:49 -1100") References: <192346920.20180516154605@postzone.org> <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> Message-ID: <87vabmsofd.fsf@wheatstone.g10code.de> On Thu, 17 May 2018 01:39, mirimir at riseup.net said: > However, I get that many users expect HTML, embedded images and links. Well they expect a bit of markup like *bold* or _underlined_ or /italics/ and links like https://gnupg.org but any decent MUA already supports this for plain text mails. Proper GUI based MUAs also support inline images (which are part of MIME); I used such MUAs already in in the mid 90ies. I doubt that mail is the right thing to employ fancy CSS stuff, though. > So the best solution would be a tweak to GnuPG that breaks HTML and > embedded remote content. That would protect against Efail, no matter how gpg will nver touch the payload. If MUAs want to sanitize HTML, I won't have a problem with that. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bernhard at intevation.de Thu May 17 10:11:56 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 17 May 2018 10:11:56 +0200 Subject: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <192346920.20180516154605@postzone.org> References: <192346920.20180516154605@postzone.org> Message-ID: <201805171012.00379.bernhard@intevation.de> Am Mittwoch 16 Mai 2018 15:46:05 schrieb Martin: > I think a fundamental discussion is necessary with the question: Who > should / will use GnuPG in the future? Note that during one contract in 2016 we came up with some thoughts in where GnuPG could be heading: https://wiki.gnupg.org/EasyGpg2016/VisionAndStories > Two extremes: Only these people who need really to encrypt their > emails because they are persecuted. But these people learned how to > handle their email client correctly and these people will write > text-only also in the future. The problem stays viewing email contents. > Or is Email encrypting a need for *every* email user? But there the > standard today IS that mails are HTML-written and contain links and > pictures and so on. If GnuPG should be a tool for "everybody" HTML > mail must be encrypted and decrypted correctly by the clients and > GnuPG should give any important information, Personally I believe that it is a need for users to have end-to-end encryption with email. And it is a legitimate need for users to have some markup and graphical layout. I agree that technically HTML (with it extensions) is a bad format to serve this need. Similiar to PDF. One RTF was an approach Nextstep's mail took and that got some adoption, but not enough. Today it would be some very simple wiki markup language. The technical and organisational difficulty is how to control backchannels and educate and support users to be able to make good decisions about their security and the implications and transported files. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu May 17 10:01:37 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 10:01:37 +0200 Subject: Breaking MIME concatenation In-Reply-To: (Robert J. Hansen's message of "Wed, 16 May 2018 19:48:21 -0400") References: <192346920.20180516154605@postzone.org> <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> Message-ID: <87r2masobi.fsf@wheatstone.g10code.de> On Thu, 17 May 2018 01:48, rjh at sixdemonbag.org said: > While y'all are having this discussion, remember that GnuPG's 95% use > case is verifying Linux packages, and that number isn't expected to > change a whole lot. I am pretty sure that there are more Windows GPG users than users who run Linux on their desktop. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu May 17 10:07:19 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 10:07:19 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: (Patrick Brunschwig's message of "Thu, 17 May 2018 08:59:48 +0200") References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> Message-ID: <87muwyso20.fsf@wheatstone.g10code.de> On Thu, 17 May 2018 08:59, patrick at enigmail.net said: > Within 12 hours after the release I got 5 bug reports/support requests Kudos to Enigmail for acting as our guinea pig. I implemented the same thing in GPGME this morning (see my mail to enigmail users). What shall we do now? Provide a separate tool to decrypt and clean HTML messages or add a tool to Enigmail to do just this? Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Thu May 17 10:20:51 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 17 May 2018 09:20:51 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> Message-ID: On 17/05/18 07:59, Patrick Brunschwig wrote: > Within 12 hours after the release I got 5 bug reports/support requests > from users who can't read their (old?) mails anymore. And the day in > Europe has only just begun -- many users did not yet upgrade ... Are we confident so far that this is limited to the expected breaking cases (pre-MDC ciphers) and not some unexpected side effect? -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From patrick at enigmail.net Thu May 17 10:24:59 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 17 May 2018 10:24:59 +0200 Subject: Breaking MIME concatenation In-Reply-To: <7BBE0ECE-06BE-4ECD-B16E-22266E5D23A7__24422.9685319171$1526504189$gmane$org@gpgtools.org> References: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> <7E16B6A6-7A96-49B4-B8CF-C5CCBC62646B__9059.42430622435$1526405645$gmane$org@gpgtools.org> <3995f7eb-1ae5-1394-42de-60e004e60c6a@enigmail.net> <7BBE0ECE-06BE-4ECD-B16E-22266E5D23A7__24422.9685319171$1526504189$gmane$org@gpgtools.org> Message-ID: <214a52b5-ed4f-9e91-a167-80650f1722b2@enigmail.net> On 16.05.18 21:50, Lukas Pitschl | GPGTools wrote: > >> Am 16.05.2018 um 06:21 schrieb Patrick Brunschwig : >> >> Content-Type: mutlipart/mixed; boundary="WRAPPER" >> Content-Description: Efail protection wrapper >> >> --WRAPPER >> Content-Type: text/html >> >> >> >> >> >> --WRAPPER >> (result of PGP/MIME decryption) >> ?WRAPPER? > > Looks alright so far, does the same work for inline PGP? Is there > a particular for the specific inline-styles? At least in Enigmail, inline-PGP is not affected by remote URL calls. The reason is that Enigmail reads the encrypted message data from the displayed message, and then replaces the displayed message content with the decrypted message. In other words, if the secretly to-be-decrypted message part is not displayed, then Enigmail won't come into action. > In macOS Mail we will disable remote content loading completely > and prevent the user from re-enabling it for encrypted messages. The same is currently being developed in Thunderbird (using the "Simple HTML" mode), together with a clean fix for the DOM tree issues. -Patrick From andrewg at andrewg.com Thu May 17 10:24:54 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 17 May 2018 09:24:54 +0100 Subject: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <201805171012.00379.bernhard@intevation.de> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> Message-ID: <2aecfa15-99ca-d2c6-1de6-faccefe951f6@andrewg.com> On 17/05/18 09:11, Bernhard Reiter wrote: > I agree that technically HTML (with it extensions) is a bad format to serve > this need. Similiar to PDF. One RTF was an approach Nextstep's mail took > and that got some adoption, but not enough. Today it would be some very simple > wiki markup language. Content-type: text/markdown ;-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu May 17 10:27:51 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 10:27:51 +0200 Subject: Users GnuPG aims for? In-Reply-To: <201805171012.00379.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 17 May 2018 10:11:56 +0200") References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> Message-ID: <87efiasn3s.fsf_-_@wheatstone.g10code.de> On Thu, 17 May 2018 10:11, bernhard at intevation.de said: > The technical and organisational difficulty is how to control backchannels It is not technical or organizational problem but a question on how to keep the marketing departments at bay. The need to avoid oracles is an old and standard topic in cryptography. We all know about the dangers and if you look at the tools which are not developed from the featurism ridden industry you will see that they commonly are aware of the problems and try to avoid acting as an oracle. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu May 17 10:33:42 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 10:33:42 +0200 Subject: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <2aecfa15-99ca-d2c6-1de6-faccefe951f6@andrewg.com> (Andrew Gallagher's message of "Thu, 17 May 2018 09:24:54 +0100") References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2aecfa15-99ca-d2c6-1de6-faccefe951f6@andrewg.com> Message-ID: <87a7sysmu1.fsf@wheatstone.g10code.de> On Thu, 17 May 2018 10:24, andrewg at andrewg.com said: > Content-type: text/markdown ;-) Content-type: text/org-mode But we need to disable Babel processing. So better stick with Content-type: text/plain and remember that mail is serious work and not for amusement. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Roman.Fiedler at ait.ac.at Thu May 17 10:45:18 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Thu, 17 May 2018 08:45:18 +0000 Subject: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <201805171012.00379.bernhard@intevation.de> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > > Am Mittwoch 16 Mai 2018 15:46:05 schrieb Martin: > > I think a fundamental discussion is necessary with the question: Who > > should / will use GnuPG in the future? > > Note that during one contract in 2016 we came up with some thoughts > in where GnuPG could be heading: > https://wiki.gnupg.org/EasyGpg2016/VisionAndStories > > > Two extremes: Only these people who need really to encrypt their > > emails because they are persecuted. But these people learned how to > > handle their email client correctly and these people will write > > text-only also in the future. > > The problem stays viewing email contents. No, there is much more to it and I have the feeling, that GnuPG development does not really account for that, thus loosing grounds. As an example, gnupg is also key management. As gnupg starts getting more and more problematic regarding some functions (see the discussions on command line/unattended use), Ubuntu Bionic AND Debian Buster dropped it from their debootstrap and replaced the apt-key management parts with own solutions. Hence "apt-key import" will not work any more on debootstrap templates (thus in containerized environments) because gnupg is in process of removal from essential system parts. Even for more limited use-cases, like e-mail decryption: Some use it for client side de/encryption procedures, others use it server side in encryption/decryption gateways. In my opinion gnupg development has a strong motion towards client-only use-cases, thus I started like Ubuntu/Debian to get rid of in all server side applications. I do that as sysadmin-self-defence, but I do not like it from an ethical aspect: good encryption tools should be basics for a free digital society. This is also the reason why I participate in the discussion. LG Roman From bernhard at intevation.de Thu May 17 11:09:41 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 17 May 2018 11:09:41 +0200 Subject: Users GnuPG aims for? In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> Message-ID: <201805171109.46345.bernhard@intevation.de> Am Donnerstag 17 Mai 2018 10:45:18 schrieb Fiedler Roman: > As gnupg starts getting more and more problematic regarding some functions > (see the discussions on command line/unattended use) Can you give me pointers here. Even unattented use needs proper care of passphrases (best is to leave them out) and status codes (which a command line cannot usually handle well, thus gpgme for more complicated cases). In my experience command line and unattended use is fully supported and extended in GnuPG. It is just the rare unix system or very small system space that may get more problematic because of different support libraries and system calls. GnuPG cannot implement all functionality it needs by itself and thus we inherit some size and platform restrictions. I wonder about pubkey management though. There is a faster pubkey store, there are ways to automatically assign fetch pubkeys with basic trust (WKD) and options to give a pubkey for just this encryption operation, those all sound like improvements in the server use cases to me. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Thu May 17 11:20:30 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 17 May 2018 10:20:30 +0100 Subject: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <87a7sysmu1.fsf@wheatstone.g10code.de> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2aecfa15-99ca-d2c6-1de6-faccefe951f6@andrewg.com> <87a7sysmu1.fsf@wheatstone.g10code.de> Message-ID: On 17/05/18 09:33, Werner Koch wrote: > and remember that mail is serious work and not for amusement. I think you're screaming into the wind there... ;-) More seriously though, properly marked-up text is demonstrably easier to read. That's why people submit academic papers in Latex instead of courier monospace with hand-drawn equations. At Patrick's suggestion I have moved to "Simple HTML" in my tbird, but even that requires noticeably more effort to scan and parse compared with "Original HTML" with disabled remote content. Featurism is absolutely a problem. But not all features are featurism. Simple markup (like the original markdown, not its increasingly featureful descendants) does make an important difference. The real trick is knowing where to draw the line. Turing-completeness in a document format is a fundamentally bad idea, but things like CSS that allow for hidden content can be problematic in certain contexts and not others. Like most things in security, "it depends". I completely understand where you're coming from, I'm a vim-loving unix beardie at heart too. But I don't think an insistence on text/plain asceticism is tenable in 2018. HTML mail is unfortunately going to be around for a long time. So mail clients (no more or less than web browsers) have a responsibility to sandbox untrusted content. Plaintext is a workaround, not a solution. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From lukele at gpgtools.org Thu May 17 11:21:06 2018 From: lukele at gpgtools.org (Lukas Pitschl | GPGTools) Date: Thu, 17 May 2018 11:21:06 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87muwyso20.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> Message-ID: <913B3C3B-9885-4781-B740-CAD4F9A3F457@gpgtools.org> > Am 17.05.2018 um 10:07 schrieb Werner Koch : > > On Thu, 17 May 2018 08:59, patrick at enigmail.net said: > >> Within 12 hours after the release I got 5 bug reports/support requests > > Kudos to Enigmail for acting as our guinea pig. I implemented the same > thing in GPGME this morning (see my mail to enigmail users). During the implementation of our MDC fix, we came across two STATUS messages which are not documented in doc/DETAILS which are: - GOODMDC - BADMDC Is there any particular reason why these have not been added to doc/DETAILS? If we check for DECRYPTION_INFO 0 X (0 being NO MDC) and the BADMDC status line (in addition to DECRYPTION_FAILED), can we safely assume that all known cases of no MDC or modified MDC are covered (even for CAST5, which at the moment issues DECRYPTION_OKAY)? Best, Lukas GPGTools -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 268 bytes Desc: Message signed with OpenPGP using GPGMail URL: From skquinn at rushpost.com Thu May 17 10:32:34 2018 From: skquinn at rushpost.com (Shawn K. Quinn) Date: Thu, 17 May 2018 03:32:34 -0500 Subject: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <2aecfa15-99ca-d2c6-1de6-faccefe951f6@andrewg.com> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2aecfa15-99ca-d2c6-1de6-faccefe951f6@andrewg.com> Message-ID: On 05/17/2018 03:24 AM, Andrew Gallagher wrote: > On 17/05/18 09:11, Bernhard Reiter wrote: >> I agree that technically HTML (with it extensions) is a bad format to serve >> this need. Similiar to PDF. One RTF was an approach Nextstep's mail took >> and that got some adoption, but not enough. Today it would be some very simple >> wiki markup language. > > Content-type: text/markdown ;-) Wouldn't Markdown potentially suffer from the same types of problems? Or am I missing something? -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From raf at raf.org Thu May 17 02:41:11 2018 From: raf at raf.org (raf at raf.org) Date: Thu, 17 May 2018 10:41:11 +1000 Subject: Breaking MIME concatenation In-Reply-To: <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> References: <192346920.20180516154605@postzone.org> <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> Message-ID: <20180517004111.4hb6frqcpmeegype@raf.org> Mirimir wrote: > So the best solution would be a tweak to GnuPG that breaks HTML and > embedded remote content. That would protect against Efail, no matter how > email clients were configured. It'd also protect against other exploits > that depend on fetching remote content. And it wouldn't require users to > entirely forgo HTML and embedded remote content. Just with GnuPG. I hope that's not a suggestion that gnupg should examine the data that it's decrypting, identify whether or not it is HTML, identify whether or not the HTML is well-formed and complete, and if not, append additional HTML to "complete" the incomplete HTML. Isn't that the same as tampering with the encrypted message? :-) And wouldn't it need to do this even in the absence of MDC failure? Admittedly, if there was MDC failure, the content has already been tampered with so what harm would a little more tampering do? :-) And by "protect against other exploits", what did you have in mind? Should gnupg try to identify PDF content, OLE objects in Office documents? How much file format knowledge will gnupg need to have stuffed into it to protect everyone from everything? :-) But I can't believe that such functionality belongs in gnupg. Certainly not when I'm decrypting database backups. I think it would make more sense if the email clients and addons that use gnupg to perform email decryption performed that addition themselves because they know to expect HTML content. It would make even more sense for email clients not to combine separate MIME parts naively into a single HTML document (I wonder how many emails that would break). It seems that nobody is expecting the email client/addon authors to make such changes but hopefully they will. Of course if gnupg could be changed in such a way that all email clients were fixed automatically that would be great/efficient. But I think the best thing gnupg can do is to suppress plaintext output on MDC failure (as already mentioned by many) assuming that that's even possible, but even that won't help with this MIME part rendering issue. cheers, raf From andrewg at andrewg.com Thu May 17 12:32:10 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 17 May 2018 11:32:10 +0100 Subject: Breaking MIME concatenation In-Reply-To: <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> References: <192346920.20180516154605@postzone.org> <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> Message-ID: On 17/05/18 00:39, Mirimir wrote: > So the best solution would be a tweak to GnuPG that breaks HTML and > embedded remote content. I know I did suggest this earlier as a thought experiment, but MIME issues are obviously better implemented in the mail client itself, or in extremis in the secure mail plugin(s). And since this has already been implemented in at least one plugin (see Patrick's earlier messages) I think it's best to leave it on that side of the fence. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From philipp.gesang at intra2net.com Thu May 17 10:42:40 2018 From: philipp.gesang at intra2net.com (Philipp Gesang) Date: Thu, 17 May 2018 10:42:40 +0200 Subject: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <2aecfa15-99ca-d2c6-1de6-faccefe951f6@andrewg.com> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2aecfa15-99ca-d2c6-1de6-faccefe951f6@andrewg.com> Message-ID: <20180517084240.GB6689@drift.m.i2n> -<| Quoting Andrew Gallagher , on Thursday, 2018-05-17 09:24:54 AM |>- > On 17/05/18 09:11, Bernhard Reiter wrote: > > I agree that technically HTML (with it extensions) is a bad format to serve > > this need. Similiar to PDF. One RTF was an approach Nextstep's mail took > > and that got some adoption, but not enough. Today it would be some very simple > > wiki markup language. > > Content-type: text/markdown ;-) Which allows embedding raw HTML: https://spec.commonmark.org/0.27/#html-blocks Best, Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wk at gnupg.org Thu May 17 12:39:03 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 12:39:03 +0200 Subject: Users GnuPG aims for? In-Reply-To: (Andrew Gallagher's message of "Thu, 17 May 2018 10:20:30 +0100") References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2aecfa15-99ca-d2c6-1de6-faccefe951f6@andrewg.com> <87a7sysmu1.fsf@wheatstone.g10code.de> Message-ID: <87d0xupnw8.fsf_-_@wheatstone.g10code.de> On Thu, 17 May 2018 11:20, andrewg at andrewg.com said: > More seriously though, properly marked-up text is demonstrably easier to > read. That's why people submit academic papers in Latex instead of Right. But there is nothing which inhibits a MUA to render a mail in a more appropriate way. But the trend is to enforce a certain rendering on users and by that making mail harder to read for, say, blind people. It is not only text/html but also the bad habit of writing overlong lines instead of proper paragraphs. Reflowing can be better done by client as long as the sender uses common formatting rules (which can be enforced automatically). The reader modes of browser actually present a better readable version of a web page but I assume they are not easy to get right. > around for a long time. So mail clients (no more or less than web > browsers) have a responsibility to sandbox untrusted content. Plaintext But the sandboxing does not work because the marketing folks want their logs and stats on when and how often their mails are being read. I often get mails which just say click here to read it in an easier way :-(. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From patrick at enigmail.net Thu May 17 12:50:12 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 17 May 2018 12:50:12 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87muwyso20.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> Message-ID: <74cfd966-b071-4683-10c5-9b0c55da60d2@enigmail.net> On 17.05.18 10:07, Werner Koch wrote: > On Thu, 17 May 2018 08:59, patrick at enigmail.net said: > >> Within 12 hours after the release I got 5 bug reports/support requests > > Kudos to Enigmail for acting as our guinea pig. I implemented the same > thing in GPGME this morning (see my mail to enigmail users). > > What shall we do now? Provide a separate tool to decrypt and clean HTML > messages or add a tool to Enigmail to do just this? Good question... Thunderbird is working on fixing the HTML display issue. But I think we should really start enforcing users to enable MDC. I therefore would prefer keeping the barrier high. In any case, this is nothing that I could implement with a week or two. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu May 17 12:49:12 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 12:49:12 +0200 Subject: Users GnuPG aims for? In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> (Fiedler Roman's message of "Thu, 17 May 2018 08:45:18 +0000") References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> Message-ID: <878t8ipnfb.fsf_-_@wheatstone.g10code.de> On Thu, 17 May 2018 10:45, Roman.Fiedler at ait.ac.at said: > encryption/decryption gateways. In my opinion gnupg development has a > strong motion towards client-only use-cases, thus I started like Huh? Didn't you noticed all the new features we implemented to make the scripting of key managment easy or the remote use gpg on servers with private keys kept on the desktop or another secure box? Salam-Shalom, Werner p.s: Regarding my other point in this thread: Your mail is an example for a hard to read one due to overlong lines and wrong localization of the the "Re:" prefix in the the subject. I know that it is not your fault but due to rong defaults of some MUAs. -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Roman.Fiedler at ait.ac.at Thu May 17 13:11:14 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Thu, 17 May 2018 11:11:14 +0000 Subject: AW: AW: AW: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87lgcjtuts.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> <1844654093.20180514231332@my_localhost_LG> <2ECE9D9EEF1F524185270138AE23265955B7B056@S0MSMAIL112.arc.local> <87k1s3x0m9.fsf@wheatstone.g10code.de> <2ECE9D9EEF1F524185270138AE23265955B7B5B9@S0MSMAIL112.arc.local> <4A78D78D-540E-47E2-9335-6535023AC460@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7B651@S0MSMAIL112.arc.local> <87lgcjtuts.fsf@wheatstone.g10code.de> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7B9C7@S0MSMAIL112.arc.local> > Von: Werner Koch [mailto:wk at gnupg.org] > > On Wed, 16 May 2018 16:24, Roman.Fiedler at ait.ac.at said: > > > In my opinion it is hard to find such a "one size fits all" > > solution. Like Werner's example: disabling decryption streaming > > The goal of the MDC is to assure that the message has been received > exactly as the sender set it. Thus there is just a binary decision: > Okay or Fail. Everything is like you have been dropped at boot time > into manual fsck mode - you can do something about it or you just > irginore things and restore the partition. How could that work together with the memory based "wipe" approach, you envisioned in your message https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html , last paragraph? If I understand your approach correctly, it will imply that at least one do-not-apply-one-size-fits-all switch has to be present, thus contradicting one of your statements. Or did I get something wrong in my argument? The decision output (fail/ok) in the end might be binary for both use-cases but the internal logic (process model) for validation/output will be different. > > streaming of backups (decryption&output before final validation). So > > you need something on the interface to support that non-standard > > behavior, deviate from the default. > > It is already there. If you use "--output FILE" the file is either > created or not. Your choice. Would that imply, that using e.g. "--output /proc/self/3" would implicitly change the security behavior of gpg, e.g. by switching from "output before validation" model to "validation before output" model (again compare your message, cited above)? Implicit feedback from selected output mode on security related MDC-check behavior would seem dangerous to me. Somehow rings an alarm bell, if that should be the proposed solution. LG Roman From wk at gnupg.org Thu May 17 13:03:02 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 13:03:02 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <913B3C3B-9885-4781-B740-CAD4F9A3F457@gpgtools.org> (Lukas Pitschl's message of "Thu, 17 May 2018 11:21:06 +0200") References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> <913B3C3B-9885-4781-B740-CAD4F9A3F457@gpgtools.org> Message-ID: <8736yqpms9.fsf@wheatstone.g10code.de> On Thu, 17 May 2018 11:21, lukele at gpgtools.org said: > Is there any particular reason why these have not been added to > doc/DETAILS? They don't make much sense. I can't remember why I added them. > If we check for DECRYPTION_INFO 0 X (0 being NO MDC) and the > BADMDC status line (in addition to DECRYPTION_FAILED), can we > safely assume that all known cases of no MDC or modified MDC are > covered (even for CAST5, which at the moment issues DECRYPTION_OKAY)? Yes, but read on: Ignore the BADMDC; it is not needed. You will get a DECRYPTION_FAILED if the MDC is broken. However, it does not catch the case for a MISSING MDC (that is the use of a non-MDC enryption packet). The MDC can be stripped and also the plaintext will then be partly garbled we need to detect this. gpg detect this for all modern cipher algorithsm (ie. AES and Camellia) and gibes a DECRYPTION_FAILED. For backward compatibility reasons I fear to extend this in 2.2 to the old algorithms. If you parse DECRYTPION_INFO beplease consider that its current defineion (in master) is: *** DECRYPTION_INFO [] Print information about the symmetric encryption algorithm and the MDC method. This will be emitted even if the decryption fails. For an AEAD algorithm AEAD_ALGO is not 0. GPGSM currently does not print such a status. The important print is that MDC_METHOD will be 0 with the forthcoming AEAD algorithm. Thus you need to check whether 3rd argument is there. mdc_method = atoi(arg_1) aead_algo = have_3_args? atoi(arg_3) : 0 if (!mdc_method && !aeadalgo) return DECRYPTION_FAILED That is what I implement in GPGME this morning. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Roman.Fiedler at ait.ac.at Thu May 17 13:13:58 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Thu, 17 May 2018 11:13:58 +0000 Subject: AW: Users GnuPG aims for? In-Reply-To: <201805171109.46345.bernhard@intevation.de> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> <201805171109.46345.bernhard@intevation.de> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7B9D9@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > > Am Donnerstag 17 Mai 2018 10:45:18 schrieb Fiedler Roman: > > As gnupg starts getting more and more problematic regarding some > functions > > (see the discussions on command line/unattended use) > > Can you give me pointers here. > Even unattented use needs proper care of passphrases > (best is to leave them out) and status codes (which a command line cannot > usually handle well, thus gpgme for more complicated cases). There were quite many messages, that caused alarm bells ringing for me. Hard to dig them out all now. But maybe I am just over-sensitive to words between the lines or wrong in some other ways. Here are some examples: Pinentry: I for myself struggled with it also for a day, but also many other users have problems. Realizing, that gpg aims might be going into a different direction may motivate you to leave now before having to struggle again and maybe more at the next OS update, when you need to apply more workarounds. https://lists.gnupg.org/pipermail/gnupg-users/2018-March/060097.html (initramfs use) https://lists.gnupg.org/pipermail/gnupg-users/2015-March/053175.html (systemd "So it feels quite strange that i need to do all this juggling to get it working") Other examples: https://lists.gnupg.org/pipermail/gnupg-users/2016-February/055294.html (do not use gpg for encryption with different policies) https://lists.gnupg.org/pipermail/gnupg-devel/2016-September/031557.html (gpg-agent idle timeout workarounds) http://seclists.org/oss-sec/2017/q4/373 (a former gpg developer is explaining decisions, why he is implementing a new variant and his arguments (short lived processes) make completely sense for those usecases I envision, compare to the previous mail thread). > In my experience command line and unattended use is fully supported > and extended in GnuPG. It is just the rare unix system or very small system > space that may get more problematic because of different support libraries > and > system calls. GnuPG cannot implement all functionality it needs by itself > and thus we inherit some size and platform restrictions. That is understandable. But I cannot see the concept already, how this bloating can be avoided in future. And in the end gpg has to come up with some concept, e.g. regarding support of older mail message decryption modes plus all the libraries required to do that. Hence my critical remarks. > I wonder about pubkey management though. There is a faster pubkey store, > there are ways to automatically assign fetch pubkeys with basic trust (WKD) > and options to give a pubkey for just this encryption operation, those all > sound like improvements in the server use cases to me. Yes, but all those features do not apply to apt-key or are of little relevance. Hence gpg seems to have been included just for minimal use (just adding/removing keys, everything is trusted as performed by root user anyway). I do not know the reasons behind them dropping gpg, but I guess the just needed a failesafe, minimalistic tool for that purpose and now they dropped gpg and run only with gpgv to my knowledge. LG Roman From andrewg at andrewg.com Thu May 17 13:15:35 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 17 May 2018 12:15:35 +0100 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <74cfd966-b071-4683-10c5-9b0c55da60d2@enigmail.net> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> <74cfd966-b071-4683-10c5-9b0c55da60d2@enigmail.net> Message-ID: <5044C234-98E1-4693-8FC2-DB9A666F9D66@andrewg.com> > On 17 May 2018, at 11:50, Patrick Brunschwig wrote: > >> On 17.05.18 10:07, Werner Koch wrote: >> On Thu, 17 May 2018 08:59, patrick at enigmail.net said: >> >>> Within 12 hours after the release I got 5 bug reports/support requests >> >> Kudos to Enigmail for acting as our guinea pig. I implemented the same >> thing in GPGME this morning (see my mail to enigmail users). >> >> What shall we do now? Provide a separate tool to decrypt and clean HTML >> messages or add a tool to Enigmail to do just this? > > Good question... Thunderbird is working on fixing the HTML display > issue. But I think we should really start enforcing users to enable MDC. > I therefore would prefer keeping the barrier high. In any case, this is > nothing that I could implement with a week or two. I agree, while it would be easy for the users to have a magic button in enigmail, this isn?t something we should be encouraging users to use on a regular basis. IMO a better solution would be a standalone tool that you could point at a local Maildir and tell it to clean and re-encrypt anything it finds that is bad (for a given value of ?bad?), and save it to a new Maildir, perhaps with an attachment explaining what was done. This would of course invalidate any signatures on the re-encrypted data, but that?s OK for the use case. It should not be an in-place update, nor should it work over e.g. IMAP because that would a) encourage people to run it in a cronjob and b) destroy the originals, which may be a deal breaker for archival purposes. A From Roman.Fiedler at ait.ac.at Thu May 17 13:30:17 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Thu, 17 May 2018 11:30:17 +0000 Subject: AW: Users GnuPG aims for? In-Reply-To: <878t8ipnfb.fsf_-_@wheatstone.g10code.de> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> <878t8ipnfb.fsf_-_@wheatstone.g10code.de> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7BA03@S0MSMAIL112.arc.local> Just a foreword: sorry for not acknowledging all the good proposals you make - many of them I can fully second - and all the good changes you apply, I really appreciate them. I just do not reply to all of them ... > Von: Werner Koch [mailto:wk at gnupg.org] > > On Thu, 17 May 2018 10:45, Roman.Fiedler at ait.ac.at said: > > > encryption/decryption gateways. In my opinion gnupg development has a > > strong motion towards client-only use-cases, thus I started like > > Huh? Didn't you noticed all the new features we implemented to make the > scripting of key managment easy or Those are really good, I am using them already. > the remote use gpg on servers with > private keys kept on the desktop or another secure box? Here I decided to implement my own solution as there is (was?) no option I would trust enough to reliably prohibit storage of any passphrases or unlocked keys in gpg agent when the key was used once. So agent is fine, but not for storing any unlocked key material. > ... > p.s: > Regarding my other point in this thread: Your mail is an example > for a hard to read one due to overlong lines and wrong localization of > the the "Re:" prefix in the the subject. I know that it is not your > fault but due to rong defaults of some MUAs. So right, I hate the company standard for that. Changing the prefix would trigger a bug/unexpected implicit behaviour of outlook, thus breaking thread view of common mailing list software. So I can only choose my poison. BTW: In my opinion, you are complete right on locating the fault on MUAs side for that. I fear, that one reason more for them being that bad in the office environment could be: who would want to have complex (and vulnerable, data leaking) desktop search engines indexing your mails, who would buy larger storages if mails were only 1-10% of size and could be quickly filtered by pure plaintext search, who would buy stronger processors, larger RAM required therefore? LG Roman From Roman.Fiedler at ait.ac.at Thu May 17 13:40:41 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Thu, 17 May 2018 11:40:41 +0000 Subject: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <5044C234-98E1-4693-8FC2-DB9A666F9D66@andrewg.com> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> <74cfd966-b071-4683-10c5-9b0c55da60d2@enigmail.net> <5044C234-98E1-4693-8FC2-DB9A666F9D66@andrewg.com> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7BA2E@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > > On 17 May 2018, at 11:50, Patrick Brunschwig > wrote: > > > >> On 17.05.18 10:07, Werner Koch wrote: > >> On Thu, 17 May 2018 08:59, patrick at enigmail.net said: > >> > >>> Within 12 hours after the release I got 5 bug reports/support requests > >> > >> Kudos to Enigmail for acting as our guinea pig. I implemented the same > >> thing in GPGME this morning (see my mail to enigmail users). > >> > >> What shall we do now? Provide a separate tool to decrypt and clean HTML > >> messages or add a tool to Enigmail to do just this? > > > > Good question... Thunderbird is working on fixing the HTML display > > issue. But I think we should really start enforcing users to enable MDC. > > I therefore would prefer keeping the barrier high. In any case, this is > > nothing that I could implement with a week or two. > > I agree, while it would be easy for the users to have a magic button in > enigmail, this isn?t something we should be encouraging users to use on a > regular basis. > > IMO a better solution would be a standalone tool that you could point at a > local Maildir and tell it to clean and re-encrypt anything it finds that is bad (for > a given value of ?bad?), and save it to a new Maildir, perhaps with an > attachment explaining what was done. This would of course invalidate any > signatures on the re-encrypted data, but that?s OK for the use case. It should > not be an in-place update, nor should it work over e.g. IMAP because that > would a) encourage people to run it in a cronjob and b) destroy the originals, > which may be a deal breaker for archival purposes. Sounds nice. Maybe if you combine it with the suggestions from https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060362.html (and perhaps improve my proposal, as a first guess usually cannot be the best), you could kill two birds with one stone. Hence you also could have a shorter path to get rid of old ciphers, MDCs and other backward compatibility stuff, thus increasing security and speeding up development. LG Roman From lukele at gpgtools.org Thu May 17 13:55:13 2018 From: lukele at gpgtools.org (Lukas Pitschl | GPGTools) Date: Thu, 17 May 2018 13:55:13 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <8736yqpms9.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> <913B3C3B-9885-4781-B740-CAD4F9A3F457@gpgtools.org> <8736yqpms9.fsf@wheatstone.g10code.de> Message-ID: > Am 17.05.2018 um 13:03 schrieb Werner Koch : > > The important print is that MDC_METHOD will be 0 with the forthcoming > AEAD algorithm. Thus you need to check whether 3rd argument is there. > > mdc_method = atoi(arg_1) > aead_algo = have_3_args? atoi(arg_3) : 0 > if (!mdc_method && !aeadalgo) > return DECRYPTION_FAILED > > That is what I implement in GPGME this morning. Thank you very much for these additional details. We have adjusted our implementation to consider the addition of the AEAD algorithm to the DECRYPTION_INFO status message. Best, Lukas GPGTools -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 268 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dkg at fifthhorseman.net Thu May 17 16:49:55 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 May 2018 10:49:55 -0400 Subject: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> Message-ID: <87zi0yl4ks.fsf@fifthhorseman.net> On Thu 2018-05-17 08:45:18 +0000, Fiedler Roman wrote: > As gnupg starts getting more and more problematic regarding some > functions (see the discussions on command line/unattended use), Ubuntu > Bionic AND Debian Buster dropped it from their debootstrap I don't know about Ubuntu Bionic, but for Debian Buster this is simply false. Buster relies on gpgv (which is part of the GnuPG suite) for validating archive signatures. > and replaced the apt-key management parts with own solutions. apt-key has been deprecated for a while now. I don't think i've seen a secure use of apt-key that i can really encourage anywhere. If you want to do sane cryptographic controls on repositories, you should (a) place the key for a given repo somewhere sensible in the filesystem (e.g. /usr/share/keyrings/REPONAME-keyring.gpg), and (b) add a Signed-By: line to your .sources file (or a signed-by option to the line in your .list file). See sources.list(5) and https://wiki.debian.org/DebianRepository/UseThirdParty for more details. See also https://bugs.debian.org/877012 for suggestions about improvements to scoped cryptographic authorities for the default installation of debian repositories. > Hence "apt-key import" will not work any more on debootstrap templates > (thus in containerized environments) because gnupg is in process of > removal from essential system parts. Again, this is simply not true. e-mail itself (let alone encrypted mail) is not an essential system part, but cryptographic software update verification *is* an essential system part, and debian continues to depend on gpgv for that purpose. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Roman.Fiedler at ait.ac.at Thu May 17 17:37:55 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Thu, 17 May 2018 15:37:55 +0000 Subject: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <87zi0yl4ks.fsf@fifthhorseman.net> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> <87zi0yl4ks.fsf@fifthhorseman.net> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7BB6F@S0MSMAIL112.arc.local> > Von: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] > > On Thu 2018-05-17 08:45:18 +0000, Fiedler Roman wrote: > > As gnupg starts getting more and more problematic regarding some > > functions (see the discussions on command line/unattended use), Ubuntu > > Bionic AND Debian Buster dropped it from their debootstrap > > I don't know about Ubuntu Bionic, but for Debian Buster this is simply > false. > > Buster relies on gpgv (which is part of the GnuPG suite) for validating > archive signatures. That seems just a misunderstanding, as my initial message mentioning the changes was imprecise from my side, the follow-up https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060422.html should have made it clear, that we are both talking about the same thing. """Yes, but all those features do not apply to apt-key or are of little relevance. Hence gpg seems to have been included just for minimal use (just adding/removing keys, everything is trusted as performed by root user anyway). I do not know the reasons behind them dropping gpg, but I guess the just needed a failesafe, minimalistic tool for that purpose and now they dropped gpg and run only with gpgv to my knowledge.""" > > and replaced the apt-key management parts with own solutions. > > apt-key has been deprecated for a while now. I don't think i've seen a > secure use of apt-key that i can really encourage anywhere. > > If you want to do sane cryptographic controls on repositories, you > should (a) place the key for a given repo somewhere sensible in the > filesystem (e.g. /usr/share/keyrings/REPONAME-keyring.gpg), and (b) add > a Signed-By: line to your .sources file (or a signed-by option to the > line in your .list file). > > See sources.list(5) and > https://wiki.debian.org/DebianRepository/UseThirdParty for more details. > > See also https://bugs.debian.org/877012 for suggestions about > improvements to scoped cryptographic authorities for the default > installation of debian repositories. Thanks for the information. I thought, that the new model would be using "/etc/apt/trusted.gpg.d", as recommended by an online version of "apt-key". But of course the per-repository pinning of keys could make key management easier as there is a n:1 link between repositories and keys, thus it is easier to avoid stale keys in the common key storage file. > ... From ben at adversary.org Thu May 17 17:35:02 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 18 May 2018 01:35:02 +1000 Subject: [GPGME] Repeated decrypt fails In-Reply-To: References: Message-ID: <20180517153502.cr3qwf2rfbz6rful@adversary.org> On Wed, May 16, 2018 at 10:54:52AM -0400, Randy Trinh wrote: > Hi everyone, > > I'm fairly new to GnuPG and GPGME in general and I'm currently Firstly, kudos for going straight to GPGME instead of wrapping the GPG binary. ? > trying to implement a process in which a file is uploaded from a > website in which case my program uses GPGME to decrypt the file > returning true or false. Does the website encrypt the file uploaded by (eventually) some end user or do they encrypt the file first and then upload that which your code subsequently decrypts? > The first time I upload the file (a .tar.gz) and run > "gpgme_op_decrypt_start" and then "gpgme_wait", the file is > decrypted successfully in which case I can extract the contents, but > if I upload the SAME original file again or any amount of times > after the first instance, GPGME fails** to decrypt it. Hmm, that's interestingly odd. > Is there anything I may be doing wrong? Maybe ? > **Fails: GPGME returns an error of success and a "decrypted" .tar.gz > file that is empty -- The uploaded file in both instances can still > be decrypted by calling GnuPG from command line but the only way to > get GPGME to successfully decrypt after the first decryption is to > restart my program. Yeah, this is strange, but we'll need more info to work out what's going on. Are you able to share the code for what's happening here and, if the website also encrypts the uploaded data, that bit too? > (Is it also normal for GPGME to return an error of success for this > instance as it has clearly failed/produced a corrupted file? > Similarly it also returns an error result of success even when I > upload a non-encrypted .tar.gz whereas GnuPG outputs that no OpenPGP > data is found and the decrypt message has failed: eof) No, that's not normal and I'm wondering how it happened, but there are some functions which might do it and it may also depend on which version(s) of GPG and GPGME you're using. Which are they, by the way? If it's not using the current release of GPGME; the first bit of advice will be to try the current version checked out from the git repo and see if it continues to do the same thing. GPGME has received a certain amount of love and attention over the last couple of years more than it may have in the past and though there have been one or two hiccups, it's still vastly improved for that (ongoing) effort. Which at least means that it's a good time to start with it because enough people are looking at its innards that answers shouldn't be too far off. ? Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From trinh.randy at gmail.com Thu May 17 20:48:01 2018 From: trinh.randy at gmail.com (Randy Trinh) Date: Thu, 17 May 2018 14:48:01 -0400 Subject: [GPGME] Repeated decrypt fails In-Reply-To: <20180517153502.cr3qwf2rfbz6rful@adversary.org> References: <20180517153502.cr3qwf2rfbz6rful@adversary.org> Message-ID: On Thu, May 17, 2018 at 11:35 AM, Ben McGinnes wrote: > > > Does the website encrypt the file uploaded by (eventually) some end > > user or do they encrypt the file first and then upload that which your > > code subsequently decrypts? The file is encrypted first by the user and then uploaded to which my code subsequently decrypts it. > > Yeah, this is strange, but we'll need more info to work out what's > > going on. Are you able to share the code for what's happening here > > and, if the website also encrypts the uploaded data, that bit too? > Certainly! I've provided the entire GPGME portion of the function below, I'm not entirely certain if this is acceptable to call every time my program decides to attempt a decrypt though (Feel free to highlight my errors): gpgme_check_version(NULL); setlocale (LC_ALL, ""); gpgme_error_t err, stat; gpgme_ctx_t ctx; gpgme_decrypt_result_t decResult; gpgme_data_t fileEncrypted, fileDecrypted, keydata; int systemVal; std::string tempFile = "TemporaryFile"; std::string newFileName = "Decrypted"; std::string newFileNameExt = newFileName + ".tar.gz"; const char* name = newFileNameExt.c_str(); err = gpgme_new(&ctx); err = gpgme_engine_check_version (GPGME_PROTOCOL_OpenPGP); if (boost::filesystem::exists(tempFile)) { boost::filesystem::remove_all(tempFile); } boost::filesystem::create_directory(tempFile); int fdEncrypt = open(fileName, O_RDONLY); int fdDecrypt = open(name, O_CREAT | O_WRONLY, S_IRUSR | S_IWUSR); err = gpgme_data_new_from_fd(&fileEncrypted, fdEncrypt); err = gpgme_data_new_from_fd(&fileDecrypted, fdDecrypt); err = gpgme_op_decrypt_start(ctx, fileEncrypted, fileDecrypted); ctx = gpgme_wait(ctx, &stat, 1); std::cout << "Decrypt Status: " << gpgme_strerror(err) << std::endl; gpgme_decrypt_result_t dResult = gpgme_op_decrypt_result(ctx); if (dResult->unsupported_algorithm) { std::cout << "invalid decrypt" << std::endl; } close(fdEncrypt); close(fdDecrypt); gpgme_release(ctx); > > No, that's not normal and I'm wondering how it happened, but there are > > some functions which might do it and it may also depend on which > > version(s) of GPG and GPGME you're using. Which are they, by the way? > The version of GPG I am using is 2.0.22 (or 1.4.16) I have both installed but I'm actually not entirely confident which one is being used by GPGME. As for GPGME, I am using Ver 1.11.1. Thanks for the reply! ? Cheers, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu May 17 21:01:23 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 21:01:23 +0200 Subject: AW: AW: AW: AW: Efail or OpenPGP is safer than S/MIME In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7B9C7@S0MSMAIL112.arc.local> (Fiedler Roman's message of "Thu, 17 May 2018 11:11:14 +0000") References: <87mux28yts.fsf@wheatstone.g10code.de> <0e20a6e4-28d7-36f5-0436-e59c0d4f11ba@andrewg.com> <86415e38-af36-91ac-f175-40db831cd9af@andrewg.com> <134609be-dac9-0d4d-4665-32dc5155bf4a@sixdemonbag.org> <3c0891f1-e1cd-0d88-0789-db685cd783c4@andrewg.com> <71d56a23-889e-6b63-fd5b-f8b8b29cdddb@andrewg.com> <06596f81-f52b-9b02-d1b3-4f1c6ecbfbb0@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7A916@S0MSMAIL112.arc.local> <1844654093.20180514231332@my_localhost_LG> <2ECE9D9EEF1F524185270138AE23265955B7B056@S0MSMAIL112.arc.local> <87k1s3x0m9.fsf@wheatstone.g10code.de> <2ECE9D9EEF1F524185270138AE23265955B7B5B9@S0MSMAIL112.arc.local> <4A78D78D-540E-47E2-9335-6535023AC460@andrewg.com> <2ECE9D9EEF1F524185270138AE23265955B7B651@S0MSMAIL112.arc.local> <87lgcjtuts.fsf@wheatstone.g10code.de> <2ECE9D9EEF1F524185270138AE23265955B7B9C7@S0MSMAIL112.arc.local> Message-ID: <87muwym7i4.fsf@wheatstone.g10code.de> On Thu, 17 May 2018 13:11, Roman.Fiedler at ait.ac.at said: > How could that work together with the memory based "wipe" approach, you envisioned in your message https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html , last paragraph? Tha is a different layer. Basically a part of a MUA. That feature would be a safenet in case the actual MUA part does not check return codes from GPGME. GPGME has several types of data objects - Memory based - File based - File descriptor based - Callback based For the first two we can clear the memory or delete the file in case of an error and before we return to the caller. It is actually a bit complicate to implement because gpgme allows for synchornous and asynchronous operation and for the latter we have not yet a way to associate the data object with context. > Would that imply, that using e.g. "--output /proc/self/3" would > implicitly change the security behavior of gpg, e.g. by switching from > "output before validation" model to "validation before output" model No, gpg has no idea about this. It only aware whether it is working on a named file or on a file descriptor (which also includes a pipe) Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu May 17 21:48:33 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 May 2018 15:48:33 -0400 Subject: Breaking MIME concatenation In-Reply-To: <87r2masobi.fsf@wheatstone.g10code.de> References: <192346920.20180516154605@postzone.org> <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> <87r2masobi.fsf@wheatstone.g10code.de> Message-ID: <87tvr6kqr2.fsf@fifthhorseman.net> On Thu 2018-05-17 10:01:37 +0200, Werner Koch wrote: > On Thu, 17 May 2018 01:48, rjh at sixdemonbag.org said: > >> While y'all are having this discussion, remember that GnuPG's 95% use >> case is verifying Linux packages, and that number isn't expected to >> change a whole lot. > > I am pretty sure that there are more Windows GPG users than users who > run Linux on their desktop. given that the OS package verification use case is relevant for millions of server installations, i'm not convinced that Linux on the Desktop is really what rjh was referring to. --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 Thu May 17 21:58:17 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 May 2018 15:58:17 -0400 Subject: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7BB6F@S0MSMAIL112.arc.local> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> <87zi0yl4ks.fsf@fifthhorseman.net> <2ECE9D9EEF1F524185270138AE23265955B7BB6F@S0MSMAIL112.arc.local> Message-ID: <87r2makqau.fsf@fifthhorseman.net> On Thu 2018-05-17 15:37:55 +0000, Fiedler Roman wrote: > Von: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] > >> See sources.list(5) and >> https://wiki.debian.org/DebianRepository/UseThirdParty for more details. >> >> See also https://bugs.debian.org/877012 for suggestions about >> improvements to scoped cryptographic authorities for the default >> installation of debian repositories. > > Thanks for the information. I thought, that the new model would be > using "/etc/apt/trusted.gpg.d", as recommended by an online version of > "apt-key". I recommend not relying directly on apt-key, whether online or offline :) > But of course the per-repository pinning of keys could make key > management easier as there is a n:1 link between repositories and > keys, thus it is easier to avoid stale keys in the common key storage > file. yes. furthermore, per-repository pinning of keys avoids the possibility of one repository owner signing a Release file for a different repository. This paves the way for a local administrator to put meaningful constraints on a given external repository (e.g. pinning which packages can be shipped from that repo, or restricting maintainer scripts from running). I welcome any and all help in continuing to drive the ecosystem down this path. 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 rjh at sixdemonbag.org Thu May 17 22:42:52 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 17 May 2018 16:42:52 -0400 Subject: Breaking MIME concatenation In-Reply-To: <87tvr6kqr2.fsf@fifthhorseman.net> References: <192346920.20180516154605@postzone.org> <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> <87r2masobi.fsf@wheatstone.g10code.de> <87tvr6kqr2.fsf@fifthhorseman.net> Message-ID: > given that the OS package verification use case is relevant for > millions > of server installations, i'm not convinced that Linux on the Desktop is > really what rjh was referring to. > > --dkg dkg got it in one. Especially with the advent of cloud computing and one-click deployments of whole OSes, the package verification space is bigger than ever before. I don't have concrete numbers here, but my suspicion is that GnuPG is a package verification system that's useful for email... and most of the problems people have with it as a package verification system stem from the fact it was originally an email privacy system. This isn't a mark against it. Any good software package will soon get used for things far beyond the authors' original intent. From mirimir at riseup.net Fri May 18 02:09:41 2018 From: mirimir at riseup.net (Mirimir) Date: Thu, 17 May 2018 13:09:41 -1100 Subject: Breaking MIME concatenation In-Reply-To: <87vabmsofd.fsf@wheatstone.g10code.de> References: <192346920.20180516154605@postzone.org> <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> <87vabmsofd.fsf@wheatstone.g10code.de> Message-ID: On 05/16/2018 08:59 PM, Werner Koch wrote: > On Thu, 17 May 2018 01:39, mirimir at riseup.net said: > >> However, I get that many users expect HTML, embedded images and links. > > Well they expect a bit of markup like *bold* or _underlined_ or > /italics/ and links like https://gnupg.org but any decent MUA already > supports this for plain text mails. Proper GUI based MUAs also support > inline images (which are part of MIME); I used such MUAs already in in > the mid 90ies. > > I doubt that mail is the right thing to employ fancy CSS stuff, though. I usually just look at text. But this has moved me to look at source for some commercial messages. They're basically sending websites. Insane. >> So the best solution would be a tweak to GnuPG that breaks HTML and >> embedded remote content. That would protect against Efail, no matter how > > gpg will nver touch the payload. If MUAs want to sanitize HTML, I won't > have a problem with that. Upon reflection, I get that. So yes, in MUAs. But however implemented, the lesson here is that HTML and executable code in messages aren't compatible with gpg security. > Shalom-Salam, > > Werner > From Roman.Fiedler at ait.ac.at Fri May 18 07:31:36 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Fri, 18 May 2018 05:31:36 +0000 Subject: AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <87r2makqau.fsf@fifthhorseman.net> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> <87zi0yl4ks.fsf@fifthhorseman.net> <2ECE9D9EEF1F524185270138AE23265955B7BB6F@S0MSMAIL112.arc.local> <87r2makqau.fsf@fifthhorseman.net> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7BCFF@S0MSMAIL112.arc.local> > Von: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] > > On Thu 2018-05-17 15:37:55 +0000, Fiedler Roman wrote: > > Von: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] > > > >> See sources.list(5) and > >> https://wiki.debian.org/DebianRepository/UseThirdParty for more details. > >> > >> See also https://bugs.debian.org/877012 for suggestions about > >> improvements to scoped cryptographic authorities for the default > >> installation of debian repositories. > > > > Thanks for the information. I thought, that the new model would be > > using "/etc/apt/trusted.gpg.d", as recommended by an online version of > > "apt-key". > > I recommend not relying directly on apt-key, whether online or offline :) I see. If understood correctly, the trusted.gpg.d bypasses key management with apt-key completely, so not running into problems with apt-key deprecation. > > But of course the per-repository pinning of keys could make key > > management easier as there is a n:1 link between repositories and > > keys, thus it is easier to avoid stale keys in the common key storage > > file. > > yes. furthermore, per-repository pinning of keys avoids the possibility > of one repository owner signing a Release file for a different > repository... I thought about that also, but shouldn't 99%+ of systems perform no pinning whatsoever of packages to repositories? In that case, the "wrong" repository could publish just a slightly increased package version number of a package from another repository. Unattended updates will apply it anyway and also for users it would be hard noticing it: at least my "apt-get" version does not show any information about the repository a package would be downloaded from before confirming the installation. Thus the user would have to check each single package manually by invoking "apt-cache policy [pkg-name]" or use "apt-get download [packagelist]", check the logs and install packages with "dpkg". Unless my system is misconfigured or other assumptions do not hold true, that would imply, that the only security benefit from key pinning is only about maintenance, making detection/pruning of stale keys easier. > ... LG Roman From wk at gnupg.org Fri May 18 11:58:16 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 May 2018 11:58:16 +0200 Subject: [GPGME] Repeated decrypt fails In-Reply-To: (Randy Trinh's message of "Thu, 17 May 2018 14:48:01 -0400") References: <20180517153502.cr3qwf2rfbz6rful@adversary.org> Message-ID: <8736ypl1zb.fsf@wheatstone.g10code.de> On Thu, 17 May 2018 20:48, trinh.randy at gmail.com said: > err = gpgme_op_decrypt_start(ctx, fileEncrypted, fileDecrypted); > ctx = gpgme_wait(ctx, &stat, 1); > > std::cout << "Decrypt Status: " << gpgme_strerror(err) << std::endl; Here you show the result of the start operation which is usuallay success. What you need to check here instead is STAT as returned by gpgme_wait. Is there a reason why you use the asynchronous operaions and not the synchronous? Your code would not work with multiple threads because gpgme_wait may only be called by one thread. > The version of GPG I am using is 2.0.22 (or 1.4.16) I have both installed gpgme has a function to figure this out: /* Get the information about the configured engines. A pointer to the * first engine in the statically allocated linked list is returned. * The returned data is valid until the next gpgme_ctx_set_engine_info. */ gpgme_engine_info_t gpgme_ctx_get_engine_info (gpgme_ctx_t ctx); or you run your program with GPGME_DEBUG=1:gpgme.log: ./test which prints the full name of the used tools. Call them then with option --version. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From patrick at enigmail.net Fri May 18 12:18:29 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Fri, 18 May 2018 12:18:29 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <8736yqpms9.fsf__2264.44759541682$1526555521$gmane$org@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> <913B3C3B-9885-4781-B740-CAD4F9A3F457@gpgtools.org> <8736yqpms9.fsf__2264.44759541682$1526555521$gmane$org@wheatstone.g10code.de> Message-ID: <051c33c9-4eed-cc72-728e-cf280d8f1482@enigmail.net> On 17.05.18 13:03, Werner Koch wrote: > If you parse DECRYTPION_INFO beplease consider that its current > defineion (in master) is: > > *** DECRYPTION_INFO [] > Print information about the symmetric encryption algorithm and the > MDC method. This will be emitted even if the decryption fails. > For an AEAD algorithm AEAD_ALGO is not 0. GPGSM currently does > not print such a status. > > The important print is that MDC_METHOD will be 0 with the forthcoming > AEAD algorithm. Thus you need to check whether 3rd argument is there. > > mdc_method = atoi(arg_1) > aead_algo = have_3_args? atoi(arg_3) : 0 > if (!mdc_method && !aeadalgo) > return DECRYPTION_FAILED > > That is what I implement in GPGME this morning. How far back will that solution work? I.e. is this supported by all 2.0.x and 2.2.x versions of gpg? Thanks, Patrick From ndk.clanbo at gmail.com Fri May 18 12:48:42 2018 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 18 May 2018 12:48:42 +0200 Subject: AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7BCFF@S0MSMAIL112.arc.local> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> <87zi0yl4ks.fsf@fifthhorseman.net> <2ECE9D9EEF1F524185270138AE23265955B7BB6F@S0MSMAIL112.arc.local> <87r2makqau.fsf@fifthhorseman.net> <2ECE9D9EEF1F524185270138AE23265955B7BCFF@S0MSMAIL112.arc.local> Message-ID: <9f8378f0-d1ac-cbf4-fba9-bbaf18c0beb9@gmail.com> Il 18/05/2018 07:31, Fiedler Roman ha scritto: > I thought about that also, but shouldn't 99%+ of systems perform no pinning whatsoever of packages to repositories? In that case, the "wrong" repository could publish just a slightly increased package version number of a package from another repository. Unattended updates will apply it anyway and also for users it would be hard noticing it: at least my "apt-get" version does not show any information about the repository a package would be downloaded from before confirming the installation. Thus the user would have to check each single package manually by invoking "apt-cache policy [pkg-name]" or use "apt-get download [packagelist]", check the logs and install packages with "dpkg". Well, assume that who can publish to a repo you trust *is root* on your machine. Even if you could pin the package, what prevents him from adding a suid exe ? > Unless my system is misconfigured or other assumptions do not hold true, that would imply, that the only security benefit from key pinning is only about maintenance, making detection/pruning of stale keys easier. That's exactly what ther're for. BYtE, Diego From whitey at posteo.net Fri May 18 15:50:00 2018 From: whitey at posteo.net (Whitey) Date: Fri, 18 May 2018 13:50:00 +0000 Subject: Breaking MIME concatenation In-Reply-To: References: <192346920.20180516154605@postzone.org> <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> <87r2masobi.fsf@wheatstone.g10code.de> <87tvr6kqr2.fsf@fifthhorseman.net> Message-ID: <3f6b47b6-fcca-e750-9740-028b6921b4de@posteo.net> Robert J. Hansen wrote: > I don't have concrete numbers here, but my suspicion is that GnuPG is a > package verification system that's useful for email... and most of the > problems people have with it as a package verification system stem from > the fact it was originally an email privacy system. Which might explain why some Linux distros are lax about updating GnuPG. Ancient versions work o.k. for package verification. -- Whitey "To suppress free speech is a double wrong. It violates the rights of the hearer as well as those of the speaker." Frederick Douglass From m.mansfeld at mansfeld-elektronik.de Fri May 18 15:40:53 2018 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Fri, 18 May 2018 15:40:53 +0200 Subject: =?ISO-8859-1?Q?Kommentar:_Efail_ist_ein_Megafail_f=FCr_E-Mail-Verschl=FCsselung_|_heise_online?= Message-ID: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> OK, maybe someones weekend will be spoilt after reading this comment, but hey, it's an original J?rgen Schmidt (responsible redactor seems to be Martin Holland), what else would you expect.... J?rgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just ignore this comment. https://heise.de/-4051354 (in German language, I don't think it's worth a translation :-/ ) Regards Matthias -- Unsere Korrespondenz kann mitgelesen werden. Wollen Sie das erschweren, mailen wir uns gerne mit (Open)PGP verschl?sselt. - Matthias Mansfeld Elektronik * Leiterplattenlayout Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8 Internet: http://www.mansfeld-elektronik.de OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From trinh.randy at gmail.com Fri May 18 18:31:54 2018 From: trinh.randy at gmail.com (Randy Trinh) Date: Fri, 18 May 2018 12:31:54 -0400 Subject: [GPGME] Repeated decrypt fails In-Reply-To: <8736ypl1zb.fsf@wheatstone.g10code.de> References: <20180517153502.cr3qwf2rfbz6rful@adversary.org> <8736ypl1zb.fsf@wheatstone.g10code.de> Message-ID: On Fri, May 18, 2018 at 5:58 AM, Werner Koch wrote: > Here you show the result of the start operation which is usuallay success. What you need to check here instead is STAT as returned by gpgme_wait. Thanks for that! I just fixed that and now the error I get the second time I upload is the "NO_DATA" error (which is reasonable as it decrypts anyways with no data), Again the file that is obtained through the upload can still be decrypted via the command line just fine. > Is there a reason why you use the asynchronous operaions and not the synchronous? Your code would not work with multiple threads because gpgme_wait may only be called by one thread. The only reason I have it as asynchronous would be because the file that is being decrypted is then unzipped and its contents loaded elsewhere - but rather than using a library (as of current), I just called a system() to execute the zip and without this. > gpgme has a function to figure this out: /* Get the information about the configured engines. A pointer to the * first engine in the statically allocated linked list is returned. * The returned data is valid until the next gpgme_ctx_set_engine_info. */ gpgme_engine_info_t gpgme_ctx_get_engine_info (gpgme_ctx_t ctx); With this I can confirm its using 2.0.22. > Cheers, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From m16+gnupg at monksofcool.net Fri May 18 18:25:45 2018 From: m16+gnupg at monksofcool.net (Ralph Seichter) Date: Fri, 18 May 2018 18:25:45 +0200 Subject: =?UTF-8?Q?Re:_Kommentar:_Efail_ist_ein_Megafail_f=c3=bcr_E-Mail-Ver?= =?UTF-8?Q?schl=c3=bcsselung_|_heise_online?= In-Reply-To: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> References: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> Message-ID: <5aceee64-ea76-9739-d5b0-2c97eafe3bd1@monksofcool.net> On 18.05.18 15:40, Matthias Mansfeld wrote: > J?rgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just > ignore this comment. > > https://heise.de/-4051354 Fortunately not everybody at Heise is clueless and/or a PGP hater: https://heise.de/-4050153 -Ralph From MichaelQuigley at TheWay.org Fri May 18 18:01:50 2018 From: MichaelQuigley at TheWay.org (MichaelQuigley at TheWay.org) Date: Fri, 18 May 2018 12:01:50 -0400 Subject: Don't Panic. In-Reply-To: References: Message-ID: "Gnupg-users" wrote on 05/15/2018 02:45:35 PM: > ----- Message from "Mark H. Wood" on Tue, 15 May > 2018 11:06:26 -0400 ----- > > To: > > gnupg-users at gnupg.org > > Subject: > > Re: Don't Panic. > > On Mon, May 14, 2018 at 04:48:31PM +0100, Mark Rousell wrote: > > Amongst other things this includes the following paragraph which, as I > > understand it, is essentially untrue: > > > > "There are currently no reliable fixes for the vulnerability. If you > > use PGP/GPG or S/MIME for very sensitive communication, you should > > disable it in your email client for now," said Sebastian Schinzel > > , a > > professor of computer security at the University. > > Heh. "We've discovered that locks can be picked, so you should remove > all the locks from your doors right now." > > -- > Mark H. Wood > Lead Technology Analyst +1 Well said. Michael Quigley Computer Services The Way International -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri May 18 20:10:25 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 18 May 2018 14:10:25 -0400 Subject: =?UTF-8?Q?Re:_Kommentar:_Efail_ist_ein_Megafail_f=c3=bcr_E-Mail-Ver?= =?UTF-8?Q?schl=c3=bcsselung_|_heise_online?= In-Reply-To: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> References: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> Message-ID: <5b52b410-a3ac-5512-3705-411536ca0dc6@sixdemonbag.org> > J?rgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just > ignore this comment. He's also not exactly wrong. The continuing support for SE packets is an embarrassment to us. In our defense, though, the GnuPG userbase revolts whenever Werner mentions something as mild as dropping PGP 2.6 support. When Patrick changed Enigmail to consider lack of MDC a fatal error, he had five complaints overnight. It's very easy for pundits to say "your backwards compatibility is a real problem, you need to break it and move forwards." But I don't see any of them volunteering to answer all of the support requests that would flood in if we were to do that. From dkg at fifthhorseman.net Fri May 18 20:45:26 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 18 May 2018 14:45:26 -0400 Subject: Breaking MIME concatenation In-Reply-To: <3f6b47b6-fcca-e750-9740-028b6921b4de@posteo.net> References: <192346920.20180516154605@postzone.org> <323ba05c-264c-8aa0-fdba-7d4ac2a99cf6@riseup.net> <87r2masobi.fsf@wheatstone.g10code.de> <87tvr6kqr2.fsf@fifthhorseman.net> <3f6b47b6-fcca-e750-9740-028b6921b4de@posteo.net> Message-ID: <87o9hckdkp.fsf@fifthhorseman.net> On Fri 2018-05-18 13:50:00 +0000, Whitey wrote: > Robert J. Hansen wrote: >> I don't have concrete numbers here, but my suspicion is that GnuPG is a >> package verification system that's useful for email... and most of the >> problems people have with it as a package verification system stem from >> the fact it was originally an email privacy system. > > Which might explain why some Linux distros are lax about updating GnuPG. > Ancient versions work o.k. for package verification. they won't be OK once the switch to ed25519 happens :/ --dkg From dkg at fifthhorseman.net Fri May 18 20:52:45 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 18 May 2018 14:52:45 -0400 Subject: AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation) In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7BCFF@S0MSMAIL112.arc.local> References: <192346920.20180516154605@postzone.org> <201805171012.00379.bernhard@intevation.de> <2ECE9D9EEF1F524185270138AE23265955B7B8D0@S0MSMAIL112.arc.local> <87zi0yl4ks.fsf@fifthhorseman.net> <2ECE9D9EEF1F524185270138AE23265955B7BB6F@S0MSMAIL112.arc.local> <87r2makqau.fsf@fifthhorseman.net> <2ECE9D9EEF1F524185270138AE23265955B7BCFF@S0MSMAIL112.arc.local> Message-ID: <87lgcgkd8i.fsf@fifthhorseman.net> On Fri 2018-05-18 05:31:36 +0000, Fiedler Roman wrote: > I see. If understood correctly, the trusted.gpg.d bypasses key > management with apt-key completely, so not running into problems with > apt-key deprecation. I'm actually advocating avoiding trusted.gpg.d entirely as well, and moving to explicit per-repo keyrings. So keep trusted.gpg and trusted.gpg.d completely empty, and populate /etc/apt/sources.list with lines like: deb [signed-by=/usr/share/keyrings/debian-archive-keyring.gpg] http://ftp.debian.org/debian buster main > I thought about that also, but shouldn't 99%+ of systems perform no > pinning whatsoever of packages to repositories? In that case, the > "wrong" repository could publish just a slightly increased package > version number of a package from another repository. You're asking the right questions. But please read https://wiki.debian.org/DebianRepository/UseThirdParty#Standard_pinning and the other sections on that page in more detail for the answers :) > Unless my system is misconfigured or other assumptions do not hold > true, that would imply, that the only security benefit from key > pinning is only about maintenance, making detection/pruning of stale > keys easier. Another benefit is that it is a necessary prerequisite if we want to be able to constrain some .debs (e.g. https://wiki.debian.org/UntrustedDebs and https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging) based on their origin. This is still more work to be done, but if we can't isolate repos from one another than it'll never work. So please don't discount this work just because we haven't achieved all the rest of the isolation yet. The journey of a thousand miles begins with a single step, as they say. --dkg From martin at postzone.org Fri May 18 21:27:19 2018 From: martin at postzone.org (Martin) Date: Fri, 18 May 2018 21:27:19 +0200 Subject: =?iso-8859-1?Q?Re:_Kommentar:_Efail_ist_ein_Megafail_f=FCr_E-Mail-Verschl=FCsselung_|_h?= =?iso-8859-1?Q?eise_online?= In-Reply-To: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> References: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> Message-ID: <1892043084.20180518212719@postzone.org> Hello Matthias, Friday, May 18, 2018, 3:40:53 PM, you wrote: > J?rgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just > ignore this comment. And again recommandatioin for Signal. It seems to be a PR campaign - but a very bad one. -- Best regards, Martin From calestyo at scientia.net Fri May 18 19:51:03 2018 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 18 May 2018 19:51:03 +0200 Subject: Kommentar: Efail ist ein Megafail =?ISO-8859-1?Q?f=FCr?= =?ISO-8859-1?Q?_E-Mail-Verschl=FCsselung?= | heise online In-Reply-To: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> References: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> Message-ID: <7779031d23bc325cb9d02eeb3c4033e946983eb0.camel@scientia.net> I think heise is generally becoming more and more part of the rainbow press in gerneral.. but their repeated fake news about crypto and weird claims "crypto must become easy" (in the sense of: people shouldn't need to mutually authenticate) starts to get really dangerous for the unaware people believing their shit. Cheers, Chris. From markr at signal100.com Fri May 18 21:51:52 2018 From: markr at signal100.com (Mark Rousell) Date: Fri, 18 May 2018 20:51:52 +0100 Subject: =?UTF-8?Q?Re:_Kommentar:_Efail_ist_ein_Megafail_f=c3=bcr_E-Mail-Ver?= =?UTF-8?Q?schl=c3=bcsselung_|_heise_online?= In-Reply-To: <1892043084.20180518212719@postzone.org> References: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> <1892043084.20180518212719@postzone.org> Message-ID: <5AFF2ED8.2090002@signal100.com> On 18/05/2018 20:27, Martin wrote: > Hello Matthias, > > Friday, May 18, 2018, 3:40:53 PM, you wrote: > >> J?rgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just >> ignore this comment. > And again recommandatioin for Signal. It seems to be a PR campaign - > but a very bad one. Indeed, there does seem to be a recurring campaign of pro-Signal propaganda at every turn recently on multiple fronts. It is making me very, very suspicious indeed. Those who seem to be blindly claiming that Signal is a replacement for email, without considering the specifics of individual users and use cases, are not helping security, safety, or privacy (no matter what some of the benefits of Signal may be). -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From trinh.randy at gmail.com Fri May 18 20:59:54 2018 From: trinh.randy at gmail.com (Randy Trinh) Date: Fri, 18 May 2018 14:59:54 -0400 Subject: [GPGME] Repeated decrypt fails In-Reply-To: References: <20180517153502.cr3qwf2rfbz6rful@adversary.org> <8736ypl1zb.fsf@wheatstone.g10code.de> Message-ID: On Fri, May 18, 2018 at 12:31 PM, Randy Trinh wrote: > > Thanks for that! I just fixed that and now the error I get the second time > I upload is the "NO_DATA" error (which is reasonable as it decrypts anyways > with no data), Again the file that is obtained through the upload can still > be decrypted via the command line just fine. > I identified the error! I had called "gpgme_set_engine_info" in attempt to get gpgme working on a different device earlier and did not remove this. For some weird reason this changed the configured engine version from 2.0.22 to 1.0.0 only after the first instance. Thanks for all the help everyone! Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mirimir at riseup.net Sat May 19 01:07:11 2018 From: mirimir at riseup.net (Mirimir) Date: Fri, 18 May 2018 12:07:11 -1100 Subject: =?UTF-8?Q?Re:_Kommentar:_Efail_ist_ein_Megafail_f=c3=bcr_E-Mail-Ver?= =?UTF-8?Q?schl=c3=bcsselung_|_heise_online?= In-Reply-To: <5AFF2ED8.2090002@signal100.com> References: <5AFED7E5.32502.12F8348@m.mansfeld.mansfeld-elektronik.de> <1892043084.20180518212719@postzone.org> <5AFF2ED8.2090002@signal100.com> Message-ID: <1524d20b-2f1c-6daf-8c1a-036c5d4ea936@riseup.net> On 05/18/2018 08:51 AM, Mark Rousell wrote: > On 18/05/2018 20:27, Martin wrote: >> Hello Matthias, >> >> Friday, May 18, 2018, 3:40:53 PM, you wrote: >> >>> J?rgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just >>> ignore this comment. >> And again recommandatioin for Signal. It seems to be a PR campaign - >> but a very bad one. > > Indeed, there does seem to be a recurring campaign of pro-Signal > propaganda at every turn recently on multiple fronts. It is making me > very, very suspicious indeed. > > Those who seem to be blindly claiming that Signal is a replacement for > email, without considering the specifics of individual users and use > cases, are not helping security, safety, or privacy (no matter what some > of the benefits of Signal may be). Well, PFS _is_ an advantage. But largely, using Signal means using smartphones. And just about _all_ smartphones are OPSEC nightmares. From wk at gnupg.org Sat May 19 14:15:50 2018 From: wk at gnupg.org (Werner Koch) Date: Sat, 19 May 2018 14:15:50 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <051c33c9-4eed-cc72-728e-cf280d8f1482@enigmail.net> (Patrick Brunschwig's message of "Fri, 18 May 2018 12:18:29 +0200") References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> <913B3C3B-9885-4781-B740-CAD4F9A3F457@gpgtools.org> <8736yqpms9.fsf__2264.44759541682$1526555521$gmane$org@wheatstone.g10code.de> <051c33c9-4eed-cc72-728e-cf280d8f1482@enigmail.net> Message-ID: <87vabjj0y1.fsf@wheatstone.g10code.de> On Fri, 18 May 2018 12:18, patrick at enigmail.net said: > How far back will that solution work? I.e. is this supported by all > 2.0.x and 2.2.x versions of gpg? 2.0.19 (2012) was the first to introduce DECRYPTION_INFO In any case 2.0 is end-of-life. In theory we could backport that to 1.4 but I don't think that makes sense. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From patrick at enigmail.net Sat May 19 15:00:36 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 19 May 2018 15:00:36 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87vabjj0y1.fsf@wheatstone.g10code.de> References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> <913B3C3B-9885-4781-B740-CAD4F9A3F457@gpgtools.org> <8736yqpms9.fsf__2264.44759541682$1526555521$gmane$org@wheatstone.g10code.de> <051c33c9-4eed-cc72-728e-cf280d8f1482@enigmail.net> <87vabjj0y1.fsf@wheatstone.g10code.de> Message-ID: On 19.05.18 14:15, Werner Koch wrote: > On Fri, 18 May 2018 12:18, patrick at enigmail.net said: > >> How far back will that solution work? I.e. is this supported by all >> 2.0.x and 2.2.x versions of gpg? > > 2.0.19 (2012) was the first to introduce DECRYPTION_INFO In any case > 2.0 is end-of-life. In theory we could backport that to 1.4 but I don't > think that makes sense. Enigmail runs on many long-term Linux distributions that still ship older, presumably patched, versions of GnuPG. For example, Red Hat EL 6.9/Centos 6.9 contains GnuPG 2.0.14, but current versions of Thunderbird. GnuPG 2.0.x will therefore still be relevant for me for many years to come. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jeandavid8 at verizon.net Sat May 19 15:50:51 2018 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Sat, 19 May 2018 09:50:51 -0400 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: References: <87mux28yts.fsf@wheatstone.g10code.de> <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> <913B3C3B-9885-4781-B740-CAD4F9A3F457@gpgtools.org> <8736yqpms9.fsf__2264.44759541682$1526555521$gmane$org@wheatstone.g10code.de> <051c33c9-4eed-cc72-728e-cf280d8f1482@enigmail.net> <87vabjj0y1.fsf@wheatstone.g10code.de> Message-ID: On 05/19/2018 09:00 AM, Patrick Brunschwig wrote: > On 19.05.18 14:15, Werner Koch wrote: >> On Fri, 18 May 2018 12:18, patrick at enigmail.net said: >> >>> How far back will that solution work? I.e. is this supported by all >>> 2.0.x and 2.2.x versions of gpg? >> >> 2.0.19 (2012) was the first to introduce DECRYPTION_INFO In any case >> 2.0 is end-of-life. In theory we could backport that to 1.4 but I don't >> think that makes sense. > > Enigmail runs on many long-term Linux distributions that still ship > older, presumably patched, versions of GnuPG. For example, Red Hat EL > 6.9/Centos 6.9 contains GnuPG 2.0.14, but current versions of Thunderbird. > > GnuPG 2.0.x will therefore still be relevant for me for many years to come. > Me too! Red Hat Enterprise Linux Server release 6.9 (Santiago) thunderbird-52.7.0-1.el6_9.x86_64 gnupg2-2.0.14-8.el6.x86_64 Enigmail 2.0.4 -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key:166D840A 0C610C8B Registered Machine 1935521. /( )\ Shrewsbury, New Jersey http://linuxcounter.net ^^-^^ 09:40:01 up 2 days, 17:30, 2 users, load average: 4.15, 4.27, 4.46 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From patrick at enigmail.net Sat May 19 18:47:08 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 19 May 2018 18:47:08 +0200 Subject: Efail - Possible Measures? Message-ID: In the light of the Efail vulnerability I am asking myself if it's really needed to decrypt non-regular types of emails at all. In other words, should we decrypt a multipart/encrypted MIME part at all if we detect an irregular MIME structure? If we would not decrypt irregular MIME structures, there cannot be an issue with HTML displaying. This would be a good thing, if you're an addon and you can't change the application you live in. I know that some mail clients do this already, but all those clients that are affected by Efail apparently don't. I would consider the following "regular" MIME structures: 1. top-level MIME part is multipart/encrypted. 2. an attached email (Content-Type = message/rfc822) containing a multipart/encrypted MIME part as direct child. Does anyone know of other relevant types of message structures? Does anyone see a reason why NOT to do that? -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lukele at gpgtools.org Sat May 19 19:40:32 2018 From: lukele at gpgtools.org (Lukas Pitschl | GPGTools) Date: Sat, 19 May 2018 19:40:32 +0200 Subject: Efail - Possible Measures? In-Reply-To: References: Message-ID: <905E9D4E-3F12-49A5-B613-42E1D794DEC6@gpgtools.org> > I would consider the following "regular" MIME structures: > > 1. top-level MIME part is multipart/encrypted. > 2. an attached email (Content-Type = message/rfc822) containing a > multipart/encrypted MIME part as direct child. We have been doing this in the past but changed it especially for Exchanges servers if I remember correctly, since they tend to wrap the multipart/encrypted mime part into other mime parts. Also I think it was at the Dreieich conference when I brought this issue up and was told that it is perfectly alright to have a multipart/encrypted part as a child part of other parts. It would however certainly fix this issue for PGP/MIME. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 268 bytes Desc: Message signed with OpenPGP using GPGMail URL: From list at nezwerg.de Sat May 19 20:18:25 2018 From: list at nezwerg.de (Alexander Veit) Date: Sat, 19 May 2018 20:18:25 +0200 Subject: Breaking MIME concatenation In-Reply-To: <3995f7eb-1ae5-1394-42de-60e004e60c6a@enigmail.net> References: <8e990067-dd43-12ca-cb59-8d1719e9fea1__11217.0733082623$1526396337$gmane$org@andrewg.com> <84339ca9-8828-d131-f999-48fa427397f5@enigmail.net> <7E16B6A6-7A96-49B4-B8CF-C5CCBC62646B__9059.42430622435$1526405645$gmane$org@gpgtools.org> <3995f7eb-1ae5-1394-42de-60e004e60c6a@enigmail.net> Message-ID: <22aaa13b-eed4-857b-f61a-06dfee96909e@nezwerg.de> Am 16.05.2018 um 06:21 schrieb Patrick Brunschwig: > I have actually thought through this during a sleepless night, and I > believe that it could work as a quick and easy to implement *short term* > measure until the mail clients have fixed the HTML rendering. I do not think that HTML rendering could be fixed in a way that it would meet general security requirements. Mail clients rely on different rendering/browser engines that implement HTML/CSS as a living standard and with different features and interpretations of these standards. And probably none of these engines have been designed with security implications of tampered with HTML source code in mind. In my opinion this cannot be the basis for a secure mail client. A decrypted message part should never be embedded or displayed in other message parts of the same or any other message. And with embedded I mean embedded neither in raw nor parsed message parts (such as HTML DOMs). A decrypted message should always be displayed in its own secured sandbox. I'm quite sure that not following these rules will inevitably lead to doom. -- Just my 2 cents Alex From look at my.amazin.horse Sat May 19 19:02:55 2018 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sat, 19 May 2018 19:02:55 +0200 Subject: [openpgp-email] Efail - Possible Measures? In-Reply-To: References: Message-ID: <20180519170255.bvtm73fhoic4tvbp@calamity> (Also cross-posting to Autocrypt) Patrick Brunschwig(patrick at enigmail.net)@Sat, May 19, 2018 at 06:47:08PM +0200: > In the light of the Efail vulnerability I am asking myself if it's > really needed to decrypt non-regular types of emails at all. In other > words, should we decrypt a multipart/encrypted MIME part at all if we > detect an irregular MIME structure? I used to parse stuff in a generic way in K-9 Mail at first, but changed it later (mid 2016?) to show decrypted data only in known mime structures. I planned to add support for other things as they came up, but so far I haven't received feedback about any incompatibilities. > 1. top-level MIME part is multipart/encrypted. This is the only mime structure I handle, any other pgp/mime structure will show up as an attachment. When displaying a decrypted mail, the decrypted payload is displayed like a normal message would. PGP/INLINE is handled only if the pgp data is the very first non-whitespace content, otherwise it won't be decrypted. If there are mime parts outside the encrypted payload, they are displayed as "unprotected attachments" that require an extra click to open. For the case of text/plain parts following the encrypted part, those are shown as "Unsigned Text" at the bottom and displayed in a text-only widget, nicely covering the use case of mailing list footers: https://matrix.org/_matrix/media/v1/download/stratum0.org/cKjeJctipgVjBEXIMvrqLlJL > 2. an attached email (Content-Type = message/rfc822) containing a > multipart/encrypted MIME part as direct child. I don't handle this. Does it come up for you? - V PS: Randomly signing this message. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ca+gnupg-users at esmtp.org Sun May 20 04:10:58 2018 From: ca+gnupg-users at esmtp.org (Claus Assmann) Date: Sat, 19 May 2018 19:10:58 -0700 Subject: doc patches: spelling errors Message-ID: <20180520021058.GA24210@x2.esmtp.org> --- gnupg.info-1- Sat May 19 19:01:41 2018 +++ gnupg.info-1 Sat May 19 19:02:04 2018 @@ -2516,7 +2516,7 @@ below. A "!" indicates that the signature has been successfully verified, a "-" denotes a bad signature and a "%" is used if an error occurred while checking the signature (e.g. a non supported - algorithm). Signatures where the public key is not availabale are + algorithm). Signatures where the public key is not available are not listed; to see their keyids the command `--list-sigs' can be used. @@ -5184,7 +5184,7 @@ `--default-new-key-algo STRING' This option can be used to change the default algorithms for key generation. The STRING is similar to the arguments required for - the command `--quick-add-key' but slighly different. For example + the command `--quick-add-key' but slightly different. For example the current default of `"rsa2048/cert,sign+rsa2048/encr"' (or `"rsa3072"') can be changed to the value of what we currently call future default, which is `"ed25519/cert,sign+cv25519/encr"'. You --- gnupg.info-2- Sat May 19 19:07:27 2018 +++ gnupg.info-2 Sat May 19 19:08:22 2018 @@ -332,7 +332,7 @@ This application adds read-only support for keys and certificates stored on a SmartCard-HSM (http://www.smartcard-hsm.com). - To generate keys and store certifiates you may use OpenSC + To generate keys and store certificates you may use OpenSC (https://github.com/OpenSC/OpenSC/wiki/SmartCardHSM) or the tools from OpenSCDP (http://www.openscdp.org). @@ -2578,7 +2578,7 @@ linefeed to separate file names. `--openpgp' - This option has no effect becuase OpenPGP encryption and signing is + This option has no effect because OpenPGP encryption and signing is the default. `--cms' @@ -2722,7 +2722,7 @@ When used with the command `--receive' a single Web Key Service mail is processed. Commonly this command is used with the option `--send' -to directly send the crerated mails back. See below for an +to directly send the created mails back. See below for an installation example. The command `--cron' is used for regualr cleanup tasks. For example From ca+gnupg-users at esmtp.org Sun May 20 03:56:55 2018 From: ca+gnupg-users at esmtp.org (Claus Assmann) Date: Sat, 19 May 2018 18:56:55 -0700 Subject: trivial doc patch: "the the" Message-ID: <20180520015655.GA22486@x2.esmtp.org> --- tools.texi- Sat May 19 18:52:35 2018 +++ tools.texi Sat May 19 18:52:45 2018 @@ -290,7 +290,7 @@ Apply the configuration settings listed in @var{file} to the configuration files. If @var{file} has no suffix and no slashes the command first tries to read a file with the suffix @code{.prf} from -the the data directory (@code{gpgconf --list-dirs datadir}) before it +the data directory (@code{gpgconf --list-dirs datadir}) before it reads the file verbatim. A profile is divided into sections using the bracketed component name. Each section then lists the option which shall go into the respective configuration file. --- gpgconf.1- Sat May 19 18:52:27 2018 +++ gpgconf.1 Sat May 19 18:53:12 2018 @@ -84,7 +84,7 @@ Apply the configuration settings listed in \fIfile\fR to the configuration files. If \fIfile\fR has no suffix and no slashes the command first tries to read a file with the suffix \fB.prf\fR from -the the data directory (\fBgpgconf --list-dirs datadir\fR) before it +the data directory (\fBgpgconf --list-dirs datadir\fR) before it reads the file verbatim. A profile is divided into sections using the bracketed component name. Each section then lists the option which shall go into the respective configuration file. From rjh at sixdemonbag.org Sun May 20 08:26:47 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 20 May 2018 02:26:47 -0400 Subject: A postmortem on Efail Message-ID: Writing just for myself -- not for GnuPG and not for Enigmail and definitely not for my employer -- I put together a postmortem on Efail. You may find it worth reading. You may also not. Your mileage will probably vary. :) https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08 From rjh at sixdemonbag.org Sun May 20 09:28:39 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 20 May 2018 03:28:39 -0400 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: > Break backwards compatibility already: it?s time. Ignore the haters. I > trust you. :) :) :) :) :) From mirimir at riseup.net Sun May 20 10:33:47 2018 From: mirimir at riseup.net (Mirimir) Date: Sat, 19 May 2018 21:33:47 -1100 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: On 05/19/2018 08:28 PM, Robert J. Hansen wrote: >> Break backwards compatibility already: it?s time. Ignore the haters. I >> trust you. > > :) :) :) :) :) I'm OK with that :) From bereska at hotmail.com Sun May 20 09:49:09 2018 From: bereska at hotmail.com (Dmitry Gudkov) Date: Sun, 20 May 2018 07:49:09 +0000 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: ?We be of one blood, ye and I? ? Rudyard Kipling, The Jungle Books On 20/05/2018 10:28, Robert J. Hansen wrote: >> Break backwards compatibility already: it?s time. Ignore the haters. I >> trust you. > > :) :) :) :) :) > From elowe at elowe.com Sun May 20 09:02:39 2018 From: elowe at elowe.com (Earle Lowe) Date: Sun, 20 May 2018 00:02:39 -0700 Subject: S/MIME and AE Message-ID: I can't see anyway that S/MIME gets resolved with anything other than heuristics that look for the footprints of the CBC malleability in efail (random blocks and/or 8bit content) etc. There are two other alternatives, only one is plausible, IMO 1) Only allow emails where the signature verifies. It doesn't have to be valid in terms of chaining to a trusted root, but it does need to verify. This also means you throw out anything not signed (or signed first, then encrypted) (both of which are allowed). This option may turn out to be plausibly implemented - but is a pretty big change to how most S/MIME implementations in actual clients work - they usually hardly do anything even with bad signatures. 2) Use the various AE CMS RFCs - This is a long-term effort given the experience with OpenPGP in deprecating non-MDC packets. First either the S/MIME RFC needs to be updated to remove AES-CBC as essentially the default and replace it with another one - AND certificates need to start using the SMIMECapabilitiesExtensions - or vendors start ignoring the existing RFC and just go ahead. I don't see any way a sender can have some plausible idea what the recipient can decrypt without having some knowledge of the version of S/MIME they are using - and this is what SMIMECapabilities is for in the certificate. Then once the vendors get together and decide on the new behaviour, and the certs get updated with new Capabilities - we can wait about how many years for it all to percolate through the ecosystem? There is a reason no one bothered to implement any of those RFCs in the first place. For OpenPGP and MDC, I vote for completely and fully removing non-MDC SE Packets - no more generating SE packets for any version of keys or ciphers, ignoring the MDC feature packet in V4 keys, and refusing to decrypt anything without MDC. I'm ok if some kind of user option needs to exist to decrypt old content - but I think it should be clearly seen as a dangerous and insecure option. -Earle -------------- next part -------------- An HTML attachment was scrubbed... URL: From bereska at hotmail.com Sun May 20 09:23:17 2018 From: bereska at hotmail.com (Dmitry Gudkov) Date: Sun, 20 May 2018 07:23:17 +0000 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: I want to get involved and give a damn! Break backwards compatibility already: it?s time. Ignore the haters. I trust you. On 20/05/2018 09:26, Robert J. Hansen wrote: > Writing just for myself -- not for GnuPG and not for Enigmail and > definitely not for my employer -- I put together a postmortem on Efail. > You may find it worth reading. You may also not. Your mileage will > probably vary. :) > > https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40cipherpunk%2Fefail-a-postmortem-4bef2cea4c08&data=02%7C01%7C%7Cc13b709433394c96d61608d5be1ad73d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636623944863861029&sdata=4yVPteoBQ3e9eSB%2FMm%2B4NMt95nSicgfxxAFeJIqkc0g%3D&reserved=0 > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users&data=02%7C01%7C%7Cc13b709433394c96d61608d5be1ad73d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636623944863861029&sdata=xuw5k7vuQmyKKsGlpmoY3xL5Ol3fETl2sTQKxPrCZ%2Fs%3D&reserved=0 > From demfloro at demfloro.ru Sun May 20 10:31:09 2018 From: demfloro at demfloro.ru (Dmitrii Tcvetkov) Date: Sun, 20 May 2018 11:31:09 +0300 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: <20180520113109.399c6d35@fire.localdomain> On Sun, 20 May 2018 02:26:47 -0400 "Robert J. Hansen" wrote: > Writing just for myself -- not for GnuPG and not for Enigmail and > definitely not for my employer -- I put together a postmortem on > Efail. You may find it worth reading. You may also not. Your > mileage will probably vary. :) > > https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08 > Thank you for the postmortem. I don't know any users of GnuPG who still have to work with non-MDC OpenPGP messages (frankly, don't know any GnuPG users IRL, but working on it). But it seems to me that GnuPG is so widely widespread because it was so stable and there was no breaking upgrades, so users didn't expect any breaking change at all. I, as a user, don't need support for non-MDC messages and surely PGP 2.6, but I can imagine how challenging it can be to upgrade a system, which was state-of-the-art years ago, but right now is obsolete. Really it's not an upgrade, but rebuild from the scratch. And some parts of the system are probably proprietary, so cooperation from vendors is required. And the fact that obsolete features weren't dropped due to users feedback means that GnuPG upstream understands this too. But something has to change, it can't go like this forever, we do need breaking changes to remove outdated parts. I trust upstream's judgement. From andrewg at andrewg.com Sun May 20 11:22:29 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 20 May 2018 10:22:29 +0100 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: <499385E3-CCA7-4CFA-9AF5-EF6EB59EC476@andrewg.com> > On 20 May 2018, at 07:26, Robert J. Hansen wrote: > > Writing just for myself -- not for GnuPG and not for Enigmail and > definitely not for my employer -- I put together a postmortem on Efail. > You may find it worth reading. You may also not. Your mileage will > probably vary. :) I wouldn?t call myself a cryptography expert, although I do try my best to keep up. I speak as a tinkerer who wants to humanise cryptography, because it?s still too hard for ordinary people to understand, and you shouldn?t need to understand everything about a technology to be able to use it properly, because that defeats the purpose of technology. I find a lot of things about the whole PGP ecosystem interminably frustrating. But the worst thing is the inertia. We know there are things that need done, but getting them done often seems politically impossible. Not to mention the small number of people who are actually getting paid a salary to fix these things. TLS at least gets attention because the Googles, Apples and Facebooks of the internet are beating people over the head saying ?we need to push forward?. TLS breaks backwards compatibility regularly. That?s the price of improved security. I said earlier that deprecation has to happen, but I?ll reiterate here. If doing the things that we know need to be done requires breaking backwards compatibility, then so be it. A From jdever at triad.rr.com Sun May 20 10:34:21 2018 From: jdever at triad.rr.com (Jim Dever) Date: Sun, 20 May 2018 04:34:21 -0400 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: <44e059d3-b51a-5fc6-45c5-626cf167edfc@triad.rr.com> I've used PGP ever since I discovered it when I ran a BBS back in the late 80's early 90's. I rarely post but always listening. Definitely time to break backward compatibility if it will help move it forward! Go for it! On 5/20/2018 3:28 AM, Robert J. Hansen wrote: >> Break backwards compatibility already: it?s time. Ignore the haters. I >> trust you. > > :) :) :) :) :) > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From al-gnupg_users at none.at Sun May 20 12:44:44 2018 From: al-gnupg_users at none.at (Aleksandar Lazic) Date: Sun, 20 May 2018 12:44:44 +0200 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: <20180520104436.GA11720@aleks-PC> Hi Robert. On 20/05/2018 02:26, Robert J. Hansen wrote: > Writing just for myself -- not for GnuPG and not for Enigmail and > definitely not for my employer -- I put together a postmortem on Efail. > You may find it worth reading. You may also not. Your mileage will > probably vary. :) > > https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08 As a long time reader and partly gpg user I would like to thank you for the post. >From my point of view must be something more behind the curtain. I do not want to create a conspiracy theory but it's wiggy that EFF favors *NO* security ,pgp or s/mime, instead to fix the current possibilities and promote signal. As serveral people mentioned in the different Internet medias is signal not a replaceable for e-mail, until the signal company does not offer a own e-mail service. That's just my gut instincts the future will share some lights into this EFAIL scandal. jm2c Best regards Aleks From al-gnupg_users at none.at Sun May 20 13:03:07 2018 From: al-gnupg_users at none.at (Aleksandar Lazic) Date: Sun, 20 May 2018 13:03:07 +0200 Subject: Efail or OpenPGP is safer than S/MIME In-Reply-To: <87vabjj0y1.fsf@wheatstone.g10code.de> References: <9ade7e7c-6931-2580-5f2e-5138334b0191@sixdemonbag.org> <4760889b-be78-7520-811f-a2a5fe0097db@andrewg.com> <360f1994-af7f-ed0c-8da2-23e4881cd0e1__4687.83734036169$1526375664$gmane$org@andrewg.com> <87muwyso20.fsf@wheatstone.g10code.de> <913B3C3B-9885-4781-B740-CAD4F9A3F457@gpgtools.org> <8736yqpms9.fsf__2264.44759541682$1526555521$gmane$org@wheatstone.g10code.de> <051c33c9-4eed-cc72-728e-cf280d8f1482@enigmail.net> <87vabjj0y1.fsf@wheatstone.g10code.de> Message-ID: <20180520110300.GB11720@aleks-PC> On 19/05/2018 14:15, Werner Koch wrote: > On Fri, 18 May 2018 12:18, patrick at enigmail.net said: > > > How far back will that solution work? I.e. is this supported by all > > 2.0.x and 2.2.x versions of gpg? > > 2.0.19 (2012) was the first to introduce DECRYPTION_INFO In any case > 2.0 is end-of-life. In theory we could backport that to 1.4 but I don't > think that makes sense. On windows is the situtiaon really bad. ### aleks at aleks-PC MINGW64 ~ $ uname -a MINGW64_NT-6.1 aleks-PC 2.10.0(0.325/5/3) 2018-02-09 15:25 x86_64 Msys aleks at aleks-PC MINGW64 ~ $ pacman -Ss gpg mingw32/mingw-w64-i686-gpgme 1.11.1-1 A C wrapper library for GnuPG (mingw-w64) mingw32/mingw-w64-i686-libgpg-error 1.29-1 Support library for libgcrypt (mingw-w64) mingw64/mingw-w64-x86_64-gpgme 1.11.1-1 A C wrapper library for GnuPG (mingw-w64) mingw64/mingw-w64-x86_64-libgpg-error 1.29-1 [Installiert] Support library for libgcrypt (mingw-w64) msys/libgpg-error 1.27-1 (libraries) [Installiert] Support library for libgcrypt msys/libgpg-error-devel 1.27-1 (development) [Installiert] Libgpg-error headers and libraries msys/libgpgme 1.6.0-1 (libraries) [Installiert] A C wrapper library for GnuPG msys/libgpgme-devel 1.6.0-1 (development) Libgpgme headers and libraries ### I have installed the latest gpg4win 3.1.1 and then you are able to run a more or less recent version of gpg ### aleks at aleks-PC MINGW64 ~ $ LANG=C /c/Program\ Files\ \(x86\)/GnuPG/bin/gpg --version gpg (GnuPG) 2.2.7 libgcrypt 1.8.2 Copyright (C) 2018 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/aleks/AppData/Roaming/gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ### The point is that as long as the distribution does not update there packages they will be always complains from the users. > Shalom-Salam, > > Werner > > -- > # Please read: Daniel Ellsberg - The Doomsday Machine # > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. Best regards Aleks From pkk at spth.de Sun May 20 13:11:29 2018 From: pkk at spth.de (Philipp Klaus Krause) Date: Sun, 20 May 2018 13:11:29 +0200 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: <9e3d9a28-6f73-b898-b622-389b6eabb04e@spth.de> Am 20.05.2018 um 08:26 schrieb Robert J. Hansen: > Writing just for myself -- not for GnuPG and not for Enigmail and > definitely not for my employer -- I put together a postmortem on Efail. > You may find it worth reading. You may also not. Your mileage will > probably vary. :) > > https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08 I don't think breaking backwards-compability is an all-or-nothing question. IMO, it is important to still be able to decrypt old data. On the other hand one wants sane, secure use with current data. The functionality needed to decrpyt old files should still be there. Possibly hidden behind some new option, if that helps security for typical users. If my mail client will no longer be able to display some old encrypted message, that's ok. But I should be still able to read that message by invoking GPG from the command-line with suitable options. Philipp From dirk.gottschalk1980 at googlemail.com Sun May 20 15:51:40 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 20 May 2018 15:51:40 +0200 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> Hi. Am Sonntag, den 20.05.2018, 02:26 -0400 schrieb Robert J. Hansen: > Writing just for myself -- not for GnuPG and not for Enigmail and > definitely not for my employer -- I put together a postmortem on > Efail. > You may find it worth reading. You may also not. Your mileage will > probably vary. :) > > https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08 Thank you for this real good post. You have some real good arguments. I use GnuPG for many, many years now and for all purposes it is usable for. Encrypting/Signinmg files, emails, backups, and, as you wrote, it is used to check packages for my distribution (Fedora). And I even "abuse" GnuPG to do things, which are not part of the "official" use cases, but it works even in this cases. I think the backwards compatiblity should be broken to improve things. It would be possible to implement something like --legacy to re-enable the old functionality. This could also be implemented in email clients and plug-ins like enigmail as a checkbox. Increment your numnber of natively OpenPGP supporting email clients from zero to one. Evolution has this implemented. At least as an interface to gnupg-agent. Okay, I should say I am one of the very few users, which are using GnuPG on a regular basis for many use cases. I even have a few Smartcards with keys and so on. And I would like to help improving things, if help is welcome. Again, thank you for posting this statement, it wasw really nice to read. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From markr at signal100.com Sun May 20 20:05:26 2018 From: markr at signal100.com (Mark Rousell) Date: Sun, 20 May 2018 19:05:26 +0100 Subject: A postmortem on Efail In-Reply-To: <9e3d9a28-6f73-b898-b622-389b6eabb04e@spth.de> References: <9e3d9a28-6f73-b898-b622-389b6eabb04e@spth.de> Message-ID: <5B01B8E6.70803@signal100.com> On 20/05/2018 12:11, Philipp Klaus Krause wrote: > I don't think breaking backwards-compability is an all-or-nothing question. > > IMO, it is important to still be able to decrypt old data. On the other > hand one wants sane, secure use with current data. > The functionality needed to decrpyt old files should still be there. > Possibly hidden behind some new option, if that helps security for > typical users. > > If my mail client will no longer be able to display some old encrypted > message, that's ok. But I should be still able to read that message by > invoking GPG from the command-line with suitable options. > > Philipp > I must agree with this. Absolutely losing a decryption ability that many people clearly do still require is not a sensible path, but putting 'legacy decryption' ability behind a brand new option that requires some kind of active change by users who do need it is a reasonable and sensible compromise imo. In short, it is not necessary to entirely remove the ability to decrypt legacy-encrypted data to have the effect of deprecating its use. -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Sun May 20 20:07:38 2018 From: markr at signal100.com (Mark Rousell) Date: Sun, 20 May 2018 19:07:38 +0100 Subject: A postmortem on Efail In-Reply-To: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> References: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> Message-ID: <5B01B96A.8080703@signal100.com> On 20/05/2018 14:51, Dirk Gottschalk via Gnupg-users wrote: > I think the backwards compatiblity should be broken to improve things. > It would be possible to implement something like --legacy to re-enable > the old functionality. Agreed. > This could also be implemented in email clients > and plug-ins like enigmail as a checkbox. Personally I'd prefer that mail client did not provide an interface to any "--legacy" options but it's up to mail client authors of course. -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Sun May 20 20:26:09 2018 From: markr at signal100.com (Mark Rousell) Date: Sun, 20 May 2018 19:26:09 +0100 Subject: A postmortem on Efail In-Reply-To: <20180520104436.GA11720@aleks-PC> References: <20180520104436.GA11720@aleks-PC> Message-ID: <5B01BDC1.8040809@signal100.com> On 20/05/2018 11:44, Aleksandar Lazic wrote: > I do not want to create a conspiracy theory but it's wiggy that > EFF favors *NO* security ,pgp or s/mime, instead to fix the current > possibilities and promote signal. > > As serveral people mentioned in the different Internet medias is signal > not a replaceable for e-mail, until the signal company does not offer a > own e-mail service. > > That's just my gut instincts the future will share some lights into this > EFAIL scandal. I share this view. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Sun May 20 21:16:35 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 20 May 2018 20:16:35 +0100 Subject: A postmortem on Efail In-Reply-To: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> References: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> Message-ID: <31decabb-2ae9-5fa2-9eaa-2ed0cb289f69@incenp.org> On 05/20/2018 02:51 PM, Dirk Gottschalk via Gnupg-users wrote: > It would be possible to implement something like --legacy to > re-enable the old functionality. For information, for the problem at hand, two things have been done in that direction: In GnuPG itself: GnuPG will now error out when attempting to decrypt *any* message that is not integrity-protected, *unless* the --ignore-mdc-error flag has been set. This has only been done in the master branch of GnuPG (to be released as GnuPG 2.3 at some point), *not* in the current stable 2.2 branch. In GpgME: GpgME will return a failure when attempting to decrypt *any* message that is not integrity-protected, inconditionnally and even if GnuPG itself only emits a warning. What this all means is that all clients using GpgME will lose the ability to decrypt old, unprotected message upon the next GpgME release (i.e., those clients will be completely immune to Efail even if they currently ignore the no-MDC warning). Users will still be able to decrypt such unprotected messages by calling gpg directly (with the --ignore-mdc-error flag, if needed). Clients that spawn gpg themselves without using GpgME will still be able to decrypt unprotected messages (and therefore, be potentially vulnerable to Efail if they don't pay attention to GnuPG warnings) until GnuPG 2.3 is released. And more generally on the backward compatibility problem: to decrypt all kind of "legacy" messages there will always be the option of using GnuPG 1.4.x, which is still maintained especially for compatibility with 1990-era PGP (it notably retains support for things like PGP 2.6 keys or the MD5 hash algorithm). Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From markr at signal100.com Sun May 20 21:45:48 2018 From: markr at signal100.com (Mark Rousell) Date: Sun, 20 May 2018 20:45:48 +0100 Subject: A postmortem on Efail In-Reply-To: <31decabb-2ae9-5fa2-9eaa-2ed0cb289f69@incenp.org> References: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> <31decabb-2ae9-5fa2-9eaa-2ed0cb289f69@incenp.org> Message-ID: <5B01D06C.1090904@signal100.com> On 20/05/2018 20:16, Damien Goutte-Gattat via Gnupg-users wrote: > On 05/20/2018 02:51 PM, Dirk Gottschalk via Gnupg-users wrote: >> It would be possible to implement something like --legacy to >> re-enable the old functionality. > > For information, for the problem at hand, two things have been done in > that direction: > > In GnuPG itself: GnuPG will now error out when attempting to decrypt > *any* message that is not integrity-protected, *unless* the > --ignore-mdc-error flag has been set. This has only been done in the > master branch of GnuPG (to be released as GnuPG 2.3 at some point), > *not* in the current stable 2.2 branch. > > In GpgME: GpgME will return a failure when attempting to decrypt *any* > message that is not integrity-protected, inconditionnally and even if > GnuPG itself only emits a warning. > > What this all means is that all clients using GpgME will lose the > ability to decrypt old, unprotected message upon the next GpgME > release (i.e., those clients will be completely immune to Efail even > if they currently ignore the no-MDC warning). Users will still be able > to decrypt such unprotected messages by calling gpg directly (with the > --ignore-mdc-error flag, if needed). > > Clients that spawn gpg themselves without using GpgME will still be > able to decrypt unprotected messages (and therefore, be potentially > vulnerable to Efail if they don't pay attention to GnuPG warnings) > until GnuPG 2.3 is released. This seems reasonable to me. It means that legacy decryption is still available in current and future code even if it requires users to take some kind of action. > And more generally on the backward compatibility problem: to decrypt > all kind of "legacy" messages there will always be the option of using > GnuPG 1.4.x, which is still maintained especially for compatibility > with 1990-era PGP (it notably retains support for things like PGP 2.6 > keys or the MD5 hash algorithm). I presume that one day the 1.x.y code will reach end of life. If and when that happens, I strongly suspect that there will still be users who will need to decrypt legacy-encrypted data and I think it is important that they can still do this with a maintained (2.x.y) code base. (And I realise that this is easy for me to say since I'm not contributing to maintaining the code.) -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Sun May 20 22:32:36 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 20 May 2018 21:32:36 +0100 Subject: A postmortem on Efail In-Reply-To: <5B01D06C.1090904@signal100.com> References: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> <31decabb-2ae9-5fa2-9eaa-2ed0cb289f69@incenp.org> <5B01D06C.1090904@signal100.com> Message-ID: On 05/20/2018 08:45 PM, Mark Rousell wrote: > I presume that one day the 1.x.y code will reach end of life. There's no plan to terminate the 1.x branch. It will not gain any new features, but as stated by Werner Koch a few months ago, it "will be kept alive for use with PGP 2 encrypted and signed data" [1]. > I think it is important that they can still do this with a maintained (2.x.y) code base. Support for PGP 2 has already been dropped from the current stable branch, I don't think it will ever be brought back. But the 1.4.x branch *is* maintained, even if only for critical bugfixes. Damien [1] https://lists.gnupg.org/pipermail/gnupg-users/2018-January/059815.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jurgenpolster at gmail.com Sun May 20 22:21:57 2018 From: jurgenpolster at gmail.com (=?utf-8?Q?J=C3=BCrgen_Polster?=) Date: Sun, 20 May 2018 22:21:57 +0200 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: Am 20.05.2018 um 09:28 schrieb Robert J. Hansen : >> Break backwards compatibility already: it?s time. Ignore the haters. I >> trust you. > > :) :) :) :) :) Yes, please! I DO trust you! Juergen Polster From gnupg-users at spodhuis.org Sun May 20 22:28:13 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Sun, 20 May 2018 16:28:13 -0400 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: <20180520202812.GA27080@breadbox.private.spodhuis.org> On 2018-05-20 at 02:26 -0400, Rob J Hansen wrote: > https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08 Excellent post. I favor breaking backwards compatibility and including in the shipped README a description of "The conditions under which we anticipate future backwards compatibility breaks". Maintaining code, with the added code-paths, for handling obsolete crypto has a cost. Rarely exercised code-paths are security attack surface. I favor: 1. Branch GnuPG 1.x, remove all ability to encrypt or generate signatures, have something like "gpgv" but able to decrypt too (so still needs access to private keys). Call it `gpg-legacy-reader`. The name makes it clear that future updates won't add new crypto support (until such time as something else has to be declared legacy). Explicitly state that the legacy reader must not be automatically used in an online mode which enables oracles and that timing attacks are out-of-scope. Simplify. Do not support people deploying this to untrusted hardware platforms or VMs where they need to defend against other users/occupants. This should be a last-resort tool, invoked/triggered manually. 2. Drop all support, always, for non-MDC and other ancient modes, algorithms and packet formats from GnuPG. Simplify the code-base, reduce the burden on the maintainers for the actively maintained branch. 3. _Possibly_ consider an API in gpgme to trigger using gpg-legacy-reader behind the scenes, to make it easier for mail-clients to have a Big Red Decrypt Button to deal with ancient crap. Make it clear that this MUST NOT be automatically used and that the user should be prompted with warnings of the danger. 4. Get together actual MUA maintainers who are users of the GnuPG code-base in a mailing-list and hammer out details of "what should be done about old mail". Cryptographers have long said to decrypt inbound mail and re-encrypt it to a storage key, which can periodically be rotated, but AFAIK mail-clients don't have sane ways to do this. There's no handling of recording verification state of things such as DKIM/ARC on the _original_ message in such a way that it could be used in future; perhaps a client signing key for a new header, only used to add to headers in the mailstore? Without all the need for canonicalization, could be much simpler than DKIM. There's no tooling/expectations around lifecycle of reencryption when using open protocol mailstores via IMAP, there's no discussion of key management and recovery, there's no discussion of impact upon backups. Instead, we have a lot of talking at the "nobody should do that" level and no contributions to actual practices to keep people from having to do "that". It's time for this to change. I don't know if the MTA side can do _anything_ to help here, but if there's anything sane the MTA side can do to help, I can work to get Exim doing it. If there's anything I can do to help, please let me know. -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Mon May 21 02:02:06 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Mon, 21 May 2018 01:02:06 +0100 Subject: A postmortem on Efail In-Reply-To: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> References: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> Message-ID: <1562606096.20180521010206@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 20 May 2018 at 2:51:40 PM, in , Dirk Gottschalk via Gnupg-users wrote:- > I think the backwards compatiblity should be broken > to improve things. Backwards compatibility was already broken when support for old-style keys was dropped. - -- Best regards MFPA Act normal and the crowd will accept you. Act deranged and they will make you their leader. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWwIMi18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +kbJAQC0LoNl/BRkjw5j64djAI/nf5ACSXHgBrYgITWQ82E8xQEAyfdBkG1hSheZ qGNWPBW6UGvMurH63ToMLKZFk5rG0g6JApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWwIMi18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/6bAD/4ojk4qRSK8VWWmwvo3YDa8kckE fQc2rJl2WT+ff5J9yhFFtHKzGjADjurmKjKv7qnzTOdYROxYm4k4wt0ZJ8vbmf2L X5DvKol/Y2mxAHUINpu3DmiJyPGUU3cwW7Fh5S/syj/QYUhXrQwb3rFAm9wo+IAK ja8R5yDWAbKzOKGIVtD17Na7lwq4rH+GXoqakJO3ZfizrS16plfUOf00DSc04Jpg oiRiA1b8O3ngxP2ly+wpP1OHngNm8X4/T12GWv4IpngTRnAM5zajO99ym0X/mfKN HI8Xo/3xxU/i2j2ImNHJhRaXti41GV8fqXl+KbbCXIgTxyvwI/7Pvxm1S0lW+3qa A4g7WNDRlA3BW9cmk7VzOMdXOFhKqX6D+uHE+BHvOS1LAPkGwEVFb9kQi3sEfjTm 2h8VfuNOHzonxWCXk6zLrajxSnPf34rDBuHpqK56N/wY7tBM3do7QT+A5zzJYaJD wRlG9KYSajBj89wlDS0XIb6MSNaf6kQ+kfaHztvrK1lm0MpBjh3zE5VipR5UZgk/ O/j/dLBuB1dZzYvLd7kB2hUrAumf2QorhKWF74Gm9joFAqI2Kf930Gb06p8oVm++ 0lH53vkrR9JDx/wbLqRJPWbsr81Yk6s5kOubZ+oRanHo1KdLqj+jqdnSebEd6yHc 6BdR+GSh02rmrJ6Ovw== =XAW/ -----END PGP SIGNATURE----- From mick.crane at gmail.com Mon May 21 00:34:59 2018 From: mick.crane at gmail.com (mick crane) Date: Sun, 20 May 2018 23:34:59 +0100 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: <3f98f86e7ad18c49fcec2c8746102b02@gmail.com> On 2018-05-20 07:26, Robert J. Hansen wrote: > Writing just for myself -- not for GnuPG and not for Enigmail and > definitely not for my employer -- I put together a postmortem on Efail. > You may find it worth reading. You may also not. Your mileage will > probably vary. :) > > https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08 I do applause here because I needed to sign up or something to applaud on the link. mick -- Key ID 4BFEBB31 From mirimir at riseup.net Mon May 21 02:43:07 2018 From: mirimir at riseup.net (Mirimir) Date: Sun, 20 May 2018 13:43:07 -1100 Subject: A postmortem on Efail In-Reply-To: <20180520104436.GA11720@aleks-PC> References: <20180520104436.GA11720@aleks-PC> Message-ID: <1be06d81-1d81-0474-6f26-b32760fa82f4@riseup.net> On 05/19/2018 11:44 PM, Aleksandar Lazic wrote: > Hi Robert. > > On 20/05/2018 02:26, Robert J. Hansen wrote: >> Writing just for myself -- not for GnuPG and not for Enigmail and >> definitely not for my employer -- I put together a postmortem on Efail. >> You may find it worth reading. You may also not. Your mileage will >> probably vary. :) >> >> https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08 > > As a long time reader and partly gpg user I would like to thank you for > the post. > >>From my point of view must be something more behind the curtain. > > I do not want to create a conspiracy theory but it's wiggy that > EFF favors *NO* security ,pgp or s/mime, instead to fix the current > possibilities and promote signal. I read the EFF warning as a temporary measure, to prevent adversaries from sending cyphertext, and getting plaintext back. Until these exploits were blocked. And if necessary, to use Signal in the interim. From jeremy at turnkeylinux.org Mon May 21 02:51:41 2018 From: jeremy at turnkeylinux.org (Jeremy Davis) Date: Mon, 21 May 2018 10:51:41 +1000 Subject: =?UTF-8?Q?Break_backwards_compatibility_already:_it=e2=80=99s_time.?= =?UTF-8?Q?_Ignore_the_haters._I_trust_you.?= Message-ID: I just read the awesome article "Efail: A Postmortem" by Robert Hansen. Thanks for this Robert. Great work! As suggested by Robert, I've signed up to say: Break backwards compatibility already: it?s time. Ignore the haters. I trust you! :) Cheers, Jeremy From JSchuettler at gmx.de Mon May 21 03:12:45 2018 From: JSchuettler at gmx.de (=?UTF-8?Q?Jochen_Sch=c3=bcttler?=) Date: Mon, 21 May 2018 03:12:45 +0200 Subject: Break backwards compatibility Message-ID: <968cda26-39d5-6f0c-c771-e264ddd89f62@gmx.de> I'm all for breaking backwards compatibility. What's the worst the haters can do? Turn their back on GnuPG? Shout out really loud once more? I think they should get a life! From markr at signal100.com Mon May 21 05:07:46 2018 From: markr at signal100.com (Mark Rousell) Date: Mon, 21 May 2018 04:07:46 +0100 Subject: A postmortem on Efail In-Reply-To: References: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> <31decabb-2ae9-5fa2-9eaa-2ed0cb289f69@incenp.org> <5B01D06C.1090904@signal100.com> Message-ID: <5B023802.6090103@signal100.com> On 20/05/2018 21:32, Damien Goutte-Gattat via Gnupg-users wrote: > On 05/20/2018 08:45 PM, Mark Rousell wrote: >> I think it is important that they can still do this with a maintained >> (2.x.y) code base. > > Support for PGP 2 has already been dropped from the current stable > branch, I don't think it will ever be brought back. But the 1.4.x > branch *is* maintained, even if only for critical bugfixes. I think you mean that support for 2.0.y has been dropped, surely? When I wrote "2.x.y" above I meant that users should be able to continue decrypting legacy-encrypted data (albeit with a change of commands/options compared to the present) with whatever the currently-supported version of 2.something is at any point in the future. -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Mon May 21 05:19:32 2018 From: markr at signal100.com (Mark Rousell) Date: Mon, 21 May 2018 04:19:32 +0100 Subject: Break backwards compatibility In-Reply-To: <968cda26-39d5-6f0c-c771-e264ddd89f62@gmx.de> References: <968cda26-39d5-6f0c-c771-e264ddd89f62@gmx.de> Message-ID: <5B023AC4.20807@signal100.com> On 21/05/2018 02:12, Jochen Sch?ttler wrote: > I'm all for breaking backwards compatibility. > > What's the worst the haters can do? Turn their back on GnuPG? Shout out > really loud once more? I think they should get a life! I rather suspect they do have a life supporting scenarios that they cannot change that require legacy-decryption capability. If legacy-decryption was removed entirely from current versions of GnuPG then they would simply have to continue using old, unsupported, and potentially vulnerable versions. I do not think it is reasonable to just cut them off entirely. As Philipp Klaus Krause [1] and Dirk Gottschalk [2] pointed out above, breaking backward compatibility does not have to be (and should not be in my opinion) absolute. The ability to decrypt old, legacy-encrypted data is, like it or not, still present in the real world and it is therefore surely proper for GnuPG to retain the ability to decrypt such data in maintained code (albeit whilst requiring users to take action to make changes to their configuration to be able to continue decrypting such data using GnuPG). I agree with those who say that there is no need for mail clients to be able to decrypt legacy-encrypted data. [1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060473.html [2] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060474.html -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeandavid8 at verizon.net Mon May 21 05:14:37 2018 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Sun, 20 May 2018 23:14:37 -0400 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: References: Message-ID: On 05/20/2018 08:51 PM, Jeremy Davis wrote: > I just read the awesome article "Efail: A Postmortem" by Robert Hansen. > > Thanks for this Robert. Great work! > > As suggested by Robert, I've signed up to say: > > Break backwards compatibility already: it?s time. Ignore the haters. I > trust you! :) > One of the problems with Windows is that they preserved the backwards compatibility for far too long, so they could never clean it up enough to make it any good. I admit that Windows 7 is better than Windows XP that was much better than Windows 95. I wonder just how much complexity there is in my FiOS box to convert the fiber-optic to plain old telephone service that must still be compatible with my old rotary dial telephone that requires 90 volt 20 cycle power to ring the bell. And all my electronic telephones with electronic ringers that must be protected from that 90 volt ringing current. Can you imagine the redesign that would be required so I could start the gasoline engine in my Prius with a hand crank in the front? -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key:166D840A 0C610C8B Registered Machine 1935521. /( )\ Shrewsbury, New Jersey http://linuxcounter.net ^^-^^ 23:05:01 up 4 days, 6:55, 1 user, load average: 4.04, 4.05, 4.07 From JSchuettler at gmx.de Mon May 21 05:56:04 2018 From: JSchuettler at gmx.de (=?UTF-8?Q?Jochen_Sch=c3=bcttler?=) Date: Mon, 21 May 2018 05:56:04 +0200 Subject: Break backwards compatibility In-Reply-To: <5B023AC4.20807@signal100.com> References: <968cda26-39d5-6f0c-c771-e264ddd89f62@gmx.de> <5B023AC4.20807@signal100.com> Message-ID: And that is my opinion, too. Some people have the necessity to decrypt old data, so there should be a separate tool for them to do exactly that. It's the only way to start off fresh. But I believe many people shouting out against the developers really have no such reason. They are described very well with the word "hater" and can be disregarded. Am 21.05.2018 um 05:19 schrieb Mark Rousell: > On 21/05/2018 02:12, Jochen Sch?ttler wrote: >> I'm all for breaking backwards compatibility. >> >> What's the worst the haters can do? Turn their back on GnuPG? Shout out >> really loud once more? I think they should get a life! > I rather suspect they do have a life supporting scenarios that they > cannot change that require legacy-decryption capability. > > If legacy-decryption was removed entirely from current versions of GnuPG > then they would simply have to continue using old, unsupported, and > potentially vulnerable versions. I do not think it is reasonable to just > cut them off entirely. > > As Philipp Klaus Krause [1] and Dirk Gottschalk [2] pointed out above, > breaking backward compatibility does not have to be (and should not be > in my opinion) absolute. The ability to decrypt old, legacy-encrypted > data is, like it or not, still present in the real world and it is > therefore surely proper for GnuPG to retain the ability to decrypt such > data in maintained code (albeit whilst requiring users to take action to > make changes to their configuration to be able to continue decrypting > such data using GnuPG). > > I agree with those who say that there is no need for mail clients to be > able to decrypt legacy-encrypted data. > > > > > [1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060473.html > [2] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060474.html > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Mon May 21 07:20:33 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 21 May 2018 01:20:33 -0400 Subject: Breaking changes Message-ID: Here's my own set of suggestions for breaking changes to GnuPG: 1. End-of-life 1.4 already. Yes, it's the only option for PGP 2.6. Yes, it's the only option for old and out-of-date stuff. Yes, there will be people who need to decrypt this stuff. All of that is true, but *we* don't need to be the people who cater to their needs. At this point if you need pre-Web crypto (which, I remind people, is pretty much what PGP 2.6 is), you have a specialized need and you need to talk to someone about a custom solution. There are companies that specialize in this sort of thing (like, say, g10 Code). We should keep the 1.4 source code available, but wash our hands of it and say it will receive *no* future fixes, not even for security issues -- and we need to stand on that when people start screaming. Rationale: as long as we keep GnuPG 1.4 around and even semi-supported, people will insist on not upgrading. 2. End-of-life 2.0. 2.2 is the replacement branch for 2.0, and it's been around for ten months. Yes, some major distros have incorporated 2.0 into their long-term support releases. That's on them, *not* us. State, "we're going to continue to give security fixes to 2.0 but that will end December 31, 2018." Rationale: 2.3 will be coming out soon. I can understand supporting 2.2 and 2.3 simultaneously, but 2.0, 2.2, and 2.3 simultaneously seems like we're dropping 1.4 just to pick up another boat anchor. 3. In 2.3, make RFC4880bis04 the default. There's a lot of good stuff in bis04. Unfortunately, until the WG restarts there's little in the way of implementations of it. But it still exists, and it's the safest thing we've got so far, so let's make the cutover. Include an --rfc4880 option for interoperability with clients that aren't -bis04 compliant. Rationale: we may only get one chance to make serious breaking changes, so let's go big or go home. Let me make it clear: these changes are extreme. Some knowledgeable people will say they're too extreme. I disagree. Let's get all the breaking pain over at once, and put GnuPG on track for the future. And if defaulting to -bis04 puts pressure on other implementations to support it, and/or puts pressure on the WG to approve it, well -- I'm fine with that. From dgouttegattat at incenp.org Mon May 21 10:53:22 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 21 May 2018 09:53:22 +0100 Subject: Breaking changes In-Reply-To: References: Message-ID: <1bd5b37a-5445-ef71-5b4a-6c011a72ad97@incenp.org> On 05/21/2018 06:20 AM, Robert J. Hansen wrote: > 2. End-of-life 2.0. That one at least is already done. The 2.0 branch reached EOL with the 2.0.31 release on December 29, 2017. I believe Werner stated clearly enough that there will be *no* further point release on that branch, not even for critical security fixes. If a distro is currently shipping a 2.0.x version, backporting any such security fix will be left to the packagers/maintainers for that distro. The last release of the 2.0.x branch is not even listed anymore on gnupg.org's download page. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Mon May 21 10:54:46 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 21 May 2018 09:54:46 +0100 Subject: A postmortem on Efail In-Reply-To: <5B023802.6090103@signal100.com> References: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> <31decabb-2ae9-5fa2-9eaa-2ed0cb289f69@incenp.org> <5B01D06C.1090904@signal100.com> <5B023802.6090103@signal100.com> Message-ID: On 05/21/2018 04:07 AM, Mark Rousell wrote: > I think you mean that support for 2.0.y has been dropped, surely? No, I do mean that support for all PGP 2-related stuff has been dropped from the current stable branch. Modern GnuPG (? 2.1) can neither read nor write anything that has been generated by PGP 2.x. Compatibility starts with PGP 5, which dates back to 1997. > When I wrote "2.x.y" above I meant that users should be able > to continue decrypting legacy-encrypted data (albeit with a change of > commands/options compared to the present) with whatever the > currently-supported version of 2.something is at any point in the > future. Well, that's already not the case. If you have pre-1997 data, you need to use GnuPG 1.4, which again *is* still supported precisely for this use case. (You could also, in theory, use GnuPG 2.0.x, but *that* branch is explicitly no longer supported.) Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From mkesper at fsfe.org Mon May 21 09:53:49 2018 From: mkesper at fsfe.org (Michael Kesper) Date: Mon, 21 May 2018 09:53:49 +0200 Subject: Break backwards compatibility In-Reply-To: <5B023AC4.20807@signal100.com> References: <968cda26-39d5-6f0c-c771-e264ddd89f62@gmx.de> <5B023AC4.20807@signal100.com> Message-ID: <1526889229.29309.1.camel@fsfe.org> Hi all, Am Montag, den 21.05.2018, 04:19 +0100 schrieb Mark Rousell: > On 21/05/2018 02:12, Jochen Sch?ttler wrote: > > I'm all for breaking backwards compatibility. > > > > What's the worst the haters can do? Turn their back on GnuPG? Shout > > out > > really loud once more? I think they should get a life! > ? > I rather suspect they do have a life supporting scenarios that they > cannot change that require legacy-decryption capability. > > If legacy-decryption was removed entirely from current versions of > GnuPG then they would simply have to continue using old, unsupported, > and potentially vulnerable versions. I do not think it is reasonable > to just cut them off entirely. I think it might be best to put that functionality into a separate GnuPG version called gpg-legacy. Make it clear in all man pages of this tool, the --version and --help options that this only exists to decrypt existing but now obsolete encrypted material and that it can't be used to create such material anymore. > As Philipp Klaus Krause [1] and Dirk Gottschalk [2] pointed out > above, breaking backward compatibility does not have to be (and > should not be in my opinion) absolute. The ability to decrypt old, > legacy-encrypted data is, like it or not, still present in the real > world and it is therefore surely proper for GnuPG to retain the > ability to decrypt such data in maintained code (albeit whilst > requiring users to take action to make changes to their configuration > to be able to continue decrypting such data using GnuPG). > > I agree with those who say that there is no need for mail clients to > be able to decrypt legacy-encrypted data. Dirk Gottschalk wrote in https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060474.html > I think the backwards compatiblity should be broken to improve > things. > It would be possible to implement something like --legacy to re- > enable > the old functionality. This could also be implemented in email > clients > and plug-ins like enigmail as a checkbox. No! Everybody will just turn on that checkbox then and be none the wiser. Regarding breaking changes: Please study carefully the Python2 -> Python3 transition. By keeping Python2 for 10 long years supported after deprecation, only the haters became louder and louder, "Success" stories of leaving the Python eco system exploded. Would they have integrated a non-GIL switch into that breaking change, the work for normal Python projects would not have been greater but the reason to switch would have been. Just 2 cents of a long-term GnuPG (and Python) user Michael -- Michael Kesper Supporter of FSFE https://fsfe.org/about GPG Fingerprint: F035 8BD9 D0C2 0E6A 85B5??6A60 4208 05C6 8907 4FAD -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part URL: From m16+gnupg at monksofcool.net Mon May 21 11:46:57 2018 From: m16+gnupg at monksofcool.net (Ralph Seichter) Date: Mon, 21 May 2018 11:46:57 +0200 Subject: Breaking changes In-Reply-To: References: Message-ID: On 21.05.18 07:20, Robert J. Hansen wrote: > We should keep the 1.4 source code available, but wash our hands of it > and say it will receive *no* future fixes, not even for security > issues -- and we need to stand on that when people start screaming. I agree. In my experience, this stance--publicly documented--will allow people to say to their bosses "support has ended, and for security reasons we now need a budget to finance a move away from this outdated software". I have seen similar situations often enough; nobody would spend money as long as the old software horse was still twitching. Discontinue version 1.4 right away, quoting Efail as a trigger if you wish, and set an EOL for version 2.0 in a few months, as you suggested. > Let's get all the breaking pain over at once, and put GnuPG on track > for the future. People are going to be (temporarily) very annoyed anyway, so go all the way. Like Ferdinand von Schill said: "Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende." -Ralph From andrew.skretvedt at gmail.com Mon May 21 10:56:07 2018 From: andrew.skretvedt at gmail.com (Andrew Skretvedt) Date: Mon, 21 May 2018 08:56:07 +0000 Subject: =?UTF-8?Q?Break_backwards_compatibility_already:_it=e2=80=99s_time.?= =?UTF-8?Q?_Ignore_the_haters._I_trust_you.?= In-Reply-To: References: Message-ID: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> ?Break backwards compatibility already: it?s time. Ignore the haters. I trust you.? +1 Efail caused me to run across the criticism that Moxie Marlinespike wrote about GnuPG/OpenPGP in early 2015. https://moxie.org/blog/gpg-and-me/ It felt to me that without naming it, he'd focused on the email use case to the exclusion of others, missing those other niches Robert Hansen mentioned in his "Efail Postmortem". Reading the Postmortem, I recalled another article about how being "mediocre" can actually be a good thing. https://www.ribbonfarm.com/2018/04/24/survival-of-the-mediocre-mediocre/ Poor things die for being ill-suited to purpose, cutting-edge things are often brittle and fail spectacularly when the problem varies too far from the design considerations. OpenPGP has maybe been so begrudgingly successful all this time because it's been /mediocre/ enough to remain flexible to adapt to changes in cryptography and best practices and discoveries about insecurities we weren't aware of in the past. I think Efail has shown now that OpenPGP/GnuPG retains the flexibility to continue to adapt and maintain a well used and trusted standard for private and authenticated data and communications, but it won't achieve this if its evolution is frozen. It seems to me that if the pearl-clutchers who would howl too loudly about breaking backwards compatibility were as concerned as they claim, they would realize that software evolves. But this evolution doesn't eradicate its past. GnuPG is open software. It's ganoo-pee-gee! If you're a pearl-clutcher with a legacy use-case, perhaps it's time to really analyze that case. Do you have a darn good reason to want to expose yourself to creeping insecurity? Because its history won't be eradicated, if you /do/ have good reasons, you can maintain for yourself a legacy fork. To do that you may need to have certain skills or be willing to hire-out for them. I think that's fair. It's free as in freedom, not beer, not support. For my vote, I think persons so situated might have suddenly imposed upon the larger community long enough, now that Efail has taught us something we may not have fully appreciated about the present state of OpenPGP and the way it's been pipelined with other tools. I cannot accept that "Pretty Good Privacy" is at risk, through apathy and underfunding and WG failures, of becoming "Passivity Guaranteed Peril". Robert signed off: > Never forget that we?re on the same side, and the people on the other side include tyrants and murderers. Let?s stick together. Oh yes! From whatever corner you fear most a bogeyman might be lurking, one of the best ways to protect freedom and liberty is by ensuring that the general public always has a trustworthy cryptosystem at their disposal. Maybe it secures an oppressed group from a tyrant, maybe it authenticates a contract that existed after a dispute arises, maybe it's simply ensuring your new laptop isn't becoming co-opted to into making you an unwitting slave of cryptocoin pirates. These are all good reasons to register support. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4004 bytes Desc: S/MIME Cryptographic Signature URL: From ben at adversary.org Mon May 21 14:34:30 2018 From: ben at adversary.org (Ben McGinnes) Date: Mon, 21 May 2018 22:34:30 +1000 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: <20180521123430.vwfkpz4wsqpq5awn@adversary.org> On Sun, May 20, 2018 at 02:26:47AM -0400, Robert J. Hansen wrote: > Writing just for myself -- not for GnuPG and not for Enigmail and > definitely not for my employer -- I put together a postmortem on Efail. > You may find it worth reading. You may also not. Your mileage will > probably vary. :) > > https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08 Very nice article and it will be a useful one to forward to a number of people. I also liked ProtonMail's more technical one which addressed the specifics of their own setup and demonstrated that the allegations levelled their way were not well founded. On the other hand, they use OpenPGP.js very differently to most, if not all, of the other projects which have since adopted it and are acutely aware of the inherent weaknesses within JavaScript itself, so they don't drive their entire systems with it. I agree with most of the article and largely with the need to break compatibility to an ancient flawed design. Particularly since we still have a means of accessing those ancient formats if we have to in the form of the GPG 1.4 branch. The ancient archives are as safe as they've ever been (for whatever definition of "safe" is being implied by the user/archivist). There is, however, one aspect of this issue that you touched on lightly, but didn't really delve into and which is at the centre of my, mostly unvoiced (until this email), criticism of the Efail team. That being the *incredibly* unhelpful and likely actively harmful recommendation to remove encryption and decryption functionality from vulnerable MUAs. To say, ?we have this edge case scenario that really needs an active targeted attack on a case by case basis, so everyone should just stop integrating encryption? is the kind of thing that can get people killed. Indeed, this particular release may still succeed in producing a body count. I am not yet aware of any confirmed fatalities stemming from people panicking and stopping using crypto because they listened to Efail and/or the EFF, but there is one particular community I'm watching for just that issue right now. By comparison to that I don't really care so much that Efail dropped the ball with disclosure to GnuPG or any of the other projects. It's a bit annoying, but we can all cope. I *do*, however, care that their recommendations may have lasting and potential final consequences for OpenPGP users living with and attempting to mitigate real threats to their lives and/or liberty. Playing with that sort of thing with the recklessness with which the Efail team have done is, in my not so humble opinion, an absolute disgrace. You pointed out that the vast majority of OpenPGP use is no longer email or other communications encryption. This is both true and a valid point of discussion. Nevertheless, there are still a considerable number of people who do use it that way and a number of them have to deal with threat assessments with considerably higher levels of personal risk than security researchers in academia or cryptographic developers. We must not forget these people. Ever. Even if we never hear from them. Their cases are also not a matter of being apathetic; it's that their priorities are surviving the world they're in, so they need to rely on the tools we provide (and I get the community apathy issue is actually a more general thing, so this isn' having a go at that part). The Efail researchers did forget them and their conduct demonstrates this. While they may have made some useful technical contributions regarding S/MIME and highlighting certain poor implementations in MUAs, that's no justification for reckless disregard of the lives of end users. So in my opinion it's not the merits or lack thereof in the demonstrated attacks they released that have the gravest consequence here, it's that the number one recommended mitigation technique is to remove cryptographic functions from MUAs. Even though they still said to basically perform those functions manually and independently, which does imply not opposing using cryptography itself. It's still a recommendation which is sure to create far more dangerous outcomes for end users. It's a bit like that scene in Erik the Viking where a woman is being raped and Erik kills the rapist, but his sword goes right through the rapist and kills the woman too. He did stop the rape, but that doesn't make his action a successful one. I think it's fair to say that most, if not all, of those of us working with this tech are reasonably intelligent. So surely we can operate at a level with a bit more forethought than a viking, fictional or otherwise. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon May 21 14:51:17 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 21 May 2018 08:51:17 -0400 Subject: A postmortem on Efail In-Reply-To: <20180521123430.vwfkpz4wsqpq5awn@adversary.org> References: <20180521123430.vwfkpz4wsqpq5awn@adversary.org> Message-ID: > That being the *incredibly* unhelpful and likely actively harmful > recommendation to remove encryption and decryption functionality from > vulnerable MUAs. I blame the EFF for that more than I blame the Efail developers. I expect the people who develop new attacks to overstate their importance: it's not out of any intent to deceive, it's just that they're too close to the problem to have a clear perspective on the user impact. The EFF, though... But even then, I have some sympathy for their position. The EFF works with many different activists in many different countries running many different setups. They were in a difficult situation of needing to put out a press release that had useful recommendations for everyone, left no one out in the cold, while still not raising a panic. Let me be clear: I think the EFF behaved irresponsibly. But I can be sympathetic to their situation, too. It's not a one-or-the-other thing. And I'm going to remain quiet on this further until I have time to see the EFF's postmortem. > Indeed, this particular release may still succeed in producing a body > count. I am not yet aware of any confirmed fatalities stemming from > people panicking and stopping using crypto because they listened to > Efail and/or the EFF, but there is one particular community I'm > watching for just that issue right now. If I can help in any way, please let me know. > We must not forget these people. Ever. I entirely agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From e+gpg at kellett.im Mon May 21 15:06:14 2018 From: e+gpg at kellett.im (Ed Kellett) Date: Mon, 21 May 2018 14:06:14 +0100 Subject: =?UTF-8?Q?Break_backwards_compatibility_already:_it=e2=80=99s_time.?= =?UTF-8?Q?_Ignore_the_haters._I_trust_you.?= In-Reply-To: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> Message-ID: On 2018-05-21 09:56, Andrew Skretvedt wrote: > It seems to me that if the pearl-clutchers who would howl too loudly > about breaking backwards compatibility were as concerned as they claim, > they would realize that software evolves. But this evolution doesn't > eradicate its past. GnuPG is open software. It's ganoo-pee-gee! > > If you're a pearl-clutcher with a legacy use-case, perhaps it's time to > really analyze that case. Do you have a darn good reason to want to > expose yourself to creeping insecurity? Because its history won't be > eradicated, if you /do/ have good reasons, you can maintain for yourself > a legacy fork. To do that you may need to have certain skills or be > willing to hire-out for them. Maybe they just want to be able to read emails that they received a long time ago? I don't. I didn't start using OpenPGP long enough ago. But I think it's a bit unfair to call this "exposing yourself to creeping insecurity". It shouldn't ever be dangerous to *read an email* with an up-to-date email client, no matter what, because emails shouldn't be able to phone home. And the emails we're sending and receiving now aren't going to become more dangerous as time passes (though they could become less so, if a current vulnerability is mitigated by future client software). I guess what I'm trying to say here is that it's not decrypting old crypto that's wrong. It's accepting new emails with old crypto that is wrong. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Mon May 21 15:31:37 2018 From: ben at adversary.org (Ben McGinnes) Date: Mon, 21 May 2018 23:31:37 +1000 Subject: A postmortem on Efail In-Reply-To: <1be06d81-1d81-0474-6f26-b32760fa82f4@riseup.net> References: <20180520104436.GA11720@aleks-PC> <1be06d81-1d81-0474-6f26-b32760fa82f4@riseup.net> Message-ID: <20180521133137.rzv4lsadsfsga4my@adversary.org> On Sun, May 20, 2018 at 01:43:07PM -1100, Mirimir wrote: > On 05/19/2018 11:44 PM, Aleksandar Lazic wrote: >> >> I do not want to create a conspiracy theory but it's wiggy that >> EFF favors *NO* security ,pgp or s/mime, instead to fix the current >> possibilities and promote signal. > > I read the EFF warning as a temporary measure, to prevent > adversaries from sending cyphertext, and getting plaintext > back. Until these exploits were blocked. And if necessary, to use > Signal in the interim. I could have given them that benefit of the doubt on the initial article too, but the FAQ they now have on the Surveillance Self-Defense website does rather eviscerate any hope of that: https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions ?What if I keep getting PGP emails? You can decrypt these emails via the command line. If you prefer not to, notify your contacts that PGP is, for the time being, no longer safe to use in email clients and decide whether the conversation can continue over another end-to-end encrypted platform, such as Signal.? Because that couldn't possibly create a Chinese Whispers style situation of self-perpetuating FUD ? ? Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From mwood at iupui.edu Mon May 21 16:17:12 2018 From: mwood at iupui.edu (Mark H. Wood) Date: Mon, 21 May 2018 10:17:12 -0400 Subject: A postmortem on Efail In-Reply-To: References: Message-ID: <20180521141712.GA367@IUPUI.Edu> On Sun, May 20, 2018 at 07:23:17AM +0000, Dmitry Gudkov wrote: > I want to get involved and give a damn! [applause] > Break backwards compatibility already: it?s time. Ignore the haters. I > trust you. (I understand that that's a quote of a discussion-opener from the write-up.) I'd like to first see how many haters can be won over by selling the necessary changes. By "selling" I mean addressing the concerns of those who aren't convinced that they want something: o Why this is important *to you*, even though its importance was not immediately obvious. o What we have done, and are doing, to keep *your* cost down. o What else would we need to do, to make this something *you* want? -- 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 kr at glsys.de Mon May 21 16:56:40 2018 From: kr at glsys.de (=?utf-8?Q?Klaus_R=C3=B6mer?=) Date: Mon, 21 May 2018 16:56:40 +0200 Subject: efail is imho only a html rendering bug Message-ID: <0FFC25A6-3B08-4B00-A14E-8C678D241391@glsys.de> Internet works because we have standards. Rfc 3986 states that URLs have to be ecoded. Redering-Engies which send unencodes content including whitespaces and newlines to an external Server are seriously broken. (Only to point the finger at the real bug) Kind Regards, Klaus From rjh at sixdemonbag.org Mon May 21 19:11:16 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 21 May 2018 13:11:16 -0400 Subject: efail is imho only a html rendering bug In-Reply-To: <0FFC25A6-3B08-4B00-A14E-8C678D241391@glsys.de> References: <0FFC25A6-3B08-4B00-A14E-8C678D241391@glsys.de> Message-ID: <747ecd91b86c59750e7cca6c66de93c0@monkeyblade.net> > (Only to point the finger at the real bug) Efail is not just an HTML rendering bug. It includes very real attacks against S/MIME as it's used by thousands of corporations. It's true that the cryptanalytic attack on OpenPGP is pretty much nothing. But even then, there's room to argue whether GnuPG has made it too easy for email clients to do the wrong thing. Efail is not just an HTML rendering bug. The hype around it is awful, but there are good things in the paper and we should be careful not to wash our hands of it and say "nope, not our problem..." From ben at adversary.org Mon May 21 19:12:44 2018 From: ben at adversary.org (Ben McGinnes) Date: Tue, 22 May 2018 03:12:44 +1000 Subject: A postmortem on Efail In-Reply-To: References: <20180521123430.vwfkpz4wsqpq5awn@adversary.org> Message-ID: <20180521171244.zu45ztrcljnpkp6e@adversary.org> On Mon, May 21, 2018 at 08:51:17AM -0400, Robert J. Hansen wrote: >> That being the *incredibly* unhelpful and likely actively harmful >> recommendation to remove encryption and decryption functionality from >> vulnerable MUAs. > > I blame the EFF for that more than I blame the Efail developers. I > expect the people who develop new attacks to overstate their > importance: it's not out of any intent to deceive, it's just that > they're too close to the problem to have a clear perspective on the > user impact. That is a good point and a fairly common situation; possibly the second most common form of engineering blindness (the first one being having a favourite tool and applying it to every problem regardless of relevance ? when armed with one's favourite hammer, everything looks like a nail). > The EFF, though... Indeed ? > But even then, I have some sympathy for their position. The EFF > works with many different activists in many different countries > running many different setups. They were in a difficult situation > of needing to put out a press release that had useful > recommendations for everyone, left no one out in the cold, while > still not raising a panic. Had their publications been limited to the articles on the 13th and 14th, I could buy that. Unfortunately the updates to the SSD website on the 15th really strain things, especially the FAQ. Not only is it potentially panic-inducing, but they recommend an approach of having end users campaign against using OpenPGP at all with all of their contacts with no regard for what additional circumstances those contacts have. They've literally created a FUD-virus as a meme which will self-replicate throughout the web-of-trust. I'm sure we'll be encountering people advising others not to use OpenPGP long after the last of those affected MUAs are patched and *that* is stretching the edges of the term reckless (as it is usually used in legislation, e.g. reckless endangerment of life as opposed to, say, wilful endangerment of life). I also don't believe they can actually fix this now that they've created it without a complete reversal of their current position; which they can't do because of the MUAs which are affected and some users could be targeted. By the time the conditions are such that they can consistently give the ?all clear? on the matter, the FUD-virus will have spread too far and be too independent of them to stop (but will still gain credibility and traction by trading off their name and reputation). > Let me be clear: I think the EFF behaved irresponsibly. But I can > be sympathetic to their situation, too. It's not a one-or-the-other > thing. Sure; doing nothing and ignoring the affected MUAs does no one any good, but this response is likely to do more harm than the thing it's intended to stop and it didn't have to be that way. Not to mention the little matter that their sole recommendation of a viable alternative in all circumstances is a service which is entirely dependent on a centralised server (or network of servers). One which explicitly cannot be implemented in a federated manner and all attempts to fork it in order to do precisely that have been abandoned as a result of Moxie's opposition to them trying to connect to his network to communicate with Signal users. It's simply not a complete replacement in spite of EFF's wish that it is. It's a great addition to a suite of of services and tools, but relying on it as a replacement for OpenPGP is misguided (not to mention impossible for some people and/or networks and/or pseudonymity requirements). > And I'm going to remain quiet on this further until I have > time to see the EFF's postmortem. I won't going beyond the current statement describing it as reckless yet and I hope I don't have to. Perhaps they will be able to do some damage control in their own review. >> Indeed, this particular release may still succeed in producing a body >> count. I am not yet aware of any confirmed fatalities stemming from >> people panicking and stopping using crypto because they listened to >> Efail and/or the EFF, but there is one particular community I'm >> watching for just that issue right now. > > If I can help in any way, please let me know. Appreciated, but in this particular case it would probably be a crime for you to do so, at least directly to said group, whereas it's perfectly legal over here. It might depend a little on the interpretation of the First Amendment over there, though, and it is still possible that those laws are unconstitutional, but it's too early to know for sure yet and it doesn't look like there are too many organisations over there wanting to challenge it (yet). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From jrh29 at alumni.cwru.edu Mon May 21 18:25:24 2018 From: jrh29 at alumni.cwru.edu (Justin Hibbits) Date: Mon, 21 May 2018 11:25:24 -0500 Subject: Duplicate personal key in keyring Message-ID: Through some unknown series of events, I now have two copies of my personal gpg key in my keyring. I double-checked to see if GPG is seeing the same key in two keyrings (maybe reading a backup), but both keys are being read from the same keyring. This leads me to two questions: 1) How could this happen in the first place? 2) How can I fix this, short of generating a new key and revoking the existing key? I've tried backing up the keyring and deleting one copy, but it deleted both copies. I searched online for anyone else who had a similar issue, and came up empty, except for one person who was seeing the same key from two files. Any help is appreciated. As a last resort I could revoke the key and generate a new one, but I would like to avoid that if possible. Thanks, Justin Hibbits From mirimir at riseup.net Tue May 22 00:17:29 2018 From: mirimir at riseup.net (Mirimir) Date: Mon, 21 May 2018 11:17:29 -1100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> Message-ID: <3d1e8173-d8dc-f791-c8f9-b7aa226b31b9@riseup.net> On 05/21/2018 02:06 AM, Ed Kellett wrote: > Maybe they just want to be able to read emails that they received a long > time ago? So decrypt them all into a ramdisk, tar, and encrypt with GnuPG. Or put it on a backup box with LUKS. Or both. From mirimir at riseup.net Tue May 22 00:19:18 2018 From: mirimir at riseup.net (Mirimir) Date: Mon, 21 May 2018 11:19:18 -1100 Subject: A postmortem on Efail In-Reply-To: <20180521133137.rzv4lsadsfsga4my@adversary.org> References: <20180520104436.GA11720@aleks-PC> <1be06d81-1d81-0474-6f26-b32760fa82f4@riseup.net> <20180521133137.rzv4lsadsfsga4my@adversary.org> Message-ID: <1a07d378-8d91-4891-01ed-4caae011776c@riseup.net> On 05/21/2018 02:31 AM, Ben McGinnes wrote: > On Sun, May 20, 2018 at 01:43:07PM -1100, Mirimir wrote: >> On 05/19/2018 11:44 PM, Aleksandar Lazic wrote: >>> >>> I do not want to create a conspiracy theory but it's wiggy that >>> EFF favors *NO* security ,pgp or s/mime, instead to fix the current >>> possibilities and promote signal. >> >> I read the EFF warning as a temporary measure, to prevent >> adversaries from sending cyphertext, and getting plaintext >> back. Until these exploits were blocked. And if necessary, to use >> Signal in the interim. > > I could have given them that benefit of the doubt on the initial > article too, but the FAQ they now have on the Surveillance > Self-Defense website does rather eviscerate any hope of that: > > https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions > > ?What if I keep getting PGP emails? > > You can decrypt these emails via the command line. If you prefer not > to, notify your contacts that PGP is, for the time being, no longer > safe to use in email clients and decide whether the conversation can > continue over another end-to-end encrypted platform, such as Signal.? > > Because that couldn't possibly create a Chinese Whispers style > situation of self-perpetuating FUD ? ? > > > Regards, > Ben I hadn't seen that. Pretty stupid :( From dirk.gottschalk1980 at googlemail.com Tue May 22 02:15:25 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 22 May 2018 02:15:25 +0200 Subject: Duplicate personal key in keyring In-Reply-To: References: Message-ID: <400152479ec96cdfab7c9596f3d7822139b4cb02.camel@googlemail.com> Hello Justin. Am Montag, den 21.05.2018, 11:25 -0500 schrieb Justin Hibbits: > Through some unknown series of events, I now have two copies of my > personal gpg key in my keyring. I double-checked to see if GPG is > seeing the same key in two keyrings (maybe reading a backup), but > both > keys are being read from the same keyring. > This leads me to two questions: > 1) How could this happen in the first place? I had a similar problem a while ago. In my case the key database was corrupted. > 2) How can I fix this, short of generating a new key and revoking the > existing key? In my case I exported the public and the private keys of my own keys, then exported the complete public key ring, both ascii armored. Then I simply deleted the key database file(s) and re-imported the exports. GPG imports keys only once, so the duplicates should vanish when re- importing. > I've tried backing up the keyring and deleting one copy, but it > deleted both copies. I searched online for anyone else who had a > similar issue, and came up empty, except for one person who was > seeing the same key from two files. Did you make an ascii armored export, or what kind of Backup do you mean? Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From markr at signal100.com Tue May 22 02:28:24 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 01:28:24 +0100 Subject: A postmortem on Efail In-Reply-To: References: <4cbf829f9c4f7a1d629a3b56f9dda5a70be2b8d2.camel@googlemail.com> <31decabb-2ae9-5fa2-9eaa-2ed0cb289f69@incenp.org> <5B01D06C.1090904@signal100.com> <5B023802.6090103@signal100.com> Message-ID: <5B036428.8080401@signal100.com> On 21/05/2018 09:54, Damien Goutte-Gattat via Gnupg-users wrote: > On 05/21/2018 04:07 AM, Mark Rousell wrote: >> I think you mean that support for 2.0.y has been dropped, surely? > No, I do mean that support for all PGP 2-related stuff has been dropped > from the current stable branch. Modern GnuPG (? 2.1) can neither read > nor write anything that has been generated by PGP 2.x. Compatibility > starts with PGP 5, which dates back to 1997. Ah, gotcha. I was being careless over terminology. >> When I wrote "2.x.y" above I meant that users should be able >> to continue decrypting legacy-encrypted data (albeit with a change of >> commands/options compared to the present) with whatever the >> currently-supported version of 2.something is at any point in the >> future. > Well, that's already not the case. If you have pre-1997 data, you need > to use GnuPG 1.4, which again *is* still supported precisely for this > use case. (You could also, in theory, use GnuPG 2.0.x, but *that* branch > is explicitly no longer supported.) Thanks. This satisfies my preferences, that legacy-encrypted data can be decrypted with maintained code. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 02:29:38 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 01:29:38 +0100 Subject: A postmortem on Efail In-Reply-To: <20180521133137.rzv4lsadsfsga4my@adversary.org> References: <20180520104436.GA11720@aleks-PC> <1be06d81-1d81-0474-6f26-b32760fa82f4@riseup.net> <20180521133137.rzv4lsadsfsga4my@adversary.org> Message-ID: <5B036472.9080303@signal100.com> On 21/05/2018 14:31, Ben McGinnes wrote: > I could have given them that benefit of the doubt on the initial > article too, but the FAQ they now have on the Surveillance > Self-Defense website does rather eviscerate any hope of that: > > https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions > > ?What if I keep getting PGP emails? > > You can decrypt these emails via the command line. If you prefer not > to, notify your contacts that PGP is, for the time being, no longer > safe to use in email clients and decide whether the conversation can > continue over another end-to-end encrypted platform, such as Signal.? > > Because that couldn't possibly create a Chinese Whispers style > situation of self-perpetuating FUD ? ? Very foolish and very slanted indeed in a certain direction. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 02:42:07 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 01:42:07 +0100 Subject: A postmortem on Efail In-Reply-To: <20180521141712.GA367@IUPUI.Edu> References: <20180521141712.GA367@IUPUI.Edu> Message-ID: <5B03675F.7050004@signal100.com> On 21/05/2018 15:17, Mark H. Wood wrote: >> Break backwards compatibility already: it?s time. Ignore the haters. I >> trust you. > (I understand that that's a quote of a discussion-opener from the write-up.) > > I'd like to first see how many haters can be won over by selling the > necessary changes. > > By "selling" I mean addressing the concerns of those who aren't > convinced that they want something: > > o Why this is important *to you*, even though its importance was not > immediately obvious. To my mind it is at the outset counter-productive to refer to "haters". To use the term "haters" implies that anyone who does not share one's own view is somehow wrong and/or that their arguments can potentially be dismissed on the grounds or emotionalism rather than rationality. In practice, those like myself who recognise that the ability to decrypt legacy-encrypted data is a basic requirement for many users with archival needs do not "hate" anything. We just recognise that decryption of legacy-encrypted data is a real world requirement right now and will continue to be for many years, and so I think it is right and proper for this project to continue to support this activity with maintained software (albeit with a requirement for users to make some changes to support such activity). > o What we have done, and are doing, to keep *your* cost down. If the aim is to keep end-users' costs down then do not completely remove legacy features that are still needed in the real world. Decryption of legacy-encrypted data is one of those features, like it or not. > o What else would we need to do, to make this something *you* want? Go back in time and change history! What is now archived is archived and cannot be changed. Like it or not, it will need to be decrypted for a very long time to come. Ideally this should be achievable with maintained, current-version software. By all means, if that software needs to be a special-use, decrypt-only, program that is hardly ever updated except to patch code vulnerabilities then so be it. But do not throw your long-time users or their data under the bus for the sake of eliminating backwards compatibility. Stability and compatibility really do matter to many classes of users. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 02:50:49 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 01:50:49 +0100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> Message-ID: <5B036969.4060005@signal100.com> On 21/05/2018 14:06, Ed Kellett wrote: > I think it's > a bit unfair to call this "exposing yourself to creeping insecurity". It > shouldn't ever be dangerous to *read an email* with an up-to-date email > client, no matter what, because emails shouldn't be able to phone home. > And the emails we're sending and receiving now aren't going to become > more dangerous as time passes (though they could become less so, if a > current vulnerability is mitigated by future client software). > > I guess what I'm trying to say here is that it's not decrypting old > crypto that's wrong. It's accepting new emails with old crypto that is > wrong. > Well said (both paragraphs). What Andrew Skretvedt suggested is a clear example of what I earlier described[1] as "throw your long-time users or their data under the bus". It's not a reasonable option. [1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060512.html -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 03:04:08 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 02:04:08 +0100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> Message-ID: <5B036C88.90308@signal100.com> On 21/05/2018 09:56, Andrew Skretvedt wrote: > I think Efail has shown now that OpenPGP/GnuPG retains the flexibility > to continue to adapt and maintain a well used and trusted standard for > private and authenticated data and communications, but it won't > achieve this if its evolution is frozen. I agree. But remember that retaining the ability to decrypt legacy-encrypted data (i.e. continuing to support long-time users) does not require the GnuPG's evolution be frozen. > It seems to me that if the pearl-clutchers who would howl too loudly > about breaking backwards compatibility were as concerned as they > claim, they would realize that software evolves. But this evolution > doesn't eradicate its past. GnuPG is open software. It's ganoo-pee-gee! > > If you're a pearl-clutcher with a legacy use-case, perhaps it's time > to really analyze that case. Do you have a darn good reason to want to > expose yourself to creeping insecurity? Because its history won't be > eradicated, if you /do/ have good reasons, you can maintain for > yourself a legacy fork. To do that you may need to have certain skills > or be willing to hire-out for them. > > I think that's fair. It's free as in freedom, not beer, not support. > For my vote, I think persons so situated might have suddenly imposed > upon the larger community long enough, now that Efail has taught us > something we may not have fully appreciated about the present state of > OpenPGP and the way it's been pipelined with other tools. Your point is not helped by using patronising and condescending language like "pearl-clutcher". What you are attempting to belittle and dismiss here is surely a perfectly valid use case: That is accessing archived data. Sure, I can see that it is not a use case that you like or that matters to you but that doesn't make it any less of a valid use case right now, today, and in the future in the real world. This is not a "legacy use-case" as you chose to name it. The fact that the data is encrypted using legacy encryption doesn't make it a "legacy use-case". There is no "creeping insecurity" whatsoever in continuing to access archival data but there would be something of an eventual creeping insecurity if users in this position were required to use unmaintained software versions. So, no, it is not fair to throw these long-time users under the bus, as you propose. No, it is utterly unreasonable to propose that they maintain their own "legacy fork". Such users have not "imposed upon the larger community": They are _part_ of the larger community. As I have said in other messages, it is entirely reasonable to expect them to make some changes (although remember that re-encrypting the data is not an option) in terms of using new versions of maintained software to be able to continue decrypting the archived data but to just cut them off such that they have to use unmaintained software is not what one should have to expect. It would be reckless. And, as I say, continuing to support present day archival use cases does not mean that the main body of GnuPG cannot move on. It most certainly can continue to evolve and should do so. But those people who have to handle legacy-encrypted data are not legacy users. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 03:06:21 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 02:06:21 +0100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: <3d1e8173-d8dc-f791-c8f9-b7aa226b31b9@riseup.net> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> <3d1e8173-d8dc-f791-c8f9-b7aa226b31b9@riseup.net> Message-ID: <5B036D0D.4030808@signal100.com> On 21/05/2018 23:17, Mirimir wrote: > On 05/21/2018 02:06 AM, Ed Kellett wrote: > > > >> Maybe they just want to be able to read emails that they received a long >> time ago? > So decrypt them all into a ramdisk, tar, and encrypt with GnuPG. Or put > it on a backup box with LUKS. Or both. You are proposing to alter archival data. That's not an option. If you change it then you've changed the archive then it is no longer an accurate archive. -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 03:19:37 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 02:19:37 +0100 Subject: A postmortem on Efail In-Reply-To: <20180521123430.vwfkpz4wsqpq5awn@adversary.org> References: <20180521123430.vwfkpz4wsqpq5awn@adversary.org> Message-ID: <5B037029.8080401@signal100.com> On 21/05/2018 13:34, Ben McGinnes wrote: > I agree with most of the article and largely with the need to break > compatibility to an ancient flawed design. Particularly since we > still have a means of accessing those ancient formats if we have to in > the form of the GPG 1.4 branch. The ancient archives are as safe as > they've ever been (for whatever definition of "safe" is being implied > by the user/archivist). Indeed, this satisfies my archive retrieval concerns. > There is, however, one aspect of this issue that you touched on > lightly, but didn't really delve into and which is at the centre of > my, mostly unvoiced (until this email), criticism of the Efail team. > That being the *incredibly* unhelpful and likely actively harmful > recommendation to remove encryption and decryption functionality from > vulnerable MUAs. > > To say, ?we have this edge case scenario that really needs an active > targeted attack on a case by case basis, so everyone should just stop > integrating encryption? is the kind of thing that can get people > killed. This has been commented on by a few people on this list, myself included: [1] To my mind, it reeks of slanted propaganda for Signal, and there does seem to be a lot of it around at the moment. Signal has security benefits but it's not (yet?) a replacement for encrypted email, whereas a number of commentators seem to treat it as if all email, encrypted or not, should be deprecated in favour of Signal. This is not sensible or good advice without considering individual use cases (regardless of Efail). > I *do*, however, care that their > recommendations may have lasting and potential final consequences for > OpenPGP users living with and attempting to mitigate real threats to > their lives and/or liberty. > > Playing with that sort of thing with the recklessness with which the > Efail team have done is, in my not so humble opinion, an absolute > disgrace. > > You pointed out that the vast majority of OpenPGP use is no longer > email or other communications encryption. This is both true and a > valid point of discussion. Nevertheless, there are still a > considerable number of people who do use it that way and a number of > them have to deal with threat assessments with considerably higher > levels of personal risk than security researchers in academia or > cryptographic developers. > > We must not forget these people. Ever. Even if we never hear from > them. Their cases are also not a matter of being apathetic; it's that > their priorities are surviving the world they're in, so they need to > rely on the tools we provide (and I get the community apathy issue is > actually a more general thing, so this isn' having a go at that part). > > The Efail researchers did forget them and their conduct demonstrates > this. While they may have made some useful technical contributions > regarding S/MIME and highlighting certain poor implementations in > MUAs, that's no justification for reckless disregard of the lives of > end users. Well said. > So in my opinion it's not the merits or lack thereof in the > demonstrated attacks they released that have the gravest consequence > here, it's that the number one recommended mitigation technique is to > remove cryptographic functions from MUAs. Without wanting to sound like a conspiracy geek, removing encryption from email would, of course, benefit Signal and its takeup. [1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060450.html -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mirimir at riseup.net Tue May 22 03:41:14 2018 From: mirimir at riseup.net (Mirimir) Date: Mon, 21 May 2018 14:41:14 -1100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> Message-ID: On 05/21/2018 02:06 AM, Ed Kellett wrote: > On 2018-05-21 09:56, Andrew Skretvedt wrote: >> It seems to me that if the pearl-clutchers who would howl too loudly >> about breaking backwards compatibility were as concerned as they claim, >> they would realize that software evolves. But this evolution doesn't >> eradicate its past. GnuPG is open software. It's ganoo-pee-gee! >> >> If you're a pearl-clutcher with a legacy use-case, perhaps it's time to >> really analyze that case. Do you have a darn good reason to want to >> expose yourself to creeping insecurity? Because its history won't be >> eradicated, if you /do/ have good reasons, you can maintain for yourself >> a legacy fork. To do that you may need to have certain skills or be >> willing to hire-out for them. > > Maybe they just want to be able to read emails that they received a long > time ago? > > I don't. I didn't start using OpenPGP long enough ago. But I think it's > a bit unfair to call this "exposing yourself to creeping insecurity". It > shouldn't ever be dangerous to *read an email* with an up-to-date email > client, no matter what, because emails shouldn't be able to phone home. > And the emails we're sending and receiving now aren't going to become > more dangerous as time passes (though they could become less so, if a > current vulnerability is mitigated by future client software). The problem is that many users of up-to-date email clients seem to want HTML with remote content. That allows Efail, but only if OpenPGP does not hard fail for unauthenticated cyphertext. And that typically breaks decryption of cyphertext created by old software, which didn't require authentication by default. > I guess what I'm trying to say here is that it's not decrypting old > crypto that's wrong. It's accepting new emails with old crypto that is > wrong. Yes, "accepting new emails with old crypto" is the problem. But Efail relies on cyphertext embedded in URLs, which won't unauthenticate. Anyway, the solution is arguably making decryption of iffy cyphertext an option that must be explicitly selected. Not the default. From markr at signal100.com Tue May 22 03:22:27 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 02:22:27 +0100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: References: Message-ID: <5B0370D3.1060606@signal100.com> On 21/05/2018 04:14, Jean-David Beyer wrote: > On 05/20/2018 08:51 PM, Jeremy Davis wrote: >> I just read the awesome article "Efail: A Postmortem" by Robert Hansen. >> >> Thanks for this Robert. Great work! >> >> As suggested by Robert, I've signed up to say: >> >> Break backwards compatibility already: it?s time. Ignore the haters. I >> trust you! :) >> > One of the problems with Windows is that they preserved the backwards > compatibility for far too long, so they could never clean it up enough > to make it any good. I admit that Windows 7 is better than Windows XP > that was much better than Windows 95. Different mindsets. You call it a problem but from the perspective of a great many Windows users, backwards compatibility (i.e. stability) is a key feature, not a bug. However, GnuPG clearly can make backwards-incompatible progress without dropping all maintained support for legacy decryption. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 03:24:28 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 02:24:28 +0100 Subject: Break backwards compatibility In-Reply-To: References: <968cda26-39d5-6f0c-c771-e264ddd89f62@gmx.de> <5B023AC4.20807@signal100.com> Message-ID: <5B03714C.2030107@signal100.com> On 21/05/2018 04:56, Jochen Sch?ttler wrote: > Some people have the necessity to decrypt old data, so there should be a > separate tool for them to do exactly that. It's the only way to start > off fresh. Agreed. And I think that GnuPG 1.x provides this tool, doesn't it. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 03:25:44 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 02:25:44 +0100 Subject: Break backwards compatibility In-Reply-To: <1526889229.29309.1.camel@fsfe.org> References: <968cda26-39d5-6f0c-c771-e264ddd89f62@gmx.de> <5B023AC4.20807@signal100.com> <1526889229.29309.1.camel@fsfe.org> Message-ID: <5B037198.5080509@signal100.com> On 21/05/2018 08:53, Michael Kesper wrote: > I think it might be best to put that functionality into a separate > GnuPG version called gpg-legacy. > Make it clear in all man pages of this tool, the --version and --help > options that this only exists to decrypt existing but now obsolete > encrypted material and that it can't be used to create such material > anymore. Seems reasonable to me, although does GnuPG 1.x already effectively fulfil that role? -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From mirimir at riseup.net Tue May 22 03:47:31 2018 From: mirimir at riseup.net (Mirimir) Date: Mon, 21 May 2018 14:47:31 -1100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: <5B036D0D.4030808@signal100.com> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> <3d1e8173-d8dc-f791-c8f9-b7aa226b31b9@riseup.net> <5B036D0D.4030808@signal100.com> Message-ID: <638db831-d61b-b4f8-6430-6fe72f05b395@riseup.net> On 05/21/2018 02:06 PM, Mark Rousell wrote: > On 21/05/2018 23:17, Mirimir wrote: >> On 05/21/2018 02:06 AM, Ed Kellett wrote: >> >> >> >>> Maybe they just want to be able to read emails that they received a long >>> time ago? >> So decrypt them all into a ramdisk, tar, and encrypt with GnuPG. Or put >> it on a backup box with LUKS. Or both. > > You are proposing to alter archival data. That's not an option. If you > change it then you've changed the archive then it is no longer an > accurate archive. Well, there are all sorts of archives, I guess. But OK. The point here is not to expect that you can open such archives in an email client with Internet access, which is also receiving new email. Because that makes it vulnerable to Efail and follow-ons. So put the archives in an air-gapped machine, with a suitably tweaked email client to access them. From mirimir at riseup.net Tue May 22 03:53:46 2018 From: mirimir at riseup.net (Mirimir) Date: Mon, 21 May 2018 14:53:46 -1100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> Message-ID: <1939b843-adea-7afe-0737-57cbef723817@riseup.net> On 05/21/2018 02:41 PM, Mirimir wrote: > Yes, "accepting new emails with old crypto" is the problem. But Efail > relies on cyphertext embedded in URLs, which won't unauthenticate. Damn copypasta :( Please make that: > Yes, "accepting new emails with old crypto" is the problem. But Efail > relies on cyphertext embedded in URLs, which won't authenticate. From markr at signal100.com Tue May 22 03:39:27 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 02:39:27 +0100 Subject: Breaking changes In-Reply-To: References: Message-ID: <5B0374CF.9000608@signal100.com> On 21/05/2018 06:20, Robert J. Hansen wrote: > Here's my own set of suggestions for breaking changes to GnuPG: > > 1. End-of-life 1.4 already. > > Yes, it's the only option for PGP 2.6. Yes, it's the only option for > old and out-of-date stuff. Yes, there will be people who need to > decrypt this stuff. All of that is true, but *we* don't need to be the > people who cater to their needs. Get real. These people are long-time GnuPG users and now you want to throw them under the bus because... well, because you prefer it that way. No, that's not a fair, it's not reasonable, it's not ethical, or it's even professional. > At this point if you need pre-Web > crypto (which, I remind people, is pretty much what PGP 2.6 is), you > have a specialized need and you need to talk to someone about a custom > solution. Err... the specialised solution surely is GnuPG 1.4. > There are companies that specialize in this sort of thing > (like, say, g10 Code). So you are saying that long-time users should be deprived of an open source ongoing-maintained solution to their entirely valid present day use case to benefit a private company. Isn't that effectively equivalent to commercial sponsors taking previously open source code base private? It's hardly a popular move when it happens. Yes, I know that the scenario you are proposing is not /exactly/ the same but people will, quite understandably, treat it as such. > We should keep the 1.4 source code available, but wash our hands of it > and say it will receive *no* future fixes, not even for security issues > -- and we need to stand on that when people start screaming. Surely if you can recognise that people will start screaming then you must also understand that it is entirely the wrong thing to do. > Rationale: as long as we keep GnuPG 1.4 around and even semi-supported, > people will insist on not upgrading. If you drop maintenance of code that can handle the data that some people need to cope with then they will naturally have to stay with old, unmaintained code anyway. So dropping maintenance of 1.x will only cause a problem in this respect, not cure on. If you are (understandably) concerned about people still use 1.4 for encryption of new data then the sensible choice is surely to do what people have suggested in this thread: That is to produce a decryption-only maintained version that still allows users who need to access archived legacy-encrypted data to do so. Clearly you are concerned with preventing people using legacy encryption for new data and I agree with this concern. But there is no need to throw present day, long-time users who must handle legacy-encrypted data under the bus to do so. -- Mark Rousell PGP public key: http://www.signal100.com/markr/pgp Key ID: C9C5C162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 03:42:45 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 02:42:45 +0100 Subject: Breaking changes In-Reply-To: References: Message-ID: <5B037595.2070607@signal100.com> On 21/05/2018 10:46, Ralph Seichter wrote: > On 21.05.18 07:20, Robert J. Hansen wrote: > >> We should keep the 1.4 source code available, but wash our hands of it >> and say it will receive *no* future fixes, not even for security >> issues -- and we need to stand on that when people start screaming. > I agree. In my experience, this stance--publicly documented--will allow > people to say to their bosses "support has ended, and for security > reasons we now need a budget to finance a move away from this outdated > software". I have seen similar situations often enough; nobody would > spend money as long as the old software horse was still twitching. > > Discontinue version 1.4 right away, quoting Efail as a trigger if you > wish, and set an EOL for version 2.0 in a few months, as you suggested. It's not that simple. There are more use cases to take into account. Whilst what you say is true for people still encrypting new data with 1.4 (and I agree that they should be prevented from doing so), there are other people (perhaps even more people) who have a legitimate need to access historical/archival encrypted data. Preventing users from encrypting new data using legacy encryption does NOT need to mean that other users have to be prevented from (quite legitimately) accessing archived data using legacy encryption with maintained software. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 03:46:21 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 02:46:21 +0100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: <638db831-d61b-b4f8-6430-6fe72f05b395@riseup.net> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> <3d1e8173-d8dc-f791-c8f9-b7aa226b31b9@riseup.net> <5B036D0D.4030808@signal100.com> <638db831-d61b-b4f8-6430-6fe72f05b395@riseup.net> Message-ID: <5B03766D.6010203@signal100.com> On 22/05/2018 02:47, Mirimir wrote: > > But OK. The point here is not to expect that you can open such archives > in an email client with Internet access, which is also receiving new > email. Because that makes it vulnerable to Efail and follow-ons. I agree. > So put > the archives in an air-gapped machine, with a suitably tweaked email > client to access them. Not all archived and encrypted data is emails. There can be all sorts of things. It doesn't really matter what and it's not up to us to tell people what their system architecture should be. As long as they have access to maintained software to access (i.e. decrypt only) this old data (and this project is definitely the best source of such maintained software) then that is enough to satisfy what I perceive as critical requirements for many types of user in this category. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Tue May 22 03:57:54 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 02:57:54 +0100 Subject: Breaking changes In-Reply-To: <5B0374CF.9000608@signal100.com> References: <5B0374CF.9000608@signal100.com> Message-ID: <5B037922.9080804@signal100.com> On 22/05/2018 02:39, Mark Rousell wrote: > Get real. These people are long-time GnuPG users and now you want to > throw them under the bus because... well, because you prefer it that > way. No, that's not a fair, it's not reasonable, it's not ethical, or > it's even professional. [etc etc] On re-reading the above message, I apologise if the language I used was provocative. However, the points I made are nevertheless valid in my opinion. Proposing cutting off maintenance of the only maintained route to decrypt certain data is provocative, of course. ;-) As I observed, it is not necessary to cut off maintained ability to decrypt historical data (surely a valid real world use case) in order to prevent users from encrypting new data with legacy standards. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From mirimir at riseup.net Tue May 22 04:34:40 2018 From: mirimir at riseup.net (Mirimir) Date: Mon, 21 May 2018 15:34:40 -1100 Subject: Breaking changes In-Reply-To: <5B037922.9080804@signal100.com> References: <5B0374CF.9000608@signal100.com> <5B037922.9080804@signal100.com> Message-ID: <5fcc1324-710f-5b56-d522-b37ca8f6e213@riseup.net> On 05/21/2018 02:57 PM, Mark Rousell wrote: > On 22/05/2018 02:39, Mark Rousell wrote: >> Get real. These people are long-time GnuPG users and now you want to >> throw them under the bus because... well, because you prefer it that >> way. No, that's not a fair, it's not reasonable, it's not ethical, or >> it's even professional. [etc etc] > > On re-reading the above message, I apologise if the language I used was > provocative. However, the points I made are nevertheless valid in my > opinion. Hey :) > Proposing cutting off maintenance of the only maintained route to > decrypt certain data is provocative, of course. ;-) As I observed, it is > not necessary to cut off maintained ability to decrypt historical data > (surely a valid real world use case) in order to prevent users from > encrypting new data with legacy standards. So is there anything that gpg v2.2 won't decrypt with the option "--ignore-mdc-error" specified? Or perhaps, with also other "Doing things one usually doesn't want to do." options? That is, are older versions really necessary? From raubvogel at gmail.com Tue May 22 03:16:37 2018 From: raubvogel at gmail.com (Mauricio Tavares) Date: Mon, 21 May 2018 21:16:37 -0400 Subject: =?UTF-8?Q?Re=3A_Break_backwards_compatibility_already=3A_it=E2=80=99s_ti?= =?UTF-8?Q?me=2E_Ignore_the_haters=2E_I_trust_you=2E?= In-Reply-To: <5B036C88.90308@signal100.com> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> <5B036C88.90308@signal100.com> Message-ID: On Mon, May 21, 2018 at 9:04 PM, Mark Rousell wrote: > On 21/05/2018 09:56, Andrew Skretvedt wrote: > > I think Efail has shown now that OpenPGP/GnuPG retains the flexibility to > continue to adapt and maintain a well used and trusted standard for private > and authenticated data and communications, but it won't achieve this if its > evolution is frozen. > > > I agree. But remember that retaining the ability to decrypt legacy-encrypted > data (i.e. continuing to support long-time users) does not require the > GnuPG's evolution be frozen. > > It seems to me that if the pearl-clutchers who would howl too loudly about > breaking backwards compatibility were as concerned as they claim, they would > realize that software evolves. But this evolution doesn't eradicate its > past. GnuPG is open software. It's ganoo-pee-gee! > > If you're a pearl-clutcher with a legacy use-case, perhaps it's time to > really analyze that case. Do you have a darn good reason to want to expose > yourself to creeping insecurity? Because its history won't be eradicated, if > you /do/ have good reasons, you can maintain for yourself a legacy fork. To > do that you may need to have certain skills or be willing to hire-out for > them. > > I think that's fair. It's free as in freedom, not beer, not support. For my > vote, I think persons so situated might have suddenly imposed upon the > larger community long enough, now that Efail has taught us something we may > not have fully appreciated about the present state of OpenPGP and the way > it's been pipelined with other tools. > > > Your point is not helped by using patronising and condescending language > like "pearl-clutcher". What you are attempting to belittle and dismiss here > is surely a perfectly valid use case: That is accessing archived data. > > Sure, I can see that it is not a use case that you like or that matters to > you but that doesn't make it any less of a valid use case right now, today, > and in the future in the real world. This is not a "legacy use-case" as you > chose to name it. The fact that the data is encrypted using legacy > encryption doesn't make it a "legacy use-case". > > There is no "creeping insecurity" whatsoever in continuing to access > archival data but there would be something of an eventual creeping > insecurity if users in this position were required to use unmaintained > software versions. > > So, no, it is not fair to throw these long-time users under the bus, as you > propose. No, it is utterly unreasonable to propose that they maintain their > own "legacy fork". Such users have not "imposed upon the larger community": > They are part of the larger community. > > As I have said in other messages, it is entirely reasonable to expect them > to make some changes (although remember that re-encrypting the data is not > an option) in terms of using new versions of maintained software to be able > to continue decrypting the archived data but to just cut them off such that > they have to use unmaintained software is not what one should have to > expect. It would be reckless. > > And, as I say, continuing to support present day archival use cases does not > mean that the main body of GnuPG cannot move on. It most certainly can > continue to evolve and should do so. But those people who have to handle > legacy-encrypted data are not legacy users. > Stupid question: what is wrong with a "encrypt/decrypt old format" flag/config option? If I have the need to use old stuff, I can turn that on. All I see here is a "do not open old stuff" as a default setting which should solve most issues. > -- > Mark Rousell > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From markr at signal100.com Tue May 22 04:38:23 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 22 May 2018 03:38:23 +0100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> <5B036C88.90308@signal100.com> Message-ID: <5B03829F.9000909@signal100.com> On 22/05/2018 02:16, Mauricio Tavares wrote: > Stupid question: what is wrong with a "encrypt/decrypt old > format" flag/config option? If I have the need to use old stuff, I can > turn that on. All I see here is a "do not open old stuff" as a default > setting which should solve most issues. There would be nothing wrong with that whatsoever from the perspective of users who need to access old encrypted data (e.g. archival access purposes), which is the particular use case I have been pointing out. However, I don't think this would satisfy those who want to ensure that users cannot encrypt /new/ data with legacy standards. In order to prevent users from doing this (which, to be clear, is something I agree with) there needs to be some way to make it difficult or impossible to encrypt new data with legacy standards /whilst allowing decryption of legacy-encrypted data so as not to cut off long-time users with a legitimate present day use case/. If it is ultimately considered to be absolutely necessary to prevent new data being encrypted with old standards then personally I'd like to see a decryption-only program that would allow use cases involving access to legacy-encrypted data to continue unmolested with maintained software whilst allowing new data to be encrypted only with software versions that have dropped backward compatibility. In large part it seems to me that there is the usual (in discussions like this) lack of recognition of the many and varied use cases that software like GnuPG can be and is put to. Calls for *all* backwards compatibility to be end-of-lifed do not take into account the fact that backward compatibility in terms of decryption capability are still valid use cases in the present day and should rightly and properly be supported with maintained software. I agree that preventing new data encryption with legacy standards is desirable. Just don't throw other users (who need to decrypt old standards and old data with currently maintained software) under the bus to get to that state. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From mirimir at riseup.net Tue May 22 05:14:43 2018 From: mirimir at riseup.net (Mirimir) Date: Mon, 21 May 2018 16:14:43 -1100 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: <5B03829F.9000909@signal100.com> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> <5B036C88.90308@signal100.com> <5B03829F.9000909@signal100.com> Message-ID: <9204fead-aa77-5dda-6d4a-9dfe91f4df5e@riseup.net> On 05/21/2018 03:38 PM, Mark Rousell wrote: > On 22/05/2018 02:16, Mauricio Tavares wrote: >> Stupid question: what is wrong with a "encrypt/decrypt old >> format" flag/config option? If I have the need to use old stuff, I can >> turn that on. All I see here is a "do not open old stuff" as a default >> setting which should solve most issues. > > There would be nothing wrong with that whatsoever from the perspective > of users who need to access old encrypted data (e.g. archival access > purposes), which is the particular use case I have been pointing out. As I read the manual for gpg v2.2, that seems possible. The hard part, of course, is knowing what options to set. Perhaps there could be a FAQ. > However, I don't think this would satisfy those who want to ensure that > users cannot encrypt /new/ data with legacy standards. In order to > prevent users from doing this (which, to be clear, is something I agree > with) there needs to be some way to make it difficult or impossible to > encrypt new data with legacy standards /whilst allowing decryption of > legacy-encrypted data so as not to cut off long-time users with a > legitimate present day use case/. Again, as I read the manual, one can set all sorts of horrible options for encryption. Some have been deprecated, though. What I don't know is whether ancient PGP default behavior can be forced in gpg v2.2. I hope not. But even if so, it'd take considerable understanding. > If it is ultimately considered to be absolutely necessary to prevent new > data being encrypted with old standards then personally I'd like to see > a decryption-only program that would allow use cases involving access to > legacy-encrypted data to continue unmolested with maintained software > whilst allowing new data to be encrypted only with software versions > that have dropped backward compatibility. I tend to agree. But who would create and maintain that? > In large part it seems to me that there is the usual (in discussions > like this) lack of recognition of the many and varied use cases that > software like GnuPG can be and is put to. Calls for *all* backwards > compatibility to be end-of-lifed do not take into account the fact that > backward compatibility in terms of decryption capability are still valid > use cases in the present day and should rightly and properly be > supported with maintained software. Again, I don't think that's part of the plan. But I'm no expert. > I agree that preventing new data encryption with legacy standards is > desirable. Just don't throw other users (who need to decrypt old > standards and old data with currently maintained software) under the bus > to get to that state. I totally agree. From vedaal at nym.hush.com Tue May 22 06:31:17 2018 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 22 May 2018 00:31:17 -0400 Subject: =?UTF-8?B?UmU6IEJyZWFrIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGFscmVhZHk6IGl04oCZcyB0aW1lLiBJZ25vcmUgdGhlIGhhdGVycy4gSSB0cnVzdCB5b3Uu?= Message-ID: <20180522043117.AD1ADA013D@smtp.hushmail.com> On 22/05/2018 02:16, Mauricio Tavares wrote: Stupid question: what is wrong with a "encrypt/decrypt old format" flag/config option? If I have the need to use old stuff, I can turn that on. All I see here is a "do not open old stuff" as a default setting which should solve most issues. ... There would be nothing wrong with that whatsoever from the perspective of users who need to access old encrypted data (e.g. archival access purposes), which is the particular use case I have been pointing out. However, I don't think this would satisfy those who want to ensure that users cannot encrypt new data with legacy standards. In order to prevent users from doing this (which, to be clear, is something I agree with) there needs to be some way to make it difficult or impossible ===== There is a simple solution that would satisfy everybody ;-) Keep an 'old' edition of GnuPG 1.4x for anyone who needs to decrypt 'old data', (or encrypt new data the 'old' way ...). As one of the original die-hard pgp2.x users who still uses pgp (Disastry's 2.6.3 multi), I can comfortably say, that 2.x diehard users still use 2.x among themselves, and don't care about GnuPG. The real issue is, that it's not easy to compile 2.x on newer systems, and people who have migrated to GnuPG on some remailer groups, still want to use their v3 keys, and need encrypting capability, which again would be solved by letting them use an 'old' version of 1.4.x, and as long as these versions are still being archived (which is reasonable for the forseeable future), they should have no problems. So, to put in a vote for RJH, ?Break backwards compatibility already: it?s time. Ignore the haters. I trust you.? vedaal From bartbutler at protonmail.ch Mon May 21 21:05:39 2018 From: bartbutler at protonmail.ch (Bart Butler) Date: Mon, 21 May 2018 15:05:39 -0400 Subject: [Autocrypt] [openpgp-email] Efail - Possible Measures? In-Reply-To: References: Message-ID: > PGP/INLINE is handled only if the pgp > data is the very first non-whitespace content, otherwise it won't be decrypted. ^ This is exactly what ProtonMail does as well. Sent from ProtonMail, encrypted email based in Switzerland. ??????? Original Message ??????? On May 19, 2018 9:47 AM, Patrick Brunschwig wrote: > > > In the light of the Efail vulnerability I am asking myself if it's > > really needed to decrypt non-regular types of emails at all. In other > > words, should we decrypt a multipart/encrypted MIME part at all if we > > detect an irregular MIME structure? > > If we would not decrypt irregular MIME structures, there cannot be an > > issue with HTML displaying. This would be a good thing, if you're an > > addon and you can't change the application you live in. I know that some > > mail clients do this already, but all those clients that are affected by > > Efail apparently don't. > > I would consider the following "regular" MIME structures: > > 1. top-level MIME part is multipart/encrypted. > 2. an attached email (Content-Type = message/rfc822) containing a > > multipart/encrypted MIME part as direct child. > > Does anyone know of other relevant types of message structures? > > Does anyone see a reason why NOT to do that? > > -Patrick > > > openpgp-email mailing list > > openpgp-email at enigmail.net > > To unsubscribe or make changes to your subscription click here: > > https://admin.hostpoint.ch/mailman/listinfo/openpgp-email_enigmail.net > > Autocrypt mailing list > > Post: Autocrypt at lists.mayfirst.org > > List info: https://lists.mayfirst.org/mailman/listinfo/autocrypt > > To Unsubscribe > > Send email to: Autocrypt-unsubscribe at lists.mayfirst.org > > Or visit: https://lists.mayfirst.org/mailman/options/autocrypt/bartbutler%40protonmail.ch > > You are subscribed as: bartbutler at protonmail.ch From mirimir at riseup.net Tue May 22 08:30:10 2018 From: mirimir at riseup.net (Mirimir) Date: Mon, 21 May 2018 19:30:10 -1100 Subject: I just got an odd message Message-ID: <816c1c96-3e89-83f4-f24c-7599082483b6@riseup.net> OK, so I just got an odd message. There's a text/html part, with suspicious bits: |
----DMMAwGuf | 1hTVhVG5 OI0QBVgA | cROBNJ3k q9IZYLZM rP0GExKW RS----=0A=0A

|
----iAmobekE | x8fPP99r k7BqbiXj | 3zlX0bTK oPoV8ioK 6J5dAT---- I don't display HTML, of course ;) Those are just screwed-up text-encoded images, right? From patrick at enigmail.net Tue May 22 08:11:46 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 22 May 2018 08:11:46 +0200 Subject: efail is imho only a html rendering bug In-Reply-To: <0FFC25A6-3B08-4B00-A14E-8C678D241391__2507.4701327414$1526920427$gmane$org@glsys.de> References: <0FFC25A6-3B08-4B00-A14E-8C678D241391__2507.4701327414$1526920427$gmane$org@glsys.de> Message-ID: <350c0fb1-cf5a-fac0-6f75-768a518a68da@enigmail.net> On 21.05.18 16:56, Klaus R?mer wrote: > Internet works because we have standards. > Rfc 3986 states that URLs have to be ecoded. > Redering-Engies which send unencodes content including whitespaces and newlines to an external Server are seriously broken. > > (Only to point the finger at the real bug) You only refer to one type of possible vulnerabilities that Efail discovered. Even if there are no remote calls involved, it is still possible to trick the user into sending a reply that contains decrypted content. -Patrick From mkesper at fsfe.org Tue May 22 09:17:02 2018 From: mkesper at fsfe.org (Michael Kesper) Date: Tue, 22 May 2018 09:17:02 +0200 Subject: Break backwards compatibility In-Reply-To: <5B037198.5080509@signal100.com> References: <968cda26-39d5-6f0c-c771-e264ddd89f62@gmx.de> <5B023AC4.20807@signal100.com> <1526889229.29309.1.camel@fsfe.org> <5B037198.5080509@signal100.com> Message-ID: <1526973422.19043.1.camel@fsfe.org> Hi Mark, Am Dienstag, den 22.05.2018, 02:25 +0100 schrieb Mark Rousell: > On 21/05/2018 08:53, Michael Kesper wrote: > > I think it might be best to put that functionality into a separate > > GnuPG version called gpg-legacy. > > Make it clear in all man pages of this tool, the --version and -- > > help > > options that this only exists to decrypt existing but now obsolete > > encrypted material and that it can't be used to create such > > material > > anymore. > ? > Seems reasonable to me, although does GnuPG 1.x already effectively > fulfil that role? Yes, did read so after writing my mail. :) Michael -- Michael Kesper Supporter of FSFE https://fsfe.org/about GPG Fingerprint: F035 8BD9 D0C2 0E6A 85B5??6A60 4208 05C6 8907 4FAD -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part URL: From lists at boyandin.info Tue May 22 08:58:16 2018 From: lists at boyandin.info (Konstantin Boyandin) Date: Tue, 22 May 2018 13:58:16 +0700 Subject: Relocating pubring.kbx in gpg.conf Message-ID: <66db36d0e95dc0bc3fd7f803aebd4d73@boyandin.info> Hello, GnuPG: 2.2.7 (built from sources), OS: Ubuntu 16.04.4 (64-bit). Problem: file pubring.kbx is by default created in GnuPG default config directory. If some other files I can efficiently relocate in gpg.conf, i.e. by using something like primary-keyring ~/mounted/gnupg/pubring.gpg secret-keyring ~/mounted/gnupg/secring.gpg trustdb-name ~/mounted/gnupg/trustdb.gpg keyring ~/mounted/gnupg/pubring.gpg but I see no obvious directives to relocate pubring.kbx - my only option, so it seems, remains relocating the entire configuration directory. Is there a less total way to relocate pubring.kbx ? Thanks. Sincerely, Konstantin From dgouttegattat at incenp.org Tue May 22 11:27:56 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 22 May 2018 10:27:56 +0100 Subject: Relocating pubring.kbx in gpg.conf In-Reply-To: <66db36d0e95dc0bc3fd7f803aebd4d73@boyandin.info> References: <66db36d0e95dc0bc3fd7f803aebd4d73@boyandin.info> Message-ID: <518d5bd1-ea44-658d-2c2b-6373570e8938@incenp.org> On 05/22/2018 07:58 AM, Konstantin Boyandin via Gnupg-users wrote: > primary-keyring ~/mounted/gnupg/pubring.gpg > secret-keyring ~/mounted/gnupg/secring.gpg > trustdb-name ~/mounted/gnupg/trustdb.gpg > keyring ~/mounted/gnupg/pubring.gpg > but I see no obvious directives to relocate pubring.kbx You can use the keyring option as well, which works both for the old keyring format (.gpg) and the new keybox format (.kbx). You might want to combine that with the 'no-default-keyring' option, to prevent GnuPG from systematically create the default $GNUPGHOME/pubring.kbx. Note, however, that with GnuPG ? 2.1 the 'secret-keyring' option no longer has any effect. Modern GnuPG no longer uses a secret keyring file, private keys are handled by the Agent which always store them in $GNUPGHOME/private-keys-v1.d. > - my only option, so it seems, remains relocating the entire > configuration directory. Given that in your current configuration your private keys are *not* stored where you think they are (because 'secret-keyring' is ignored as stated above), this is indeed as far as I know your only option. Damien -------------- 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 Tue May 22 11:35:38 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 22 May 2018 05:35:38 -0400 Subject: =?UTF-8?Q?Re:_Break_backwards_compatibility_already:_it=e2=80=99s_t?= =?UTF-8?Q?ime._Ignore_the_haters._I_trust_you.?= In-Reply-To: <5B036C88.90308@signal100.com> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> <5B036C88.90308@signal100.com> Message-ID: <899ecf9c-138c-c244-db35-0af5c8ade13e@sixdemonbag.org> Guys, especially in the wake of Efail, *please* stop sending HTML mail to the list. From Roman.Fiedler at ait.ac.at Tue May 22 11:44:22 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Tue, 22 May 2018 09:44:22 +0000 Subject: =?utf-8?B?QVc6IEJyZWFrIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGFscmVhZHk6IGl0?= =?utf-8?B?4oCZcyB0aW1lLiBJZ25vcmUgdGhlIGhhdGVycy4gSSB0cnVzdCB5b3Uu?= In-Reply-To: <9204fead-aa77-5dda-6d4a-9dfe91f4df5e@riseup.net> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> <5B036C88.90308@signal100.com> <5B03829F.9000909@signal100.com> <9204fead-aa77-5dda-6d4a-9dfe91f4df5e@riseup.net> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7C553@S0MSMAIL112.arc.local> Hello list, I failed to decide, which message would be the best to reply to, so I took one with a title, rational humanists could be proud of. Ignoring the title, many of the messages had valid arguments for both sides. From my point of view the main difference seems to be, what is believed to be valid use cases and hence requirements for GnuPG. As I do not know of any requirements engineering documentation for GnuPG (also did not search for it yet), I just skimmed over the various use cases, that would be affected by fully dropping legacy support from GnuPG in the hardest way (both en/decrypt). Foreword: The arguments from below are ONLY from the mostly fully automated, non-mail, gnupg use-cases I currently have and their implications on backward compatibility. Those use cases might not be representative for automated use-cases or not worth to be considered in gnupg future. If they are not regarded important for gnupg , that would also be OK for me. It is all just about making the decision if gnupg will be the preferred encryption tool for the next 5-10yrs in our setups. To stick to logics, here are my assumptions for reasoning: * A:LegacyBad: Legacy support is more a security risk than a usability benefit, so it should be removed (or at least disabled) in the current version. * A:LateAdoptersPay: The burden on migrating legacy systems should be mostly on the side of those owning them - their lifecycle strategy decision was to minimize their costs, this should also have included a prediction, where software development/features/availability will move to. If done wrong, it is their fault. * A:MigrationPathes GnuPG on the other side has to provide simple and clear data/function migration pathes, so that long term users have trust in gnupg to be a solution for longer time. * A:NonStdBenefits: Non-standard use case support (e.g. non-mail) is a benefit for both parties: gnupg software gets also non-standard testing (thus security-relevant bugs might be discovered, that would not show up in standard use case) while other party can use software that is 80% fit to their purpose, so that system integration can be done much faster. * A:MachineTurnaround: Turn-around time of server software is about 5yrs, not all machines are migrated at once. So there will be a transition phase, where legacy and non-legacy systems will have to work together. * A:NoArchiveReencrypt: Full reading and reencryption of old tape archives (some that have to be stored/copied for 20yrs+) is not an option, both regarding efforts plus auditing support. * A:LateAdopterIsolate: As legacy software might not be able to tackle modern threats, that part of threat mitigation has to be dealt with by the operator, meaning: while gpg1.4 might have been suitable to decrypt in online (networked) setups back then, a backward compatibility setting might do that only in a state of the art 2018 64bit OS-release virtual machine with GnuPG running in an old i386, unprivileged, minimal, fully hardened LXC-container. * A:AttackSurface: While in desktop setups, more complex gnupg might not be the largest part of attack surface, the size of the gnupg-attack surface might be relevant in hardened, automated setups. If gnupg cannot be run in a simple, auditable, automatable minimal configuration, this will also affect trust in the future usability of gnupg. Considering all those assumptions, I would hope that following strategy would be somewhere in the direction of the optimal point for splitting costs between legacy operators and development (hopefully both for mail and automation): * Have 3 categories of features to ease long-term planning, both for dev and users (mail and automation): "recent": those just work "deprecated": not insecure, but something considered to be removed over the next 5-10 years. They can be enabled by "--deprecated" without any known, current security risks. "legacy": In an ideal world, they would not even be in the main code line. Having those levels would ease coordination of migration pathes between devs and users within timeline as required for [A:MachineTurnaround]. As soon as one of your tools requires "--deprecated", you should start prioritizing/handling that with your devops team. * While running a mixed setup [A:MachineTurnaround], [A:MigrationPathes] should be available, to reduce the amount of data produced with "deprecated" (or even "legacy" features) while obsolescence is already dawning. As the producing systems might not be changed without breaking warranty while [A:MachineTurnaround] is not over yet, but operators may already have increased costs according to [A:LateAdoptersPay], GnuPG tool support for migration of data in use therefore would be nice. This should be quite easy to use to tackle "deprected" features (also to motivate users to migrate in steps). For "legacy" the effort on integration might be much higher, which is OK. This could go even that far, that gnupg only writes a protocol, what was done during decryption/signature checks and the caller has to check, if that result is OK for him. In a generic solution, such a tool could be something like "gpg-archive": it justs wraps the old message, the old decryption report, the plaintext with a new key into new encrypted/signed GPG elements (wish list: would be nice if such a thing could be defined as backward-compatibility RFC for PGP some time in future): Such a feature might be needed anyway, because the old crypto (RSA-1024 or other non-quantum-safe) might not be good enough for data at rest anyway from some time point on. Such a tool might then e.g. be used on a MitM message reencryption gateway: the old machines still send messages with old (deprecated/legacy options), they are transformed by "gpg-archive": The full data (old message, old decrypt report, reencrypted plaintext) go to the auditing storages, the reencrypted plaintext to the standard (before MitM) receiver (who does not need to support legacy/deprecated from now on anymore). * For long-term-archive use cases (which usually means, that the data is REALLY at rest according to [A:NoArchiveReencrypt]), access will happen that rarely so that tools like described in [A:LateAdopterIsolate] would be acceptable for me (apart from that: the session key extraction features do you a real favor on large data streaming here, boosting performance multiple orders of magnitude. Thanks for that!) . If access happens more often, data is not really at rest, but sometime in use (and often at risk as the old archives are accessed frequently but their crypto might be weak already), so that on-the-fly reencryption might be cheaper for me as operator (reencrypt-costs vs. security-risk-costs). * Those features for automation/long-term-use need to be available somehow without gnupg becoming desktop optimized bloat-ware, which would increase the costs of hardening, testing, auditing [A:AttackSurface]. I hope I could make it clear, what I am trying to argue for. So let's drop legacy, but with style. BTW: If there is a wiki/git structure/ .... for use case documentation and requirements engineering, I would volunteer to participate - helping developing a good strategy is orders of magnitude cheaper than replacing all gnupg stuff. LG Roman From rjh at sixdemonbag.org Tue May 22 11:47:43 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 22 May 2018 05:47:43 -0400 Subject: Breaking changes In-Reply-To: <5B0374CF.9000608@signal100.com> References: <5B0374CF.9000608@signal100.com> Message-ID: > Get real. These people are long-time GnuPG users and now you want to > throw them under the bus because... well, because you prefer it that > way. 1.4 was deprecated the instant 2.0 was released. After much pushback it was agreed to continue supporting 1.4. But after fourteen years it's time to end it so that Werner's limited time can be fully devoted to the 2.3 branch. > Err... the specialised solution surely is GnuPG 1.4. Yes. And the code will still be around. It will just no longer be maintained. If it's that important to you, you should consider maintaining it yourself or paying someone to maintain it. > So you are saying that long-time users should be deprived of an open > source ongoing-maintained solution to their entirely valid present day > use case to benefit a private company. Why do you feel you have the right to make Werner work for you for free? That's what you're saying here. "I'm not paying a dime and I insist on my legacy package getting highly professional work done on it for free." Well... no. It doesn't work that way. Werner gets to work on what he wants to work on, and I think the best bang for the buck, community-wise, is 2.3. But if Werner were to say tomorrow, "I'm done, guys, I'm going to go sell ice cream on the beach," I'd just say thank you, wish him well, and wonder where the beaches were in Germany. > Isn't that effectively equivalent to commercial sponsors taking > previously open source code base private? It's hardly a popular move > when it happens. Nope. 1.4 will still be out there, just unsupported. > Surely if you can recognise that people will start screaming then you > must also understand that it is entirely the wrong thing to do. No. I'm well past the point where I care about how vocal a fringe minority is. It's unwise to make engineering decisions based on the volume made by a small number of people. From andrewg at andrewg.com Tue May 22 11:55:36 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 22 May 2018 10:55:36 +0100 Subject: =?UTF-8?Q?Re:_AW:_Break_backwards_compatibility_already:_it?= =?UTF-8?Q?=e2=80=99s_time._Ignore_the_haters._I_trust_you.?= In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7C553@S0MSMAIL112.arc.local> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> <5B036C88.90308@signal100.com> <5B03829F.9000909@signal100.com> <9204fead-aa77-5dda-6d4a-9dfe91f4df5e@riseup.net> <2ECE9D9EEF1F524185270138AE23265955B7C553@S0MSMAIL112.arc.local> Message-ID: <98980ec5-d092-6455-2e10-652ecf57a76a@andrewg.com> On 22/05/18 10:44, Fiedler Roman wrote: > Such a tool might then e.g. be used on a MitM message reencryption > gateway: the old machines still send messages with old > (deprecated/legacy options), they are transformed by "gpg-archive": > The full data (old message, old decrypt report, reencrypted > plaintext) go to the auditing storages, the reencrypted plaintext to > the standard (before MitM) receiver (who does not need to support > legacy/deprecated from now on anymore). I don't think we should be encouraging the automated or transparent use of legacy crypto upgrades, particularly in an online setting such as a mail gateway. All this does is launder the obviously-dangerous bad ciphertext into an apparently-safe new ciphertext. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From Roman.Fiedler at ait.ac.at Tue May 22 12:34:29 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Tue, 22 May 2018 10:34:29 +0000 Subject: =?utf-8?B?QVc6IEFXOiBCcmVhayBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBhbHJlYWR5?= =?utf-8?B?OiBpdOKAmXMgdGltZS4gSWdub3JlIHRoZSBoYXRlcnMuIEkgdHJ1c3QgeW91?= =?utf-8?Q?.?= In-Reply-To: <98980ec5-d092-6455-2e10-652ecf57a76a@andrewg.com> References: <889ffe9e-c247-e27d-a842-1ab08b1e3d4f@gmail.com> <5B036C88.90308@signal100.com> <5B03829F.9000909@signal100.com> <9204fead-aa77-5dda-6d4a-9dfe91f4df5e@riseup.net> <2ECE9D9EEF1F524185270138AE23265955B7C553@S0MSMAIL112.arc.local> <98980ec5-d092-6455-2e10-652ecf57a76a@andrewg.com> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7C5B1@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > > On 22/05/18 10:44, Fiedler Roman wrote: > > Such a tool might then e.g. be used on a MitM message reencryption > > gateway: the old machines still send messages with old > > (deprecated/legacy options), they are transformed by "gpg-archive": > > The full data (old message, old decrypt report, reencrypted > > plaintext) go to the auditing storages, the reencrypted plaintext to > > the standard (before MitM) receiver (who does not need to support > > legacy/deprecated from now on anymore). > > I don't think we should be encouraging the automated or transparent use > of legacy crypto upgrades, particularly in an online setting such as a > mail gateway. All this does is launder the obviously-dangerous bad > ciphertext into an apparently-safe new ciphertext. Agreed, but I did not mean "e-mail" when writing "message". "Message" would more some encoded data block from a remote device, that has to be pushed to a central system from time to time, e.g. for auditing. Thus the gateway exactly knows the sender's key (usually it is only one for all systems with the same security level/in the same security zone) and re-encrypts it with a single key also known to the recipient. Usually the recipient has all the trusted keys hardcoded. For "e-mail" type messages, as you noted, a transparent re-encryption would be more risk than benefit in many cases. Still, it might be useful for semi-automated migration scenarios, e.g. * User clicks on a very old e-mail message * Gnupg fails decrypting it, referring to the migration tool and asking for confirmation * The migration tool migrates/replaces that single message if the user wants that. For e-mail, creating a mime-tree might come in handy, e.g. - plaintext message (reencrypted) - decryption/migration protocol (encrypted) - old message (full old mime structure, also encrypted but without decrypting it first - thus providing data at rest protection while still preserving all the old structures for traceability) From m16+gnupg at monksofcool.net Tue May 22 12:58:50 2018 From: m16+gnupg at monksofcool.net (Ralph Seichter) Date: Tue, 22 May 2018 12:58:50 +0200 Subject: Breaking changes In-Reply-To: <5B037595.2070607@signal100.com> References: <5B037595.2070607@signal100.com> Message-ID: <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> On 22.05.18 03:42, Mark Rousell wrote: > Preventing users from encrypting new data using legacy encryption does > NOT need to mean that other users have to be prevented from (quite > legitimately) accessing archived data using legacy encryption with > maintained software. Who said "have to be prevented"? Please keep in mind that GPG is maintained on a voluntary basis. If the people who do the actual work decide to not maintain outdated software anymore, so they can focus their limited resources on current releases, they are completely free to do so and don't deserve to be chastised for the decision. If somebody wants support for old GPG versions, they can damn well pay people for that. In more than three decades in this business I have seen too many users who think that paying for software licenses and upkeep is an inconvenience, and who take open source software for an all-you- can-gobble buffet without a thought for the authors. I am not implying you are one of these people, mind you. -Ralph From andrewg at andrewg.com Tue May 22 13:41:01 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 22 May 2018 12:41:01 +0100 Subject: I just got an odd message In-Reply-To: <816c1c96-3e89-83f4-f24c-7599082483b6@riseup.net> References: <816c1c96-3e89-83f4-f24c-7599082483b6@riseup.net> Message-ID: On 22/05/18 07:30, Mirimir wrote: > Those are just screwed-up text-encoded images, right? Without seeing the full email, it's hard to tell. They don't appear to represent any well-known file type when run through a base64 decoder. Most uses of such constructions are hacks to get emails to display differently depending on the idiosyncracies of different readers, and I see plenty of them. But the text-encoded data does look odd. I grepped the last 500 days of my spam folder and found one instance from a long time back that closely matches the pattern of yours. It is missing the leading dashes and whitespace chunking but otherwise looks almost the same. It includes the domain name "wei wei gift dot com". I see nothing in my example that screams "efail", but even so I am reluctant to open it in an HTML renderer to find out. ;-) It may simply be garbage intended to confound bayesian analysis. YMMV -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From mwood at iupui.edu Tue May 22 15:12:28 2018 From: mwood at iupui.edu (Mark H. Wood) Date: Tue, 22 May 2018 09:12:28 -0400 Subject: A postmortem on Efail In-Reply-To: <5B03675F.7050004@signal100.com> References: <20180521141712.GA367@IUPUI.Edu> <5B03675F.7050004@signal100.com> Message-ID: <20180522131228.GA11822@IUPUI.Edu> On Tue, May 22, 2018 at 01:42:07AM +0100, Mark Rousell wrote: > On 21/05/2018 15:17, Mark H. Wood wrote: > >> Break backwards compatibility already: it?s time. Ignore the haters. I > >> trust you. > > (I understand that that's a quote of a discussion-opener from the write-up.) > > > > I'd like to first see how many haters can be won over by selling the > > necessary changes. > > > > By "selling" I mean addressing the concerns of those who aren't > > convinced that they want something: > > > > o Why this is important *to you*, even though its importance was not > > immediately obvious. > > To my mind it is at the outset counter-productive to refer to "haters". > To use the term "haters" implies that anyone who does not share one's > own view is somehow wrong and/or that their arguments can potentially be > dismissed on the grounds or emotionalism rather than rationality. *sigh* Imagine that I wore a wry expression as I wrote that. I think we are mostly in violent agreement. I tend to play off of the wording of a previous statement when replying, especially when I want to bend the discussion in a different direction. > In practice, those like myself who recognise that the ability to decrypt > legacy-encrypted data is a basic requirement for many users with > archival needs do not "hate" anything. We just recognise that decryption > of legacy-encrypted data is a real world requirement right now and will > continue to be for many years, and so I think it is right and proper for > this project to continue to support this activity with maintained > software (albeit with a requirement for users to make some changes to > support such activity). Yes. I, too, have encrypted stuff from way back that I would like to be able to read. Addressing such needs is part of selling the selected way forward. Another part of selling is dialogue. I see lots of confident assertions about what we should do. Is anyone taking this back to the affected users to see if any of it makes sense to them? > > o What we have done, and are doing, to keep *your* cost down. > > If the aim is to keep end-users' costs down then do not completely > remove legacy features that are still needed in the real world. > Decryption of legacy-encrypted data is one of those features, like it or > not. Yes, but don't just do it silently; tell people who need this that it is being done, because of their concerns, and how it is being done. Sell it. > > o What else would we need to do, to make this something *you* want? > > Go back in time and change history! [snip] I was hoping for practical ideas which show that the community understands the needs of all its members and is working to minimize the cost of necessary evolution. I'd like to be one community, but apparently at the moment we are two. -- 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 Ernst-Udo.Wallenborn at novosec.com Tue May 22 16:19:57 2018 From: Ernst-Udo.Wallenborn at novosec.com (Ernst-Udo Wallenborn) Date: Tue, 22 May 2018 14:19:57 +0000 Subject: AW: Breaking changes In-Reply-To: <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> Message-ID: <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> > -----Urspr?ngliche Nachricht----- > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von Ralph Seichter > Gesendet: Dienstag, 22. Mai 2018 12:59 > > On 22.05.18 03:42, Mark Rousell wrote: > > > Preventing users from encrypting new data using legacy encryption does > > NOT need to mean that other users have to be prevented from (quite > > legitimately) accessing archived data using legacy encryption with > > maintained software. > > Who said "have to be prevented"? Please keep in mind that GPG is > maintained on a voluntary basis. If the people who do the actual work > decide to not maintain outdated software anymore, so they can focus > their limited resources on current releases, they are completely free > to do so and don't deserve to be chastised for the decision. I'd favour a pragmatic approach, drawing the line depending on the state of technology: we all know that encryption does not provide absolute security; it provides relative security for a limited time. Relative because it depends on the means the adversary has, and limited time because of technological progress. Old files encrypted with a method that is trivially crackable today are actually not encrypted, they're just encoded in a fancy way. Users with such files should reevaluate their encryption strategy, and not depend on gnupg to be a permanent decoding tool. But on the other hand, email encryption can never clean up as radically as TLS1.3, because it has to provide protection for data-at-rest, too, which TLS doesn't have to address. So unless an algorithm is completely broken, it should stay supported, at least for decryption. -- Ernst-Udo Wallenborn Pgp 22FB 1CB2 82D8 A903 A289 053B 4015 1361 6040 82F7 From Reid.Thompson at omnicell.com Tue May 22 15:54:09 2018 From: Reid.Thompson at omnicell.com (Reid Thompson) Date: Tue, 22 May 2018 13:54:09 +0000 Subject: =?utf-8?B?QnJlYWsgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYWxyZWFkeTogaXTigJlz?= =?utf-8?Q?_time._Ignore_the_haters._I_trust_you.?= Message-ID: Break backwards compatibility already: it?s time. Ignore the haters. I trust you. From Reid.Thompson at omnicell.com Tue May 22 15:54:03 2018 From: Reid.Thompson at omnicell.com (Reid Thompson) Date: Tue, 22 May 2018 13:54:03 +0000 Subject: =?utf-8?B?QnJlYWsgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYWxyZWFkeTogaXTKvHMg?= =?utf-8?Q?time._Ignore_the_haters._I_trust_you.?= Message-ID: <1526997113.14924.1.camel@omnicell.com> Break backwards compatibility already: it?s time. Ignore the haters. I trust you. From jrh29 at alumni.cwru.edu Tue May 22 16:45:54 2018 From: jrh29 at alumni.cwru.edu (Justin Hibbits) Date: Tue, 22 May 2018 09:45:54 -0500 Subject: Duplicate personal key in keyring In-Reply-To: References: Message-ID: Hi DIrk, (Not subscribed to the list, so copied initial reply. Top-posting so mail readers will more easily filter) My backup was simply a full copy of my .gnupg directory, so that I could easily just destroy the new one and restore if anything failed. I'll try your suggestion, thanks! - Justin Hello Justin. Am Montag, den 21.05.2018, 11:25 -0500 schrieb Justin Hibbits: > Through some unknown series of events, I now have two copies of my > personal gpg key in my keyring. I double-checked to see if GPG is > seeing the same key in two keyrings (maybe reading a backup), but > both > keys are being read from the same keyring. > This leads me to two questions: > 1) How could this happen in the first place? I had a similar problem a while ago. In my case the key database was corrupted. > 2) How can I fix this, short of generating a new key and revoking the > existing key? In my case I exported the public and the private keys of my own keys, then exported the complete public key ring, both ascii armored. Then I simply deleted the key database file(s) and re-imported the exports. GPG imports keys only once, so the duplicates should vanish when re- importing. > I've tried backing up the keyring and deleting one copy, but it > deleted both copies. I searched online for anyone else who had a > similar issue, and came up empty, except for one person who was > seeing the same key from two files. Did you make an ascii armored export, or what kind of Backup do you mean? Regards, Dirk From mirimir at riseup.net Tue May 22 22:09:45 2018 From: mirimir at riseup.net (Mirimir) Date: Tue, 22 May 2018 09:09:45 -1100 Subject: I just got an odd message In-Reply-To: References: <816c1c96-3e89-83f4-f24c-7599082483b6@riseup.net> Message-ID: On 05/22/2018 12:41 AM, Andrew Gallagher wrote: > On 22/05/18 07:30, Mirimir wrote: >> Those are just screwed-up text-encoded images, right? > > Without seeing the full email, it's hard to tell. They don't appear to > represent any well-known file type when run through a base64 decoder. I tried that too, for the full blocks, using online decoders, and got nothing interpretable. > Most uses of such constructions are hacks to get emails to display > differently depending on the idiosyncracies of different readers, and I > see plenty of them. But the text-encoded data does look odd. In Thunderbird text mode, "----DMMAwGuf 1hTVhVG5 OI0QBVgA ... cROBNJ3k q9IZYLZM rP0GExKW RS----" appeared as the message header. Where an image might normally be. The body is: | BusinessStorage tank | | Dear Sir,. | | We are a foreign trading corporation with actual strength in Chengdu, | We need to order many of Storage tank now...... I'd like to send | you the picture of our need by? the form of accessory, please find | the attached file and offer us the Preferential price by the | specifications of our picture..After receiving your offer price, I | will contact you ASAP,and Negotiation cooperation details,I also hope | that we can establish a long term cooperative relationship from now. | | Product : Storage tank ( name ) | Quantity: 50 | | Please contact me by email if you need the specification of products? | picture, I will send it to you because I often like to send message | through email??Thanks | | We look forward to having a successful cooperation...F So he _does_ refer to images. > I grepped the last 500 days of my spam folder and found one instance > from a long time back that closely matches the pattern of yours. It is > missing the leading dashes and whitespace chunking but otherwise looks > almost the same. It includes the domain name "wei wei gift dot com". > > I see nothing in my example that screams "efail", but even so I am > reluctant to open it in an HTML renderer to find out. ;-) It may simply > be garbage intended to confound bayesian analysis. > > YMMV Thanks for checking. I'm curious enough that I'll put the HTML in a LiveCD VM with no network connection, and see what Firefox does with it. From ben at adversary.org Tue May 22 23:35:41 2018 From: ben at adversary.org (Ben McGinnes) Date: Wed, 23 May 2018 07:35:41 +1000 Subject: A postmortem on Efail In-Reply-To: <5B037029.8080401@signal100.com> References: <20180521123430.vwfkpz4wsqpq5awn@adversary.org> <5B037029.8080401@signal100.com> Message-ID: <20180522213541.hmvimccsiroaafag@adversary.org> On Tue, May 22, 2018 at 02:19:37AM +0100, Mark Rousell wrote: > On 21/05/2018 13:34, Ben McGinnes wrote: > >> I agree with most of the article and largely with the need to break >> compatibility to an ancient flawed design. Particularly since we >> still have a means of accessing those ancient formats if we have to in >> the form of the GPG 1.4 branch. The ancient archives are as safe as >> they've ever been (for whatever definition of "safe" is being implied >> by the user/archivist). > > Indeed, this satisfies my archive retrieval concerns. Mine too, it's why I keep a copy of 1.4 installed at all. It's been a while since I've needed to access something encrypted to the first key I ever made way back in 1995, but I know there are archives which might require it and possibly even some which have not already been migrated to a newer key and encryption method. That's okay, though and it doesn't need current dev practices to retain those functions since there is a means of still opening that door, even if I'm no longer using DOS and thus PGP 2.3a for DOS is no longer available. No doubt the worst issue would be sanitizing such an old file of carriage returns or something like that. Depending on what it was, though there may even be WordPerfect 5.1 files buried in those archives and IIRC LibreOffice dropped support for those files a while back. I suspect that sort of issue is more likely to be a cause of angst for people needing to access old data than whether they need to run GPG 1.4.x manually to decrypt it first. >> There is, however, one aspect of this issue that you touched on >> lightly, but didn't really delve into and which is at the centre of >> my, mostly unvoiced (until this email), criticism of the Efail team. >> That being the *incredibly* unhelpful and likely actively harmful >> recommendation to remove encryption and decryption functionality from >> vulnerable MUAs. >> >> To say, ?we have this edge case scenario that really needs an active >> targeted attack on a case by case basis, so everyone should just stop >> integrating encryption? is the kind of thing that can get people >> killed. > > This has been commented on by a few people on this list, myself > included: [1] It gets mentioned here periodically, usually in conjunction with discussions of differing threat models. The EFF even have a great big section on their SSD site about conducting your own risk or threat assessment and that these things will be different for people in different circumstances. Then they decided to ignore their own advice in its entirety. > To my mind, it reeks of slanted propaganda for Signal, and there > does seem to be a lot of it around at the moment. Hmm, maybe, but I'm not entirely certain that's instigated by Signal or Whisper Systems. No doubt they're enjoying it, but I think there's another reason for that. > Signal has security benefits but it's not (yet?) a replacement for > encrypted email, It's completely incapable of replacing either email or OpenPGP. Here are two things I do regularly or constantly which Signal is fundamentally incapable of: 1. Running my own server which enables me to set certain types of controls or filters on my own server and not shared with any third party (including Moxie). 2. Encrypt files which are not intended to be sent to anyone and never were intended to be so. The same is true of certain files which are digitally signed and archived in a way which lets me prove when they were written later (it's a copyright thing and set to specifically circumvent a particular niche of morons that are unrelated to the issue at hand). Mostly, however, I mean things like keeping a journal and making damn sure that it won't be used against me. Signal can't do any of that. At all. It also can't provide a genuine means of establishing a pseudonymous identity unless you live in a country that lets you buy lots of cheap "burner" phones and/or SIMs. Maybe that is easy in the USA, maybe even elsewhere too. It's pretty much impossible in Australia. So if there were something I needed to raise somewhere pseudonymously, say via Tor and some web forum, what does the EFF suggest I use? Signal? How? > whereas a number of commentators seem to treat it as if all email, > encrypted or not, should be deprecated in favour of Signal. This is > not sensible or good advice without considering individual use cases > (regardless of Efail). Absolutely! I'm guessing that none of these commentators have ever actually personally faced a threat which threatened their lives, especially as part of some kind of minority, where the threat is both targeted and impersonal simultaneously. There are still millions of people in the world facing torture or even death just because of something they were born with (even something which may not be apparent until they reach a certain point after birth). In fact one minority I'm aware of is still so greatly at risk that there's only one country in the world which provides legislative protection for them. All the others permit and, in some cases even encourage or promote, some rather nasty practices (and I've seen some of the evidence presented to the UN's human rights reviews, including photographic). This group is *not* the same community I referred to in my previous message (the one you replied to, not the second one to Rob) There is almost certainly some overlap, though, since there will be members of this minority in that other community just based on statistical prevalence. > Well said. Thanks. >> So in my opinion it's not the merits or lack thereof in the >> demonstrated attacks they released that have the gravest >> consequence here, it's that the number one recommended mitigation >> technique is to remove cryptographic functions from MUAs. > > Without wanting to sound like a conspiracy geek, removing encryption > from email would, of course, benefit Signal and its takeup. I don't think it's necessarily for Signal, but Signal was created by someone who shares that view and, more often than not, for much the same type of reason. I think the majority of those people who adhere to that view are geeks of a certain age, approx. 40s to 50s, who came to the crypto world back during the first Crypto Wars. As much as they loved the idea of PGP, one of two things happened: either they couldn't understand it will enough to get it to work properly or, the more common story, they couldn't get others to use it due to the difficulties in doing so at that time. In their minds OpenPGP usage is "difficult to use" or "not worth the effort" because in their minds it is still their recollection of the experience back then. They've given up on it and they've dug their heels in so much they now react almost aggressively against anyone still seeking to use the thing. It's porojection and it says more about them than anything. How can I be sure, well obviously my reference to my first key indicates I was getting my intro to things around the middle of that era. The two biggest problems back then by my recollection was the lack of accessible documentation explaining the concepts without requiring a mathematics degree and practical setup guides. Over time the latter became more prevalent and eventually some good examples of the former arrived. Those coupled with the *vast* improvements to software over the intervening years means that the difficulties of the '90s are not as great as they were. There is still some effort required and people do need to think about what sort of security they need, but that just leads into the other aspect of this: it was never about the degree of difficulty, it was about the motivation to use the thing. If someone feels a genuine threat to themselves or their loved ones and OpenPGP usage is the key to ensuring that threat is kept at bay, you just watch how fast and dedicated they become. I've seen some rather surprising examples of precisely that over the years too and it's really at the core of that old argument. We can advocate about something we find fascinating until we're blue in the face, but for someone else to use it, they have to be motivated enough to want to. Signal is so simple that it's almost impossible to fuck it up (except when it resends an unencrypted SMS to someone not on the network hundreds of times without the sender knowing that's what happened and wondering why their friend or whoever is pissed off at the walls of repetitive messages), but it achieves this by moving all the options and decisions to the developers and the servers. Anyway, I think the pro-Signal commentariat is pro-Signal not because of some concerted effort to build Whisper Systems into the One True Centre of Cryptography (complete with secret handshake and, maybe, a "No Homers" policy), but because their personal experience of difficulty 20+ years ago convinced them that the solution was that everything must be so simple as to be unnoticable. Then Moxie came along, someone whose story includes a free admission that he feels the same way and he wrote this thing that's simple to use. This seems like validation of their belief and so they latch onto it with a near religious fervour. None of this is really that new in IT-land, but in this particular field it has the potential to have very bad consequences for people who are more worried about things that could get them killed or tortured or beaten or whatever than something that may have just been a bit frustrating or even embarassing. Those commentators still need to learn that it's not about them, nor is it about us; it's about the people who need it, when they need it to not get beaten, raped and/or tortured to death ... or whatever other nastiness they're trying to avoid. Besides, I'm pretty sure I can out-do the lot of them for embarrassing fuck-ups with PGP during the '90s. I once sent an encrypted email to Phil Zimmermann which was supposed to just be a "thanks for the nifty software, this so cool" message and I got a reply asking why I'd sent an encrypted empty message. Yeah, really, and of course I was mortified! I did, however, stick with it and (eventually) learned. A long time later I was able to contribute in more useful ways particularly from about three years ago onward (and this year is definitely adding to that opportunity). I even still cringed at the thought of sending Phil Zimmermann that empty message for quite a while. Now I barely think about it at all and, when I do, it's just a little amusing. I doubt Phil would even remember it at all. So what made me stop cringing at the thought of it? I couldn't give you a precise moment or thing, but it was either learning far more about the topic and being able to pass some of that along or it was experiencing some things that were far worse than mere embarassment. Maybe a little of both. The commentariat to which you referred, however, apparently still haven't learned to move beyond their own embarassment or their own problems. Which would be fine if it only affected themselves, but they're making sure it doesn't and preaching it to others; including some with concerns a bit more significant than whether they do something stupid. They seem to be more interested in the security of their ego and pride, perhaps reputation, over the actual consequences which others may pay if they follow the wrong advice for their situation. So again the real issue is not that they're pro-Signal, that's really more symptomatic. The real problem is that for whatever reason, though I strongly suspect the majority will be as I described above, they've developed a hatred for one particular piece of technology, in this case OpenPGP. Now they push any other option, currently Signal in many cases (no doubt WhatsApp would've been a contender, but lost points when bought by FarceBook) in all cases because they're more interested in hating the thing they hate than in providing relevant advice or recommendations that are geared towards helping people analyse their own threat model and implement the best tools to meet that threat. There's a really easy way to prove this too. I dare any of the Signal addresses all crypto needs" people to go to Mexico and provide info to that country or conduct citizen journalism and investigative reporting specifically on the cartels and corruption. Using Signal and a Mexican phone number. I mean if Signal is the answer, that should be enough to prevent discovery and execution, right? As for my advice on the Mexican scenario: do not do that unless you want to be executed! Last I checked Mexico had a nationalised telecommunications carrier, so the cartels only need to bribe or threaten one engineer and that's that. So once a relevant Signal contact is established, well, that's enough information to take to the national carrier with an Uzi and a demand for cooperation. You really think the telco tech or customer service rep is going to take a bullet for a customer and would anyone expect them to? Of course not and they shouldn't have to either. Whereas being able to maintain a pseudonymous identity online with the ability to verify that pseudonymous person is the same individual, but without revealing their real location can be done with other tools and for the Mexican scenario could even be done with their own domain (but with a light weight enough implementation to remain on the move). No doubt many people on this list will have already thought of a few options to handle various aspects of that kind of problem, with a few different configurations depending on specifics lacking in this hypothetical. No need to really delve into them, the point is that there are a few ways to do it with differing degrees of using different technologies depending on more detailed specifics of what needs to be done. So the solutions vary according to the needs of the person who will use it, not simply pushing Signal as some kind of mythical cryptographic Soma on everyone for every purpose. The best security advice is, and always has been, the advice which meets the needs of the person requesting it after having analysed that person's situation and that of the community or communities they're in. It will never be a one-size-fits-all magic pill or glib answer, not even Signal. Not even OpenPGP either; as it doesn't actually provide a transport method, just the structures for use with one and thus does not provide a means of guaranteeing anonymity or pseudonymity entirely on its own. In conjunction with other things it can be made to do so, of course, but that's the point. All right, there you go, if there is one part of the problems here which actually originates with Signal then there it is: conflating the protection method with the transport protocol. Signal as a solution can only ever be used with Signal the network, it can't be adapted to alternative transport protocols too readily, whereas OpenPGP can be and has been to varying extents. That, however, was a deliberate design choice made by Moxie as part of his approach of dumbing everything down to try it make it impossible for it to be too hard to use by most people and so Whisper Systems view that as a feature. Arguably it is indeed a feature, but it's the feature which should have been recognised by its supporters as being potentially dangerous for some types of threats and not the reason to pronounce it the solution to everything. So I think it's still fair to say the greatest problem is with the commentators and the real reasons motivating the nature of their commentary rather than what Signal is; and what it is is just fine if you're in a relatively privileged class in the western world who doesn't need to deal with anything requiring anonymity or pseudonymity. For everyone else, however, it may have some uses under some circumstances, but the degree to which it will do so will vary considerably and in quite a number of cases will either be very limited or will be a direct threat (or contribute to direct threats). As for the problem of the motivations of the commentators, regardless of whether or not my theory regarding experiences during the Crypto Wars is accurate or not, the real issue there is that they're letting their personal gripes override the specific situations others have to face and they don't seem to care if someone else dies as long as they get to push their agenda. I'm going to have to assume by this point two things: 1. that if they're that far into their own little world there's nothing that will convince them that maybe that's not so cool; and 2. that no one else here will be overly surprised if I (and perhaps others) disregard any degree of ethics or credibility of anyone who is so committed to a particular absolutist stance that they'll risk the lives of others (but never their own) on the righteousness of their cause. No doubt they won't care about either of those things either; or, more likely, they'll simply disregard everything postedto this list. This is something I will gladly accept if they will at the very least start giving a damn about the concerns of others facing much more heinous threats than the rest of us and needing real support from those of us involved in any aspect of the information security world, not just glib and unthinking answers which do more for a personal agenda than the person under threat. Regards, Ben P.S. I considered not sending this due to length and, possibly, responses to my disparagement of those who may value their own personal agenda over the needs of the end users seeking guidance. A subsequent conversation with someone linked to the originally referenced community had indeed disregarded OpenPGP due solely to the advice of old geeks saying it's too hard, don't even consider it (before the current thing). So the attitude of the commentariat is definitely a problem simply because they persist in pushing their old experience on a new audience as gospel instead of leaving the selection to a proper risk assessment and the needs of those people. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dank at kegel.com Tue May 22 23:38:42 2018 From: dank at kegel.com (Dan Kegel) Date: Tue, 22 May 2018 14:38:42 -0700 Subject: Breaking changes In-Reply-To: <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> Message-ID: Lessee... https://en.wikipedia.org/wiki/GNU_Privacy_Guard already give an end-of-life date for 2.0, but none for 1.4. And since Ubuntu 16.04 includes 1.4, there are likely to still be a few vocal 1.4 users out there. How about announcing an end-of-life date for 1.4 that is in the future (say, by 3 to 6 months)? That would avoid poking classic users in the eye too hard, and give time for them to get used to the idea. - Dan From dclarke at blastwave.org Tue May 22 23:48:24 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 22 May 2018 17:48:24 -0400 Subject: Breaking changes In-Reply-To: References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> Message-ID: <0d688415-b4cb-3532-f02f-24c744aabffb@blastwave.org> On 05/22/2018 05:38 PM, Dan Kegel wrote: > Lessee... > https://en.wikipedia.org/wiki/GNU_Privacy_Guard > already give an end-of-life date for 2.0, but none for 1.4. > And since Ubuntu 16.04 includes 1.4, there are likely > to still be a few vocal 1.4 users out there. > > How about announcing an end-of-life date for 1.4 that > is in the future (say, by 3 to 6 months)? Too fast. Think 12 months as a minimum. There is prod code out there running for years and a timeline that allows proper project schedule/costing/testing would be better. Dennis From gnupg at leo.gaspard.ninja Wed May 23 01:22:41 2018 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Wed, 23 May 2018 01:22:41 +0200 Subject: Breaking changes In-Reply-To: <0d688415-b4cb-3532-f02f-24c744aabffb@blastwave.org> References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> <0d688415-b4cb-3532-f02f-24c744aabffb@blastwave.org> Message-ID: <04f417be-b17a-2974-5c5b-35599a7ee90f@leo.gaspard.ninja> On 05/22/2018 11:48 PM, Dennis Clarke wrote: > On 05/22/2018 05:38 PM, Dan Kegel wrote: >> Lessee... >> https://en.wikipedia.org/wiki/GNU_Privacy_Guard >> already give an end-of-life date for 2.0, but none for 1.4. >> And since Ubuntu 16.04 includes 1.4, there are likely >> to still be a few vocal 1.4 users out there. >> >> How about announcing an end-of-life date for 1.4 that >> is in the future (say, by 3 to 6 months)? > > Too fast. Think 12 months as a minimum. There is prod code > out there running for years and a timeline that allows proper > project schedule/costing/testing would be better. If the announced end-of-life is 12 months, then people will complain for 9 months, and maybe start working on migrating during the last 3 months. I mean, I'm still seeing people actively developing python2 code bases without even thinking of migrating to python3 *now*, and retirement was initially announced for 2015? The longer you leave people with maintenance, the longer they will want maintenance past the deadline. I think 3-6 months is more than enough, and if people can't manage to update their production code in this time frame they can live with an un-maintained GnuPG until they finish migrating (unless they want to pay for paid support for continued 1.4 maintenance, that is). I don't have a personal opinion, but dropping 1.4 appears to have two advantages to me: first, it reduces the voluntary maintenance burden, and second, it may help gather funding for work on 2.3, if people choose to contract with g10code for continued maintenance. GunPG 1.4 has been out for way longer than necessary, and people are never going to migrate out of it unless they are forced to. From dclarke at blastwave.org Wed May 23 01:40:03 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 22 May 2018 19:40:03 -0400 Subject: Breaking changes In-Reply-To: <04f417be-b17a-2974-5c5b-35599a7ee90f@leo.gaspard.ninja> References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> <0d688415-b4cb-3532-f02f-24c744aabffb@blastwave.org> <04f417be-b17a-2974-5c5b-35599a7ee90f@leo.gaspard.ninja> Message-ID: <3f09295b-bab1-8fb3-47d8-3ec2c76f5fa6@blastwave.org> >>> How about announcing an end-of-life date for 1.4 that >>> is in the future (say, by 3 to 6 months)? >> >> Too fast. Think 12 months as a minimum. There is prod code >> out there running for years and a timeline that allows proper >> project schedule/costing/testing would be better. > > If the announced end-of-life is 12 months, then people will complain for > 9 months, and maybe start working on migrating during the last 3 months. > Not interested. > I mean, I'm still seeing people actively developing python2 code bases > without even thinking of migrating to python3 *now*, and retirement was > initially announced for 2015? off topic. > > The longer you leave people with maintenance, the longer they will want > maintenance past the deadline. > [1] Then a service org should exist that charges fees. > I think 3-6 months is more than enough, and if people can't manage to > update their production code in this time frame Perhaps you don't understand the complexity of a multi-tier prod env with many architectures and vendors and a lot of transaction sensitive code in place. Dennis ps: see [1] as a purchase order happens real fast sometimes with the right people involved. If Bruce Schneier says $250k then fine it gets done. Business as usual. From steffen at sdaoden.eu Wed May 23 00:15:58 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 23 May 2018 00:15:58 +0200 Subject: A postmortem on Efail In-Reply-To: <20180522213541.hmvimccsiroaafag@adversary.org> References: <20180521123430.vwfkpz4wsqpq5awn@adversary.org> <5B037029.8080401@signal100.com> <20180522213541.hmvimccsiroaafag@adversary.org> Message-ID: <20180522221558.6S8Cs%steffen@sdaoden.eu> Ben McGinnes wrote: |On Tue, May 22, 2018 at 02:19:37AM +0100, Mark Rousell wrote: |> On 21/05/2018 13:34, Ben McGinnes wrote: |> |>> I agree with most of the article and largely with the need to break ... |Mine too, it's why I keep a copy of 1.4 installed at all. It's been a I only use v1.4, and i will never never never never use anything newer because that is very large and consists of an immense amount of components that i really do not need. I receive keys via hkps:// and sign, verify, encrypt and decrypt. Having no pinentry is a bit of a problem, also because ~/ expansion is not possible in gpg.conf; but i have a small mkfifo program that feeds in the passphrase as appropriate, so this works for me. --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 gnupg at leo.gaspard.ninja Wed May 23 02:17:03 2018 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Wed, 23 May 2018 02:17:03 +0200 Subject: Breaking changes In-Reply-To: <3f09295b-bab1-8fb3-47d8-3ec2c76f5fa6@blastwave.org> References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> <0d688415-b4cb-3532-f02f-24c744aabffb@blastwave.org> <04f417be-b17a-2974-5c5b-35599a7ee90f@leo.gaspard.ninja> <3f09295b-bab1-8fb3-47d8-3ec2c76f5fa6@blastwave.org> Message-ID: On 05/23/2018 01:40 AM, Dennis Clarke wrote:>> The longer you leave people with maintenance, the longer they will want >> maintenance past the deadline. >> > > [1] Then a service org should exist that charges fees. This service org already exists, is named in the message you replied to, and is called g10code. >> I think 3-6 months is more than enough, and if people can't manage to >> update their production code in this time frame > > Perhaps you don't understand the complexity of a multi-tier prod env > with many architectures and vendors and a lot of transaction sensitive > code in place. I think I do. Such large production environments can afford paying for maintenance of what is currently GnuPG 1.4 until they complete migration. > ps: see [1] as a purchase order happens real fast sometimes with the > ???????? right people involved. If Bruce Schneier says $250k then fine > ???????? it gets done. Business as usual. From rjh at sixdemonbag.org Wed May 23 02:21:54 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 22 May 2018 20:21:54 -0400 Subject: Breaking changes In-Reply-To: <04f417be-b17a-2974-5c5b-35599a7ee90f@leo.gaspard.ninja> References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> <0d688415-b4cb-3532-f02f-24c744aabffb@blastwave.org> <04f417be-b17a-2974-5c5b-35599a7ee90f@leo.gaspard.ninja> Message-ID: > If the announced end-of-life is 12 months, then people will complain for > 9 months, and maybe start working on migrating during the last 3 months. You're an optimist. For any EOL date, a vast number of users will simply *not migrate* until they stop getting updates. The reason why is they're not subscribed to mailing lists. We could announce tomorrow's lottery numbers and they wouldn't notice. I'm fine with a 12-month EOL date. It's more important that an EOL date be made and enforced than it be any particular date. Whether it's three months, six months, twelve, I don't care, *so long as it gets done*. From dclarke at blastwave.org Wed May 23 02:46:59 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 22 May 2018 20:46:59 -0400 Subject: Breaking changes In-Reply-To: References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> <0d688415-b4cb-3532-f02f-24c744aabffb@blastwave.org> <04f417be-b17a-2974-5c5b-35599a7ee90f@leo.gaspard.ninja> Message-ID: On 05/22/2018 08:21 PM, Robert J. Hansen wrote: >> If the announced end-of-life is 12 months, then people will complain for >> 9 months, and maybe start working on migrating during the last 3 months. > > You're an optimist. For any EOL date, a vast number of users ... The real issue is the vast gulf between management and tech people and there needs to be a middle layer with decades of experience to keep the whole show functional. Dennis From ben at adversary.org Wed May 23 03:57:53 2018 From: ben at adversary.org (Ben McGinnes) Date: Wed, 23 May 2018 11:57:53 +1000 Subject: A postmortem on Efail In-Reply-To: <20180522221558.6S8Cs%steffen@sdaoden.eu> References: <20180521123430.vwfkpz4wsqpq5awn@adversary.org> <5B037029.8080401@signal100.com> <20180522213541.hmvimccsiroaafag@adversary.org> <20180522221558.6S8Cs%steffen@sdaoden.eu> Message-ID: <20180523015753.gbwisvj56k5jgsdg@adversary.org> On Wed, May 23, 2018 at 12:15:58AM +0200, Steffen Nurpmeso wrote: > > I only use v1.4, and i will never never never never use anything > newer because that is very large and consists of an immense amount > of components that i really do not need. I receive keys via hkps:// > and sign, verify, encrypt and decrypt. Having no pinentry is a bit > of a problem, also because ~/ expansion is not possible in gpg.conf; > but i have a small mkfifo program that feeds in the passphrase as > appropriate, so this works for me. Which is fine as long as no one you correspond with uses an elliptic curve key when corresponding with you. 1.4 has no support for any of the curves and they're not being backported to it. In fact the last time I tried doing anything at all with a key containing a curve even just what was supposed to be optional subkeys, 1.4 had significant problems doing anything with those keys. That sort of thing is part of the reason for maintaining a separate ~/.gnupg1 directory which was my original, pre-migration directory (combined with some shell scripts as wrappers which invoke the right version with the right configuration and enabling this: bash-4.4$ gpg1 --version gpg (GnuPG) 1.4.22 Copyright (C) 2015 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: /Users/ben/.gnupg1 Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 bash-4.4$ gpg --version gpg (GnuPG) 2.2.7 libgcrypt 1.8.2 Copyright (C) 2018 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: /Users/ben/.gnupg2 Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 bash-4.4$ Though I believe 1.4 may have been slightly modified and/or using whatever was last added to its branch rather than actually be 1.4.22's stable release. Anyway, even though my current key doesn't yet include any of the curves, I do still need more than a few components of the current branches. There are people I correspond with who use keys with curves, I also definitely need GPGME and the its Python bindings (not having them would make my work very tricky indeed). Plus the boss is a huge proponent of the modern branch and arguably its greatest advocate. ? Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From ben at adversary.org Wed May 23 04:05:47 2018 From: ben at adversary.org (Ben McGinnes) Date: Wed, 23 May 2018 12:05:47 +1000 Subject: A postmortem on Efail In-Reply-To: <1a07d378-8d91-4891-01ed-4caae011776c@riseup.net> References: <20180520104436.GA11720@aleks-PC> <1be06d81-1d81-0474-6f26-b32760fa82f4@riseup.net> <20180521133137.rzv4lsadsfsga4my@adversary.org> <1a07d378-8d91-4891-01ed-4caae011776c@riseup.net> Message-ID: <20180523020547.7dppaagn7ugeignl@adversary.org> On Mon, May 21, 2018 at 11:19:18AM -1100, Mirimir wrote: > On 05/21/2018 02:31 AM, Ben McGinnes wrote: >> >> https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions >> >> ?What if I keep getting PGP emails? >> >> You can decrypt these emails via the command line. If you prefer not >> to, notify your contacts that PGP is, for the time being, no longer >> safe to use in email clients and decide whether the conversation can >> continue over another end-to-end encrypted platform, such as Signal.? >> >> Because that couldn't possibly create a Chinese Whispers style >> situation of self-perpetuating FUD ? ? > > I hadn't seen that. Pretty stupid :( I can understand not having wanted to look too much farther after the articles on the Deep Links blog, especially the second one on the 14th. I'd been concentrating on something else and only paid it more attention a bit later, so by that stage the article also included a link at the end about the SSD updates and onward I clicked (with a sense of dread). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From ben at adversary.org Wed May 23 05:11:13 2018 From: ben at adversary.org (Ben McGinnes) Date: Wed, 23 May 2018 13:11:13 +1000 Subject: Breaking changes In-Reply-To: <04f417be-b17a-2974-5c5b-35599a7ee90f@leo.gaspard.ninja> References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> <0d688415-b4cb-3532-f02f-24c744aabffb@blastwave.org> <04f417be-b17a-2974-5c5b-35599a7ee90f@leo.gaspard.ninja> Message-ID: <20180523031113.2gfpr27m2skq5djv@adversary.org> On Wed, May 23, 2018 at 01:22:41AM +0200, Leo Gaspard via Gnupg-users wrote: > On 05/22/2018 11:48 PM, Dennis Clarke wrote: > > On 05/22/2018 05:38 PM, Dan Kegel wrote: > >> Lessee... > >> https://en.wikipedia.org/wiki/GNU_Privacy_Guard > >> already give an end-of-life date for 2.0, but none for 1.4. > >> And since Ubuntu 16.04 includes 1.4, there are likely > >> to still be a few vocal 1.4 users out there. > >> > >> How about announcing an end-of-life date for 1.4 that > >> is in the future (say, by 3 to 6 months)? > > > > Too fast. Think 12 months as a minimum. There is prod code > > out there running for years and a timeline that allows proper > > project schedule/costing/testing would be better. > > If the announced end-of-life is 12 months, then people will complain for > 9 months, and maybe start working on migrating during the last 3 months. Depends on the size of the organisation really, but yes there would be complaints if the code retained explicitly for accessing pre PGP 5 keys and data as well as running on certain types of headless systems (e.g. routers) were to be terminated in a short period of time. Which is why I doubt 1.4 will be EOL'd, but the existing policy of not updating it without a massively hugely justified reason and the ongoing and strong encouragement of migrating to 2.2. Anyway, even if this wish to expunge 1.4 were to be realised, it still would remain available in some form no matter what. This is because the GnuPG Project uses git and the 1.4 code, the 2.0 code, the 2.1 code and the 2.2 code is all in the same repo with different branches and tags and so on. Anyone even vaguely worried about losing 1.4 (don't worry, we're not revisionists) only needs to clone the whole repo somewhere and git being git, that's the entire job done. > I mean, I'm still seeing people actively developing python2 code > bases without even thinking of migrating to python3 *now*, and > retirement was initially announced for 2015? Yeah, the Py2 EOL extension was a bit excessive. Frankly it should've just been pegged to when Twisted was migrated and then paying them to do it faster. At least with GPGME's Python stuff when faced with a 2 versus 3 decision it was pretty simple: we're going with 3, albeit with a degree of support for 2.7 (i.e. it works in 2.7, but all the examples and instructions are written for 3). > The longer you leave people with maintenance, the longer they will want > maintenance past the deadline. Well, I can't argue with that after seeing what Sun's customers did. > I think 3-6 months is more than enough, and if people can't manage to > update their production code in this time frame they can live with an > un-maintained GnuPG until they finish migrating (unless they want to pay > for paid support for continued 1.4 maintenance, that is). I think you might be overestimating your familiarity with all industries which might be running it and any cases where hardware limitations or certification requirements are a factor expecially if that includes organisations which aren't, strictly speaking, standard commercial or non-profit organisations. Plus I would be rather unsurprised to learn that there were live systems utilising 1.4 in some way which really needed to remain running no matter what and if it didn't then the people in the relevant region might legitimately complain about losing power or water supply or whatever. Do I know that sort of thing is going to be a guaranteed case? No. Still, as you say, 1.4 has been active for a long time and has no doubt spread to all sorts of interesting use cases by now. In this case setting a short EOL to try to force change may not produce the result you wanted. > I don't have a personal opinion, but dropping 1.4 appears to have two > advantages to me: first, it reduces the voluntary maintenance > burden, Given how little that active burden currently is, it may not save that much and appears to be mostly backports of certain major issues which were first fixed in a more recent release. > and second, it may help gather funding for work on 2.3, if people choose > to contract with g10code for continued maintenance. That sounds rather deceptive; charging someone for maintenance of a specific product and instead of spending that on the thing they're paying for then spending it on a totally different thing that they're willing to pay to avoid having to migrate to. > GunPG 1.4 has been out for way longer than necessary, and people are > never going to migrate out of it unless they are forced to. There's a far easier way to ensure that migration without disadvantaging legitimate archival needs and it will be largely pushed by the other end users: that being when the shift to elliptic curve keys becomes standard and possibly even if it becomes a default configuration (though I expect to see more hybrid keys such as RSA primary keys and either curve subkeys or a mix of curves and asymmetric subkeys first). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From ben at adversary.org Wed May 23 05:39:42 2018 From: ben at adversary.org (Ben McGinnes) Date: Wed, 23 May 2018 13:39:42 +1000 Subject: Breaking changes In-Reply-To: References: <5B0374CF.9000608@signal100.com> Message-ID: <20180523033942.zmdhu2jjjhbtjvuw@adversary.org> On Tue, May 22, 2018 at 05:47:43AM -0400, Robert J. Hansen wrote: > > Get real. These people are long-time GnuPG users and now you want to > > throw them under the bus because... well, because you prefer it that > > way. > > 1.4 was deprecated the instant 2.0 was released. After much pushback it > was agreed to continue supporting 1.4. To be fair, 2.0 wasn't so happy on all platforms ... which is why I completely skipped it (save for one attempt to use 2.0 somewhere in the middle and one subsequent attempt to use 2.0's gpg-agent with 1.4; the former failed and the latter worked for a bit and then imploded) and only migrated once 2.1 was a thing. > But after fourteen years it's time to end it so that Werner's > limited time can be fully devoted to the 2.3 branch. Yes, well that's fair. > > Err... the specialised solution surely is GnuPG 1.4. > > Yes. And the code will still be around. It will just no longer be > maintained. If it's that important to you, you should consider > maintaining it yourself or paying someone to maintain it. Well, if the use case is solely accessing archived data (my use case for keeping it to hand or the code handy) then it's less a matter of maintaining the code base and more a case of, "as long as it compiles from now until whenever and behaves as it did, then it can access the data I need it for" and anything beyond that is just a bonus. > Well... no. It doesn't work that way. Werner gets to work on what he > wants to work on, and I think the best bang for the buck, > community-wise, is 2.3. Yep. > But if Werner were to say tomorrow, "I'm done, guys, I'm going to go > sell ice cream on the beach," I'd just say thank you, wish him well, and > wonder where the beaches were in Germany. Well it depends on which river, I guess. No one said beaches had to be by the seaside; that's just a conceit which has been largely supported by English literature. > > Isn't that effectively equivalent to commercial sponsors taking > > previously open source code base private? It's hardly a popular move > > when it happens. > > Nope. 1.4 will still be out there, just unsupported. Not to mention the little fact that all this code has been released under the current dual licenses for a *very* long time and those licenses aren't going to be broken now. > No. I'm well past the point where I care about how vocal a fringe > minority is. It's unwise to make engineering decisions based on the > volume made by a small number of people. Plus while some of us may even still have certain archives which do require the possibility of using old keys, we also generally knew about it for quite a while and thus were already aware that 1.4 was the solution and maintenance was infrequent with no guarantees. The solution was to use it on that basis and/or migrate data and if the latter isn't possible (e.g. for legal or historical preservation reasons) then make sure you know what you're doing in house with the code that is available. From my POV, as someone who still has a working copy of his original v2 key; even EOL'ing 1.4 would change nothing. I can think of some reasons why it might do bad things, but the flip side to that is the 1.4 code is a lot simpler (and self-contained), so anyone with a really scary need to maintain it should hire g10code or their own dedicated in house specialists (or both). I expect national archives and libraries will also keep copies handy for the performance of their legally mandated tasks in preserving the historical record (and if a public archive of a mailing list includes messages with signatures from v2 keys, that's the ball game from their POV and the law is the law). Still, those types of organisations are used to employing specialists in accessing legacy formats and properly archiving data, so I doubt they'll complain. It's hard to care about anything beyond that, though and I'm sure it will be a very long time before we see 1.4 not compiling on something at all. Maybe double-check after January, 2038 just in case, but otherwise ? meh. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From Roman.Fiedler at ait.ac.at Wed May 23 07:24:52 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Wed, 23 May 2018 05:24:52 +0000 Subject: AW: Breaking changes In-Reply-To: References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7C886@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > > Lessee... > https://en.wikipedia.org/wiki/GNU_Privacy_Guard > already give an end-of-life date for 2.0, but none for 1.4. > And since Ubuntu 16.04 includes 1.4, there are likely > to still be a few vocal 1.4 users out there. > > How about announcing an end-of-life date for 1.4 that > is in the future (say, by 3 to 6 months)? > ... In my opinion, just "announcing" EOL (especially with such a short notice) is quite bad practice for products aiming to be used in production setups also. This quite negatively affects trust into the product as your costs may change quite rapidly. You might argue, that companies should be used to paying for things. They are, but they want to have some planning when they are expected to pay. Would you like your car manufacturer announce, that your car is not secure any more in 6 month and that you have to pay for non-standard maintenance, if you still want to operate it securely? Apart from that: some companies using open source software are non-profit companies, like mine in research business. If our software strategy is bad - e.g. because upstream forces us suddenly to switch/pay, where we did not expect it - research funding money (mostly from the society) has to be used to keep the projects running. So when talking about EOL, gpg community should consider writing down a consistent EOL strategy, similar to those of Ubuntu, Linux kernel or others or something like I tried to argue for in the middle of https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060539.html As another poster already argued on boosting migration by pushing stronger for elliptic curve cryptography: This is very likely to motivate end users to migrate. For businesses it might be not so much: ECC within gpg is not yet approved for all kind of applications (no in-depth audit reports available yet), so RSA use will still be common for quite a time. Apart from that: due to the missing EOL strategy (see above) and the growing gpg complexity (and risks), for example we are currently experimenting using ECC without GPG for automation purposes (using the underlying crypto libraries more directly). Maybe production use of gnupg might not be a priority for gnupg in future. This might free resources otherwise needed for thinking about a sensible EOL-strategy or migration pathes. On the other hand, you might also lose feedback from audit reports/pen-testing/bug reports, which is sometimes only available from production (how many end user can reliable capture a crash every 10k hours of continued operation and distinguish it (with acceptable probabilities) from a hardware-related, hosting/virtualization infrastructure or silent kernel data corruption issue). From dank at kegel.com Wed May 23 13:56:46 2018 From: dank at kegel.com (Dan Kegel) Date: Wed, 23 May 2018 04:56:46 -0700 Subject: Breaking changes In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955B7C886@S0MSMAIL112.arc.local> References: <5B037595.2070607@signal100.com> <8a3c6066-e7ae-023c-9352-ebd2f3e908f5@monksofcool.net> <8FBA922FC32DF64382BB16C6D8A1A00B0445FD08BB@MASTER.hq.novosec.intern> <2ECE9D9EEF1F524185270138AE23265955B7C886@S0MSMAIL112.arc.local> Message-ID: On Tue, May 22, 2018 at 10:24 PM, Fiedler Roman wrote: >> https://en.wikipedia.org/wiki/GNU_Privacy_Guard >> already give an end-of-life date for 2.0, but none for 1.4. >> And since Ubuntu 16.04 includes 1.4, there are likely >> to still be a few vocal 1.4 users out there. >> >> How about announcing an end-of-life date for 1.4 that >> is in the future (say, by 3 to 6 months)? > > In my opinion, just "announcing" EOL (especially with such a short notice) is quite bad practice for products aiming to be used in production setups also. This quite negatively affects trust into the product as your costs may change quite rapidly. You might argue, that companies should be used to paying for things. They are, but they want to have some planning when they are expected to pay. Would you like your car manufacturer announce, that your car is not secure any more in 6 month and that you have to pay for non-standard maintenance, if you still want to operate it securely? > > Apart from that: some companies using open source software are non-profit companies, like mine in research business. If our software strategy is bad - e.g. because upstream forces us suddenly to switch/pay, where we did not expect it - research funding money (mostly from the society) has to be used to keep the projects running. > > So when talking about EOL, gpg community should consider writing down a consistent EOL strategy, similar to those of Ubuntu, Linux kernel or others or something like I tried to argue for in the middle of https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060539.html Yes, exactly! And taking a look at https://www.ubuntu.com/info/release-end-of-life, one sees that Ubuntu 12.04 and 14.04 have a final end of life in about February 2019; 16.04 lives until Feb 2021. To be kind to enterprise customers, GnuPG could pick one of those two dates as the EOL for 1.4. Matching 16.04's EOL would strand the fewest users, but even just matching 14.04's would make sense to a lot of people. Also, gnupg.org should add a web page like https://www.gnupg.org/release-end-of-life that lays out the EOL for all released versions; the only one with a clear EOL is 2.0.x, and that's a bit buried in text on the front page. - Dan From m16+gnupg at monksofcool.net Wed May 23 15:45:04 2018 From: m16+gnupg at monksofcool.net (Ralph Seichter) Date: Wed, 23 May 2018 15:45:04 +0200 Subject: Breaking changes In-Reply-To: References: Message-ID: <584ae73a-d6dd-e88e-3fbc-9e62ac0a8330@monksofcool.net> This thread really has me pulling my hair--what's left of it. Some core aspects from where I am standing: 1. GPG is maintained by volunteers. If you have any complaint about how this maintenance is progressing, get off your behind and be a volunteer yourself, or failing that, provide an incentive--money would be nice--to existing volunteers. See also: Gift horses, not looking in the mouth of. 2. GPG 1.4 will not suddenly vanish if it is no longer maintained. People can still use it like before. Maybe they shouldn't, but they can. 3. GPG 1.4 has been outdated for what amounts to ages in terms of software life cycles. Whoever has not migrated so far will also not migrate if you give him another 6 or 12 months. While everybody is free to stick with 1.4, nobody is required to waste resources on maintenance efforts, unless it gives him some strange pleasure to do so. I think that only a fait accompli in the form of dropping version 1.4 support will push the procrastinators in management to release necessary funds. What I percieve a lot in this thread are variations of "I wanna stay in bed for five more minutes mommy". I wonder if Werner and Robert should charge 5 EUR for every incident of whining to secure some funds? Get off your collective bums and out of bed, children! ;-) -Ralph From rjh at sixdemonbag.org Wed May 23 16:04:36 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 23 May 2018 10:04:36 -0400 Subject: Breaking changes In-Reply-To: <584ae73a-d6dd-e88e-3fbc-9e62ac0a8330@monksofcool.net> References: <584ae73a-d6dd-e88e-3fbc-9e62ac0a8330@monksofcool.net> Message-ID: <75d8609a-b66f-6c94-f5b8-5badde9f20c3@sixdemonbag.org> > What I percieve a lot in this thread are variations of "I wanna stay in > bed for five more minutes mommy". I wonder if Werner and Robert should > charge 5 EUR for every incident of whining to secure some funds? First, I am in *no way* important to GnuPG's future. I maintain a FAQ, field questions, and for the last couple of weeks have been a PR flack. Many other people do more for GnuPG than I do, and Werner does the most. Please, keep that in mind. :) Second, 1.4 isn't requiring huge resources to maintain -- it's a fairly small drain. But when problems occur, suddenly we have to track them down, fix them, test them, and release them in two branches, not one. So it's when dev time is most important -- security problems -- that the continued existence of 1.4 is most taxing. Just a thought to consider. From craigphicks at pindertek.com Wed May 23 04:35:57 2018 From: craigphicks at pindertek.com (Craig P Hicks) Date: Tue, 22 May 2018 19:35:57 -0700 Subject: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers Message-ID: At some finite date in the (hopefully) near future, most email client over GnuPG users will have an EFAIL-reading safe system setup, if they don't already. MDC will be strictly enforced. However, the situation for a secret message sending is not so good. There is no way to guarantee that the reader/receiver has updated their software and/or settings. Statistically speaking security updates are not enforced uniformly; there are always laggards. Therefore, without adequate additional precautions, there will always exist the possibility of a secret message writer/sender's message being read by an EFAIL attacker. A solution to this problem is proposed in "A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers" https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki Because each block is vulnerable, the solution works by individually protecting each block against being wholly included as part of an HTML attribute. It is possible because the attacker is restricted to dividing the message along encrypted block boundaries. The solution is very simple. The plaintext to be encrypted in a single block is divided into two parts. This first part is obfuscating string *o*, and the second part is message *m*. The choice of *o* prevents *m* from being included in the attackers attribute value. Specifically, the obfuscating string *o* must have a least the three characters single quote ('), double quote ("), and space ( ). That's enough for force the closure of the HTML attribute and protect the message *m*. You can play around with the attackers choice of starting delimiters in this Try jsoup sandbox example https://try.jsoup.org/%7E_nyXks5PuAs-zJeek8CVhpuAvtI When decrypted by the user in its raw form the total message will be human readable but a little ugly because it contains the obfuscation string *o*, but it will be safe from EFAIL. More detail is included in the above github document. Because alignment of the obfuscation part with the encryption block boundary is critical, the implementation should be done in the base module, e.g. GnuPG, rather than an email client. Of course it is not a GnuPG fault, it just happens that's the obvious safe place for this proposed solution. I've put in a request for feature to gnjpg dev, to get some feedback. I'm hoping there may be readers here willing to give critical feedback. Depending on the feedback I would try to move it forward. Craig Hicks -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndk.clanbo at gmail.com Wed May 23 23:03:47 2018 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 23 May 2018 23:03:47 +0200 Subject: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers In-Reply-To: References: Message-ID: <26be188d-b27c-ba3d-a126-3aacae10241c@gmail.com> Il 23/05/2018 04:35, Craig P Hicks ha scritto: > When decrypted by the user in its raw form the total message will be > human readable but a little ugly because it contains the obfuscation > string *o*, but it will be safe from EFAIL. While that could be OK for human-readable files, it silently alters every other content. Say *m* is a binary file (say a tar.gz) that needs automatic processing and voil? -- you broke a perfectly good use case. Say *m* is not decrypted "immediately" but archived for later use together with other (pre-patch) files. That corruption could go unnoticed for a very long time, and when it gets noticed it could have damaged a lot of archived files... IMVHO that's really bad. And all that just because a bug isn't fixed where it belongs? A security-conscious user must upgrade the programs he uses anyway. So why apply dirty workarounds? Efail is not a GPG bug, so why should it be fixed in GPG? Sure, GPG can be more picky and throw an error instead of a warning, but please do not corrupt files that will be around much longer than any buggy mail client! BYtE, Diego From 2017-r3sgs86x8e-lists-groups at riseup.net Thu May 24 01:25:25 2018 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Thu, 24 May 2018 00:25:25 +0100 Subject: Breaking changes In-Reply-To: <5fcc1324-710f-5b56-d522-b37ca8f6e213@riseup.net> References: <5B0374CF.9000608@signal100.com> <5B037922.9080804@signal100.com> <5fcc1324-710f-5b56-d522-b37ca8f6e213@riseup.net> Message-ID: <1781032663.20180524002525@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 22 May 2018 at 3:34:40 AM, in , Mirimir wrote:- > So is there anything that gpg v2.2 won't decrypt with > the option > "--ignore-mdc-error" specified? Or perhaps, with also > other "Doing > things one usually doesn't want to do." options? Yes. All support for v3 (PGP 2) keys was dropped with the release of GnuPG 2.1.0 in 2014. - -- Best regards MFPA Teamwork is essential - it allows you to blame someone else -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWwX4cF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +uo3AQCtMeZYELrt0dxPJ2/982wdfTnO04wIIvGd7gtwQcfApAD9EeznreV3NAt7 S30relocNw+jc1UXdI6iIIeCYIuz+gaJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWwX4cF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/z/RD/94TwkqVhjVBEzkoyHBu8EmY1XZ 86jLu/RBpuZGwLsmh45nfv69+MiiZz7IH89QbFZg5LSgQoJfJYzEbekLuPpnYgX2 +sA11NOd7hHaYtWQUsxx+YvfiMgf9jQxQ+SqSR/KfB8L7pJfHt3Ncwx12yDTzH/o OzTxxDjmxtDLn/HtJgEIiYE/N0rCSgu03wUm4gEBTHlvWS0t8VUq9Dtany5AErA9 myiCRGQh4xokjKxp6W3kOS+v9YK6tGHl0WfZ5i93waQgw8A/8TDmt5//GuXHlkBv STovntaIsy5ff6CGvCiKJzJF45ZmZA8CY/8jhc6y1rLNAgcIL4BA3NlAEajnht7e qv86I8SHt/vHlf93iFENuBzzDntQAoaTZN3+YF2q7zx7aW4+eUAksJVLMWZcu9vG LojOo3E9EBAcCqGodocI4i3mILxmwpGgsuJ3hJyQIg7D6j5vZ5jibj3ZXxv0Lt88 5THKVL3cF3/opENbTMPwZyG7x3R4lpuXjhZW0e80ZACIGKUJpTuQzViCw+KvDXi1 KrfTU+51zeHwmvS/FM9Hc+6udgEYH0kGnb0Q1Xued5FFciqy6vHBCM2ufxXi0zJZ Gw2bxiFaZAZMzLfJCl5qwFoNe3U9O7d814/fFvv91pGLwxZENzEEuF44SaXMKOAb ep3TVC9W8Tls03P8Ag== =kSU/ -----END PGP SIGNATURE----- From gnupg-users at spodhuis.org Thu May 24 00:05:12 2018 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Wed, 23 May 2018 18:05:12 -0400 Subject: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers In-Reply-To: References: Message-ID: <20180523220511.GA34150@osmium.lan> On 2018-05-22 at 19:35 -0700, Craig P Hicks wrote: > "A Solution for Sending Messages Safely from EFAIL-safe Senders to > EFAIL-unsafe Receivers" > > https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki There's an existing semi-standard for trying to improve email security by moving headers inside the body and having MUAs handle that consistently; the main website has gone, but the spec seems to still be up at . You might consider blending your proposal into that and talking with the Memory Hole folks (Daniel Kahn Gillmor wrote the spec) about whether or not the email headers in the header block (text/rfc822-headers section) might start with a new Efail: header which can be completely ignored for display purposes. This buys you complete independence from the type of the payload, inserting only into the headers; you lose the "first 14 bytes" part, but you were incompatible with MemoryHole anyway, and I get encrypted mail from a few MemoryHole users already, so there's a userbase there. If it's the first header, then there's nothing sensitive earlier in the encrypted message. Advocating for MUAs to default to "efail-proofed memoryhole format" for encrypted mail _might_ gain traction? -Phil From Roman.Fiedler at ait.ac.at Thu May 24 10:44:16 2018 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Thu, 24 May 2018 08:44:16 +0000 Subject: AW: Breaking changes In-Reply-To: <584ae73a-d6dd-e88e-3fbc-9e62ac0a8330@monksofcool.net> References: <584ae73a-d6dd-e88e-3fbc-9e62ac0a8330@monksofcool.net> Message-ID: <2ECE9D9EEF1F524185270138AE23265955B7CD07@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > Ralph Seichter > > This thread really has me pulling my hair--what's left of it. Some core > aspects from where I am standing: > > 1. GPG is maintained by volunteers. If you have any complaint about how > this maintenance is progressing, get off your behind and be a volunteer > yourself, or failing that, provide an incentive--money would be nice--to > existing volunteers. See also: Gift horses, not looking in the mouth of. > ... > Get off your collective bums and out of bed, children! ;-) Well, I quite invested some time in trying to argue for optimization of different parts of the gnupg product strategy. I also tried to offer to participate in writing down use-cases, do requirement engineering and EOL procedure optimization, e.g. see bottom of [1]. Maybe you do not know, what effort is behind that, or maybe you do but such offers are of no value for gnupg community, as they do not match the current strategy or maybe there is some other reason I do not know about (but I am interested in) for your replying that way. LG Roman [1] https://www.mail-archive.com/gnupg-users at gnupg.org/msg35222.html From craigphicks at pindertek.com Thu May 24 05:03:17 2018 From: craigphicks at pindertek.com (Craig P Hicks) Date: Wed, 23 May 2018 20:03:17 -0700 Subject: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers In-Reply-To: <20180523220511.GA34150@osmium.lan> References: <20180523220511.GA34150@osmium.lan> Message-ID: Thanks Phil. Very interesting! I will look into that. On Wed, May 23, 2018 at 3:05 PM, Phil Pennock wrote: > On 2018-05-22 at 19:35 -0700, Craig P Hicks wrote: > > "A Solution for Sending Messages Safely from EFAIL-safe Senders to > > EFAIL-unsafe Receivers" > > > > https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki > > There's an existing semi-standard for trying to improve email security > by moving headers inside the body and having MUAs handle that > consistently; the main website has gone, but the spec seems to still be > up at . > > You might consider blending your proposal into that and talking with the > Memory Hole folks (Daniel Kahn Gillmor wrote the spec) about whether or > not the email headers in the header block (text/rfc822-headers section) > might start with a new Efail: header which can be completely ignored for > display purposes. > > This buys you complete independence from the type of the payload, > inserting only into the headers; you lose the "first 14 bytes" part, but > you were incompatible with MemoryHole anyway, and I get encrypted mail > from a few MemoryHole users already, so there's a userbase there. If > it's the first header, then there's nothing sensitive earlier in the > encrypted message. Advocating for MUAs to default to "efail-proofed > memoryhole format" for encrypted mail _might_ gain traction? > > -Phil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trinh.randy at gmail.com Thu May 24 21:46:58 2018 From: trinh.randy at gmail.com (Randy Trinh) Date: Thu, 24 May 2018 15:46:58 -0400 Subject: gpgme: environment variable not set Message-ID: I have recently cross compiled gpgme for a program I am working on but gpgme fails to function as expected as I get an error saying an environment variable cannot be found -- verbose in this case doesn't really elaborate on what that missing environment variable may be. This happens when I try to import a key and then decrypt a file -- the import returns a success but I assume only the public key has been imported because the decrypt error claims there is no secret key. I have checked gpgconf --check-program and noticed that the scdaemon path is incorrect but I both don't know how to change the path -- and whether or not that will fix it. Does anyone have any possible idea as to why I can't seem to access my private-keys on my cross compiled device? Thanks in advance, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard.kleine at gmx.net Sat May 26 16:22:35 2018 From: bernhard.kleine at gmx.net (Bernhard Kleine) Date: Sat, 26 May 2018 16:22:35 +0200 Subject: Focus of pinentry is not maintained when switching forth to password safe and back to pinentry. (win7) Message-ID: <3eb362dc-2666-3b33-b312-eae85ed490fd@gmx.net> I found a change of behaviour of pinentry. Win7, Thunderbird with newest enigmal, password safe. When I send a signed message, Pinentry opens and asks for the password. With Alt-tab I switch to the Password manager?, copy the password with ctrl-C and switch back to pinentry. However, the pinentry focus is lost. I have already asked Patrick Brunschwig in the enigmail maillist and he suggested to change the gpg-agent.conf to a single line: grab This hoever, did not bring the focus back to Pinentry. What do you suggest? Regards Bernhard -- spitzhalde9 D-79853 lenzkirch bernhard.kleine at gmx.net www.b-kleine.com, www.urseetal.net - thunderbird mit enigmail GPG schl?ssel: D5257409 fingerprint: 08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon May 28 13:15:03 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 May 2018 13:15:03 +0200 Subject: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers In-Reply-To: <20180523220511.GA34150@osmium.lan> (Phil Pennock's message of "Wed, 23 May 2018 18:05:12 -0400") References: <20180523220511.GA34150@osmium.lan> Message-ID: <87efhwjako.fsf@wheatstone.g10code.de> On Thu, 24 May 2018 00:05, gnupg-users at spodhuis.org said: > up at . Given that I see more and more mails with "Encrypted mail" as subject, this feature is getting more and more annoying. It will eventually not anymore possible to pre-sort mails as it is commonly done either mental of by tools. Well, some MUAs might be able to auto-decrypt whole folders but that opens a more severe security problem (e.g. Tempest oracle) than having a plaintext subject. We can't enforce technical security without proper OPSEC. Regarding the Subject, Reference, etc, it is way easy and more secure to educate the user about the fact that only the content is _end-to-end_ encrypted and other parts, like the Subject, are required to be plaintext for proper routing and mail handling. Regarding the subject there is a simple and also fun solution: If you need to hide the subject, use a nonsense phrase instead. Such a phrase makes mental pre-sorting as effecitive as an on-topic subject. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon May 28 13:20:36 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 May 2018 13:20:36 +0200 Subject: gpgme: environment variable not set In-Reply-To: (Randy Trinh's message of "Thu, 24 May 2018 15:46:58 -0400") References: Message-ID: <87a7skjabf.fsf@wheatstone.g10code.de> On Thu, 24 May 2018 21:46, trinh.randy at gmail.com said: > I have recently cross compiled gpgme for a program I am working on but > gpgme fails to function as expected as I get an error saying an environment > variable cannot be found -- verbose in this case doesn't really elaborate > on what that missing environment variable may be. Use GPGME_DEBUG=9:logfile: yourprogram to see what is going on. > I have checked gpgconf --check-program and noticed that the scdaemon path > is incorrect but I both don't know how to change the path -- and whether or Let us konow why you think it is incorrect. For example scdaemon is by default installed to /usr/local/libexec - which is correct according to some file system standards but not by all. But it does not matter all tools starting at the gpgme library have a consistent view of which components are to be run. > Does anyone have any possible idea as to why I can't seem to access my > private-keys on my cross compiled device? Decrypt by hand (i.e. "gpg -v -d ....") to check additional diagnostics. If that doe not help, configure a log file for gpg-agent. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue May 29 00:39:18 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 28 May 2018 18:39:18 -0400 Subject: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers In-Reply-To: <87efhwjako.fsf@wheatstone.g10code.de> References: <20180523220511.GA34150@osmium.lan> <87efhwjako.fsf@wheatstone.g10code.de> Message-ID: > Regarding the subject there is a simple and also fun solution: If you > need to hide the subject, use a nonsense phrase instead. Such a phrase > makes mental pre-sorting as effecitive as an on-topic subject. Or, better, use a system of random nonsense phrases. Let's say you have seven different subjects that you regularly correspond about via private emails -- corresponding to seven different business customers, whatever. For each customer you've got sales, marketing, provisioning, support, R&D. Seven customers. You need a group that has seven elements. Colors: red, orange, yellow, green, blue, indigo, violet. Five different types of subjects: five permanent members of the U.N. Security Council (the U.S., Britain, France, Russia, China). You can now map a phrase like INDIGO FRANCE to a customer and a task type. Different threads get -A, -B, -C, -D suffixes: some random word beginning with that letter will suffice. INDIGO FRANCE DERELICT would refer to "the IBM contract, R&D work, the fourth thread." Sure, this only obscures the subject. It exposes the metadata and allows an attacker to monitor what the communication patterns are like. But honestly, that's plenty good enough for the vast majority of confidential emails... From franek.wiertara at onet.eu Tue May 29 10:47:55 2018 From: franek.wiertara at onet.eu (franek.wiertara) Date: Tue, 29 May 2018 10:47:55 +0200 Subject: Installing a new version of GnuPG Message-ID: <184316453-be9d5ef6d81f41d4881ae8dfed11b5e7@pmq2v.m5r2.onet> Hi, ? A year ago or so, don't remember exactly, I installed GnuPG 2.2.0 from sources with all required libraries. I donwloaded them from the GnuPG website and created binaries using standard "./configure && make && make install". It's turned out I don't have any folder from which I run "make install", so I cannot run uninstall anything using "make uninstall". Do you think it is all right if I simply download new version of gnupg and libraries and simply overwrite on anything that already exists? ? Thanks ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From skquinn at rushpost.com Tue May 29 10:54:37 2018 From: skquinn at rushpost.com (Shawn K. Quinn) Date: Tue, 29 May 2018 03:54:37 -0500 Subject: Installing a new version of GnuPG In-Reply-To: <184316453-be9d5ef6d81f41d4881ae8dfed11b5e7@pmq2v.m5r2.onet> References: <184316453-be9d5ef6d81f41d4881ae8dfed11b5e7@pmq2v.m5r2.onet> Message-ID: <542568c4-4535-9f56-75df-4629c33e327f@rushpost.com> On 05/29/2018 03:47 AM, franek.wiertara wrote: > Hi, > ? > A year ago or so, don't remember exactly, I installed GnuPG 2.2.0 from > sources with all required libraries. I donwloaded them from the GnuPG > website and created binaries using standard "./configure && make && make > install". It's turned out I don't have any folder from which I run "make > install", so I cannot run uninstall anything using "make uninstall". Do > you think it is all right if I simply download new version of gnupg and > libraries and simply overwrite on anything that already exists? > ? > Thanks Back when I ran Slackware and I had to install just about anything of substance this way, this is pretty much what I did. It's far from an optimal way to upgrade software (occasionally, stuff needs to be deleted that's no longer in use) but it got me by until I switched to other GNU/Linux distributions. Most software does not have a "make uninstall" target. That's considered the responsibility of a package manager if you have one. -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com From bonala.surya at gmail.com Mon May 28 22:05:07 2018 From: bonala.surya at gmail.com (bonala surya) Date: Tue, 29 May 2018 01:35:07 +0530 Subject: Getting error for gpg Message-ID: Hi Team We facing the issue while decrypting the files in our environment. Getting error like waiting for the lock.... as part of a work around we are removing the trustdb.gpg.lock and still the issue is repeating Could please assist us do the need full. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at boyandin.info Tue May 29 16:39:29 2018 From: lists at boyandin.info (Konstantin Boyandin) Date: 29 May 2018 10:39:29 -0400 Subject: Installing a new version of GnuPG In-Reply-To: <184316453-be9d5ef6d81f41d4881ae8dfed11b5e7@pmq2v.m5r2.onet> References: <184316453-be9d5ef6d81f41d4881ae8dfed11b5e7@pmq2v.m5r2.onet> Message-ID: <7d4c978c-d27b-45de-a4fb-a42d8f16fdf1@mtasv.net> Hi, This (doing 'make' and 'make install') is what I did from time to time on Ubuntu (currently 16.04). I used default path/prefixes, and after having installed it I rename GnuPG executable /usr/local/bin/gpg to /usr/local/bin/gpg2 Since /usr/local/bin precedes other default PATH components, gpg2 invokes the manually built GnuPG 2.2.*. That allows me to keep the gnupg2 package (it installs /usr/bin/gpg2; several other packages I use depend on gnupg2), while actually using the manually built one. That also prevents apt and certain other programs using /usr/bin/gpg from breaking (when they import a key, for example). So far, no problems with the above approach. Sincerely, Konstantin On 29.05.2018 15:47, franek.wiertara wrote: > Hi, > ? > A year ago or so, don't remember exactly, I installed GnuPG 2.2.0 from > sources with all required libraries. I donwloaded them from the GnuPG > website and created binaries using standard "./configure && make && make > install". It's turned out I don't have any folder from which I run "make > install", so I cannot run uninstall anything using "make uninstall". Do > you think it is all right if I simply download new version of gnupg and > libraries and simply overwrite on anything that already exists? > ? > Thanks From mirimir at riseup.net Tue May 29 21:22:33 2018 From: mirimir at riseup.net (Mirimir) Date: Tue, 29 May 2018 08:22:33 -1100 Subject: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers In-Reply-To: <87efhwjako.fsf@wheatstone.g10code.de> References: <20180523220511.GA34150@osmium.lan> <87efhwjako.fsf@wheatstone.g10code.de> Message-ID: <2ce0ab6c-cfb6-ae5c-029f-4d95e44b8623@riseup.net> On 05/28/2018 12:15 AM, Werner Koch wrote: > On Thu, 24 May 2018 00:05, gnupg-users at spodhuis.org said: > >> up at . > > Given that I see more and more mails with "Encrypted mail" as subject, > this feature is getting more and more annoying. It will eventually not > anymore possible to pre-sort mails as it is commonly done either mental > of by tools. Well, some MUAs might be able to auto-decrypt whole > folders but that opens a more severe security problem (e.g. Tempest > oracle) than having a plaintext subject. That is problematic for me, because I choose to store messages encrypted. My correspondents and I do use generic subject, but it's not uncommon to have long, branching threads. So it's very difficult to find old stuff. No search, without mass decryption. Maybe Enigmail needs a search extension ;) > We can't enforce technical security without proper OPSEC. Regarding the > Subject, Reference, etc, it is way easy and more secure to educate the > user about the fact that only the content is _end-to-end_ encrypted and > other parts, like the Subject, are required to be plaintext for proper > routing and mail handling. I've started playing with HeaderToolsLite in Thunderbird. One can redact many headers without affecting delivery, as I recall. But it's tedious. Maybe I ought to go back to terminal clients. > Regarding the subject there is a simple and also fun solution: If you > need to hide the subject, use a nonsense phrase instead. Such a phrase > makes mental pre-sorting as effecitive as an on-topic subject. Or perhaps ~25 character ~random strings. That way, I could easily keep notes about threads that I care about. That wouldn't be in Thunderbird, and the VM host is LUKS encrypted. Or I could use tomb. > Shalom-Salam, > > Werner > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From mwood at iupui.edu Wed May 30 15:09:10 2018 From: mwood at iupui.edu (Mark H. Wood) Date: Wed, 30 May 2018 09:09:10 -0400 Subject: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers In-Reply-To: <2ce0ab6c-cfb6-ae5c-029f-4d95e44b8623@riseup.net> References: <20180523220511.GA34150@osmium.lan> <87efhwjako.fsf@wheatstone.g10code.de> <2ce0ab6c-cfb6-ae5c-029f-4d95e44b8623@riseup.net> Message-ID: <20180530130910.GA9667@IUPUI.Edu> On Tue, May 29, 2018 at 08:22:33AM -1100, Mirimir wrote: > On 05/28/2018 12:15 AM, Werner Koch wrote: > > On Thu, 24 May 2018 00:05, gnupg-users at spodhuis.org said: > > > >> up at . > > > > Given that I see more and more mails with "Encrypted mail" as subject, > > this feature is getting more and more annoying. It will eventually not > > anymore possible to pre-sort mails as it is commonly done either mental > > of by tools. Well, some MUAs might be able to auto-decrypt whole > > folders but that opens a more severe security problem (e.g. Tempest > > oracle) than having a plaintext subject. > > That is problematic for me, because I choose to store messages > encrypted. My correspondents and I do use generic subject, but it's not > uncommon to have long, branching threads. So it's very difficult to find > old stuff. No search, without mass decryption. Maybe Enigmail needs a > search extension ;) I think that this points out something: while integrity and authenticity may be bolted on using third-party packages, secrecy must be organic to an email agent. If there is to be a "Real-Subject:" header within the encrypted payload, then user agents must look for it and handle it appropriately. This probably includes extracting and indexing suitable encrypted labels upon decryption. But that then means that the index records must be encrypted. As is often the case with devising secure facilities, much of the difficulty lies not in how to do things but in knowing where to look for things to be done. Each subset of the consumers of security practice (email is only one) needs a few trusted sources of up-to-date best practice which focus on the ways in which that subset may be usefully attacked. To do good, not only must such sources exist; they must be widely known and valued, so that people who build software will consult them regularly when planning new projects or overhauling existing ones. > > We can't enforce technical security without proper OPSEC. Regarding the > > Subject, Reference, etc, it is way easy and more secure to educate the > > user about the fact that only the content is _end-to-end_ encrypted and > > other parts, like the Subject, are required to be plaintext for proper > > routing and mail handling. Hear, hear. -- 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 tookmund at gmail.com Wed May 30 17:22:43 2018 From: tookmund at gmail.com (Jacob Adams) Date: Wed, 30 May 2018 11:22:43 -0400 Subject: GPGME export secret subkeys Message-ID: <6efe6fe6-3da8-c831-fad3-bddc7394a419@gmail.com> GPGME has export and import functions that work well as alternatives to "gpg --import" and "gpg --export". However, looking through the documentation I cannot find an equivalent to "gpg --export-secret-subkeys". Have I missed something, or does such functionality not yet exist? Thanks, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed May 30 20:00:39 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 May 2018 20:00:39 +0200 Subject: GPGME export secret subkeys In-Reply-To: <6efe6fe6-3da8-c831-fad3-bddc7394a419@gmail.com> (Jacob Adams's message of "Wed, 30 May 2018 11:22:43 -0400") References: <6efe6fe6-3da8-c831-fad3-bddc7394a419@gmail.com> Message-ID: <87fu29f2go.fsf@wheatstone.g10code.de> On Wed, 30 May 2018 17:22, tookmund at gmail.com said: > GPGME has export and import functions that work well as alternatives to > "gpg --import" and "gpg --export". However, looking through the > documentation I cannot find an equivalent to "gpg > --export-secret-subkeys". Have I missed something, or does such > functionality not yet exist? GPGME does not support all features of gpg; that is to avoid creating a too baroque API. If you need this you can resort to the gpgme_op_spawn API. For example here is how we make sure in GPA that the gpg-agent is started (required for direct smartcard operations). --8<---------------cut here---------------start------------->8--- void gpa_start_agent (void) { gpg_error_t err; gpgme_ctx_t ctx; char *pgm; const char *argv[3]; pgm = get_gpg_connect_agent_path (); if (!pgm) { g_message ("tool to start the agent is not available"); return; } ctx = gpa_gpgme_new (); gpgme_set_protocol (ctx, GPGME_PROTOCOL_SPAWN); argv[0] = ""; /* Auto-insert the basename. */ argv[1] = "NOP"; argv[2] = NULL; err = gpgme_op_spawn (ctx, pgm, argv, NULL, NULL, NULL, GPGME_SPAWN_DETACHED); if (err) g_message ("error running '%s': %s", pgm, gpg_strerror (err)); g_free (pgm); gpgme_release (ctx); } --8<---------------cut here---------------end--------------->8--- You need to adjust it for your needs; for example the first fucntion call should be get_gpg_path which can be implemented this way: --8<---------------cut here---------------start------------->8--- static const gchar * get_gpg_path (void) { gpgme_engine_info_t engine; gpgme_get_engine_info (&engine); while (engine) { if (engine->protocol == GPGME_PROTOCOL_OpenPGP) return engine->file_name; engine = engine->next; } return NULL; } --8<---------------cut here---------------end--------------->8--- Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tookmund at gmail.com Thu May 31 17:25:41 2018 From: tookmund at gmail.com (Jacob Adams) Date: Thu, 31 May 2018 11:25:41 -0400 Subject: GPGME export secret subkeys In-Reply-To: <87fu29f2go.fsf@wheatstone.g10code.de> References: <6efe6fe6-3da8-c831-fad3-bddc7394a419@gmail.com> <87fu29f2go.fsf@wheatstone.g10code.de> Message-ID: On 05/30/2018 02:00 PM, Werner Koch wrote: > On Wed, 30 May 2018 17:22, tookmund at gmail.com said: >> GPGME has export and import functions that work well as alternatives to >> "gpg --import" and "gpg --export". However, looking through the >> documentation I cannot find an equivalent to "gpg >> --export-secret-subkeys". Have I missed something, or does such >> functionality not yet exist? > > GPGME does not support all features of gpg; that is to avoid creating a > too baroque API. If you need this you can resort to the gpgme_op_spawn > API. Ah ok thank you. That's definitely more sensible than having a function for everything. > For example here is how we make sure in GPA that the gpg-agent is > started (required for direct smartcard operations). > > > --8<---------------cut here---------------start------------->8--- > void > gpa_start_agent (void) > { > gpg_error_t err; > gpgme_ctx_t ctx; > char *pgm; > const char *argv[3]; > > pgm = get_gpg_connect_agent_path (); > if (!pgm) > { > g_message ("tool to start the agent is not available"); > return; > } > > ctx = gpa_gpgme_new (); > gpgme_set_protocol (ctx, GPGME_PROTOCOL_SPAWN); > argv[0] = ""; /* Auto-insert the basename. */ > argv[1] = "NOP"; > argv[2] = NULL; > err = gpgme_op_spawn (ctx, pgm, argv, NULL, NULL, NULL, GPGME_SPAWN_DETACHED); > if (err) > g_message ("error running '%s': %s", pgm, gpg_strerror (err)); > g_free (pgm); > gpgme_release (ctx); > } > --8<---------------cut here---------------end--------------->8--- > > You need to adjust it for your needs; for example the first fucntion > call should be get_gpg_path which can be implemented this way: > > --8<---------------cut here---------------start------------->8--- > static const gchar * > get_gpg_path (void) > { > gpgme_engine_info_t engine; > > gpgme_get_engine_info (&engine); > while (engine) > { > if (engine->protocol == GPGME_PROTOCOL_OpenPGP) > return engine->file_name; > engine = engine->next; > } > return NULL; > } > --8<---------------cut here---------------end--------------->8--- > I'm using the python bindings and actually having a bit of trouble with op_spawn. I've fallen back on setting GNUPGHOME and calling python's subprocess.run which pretty much does the same thing. The simple test case attached fails for me with: Traceback (most recent call last): File "/tmp/opspawn.py", line 7, in ctx.op_spawn(gpgbin, ['', '--version'], None, out, None, 0) File "/usr/local/lib/python3.6/dist-packages/gpg/core.py", line 151, in wrapper return _funcwrap(self, *args) File "/usr/local/lib/python3.6/dist-packages/gpg/core.py", line 132, in _funcwrap result = func(slf.wrapped, *args) File "/usr/local/lib/python3.6/dist-packages/gpg/gpgme.py", line 2267, in gpgme_op_spawn return _gpgme.gpgme_op_spawn(ctx, file, argv, datain, dataout, dataerr, flags) TypeError: in method 'gpgme_op_spawn', argument 5 of type 'gpgme_data_t' Like I said it's not really a problem since I'm using subprocess but I thought I should report it nonetheless. Thanks, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: opspawn.py Type: text/x-python Size: 244 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 kookie at spacekookie.de Thu May 31 16:12:56 2018 From: kookie at spacekookie.de (kookie at spacekookie.de) Date: Thu, 31 May 2018 16:12:56 +0200 (CEST) Subject: Problem signing git commits with smartcard key Message-ID: <393566227.63640.1527775976783@office.mailbox.org> Hey there, I have a yubikey 4 that contains my GPG key. I can use the `gpg2` tool to sign messages without problems. But when I try to do the same with git, it fails. The command that git runs internally is equivalent to this: echo "This is a stream from git..." | gpg2 --status-fd=2 -bsau 555F2E4B6F87F91A4110669E90734A9E619C8A6C Which outputs the following error: [GNUPG:] KEY_CONSIDERED 555F2E4B6F87F91A4110669E90734A9E619C8A6C 0 [GNUPG:] BEGIN_SIGNING H8 gpg: signing failed: Invalid ID [GNUPG:] FAILURE sign 100663414 gpg: signing failed: Invalid ID I can sign commits correctly with a new key I made on my computer instead of on the yubikey and I'm trying to understand why this is. Generally these error messages are very cryptic and I've had a hard time finding out things about them. Any help would be appreciated, thank you! -- Katharina 'spacekookie' Fey From tookmund at gmail.com Thu May 31 19:21:31 2018 From: tookmund at gmail.com (Jacob Adams) Date: Thu, 31 May 2018 13:21:31 -0400 Subject: Problem signing git commits with smartcard key In-Reply-To: <393566227.63640.1527775976783@office.mailbox.org> References: <393566227.63640.1527775976783@office.mailbox.org> Message-ID: <2b02cdab-a58a-7826-40bd-49aac53bb6ec@gmail.com> On 05/31/2018 10:12 AM, kookie at spacekookie.de wrote: > Hey there, > > I have a yubikey 4 that contains my GPG key. I can use the `gpg2` tool to sign messages without problems. But when I try to do the same with git, it fails. The command that git runs internally is equivalent to this: > > echo "This is a stream from git..." | gpg2 --status-fd=2 -bsau 555F2E4B6F87F91A4110669E90734A9E619C8A6C > > Which outputs the following error: > > [GNUPG:] KEY_CONSIDERED 555F2E4B6F87F91A4110669E90734A9E619C8A6C 0 > [GNUPG:] BEGIN_SIGNING H8 > gpg: signing failed: Invalid ID > [GNUPG:] FAILURE sign 100663414 > gpg: signing failed: Invalid ID I think this is simply because you have the wrong key id in your command (Thus "Invalid ID"). Assuming that the key on hkps.pool.sks-keyservers.net is correct, your key id should be 9F18A093CF65F938E4C8EFA429E057516FE1BBF3, not 555F2E4B6F87F91A4110669E90734A9E619C8A6C Hope this helps, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu May 31 19:41:44 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 May 2018 19:41:44 +0200 Subject: Problem signing git commits with smartcard key In-Reply-To: <393566227.63640.1527775976783@office.mailbox.org> (kookie@spacekookie.de's message of "Thu, 31 May 2018 16:12:56 +0200 (CEST)") References: <393566227.63640.1527775976783@office.mailbox.org> Message-ID: <87po1bd8o7.fsf@wheatstone.g10code.de> On Thu, 31 May 2018 16:12, kookie at spacekookie.de said: > [GNUPG:] FAILURE sign 100663414 > gpg: signing failed: Invalid ID $ gpg-error 100663414 100663414 = (6, 118) = (GPG_ERR_SOURCE_SCD, GPG_ERR_INV_ID) = (SCD, Invalid ID) This shows that the error originates from scdaemon. To look deeper into this you should put --8<---------------cut here---------------start------------->8--- log-file /foo/bar/scd.log debug ipc verbose --8<---------------cut here---------------end--------------->8--- into ~/.gnupg/scdaemon.conf and gpgconf --kill scdaemon [1]. If you can't see anything please add a line "debug cardio" to the avove conf file. When posting anything take care: the latter option may reveal you PIN in the log. If you don't see anything post the log or send it to me by PM. Shalom-Salam, Werner [1] For live debugging in another tty look for watchgnupg in the manual. -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kookie at spacekookie.de Thu May 31 20:46:29 2018 From: kookie at spacekookie.de (kookie at spacekookie.de) Date: Thu, 31 May 2018 20:46:29 +0200 (CEST) Subject: Problem signing git commits with smartcard key In-Reply-To: <87po1bd8o7.fsf@wheatstone.g10code.de> References: <393566227.63640.1527775976783@office.mailbox.org> <87po1bd8o7.fsf@wheatstone.g10code.de> Message-ID: <892150189.14799.1527792389874@office.mailbox.org> Hey there, thanks for the reply :) > On 31 May 2018 at 19:41 Werner Koch wrote: > > > On Thu, 31 May 2018 16:12, kookie at spacekookie.de said: > > > [GNUPG:] FAILURE sign 100663414 > > gpg: signing failed: Invalid ID > > $ gpg-error 100663414 > 100663414 = (6, 118) = (GPG_ERR_SOURCE_SCD, GPG_ERR_INV_ID) = (SCD, Invalid ID) > > This shows that the error originates from scdaemon. To look deeper > into this you should put > > ... So I did that, tried the whole thing again and this was spat out into the log: ```````````````````````````````````````````````````````````` 2018-05-31 20:27:42 scdaemon[17755] DBG: chan_7 <- SERIALNO --demand=D2760001240102010006073194820000 2018-05-31 20:27:42 scdaemon[17755] ccid open error: skip 2018-05-31 20:27:42 scdaemon[17755] DBG: chan_7 -> S SERIALNO D2760001240102010006073194820000 2018-05-31 20:27:42 scdaemon[17755] DBG: chan_7 -> OK 2018-05-31 20:27:42 scdaemon[17755] DBG: chan_7 <- SETDATA 3031300D060960864801650304020105000420549B2B42DD5A5ED9F091E8614C838BA32CF21D67C8D83115B89A2738797BFCA0 2018-05-31 20:27:42 scdaemon[17755] DBG: chan_7 -> OK 2018-05-31 20:27:42 scdaemon[17755] DBG: chan_7 <- PKSIGN --hash=sha256 OPENPGP.2 2018-05-31 20:27:42 scdaemon[17755] operation sign result: Invalid ID 2018-05-31 20:27:42 scdaemon[17755] app_sign failed: Invalid ID 2018-05-31 20:27:42 scdaemon[17755] DBG: chan_7 -> ERR 100663414 Invalid ID 2018-05-31 20:27:42 scdaemon[17755] DBG: chan_7 <- RESTART 2018-05-31 20:27:42 scdaemon[17755] DBG: chan_7 -> OK ```````````````````````````````````````````````````````````` tbh...I'm very much not sure what that means. Anything in there that gives you a clue what might be going wrong? ~ Katharina From wk at gnupg.org Thu May 31 21:12:58 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 May 2018 21:12:58 +0200 Subject: Problem signing git commits with smartcard key In-Reply-To: <892150189.14799.1527792389874@office.mailbox.org> (kookie@spacekookie.de's message of "Thu, 31 May 2018 20:46:29 +0200 (CEST)") References: <393566227.63640.1527775976783@office.mailbox.org> <87po1bd8o7.fsf@wheatstone.g10code.de> <892150189.14799.1527792389874@office.mailbox.org> Message-ID: <876033d4g5.fsf@wheatstone.g10code.de> On Thu, 31 May 2018 20:46, kookie at spacekookie.de said: > 2018-05-31 20:27:42 scdaemon[17755] DBG: chan_7 <- PKSIGN --hash=sha256 OPENPGP.2 > 2018-05-31 20:27:42 scdaemon[17755] operation sign result: Invalid ID You are signing with the second key of the token. This is an encryption key and thus not able to sign. If you do a "gpg -card-status" can you see an Signature key (In the log "OpenPGP.1")? I am not so into the Yubikey thing; others might be better able to help. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: