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 alon.barlev at gmail.com Sat May 5 22:07:00 2018 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 05 May 2018 20:07:00 +0000 Subject: [tests] seccomp fails Message-ID: Hi, The seccomp tests are failing, I am almost sure these worked in the past. FAIL: dtls-with-seccomp FAIL: tls-with-seccomp FAIL: dtls-client-with-seccomp FAIL: tls-client-with-seccomp Attached a log for example. Any clue? I cannot see anything I can decipher. Kernel 4.9.95 has CONFIG_SECCOMP=y sys-libs/libseccomp-2.3.2. Thanks! Alon -------------- next part -------------- A non-text attachment was scrubbed... Name: tls-client-with-seccomp.log Type: text/x-log Size: 2486 bytes Desc: not available URL: From ineiev at gnu.org Sun May 6 09:47:57 2018 From: ineiev at gnu.org (Ineiev) Date: Sun, 6 May 2018 03:47:57 -0400 Subject: [PATCH STABLE-BRANCH-2-2] doc: Displayed values of trust Message-ID: <20180506074757.GG8919@gnu.org> Hello, I've noticed that the documentation of --edit-key is outdated: it says that the trust values are displayed with letters, whereas they are shown with strings. A tentative patch to update the documentation is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-doc-Update-description-of-displayed-trust-values.patch Type: text/x-diff Size: 5141 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From bigon at bigon.be Tue May 8 11:56:45 2018 From: bigon at bigon.be (Laurent Bigonville) Date: Tue, 8 May 2018 11:56:45 +0200 Subject: Multiple readers with scdaemon Message-ID: Hello, I recently bought a yubikey. When connecting it to my laptop that already has a smartcard reader, gnupg is not detecting it when using pcscd. I discovered that the readers detected by scdeamon is linked to the order the reader has been initialized by pcscd and only the first reader is used (as written in the manpage). To make my yubikey work I had to add a "reader-port" option with (a substring of) the yubikey name, but surprisingly if the yubikey is not present it fails back to the other reader. The situation is a bit weird, at the same time scdaemon is only using the first reader by default, adding "reader-port" make scdaemon uses that reader except if not present. Don't get me wrong the fact that fails back to the 1st reader is "good" in the sense that in the end it allows the use of 2 readers, but it's just weird IMHO. Are there any plans to support multiples readers? Shouldn't "reader-port" makes scdeamon really stick to that reader and not fallback if not present (hasn't that security implications?) Shouldn't "reader-port" matches the full name of the reader instead of a substring of it? Kind regards, Laurent Bigonville PS: I lost access to the email address of the account on the BTS, is there a way to reset the password of it without? From gniibe at fsij.org Wed May 9 02:11:53 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 09 May 2018 09:11:53 +0900 Subject: Multiple readers with scdaemon In-Reply-To: References: Message-ID: <87mux9r8l2.fsf@iwagami.gniibe.org> Laurent Bigonville wrote: > Are there any plans to support multiples readers? When you can disable PC/SC, multiple readers are supported by the internal CCID driver of scdaemon (through libusb, directly). Currently, I don't have a specific plan to support multiple readers with PC/SC. There are different PC/SC implementations, I mean, the one of Windows, the one of macOS, and pcsc-lite+libccid. In this situation, it is a bit harder for me to introduce new feature to scdaemon with PC/SC. I could test with pcsc-lite, but major users of scdaemon with PC/SC are on Windows or macOS. And it seems for me that PC/SC is not actively developed on Windows and macOS. If it is the case, I'd like to put my energy to the internal CCID driver. BTW, I'm curious if the internal CCID driver can be used on Windows and macOS. -- From bigon at bigon.be Wed May 9 13:49:46 2018 From: bigon at bigon.be (Laurent Bigonville) Date: Wed, 9 May 2018 13:49:46 +0200 Subject: Multiple readers with scdaemon In-Reply-To: <87mux9r8l2.fsf@iwagami.gniibe.org> References: <87mux9r8l2.fsf@iwagami.gniibe.org> Message-ID: Le 09/05/18 ? 02:11, NIIBE Yutaka a ?crit?: > Laurent Bigonville wrote: >> Are there any plans to support multiples readers? > When you can disable PC/SC, multiple readers are supported by the > internal CCID driver of scdaemon (through libusb, directly). In that case I cannot use other smartcards if scdaemon is still running, this is quite annoying. > Currently, I don't have a specific plan to support multiple readers with > PC/SC. There are different PC/SC implementations, I mean, the one of > Windows, the one of macOS, and pcsc-lite+libccid. In this situation, it > is a bit harder for me to introduce new feature to scdaemon with PC/SC. > I could test with pcsc-lite, but major users of scdaemon with PC/SC are > on Windows or macOS. > > And it seems for me that PC/SC is not actively developed on Windows and > macOS. If it is the case, I'd like to put my energy to the internal > CCID driver. > > BTW, I'm curious if the internal CCID driver can be used on Windows and > macOS. Isn't pcsc-lite used on MacOSX the same as the one on GNU/Linux? From dirk.gottschalk1980 at googlemail.com Sat May 12 00:26:18 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sat, 12 May 2018 00:26:18 +0200 Subject: [PATCH scute] Build a second library which uses the signature key. Message-ID: <7affff88ed4366c5c0399ece0a5d1a0fb729ec0d.camel@googlemail.com> Hi. I modified scute a little to fit my needs to use a certificate based on my signature key in LibreOffice and Thunderbird. This patch introduces the configute switch --enable-sigkey which enabled building of scutesig.so which uses the signature key. Thanks to Damien Goutte-Gattat who bumped me into the right direction to avoid duplication of slots.c. In my hurry to get this working I didn't even think about this solution for coexistent shared objects. The attached patch is based on commit a9a229a, which is the last in the master branch of the upstream repository. My changes can be viewed also in my GitHub fork ob the scute repository https://github.com/Dirk1980ac/scute I hope this is useful for other users and you are free to merge this patch back to the original source tree, if appreciated. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen Tel.: +49 1573 1152350 -------------- next part -------------- A non-text attachment was scrubbed... Name: scute.patch Type: text/x-patch Size: 3780 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 ben at adversary.org Tue May 15 06:24:44 2018 From: ben at adversary.org (Ben McGinnes) Date: Tue, 15 May 2018 14:24:44 +1000 Subject: org-babel bug and python docs Message-ID: <20180515042444.73emonyfvyfn3fin@adversary.org> Hello, So I've discovered an annoying bug (as if there's any other kind) in org-mode's babel output. Specifically that babel appears to break Python code examples in which there are nested indent blocks. It's fine with the first level of indentation, but does not honour subsequent levels of indentation. I'm tracking that here: https://dev.gnupg.org/T3977 Obviously I'll have to follow that up with org-mode devs directly, but it does leave us with a quandary. Specifically it makes the HOWTO I wrote in March somewhat less helpful than it first appeared. I am unthrilled by this, to say the least. In the mean time, a work-around was required and I figured I had two options: Option one: port the whole thing to reStructuredText, which is used for Python documentation more generally (including the official docs). Option two: port the whole thing to an XML format known to be capable of handling technical documentation. Both had advantages, but I opted for the second one. The reasons being that while reStructuredText itself is great; most methods of generating output for it involve Sphinx and while Sphinx is very usable, how to put this, it wouldn't know standards compliance and any form of markup validation if it tripped over it. So I selected something I've ranted about either here or over on gnupg-users in the past: DITA XML. I finished porting the HOWTO to that a short while ago and its currently commited to the ben/howto-dita branch in the GPGME repo, but not (yet) merged with master. I've also used it to generate a webhelp style site and put that here so you can see why it's so good for things like this: http://files.au.adversary.org/crypto/gpgme-python-howto/webhelp/index.html The HOWTO is actually an ideal size for this kind of demonstration, it's big enough to show some of the advantages, without being so big as to make the porting effort too much of a chore. I also put the metrics report for that build over here: http://files.au.adversary.org/crypto/gpgme-python-howto/metrics/gpgme-python-howto-20180515-135345-report.html It shows all sorts of little stats like which XML elements were used, how many times and so on. Most importantly, though, unlike the output generated from the org-mode file, the example code is correctly formatted (such that end users can just copy and paste from the web page), without losing syntax highlighting. It's also searchable. Even though it's a static site. I guess javascript is useful for something after all. 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 dashohoxha at gmail.com Tue May 15 07:44:44 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 15 May 2018 07:44:44 +0200 Subject: org-babel bug and python docs In-Reply-To: References: <20180515042444.73emonyfvyfn3fin@adversary.org> Message-ID: On Tue, May 15, 2018 at 7:32 AM, Dashamir Hoxha wrote: > On Tue, May 15, 2018 at 6:24 AM, Ben McGinnes wrote: > >> >> Specifically that babel appears to break Python code examples in which >> there are nested indent blocks. It's fine with the first level of >> indentation, but does not honour subsequent levels of indentation. >> [...] >> >> In the mean time, a work-around was required and I figured I had two >> options: >> >> Option one: port the whole thing to reStructuredText, which is used >> for Python documentation more generally (including the official docs). >> >> Option two: port the whole thing to an XML format known to be capable >> of handling technical documentation. >> > > As a third work-around option, have you tried to use '#+begin_example' > instead of '#+begin_src', for the code examples where the identation > is broken. The code coloring will be lost, but maybe the indentation will > be preserved. > By the way, since I use org-mode in combination with Jekyll, I leave coloring up to Jekyll, like this: #+BEGIN_EXPORT html { % highlight bash %} #!/bin/bash . . . . . . . . . . . { % endhighlight %} #+END_EXPORT -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Tue May 15 07:32:15 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 15 May 2018 07:32:15 +0200 Subject: org-babel bug and python docs In-Reply-To: <20180515042444.73emonyfvyfn3fin@adversary.org> References: <20180515042444.73emonyfvyfn3fin@adversary.org> Message-ID: On Tue, May 15, 2018 at 6:24 AM, Ben McGinnes wrote: > > Specifically that babel appears to break Python code examples in which > there are nested indent blocks. It's fine with the first level of > indentation, but does not honour subsequent levels of indentation. > [...] > > In the mean time, a work-around was required and I figured I had two > options: > > Option one: port the whole thing to reStructuredText, which is used > for Python documentation more generally (including the official docs). > > Option two: port the whole thing to an XML format known to be capable > of handling technical documentation. > As a third work-around option, have you tried to use '#+begin_example' instead of '#+begin_src', for the code examples where the identation is broken. The code coloring will be lost, but maybe the indentation will be preserved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Tue May 15 08:45:03 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 15 May 2018 08:45:03 +0200 Subject: efail -> improvements Message-ID: <201805150845.03646.bernhard@intevation.de> On an email just send to gnupg-devel@ I'm suggesting to change GnuPG to > 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). (As a supportive argument over suggestions by Werner and others. Just put here for reference as this is the development list.) Best, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From ben at adversary.org Tue May 15 09:05:15 2018 From: ben at adversary.org (Ben McGinnes) Date: Tue, 15 May 2018 17:05:15 +1000 Subject: org-babel bug and python docs In-Reply-To: References: <20180515042444.73emonyfvyfn3fin@adversary.org> Message-ID: <20180515070515.dqagwfsvlxjktaq6@adversary.org> On Tue, May 15, 2018 at 07:32:15AM +0200, Dashamir Hoxha wrote: > On Tue, May 15, 2018 at 6:24 AM, Ben McGinnes wrote: >> >> Option two: port the whole thing to an XML format known to be capable >> of handling technical documentation. > > As a third work-around option, have you tried to use > '#+begin_example' instead of '#+begin_src', for the code examples > where the identation is broken. The code coloring will be lost, but > maybe the indentation will be preserved. The same effect can be achieved by just not specifying the language with begin_src. This is a sub-optimal approach in my opinion. 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 Tue May 15 09:19:42 2018 From: ben at adversary.org (Ben McGinnes) Date: Tue, 15 May 2018 17:19:42 +1000 Subject: org-babel bug and python docs In-Reply-To: References: <20180515042444.73emonyfvyfn3fin@adversary.org> Message-ID: <20180515071942.7fjmn4z66c2v62uo@adversary.org> On Tue, May 15, 2018 at 07:44:44AM +0200, Dashamir Hoxha wrote: > > By the way, since I use org-mode in combination with Jekyll, I leave > coloring up to Jekyll, like this: Nice, but the issue here is that we're not the ones who will be generating the output, more often than not. For the most part the output ought to be generated when GPGME is installed by end users and the generation is for multiple output formats, which is why I haven't merged the DITA version with master yet since it requires processing XSLTs to produce the output in whatever format (mostly HTML 5 + CSS sites or PDF, often via XSL-FO). So expecting end users to have the DITA-OT installed (it's written in Java) is a bit of a hard sell. So is expecting them to have the same Jeckyll platform you have already configured. Though that might take a little less convincing for end users in Linux-land, it's more likely to go the other way for Windows users. Now the DITA source could be used to generate that output without the DITA-OT, but that would require someone re-implementing the standard in something that's not Java and no one has done it yet. Well, not to a complete enough extent to be terribly useful; there have been some attempts with Python by ... erm, I think it's the XMLMind team, but I'd need to check. Whereas the OT is the reference implementation and is pretty complete. For those interested, that (OASIS) standard is here: https://dita.xml.org/ The DITA-OT is here (on GitHub): https://www.dita-ot.org/ 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 bernhard at intevation.de Tue May 15 12:38:41 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 15 May 2018 12:38:41 +0200 Subject: efail -> improvements in case w/o AE (e.g. CMS) In-Reply-To: <201805150845.03646.bernhard@intevation.de> References: <201805150845.03646.bernhard@intevation.de> Message-ID: <201805151238.46144.bernhard@intevation.de> Am Dienstag 15 Mai 2018 08:45:03 schrieb Bernhard Reiter: > I'm suggesting to change GnuPG to to only display or save decrypted contents if it was integrity protected 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). for c) it may be enough that the integrity was protected by the hash in the signature, if we make sure that it is always signed and then encrypted. This is an interesting case, because a) and b) is currently not easily available for CMS with gpgsm. There is an authenticated-data type defined in STD 70 (aka RFC 5652) but not yet implemented in Gpgsm (https://dev.gnupg.org/T3979). I read that CMS would allow signing before or after encryption. The crypto gadget attack would need to be able to reorder, delete and insert encrypted data blocks because the plaintext is not yet known. So an attacker cannot fake the hash done within a signature over the plaintext. So in the case [encrypted [signed [ contents]] the contents can be considered integrity protected and could be displayed if the hash on the signature is fine, even if we cannot verify the authentication. We would need to disallow the case [signed [encrypted [signed [contents]]] as an attacker might put his own valid signature outside the manipulated ciphertext. (This has been an idea coming up by Andre while we were talking.) 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 dashohoxha at gmail.com Tue May 15 14:10:47 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 15 May 2018 14:10:47 +0200 Subject: org-babel bug and python docs In-Reply-To: <20180515042444.73emonyfvyfn3fin@adversary.org> References: <20180515042444.73emonyfvyfn3fin@adversary.org> Message-ID: On Tue, May 15, 2018 at 6:24 AM, Ben McGinnes wrote: > Hello, > So I've discovered an annoying bug (as if there's any other > kind) in org-mode's babel output. > > Specifically that babel appears to break Python code examples in which > there are nested indent blocks. It's fine with the first level of > indentation, but does not honour subsequent levels of indentation. > I checked it out of curiosity, and it seems that there is a mix of tabs and white-spaces on the source code. https://dev.gnupg.org/source/gpgme/browse/master/lang/python/docs/GPGMEpythonHOWTOen.org;e54b110aec3165a32ff9551d0c5227b88aa3dd4f$617 I am not sure whether this is the cause of the problem, but usually it is not recommended to have such a mix on source code. I think that Emacs can be configured to convert automatically tabs to white-spaces, but I don't know how this is done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Tue May 15 13:00:06 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 15 May 2018 12:00:06 +0100 Subject: Fwd: [Phabricator] Password Reset In-Reply-To: <3ebea78499a2991681ce19da57104a56@localhost.localdomain> References: <3ebea78499a2991681ce19da57104a56@localhost.localdomain> Message-ID: "1234"? "cat"? Seriously? O_o A -------- Forwarded Message -------- Subject: [Phabricator] Password Reset Date: Tue, 15 May 2018 08:37:28 +0000 From: noreply at dev.gnupg.org To: andrewg at andrewg.com Condolences on forgetting your password. You can use this link to reset it: https://dev.gnupg.org/login/once/reset/ After you set a new password, consider writing it down on a sticky note and attaching it to your monitor so you don't forget again! Choosing a very short, easy-to-remember password like "cat" or "1234" might also help. Best Wishes, Phabricator -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From aheinecke at intevation.de Tue May 15 14:31:37 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 15 May 2018 14:31:37 +0200 Subject: EFail mitigations for S/MIME (was: efail -> improvements in case w/o AE (e.g. CMS)) In-Reply-To: <201805151238.46144.bernhard@intevation.de> References: <201805150845.03646.bernhard@intevation.de> <201805151238.46144.bernhard@intevation.de> Message-ID: <508889170.5A78I2nhO6@esus> Hi, It think Bernhards mail can be summed up further. To check that the encrypted data was not manipulated we only need: - Any hash over the plaintext. To get such a hash we can most easily use a signature, regardless of any trust in the signature. The hash does not need to be encrypted. If we have no hash we won't offer to save a decrypted file from a GUI or show it in an HTML enabled mail client. This would disallow encrypt, then sign schemes but in practice everyone uses sign then encrypt anyway. 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 aheinecke at intevation.de Tue May 15 15:29:51 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 15 May 2018 15:29:51 +0200 Subject: Fwd: [Phabricator] Password Reset In-Reply-To: References: <3ebea78499a2991681ce19da57104a56@localhost.localdomain> Message-ID: <218149193.ae5p7in9xn@esus> On Tuesday, May 15, 2018 12:00:06 PM CEST Andrew Gallagher wrote: > "1234"? "cat"? Seriously? O_o Very obviously not seriously. (That sticky note stuff is also not serious.) Phabricator tries to have a light and humorous tone. Including irony. -- 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 Wed May 16 13:32:00 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 13:32:00 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <508889170.5A78I2nhO6@esus> (Andre Heinecke's message of "Tue, 15 May 2018 14:31:37 +0200") References: <201805150845.03646.bernhard@intevation.de> <201805151238.46144.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> Message-ID: <87603nygy7.fsf@wheatstone.g10code.de> On Tue, 15 May 2018 14:31, aheinecke at intevation.de said: > - Any hash over the plaintext. You mean to put a hash as kind of additional data inside the EnvelopedData (the CMS name for encrypted dats) to make somthing like the OpenPGP MDC? CMS does not allow for this. What you can do is to put arbitrary attributes into the UnprotectedAttributes section. But as the name says, this is unprotected and not encrypted so it differs from an MDC. Anyway, this would be a proprietary extension which does not help with interoperability. If you don't need to be interoperabe with other S/MIME implementaion it is anyway better to use OpenPGP. I would bet that many implementations will bail out on that uncommon and optional UnprotectedAttributes. CMS has the AuthenticatedData as a MAC system which could be put around the EnvelopedData but this features is not implemented in any widely used client. The actual extension for authenticated data is RFC-5083 which describes the Authenticated-Enveloped-Data content type. It can be used with AES-CCM or AES-GCM as specified in RFC-5084 (urgs) or with ChaCHa20-poly1305 (RFC-8103). But well, it is also not implemented. If you want to fix CMS this should be used - iff all vendors agree. 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 13:59:45 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 13:59:45 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <87603nygy7.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 16 May 2018 13:32:00 +0200") References: <201805150845.03646.bernhard@intevation.de> <201805151238.46144.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> <87603nygy7.fsf@wheatstone.g10code.de> Message-ID: <87po1vx13i.fsf@wheatstone.g10code.de> On Wed, 16 May 2018 13:32, wk at gnupg.org said: > be used with AES-CCM or AES-GCM as specified in RFC-5084 (urgs) or with > ChaCHa20-poly1305 (RFC-8103). But well, it is also not implemented. I forgot RFC-6476 which uses a MAC instead of a counter based algorithm and thus would be more robust. 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 aheinecke at intevation.de Wed May 16 14:09:41 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 16 May 2018 14:09:41 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <87603nygy7.fsf@wheatstone.g10code.de> References: <201805150845.03646.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> <87603nygy7.fsf@wheatstone.g10code.de> Message-ID: <2125424.XCCKADsp3X@esus> Hi, On Wednesday, May 16, 2018 1:32:00 PM CEST Werner Koch wrote: > On Tue, 15 May 2018 14:31, aheinecke at intevation.de said: > > > - Any hash over the plaintext. > > You mean to put a hash as kind of additional data inside the > EnvelopedData (the CMS name for encrypted dats) to make somthing like > the OpenPGP MDC? > > CMS does not allow for this. What you can do is to put arbitrary > attributes into the UnprotectedAttributes section. But as the name > says, this is unprotected and not encrypted so it differs from an MDC. Not really. I also don't think that it needs to be encrypted. Basically: Alice sends Bob encrypted data and also sends Bob "This is the hash of the plaintext" by signing the plaintext. Then Bobs client can know "This plaintext matches the hash Alice told me about". -> It has not been manipulated. Even if Eve can manipulate the Hash that Alice sends to Bob she can't create a valid Hash for the original plaintext + her modifications. > Anyway, this would be a proprietary extension which does not help with > interoperability. If you don't need to be interoperabe with other > S/MIME implementaion it is anyway better to use OpenPGP. I would bet > that many implementations will bail out on that uncommon and optional > UnprotectedAttributes. No extension. Basically what I want to do is that for S/MIME HTML Mail / Mails with attachments GpgOL will only put the plaintext into Outlook if it also has a valid signature. Regardless of the trust in the signature. I know it's a hack and proper AE would be better but I think it would mitigate an EFail style modification attack. 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 Wed May 16 16:39:58 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 May 2018 16:39:58 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <2125424.XCCKADsp3X@esus> (Andre Heinecke's message of "Wed, 16 May 2018 14:09:41 +0200") References: <201805150845.03646.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> <87603nygy7.fsf@wheatstone.g10code.de> <2125424.XCCKADsp3X@esus> Message-ID: <87y3gju0jl.fsf@wheatstone.g10code.de> On Wed, 16 May 2018 14:09, aheinecke at intevation.de said: > No extension. Basically what I want to do is that for S/MIME HTML Mail / Mails > with attachments GpgOL will only put the plaintext into Outlook if it also has > a valid signature. Regardless of the trust in the signature. You need to have the key for the signature and all kind of online checking of the key - remember it is X.509 and thus subject to malicious certifciates. We all know from OpenPGP that getting the key for signed message is not easy if people don't upload to a keyserver. For S?MIME it is worse. Without a key you can't check the signature. There are legitimate reasons not to sign a mail and to let the recipient decide, based on the content, whether it has been received from the expected sender. For example in a VS-NfD setting signatures are simply out of scope and thus not used. 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 martijn.list at gmail.com Wed May 16 16:15:45 2018 From: martijn.list at gmail.com (martijn.list) Date: Wed, 16 May 2018 16:15:45 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <508889170.5A78I2nhO6@esus> References: <201805150845.03646.bernhard@intevation.de> <201805151238.46144.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> Message-ID: <13d09c0e-0908-5f4a-f992-840d0f1ae741@gmail.com> On 15-05-18 14:31, Andre Heinecke wrote: > Hi, > > It think Bernhards mail can be summed up further. To check that the encrypted > data was not manipulated we only need: > > - Any hash over the plaintext. > > To get such a hash we can most easily use a signature, regardless of any trust > in the signature. The hash does not need to be encrypted. > > If we have no hash we won't offer to save a decrypted file from a GUI or show > it in an HTML enabled mail client. This would disallow encrypt, then sign > schemes but in practice everyone uses sign then encrypt anyway. Adding a hash will not help in the general case because other S/MIME clients will not support it. I have done some experiments with the "Generic exfiltration" attack and have been able to replicate the attack. Injecting new blocks is easy. However after every injected block, there is a block of random data. This block of random data can be used to detect whether the message was attacked with EFAIL in most cases. The S/MIME RFCs strongly suggest that every MIME part should be 7-bit. If a decrypted message therefore contains data > 127 or < 32 excluding CR/LF/TAB, the message might have been injected with additional blocks. For the "Generic exfiltration" EFAIL attack, you need at least 2 blocks of data so there will be at least 32 bytes of random data. The changes that all those bytes fall within the 7-bit range is slim so I think this check would work to detect most (if not all) EFAIL attacks. The only problem you might run into is if a sender encrypted a message containing 8-bit characters (i.e., the message was not canonicalized to 7-bit). I have written a short blog item about this here https://www.ciphermail.com/blog/efail-how-to-detect-you-are-being-attacked.html Any comments on whether this will work? As we speak I'm working on such a check. Kind regards, Martijn Brinkers From angel at pgp.16bits.net Wed May 16 17:30:47 2018 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Wed, 16 May 2018 17:30:47 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <2125424.XCCKADsp3X@esus> References: <201805150845.03646.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> <87603nygy7.fsf@wheatstone.g10code.de> <2125424.XCCKADsp3X@esus> Message-ID: <1526484647.993.14.camel@16bits.net> On 2018-05-16 at 14:09 +0200, Andre Heinecke wrote: > Not really. I also don't think that it needs to be encrypted. > > Basically: Alice sends Bob encrypted data and also sends Bob "This is > the hash of the plaintext" by signing the plaintext. > > Then Bobs client can know "This plaintext matches the hash Alice told > me about". -> It has not been manipulated. > Even if Eve can manipulate the Hash that Alice sends to Bob she can't > create a valid Hash for the original plaintext + her modifications. At first sight, it looks enough, since it would require already knowing the plaintext. However, it is not. You are providing an oracle that allows confirming whether a content is the one suspected by the attacker. Suppose we are in the context of a poll, where Alice sent Bob "The president should be Charlie". At the end of the vote, Bob publishes the encrypted mails, for auditing reasons. Eve wants to know for whom did Alice vote, so she -suspecting she voted for Charlie-, extracts the encrypted content, adds her own hash for the guessed plaintext, and sends it to the victim (she can perform any cipher malleability attack by simply adjusting the final hash). If the content is decrypted, it means she guessed right. Otherwise, the encrypted contents were different, the decryption failed and she will try the attack again with another candidate. (She may even be able to test several guesses in a single malicious email) You need both pieces to be linked. It could be enough to just include in the hash computation a "secret IV" that is stored in the encrypted part, but it seems fragile, and at that point, I would simply include the hash itself. (Obviously, if you were really including a cleartext-signed hash of the message, Eve wouldn't need to perform an efail attack at all, as she could simply test the hash against the list of people running for president) Best regards From uri at mit.edu Thu May 17 01:00:02 2018 From: uri at mit.edu (Uri Blumenthal) Date: Wed, 16 May 2018 23:00:02 +0000 Subject: EFail mitigations for S/MIME In-Reply-To: <1526484647.993.14.camel@16bits.net> References: <201805150845.03646.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> <87603nygy7.fsf@wheatstone.g10code.de> <2125424.XCCKADsp3X@esus> <1526484647.993.14.camel@16bits.net> Message-ID: IMHO the correct solution would be to switch to a true Authenticated Encryption mode - like AES-OCB or AES-GCM. Is there a chance to have this implemented soon? Sent from my test iPhone > On May 16, 2018, at 12:34, ?ngel wrote: > >> On 2018-05-16 at 14:09 +0200, Andre Heinecke wrote: >> Not really. I also don't think that it needs to be encrypted. >> >> Basically: Alice sends Bob encrypted data and also sends Bob "This is >> the hash of the plaintext" by signing the plaintext. >> >> Then Bobs client can know "This plaintext matches the hash Alice told >> me about". -> It has not been manipulated. >> Even if Eve can manipulate the Hash that Alice sends to Bob she can't >> create a valid Hash for the original plaintext + her modifications. > > At first sight, it looks enough, since it would require already knowing > the plaintext. However, it is not. You are providing an oracle that > allows confirming whether a content is the one suspected by the > attacker. > > Suppose we are in the context of a poll, where Alice sent Bob "The > president should be Charlie". At the end of the vote, Bob publishes the > encrypted mails, for auditing reasons. > Eve wants to know for whom did Alice vote, so she -suspecting she voted > for Charlie-, extracts the encrypted content, adds her own hash for the > guessed plaintext, and sends it to the victim (she can perform any > cipher malleability attack by simply adjusting the final hash). > If the content is decrypted, it means she guessed right. Otherwise, the > encrypted contents were different, the decryption failed and she will > try the attack again with another candidate. (She may even be able to > test several guesses in a single malicious email) > > You need both pieces to be linked. It could be enough to just include in > the hash computation a "secret IV" that is stored in the encrypted part, > but it seems fragile, and at that point, I would simply include the hash > itself. > > > (Obviously, if you were really including a cleartext-signed hash of the > message, Eve wouldn't need to perform an efail attack at all, as she > could simply test the hash against the list of people running for > president) > > > Best regards > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From rjh at sixdemonbag.org Thu May 17 02:40:58 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 16 May 2018 20:40:58 -0400 Subject: EFail mitigations for S/MIME In-Reply-To: References: <201805150845.03646.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> <87603nygy7.fsf@wheatstone.g10code.de> <2125424.XCCKADsp3X@esus> <1526484647.993.14.camel@16bits.net> Message-ID: <1284e588-ebb4-4d26-5788-e66b8e920778@sixdemonbag.org> > IMHO the correct solution would be to switch to a true Authenticated > Encryption mode - like AES-OCB or AES-GCM. Tell it to the Working Group, please. We don't get to write the RFC by ourselves. > Is there a chance to have this implemented soon? No. Get the WG to define it and GnuPG will implement it. From gnupg at leo.gaspard.ninja Thu May 17 02:44:01 2018 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Thu, 17 May 2018 02:44:01 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: References: <201805150845.03646.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> <87603nygy7.fsf@wheatstone.g10code.de> <2125424.XCCKADsp3X@esus> <1526484647.993.14.camel@16bits.net> Message-ID: On 05/17/2018 01:00 AM, Uri Blumenthal wrote: > IMHO the correct solution would be to switch to a true Authenticated Encryption mode - like AES-OCB or AES-GCM. > > Is there a chance to have this implemented soon? AFAIU the attack put forward by ?ngel doesn't work against GnuPG's MDC. That said, the move to a true AE mode is coming with the next standard, and will I guess be implemented when the standard will be finalized enough. >> On May 16, 2018, at 12:34, ?ngel wrote: >> >>> On 2018-05-16 at 14:09 +0200, Andre Heinecke wrote: >>> Not really. I also don't think that it needs to be encrypted. >>> >>> Basically: Alice sends Bob encrypted data and also sends Bob "This is >>> the hash of the plaintext" by signing the plaintext. >>> >>> Then Bobs client can know "This plaintext matches the hash Alice told >>> me about". -> It has not been manipulated. >>> Even if Eve can manipulate the Hash that Alice sends to Bob she can't >>> create a valid Hash for the original plaintext + her modifications. >> >> At first sight, it looks enough, since it would require already knowing >> the plaintext. However, it is not. You are providing an oracle that >> allows confirming whether a content is the one suspected by the >> attacker. >> >> Suppose we are in the context of a poll, where Alice sent Bob "The >> president should be Charlie". At the end of the vote, Bob publishes the >> encrypted mails, for auditing reasons. >> Eve wants to know for whom did Alice vote, so she -suspecting she voted >> for Charlie-, extracts the encrypted content, adds her own hash for the >> guessed plaintext, and sends it to the victim (she can perform any >> cipher malleability attack by simply adjusting the final hash). >> If the content is decrypted, it means she guessed right. Otherwise, the >> encrypted contents were different, the decryption failed and she will >> try the attack again with another candidate. (She may even be able to >> test several guesses in a single malicious email) >> >> You need both pieces to be linked. It could be enough to just include in >> the hash computation a "secret IV" that is stored in the encrypted part, >> but it seems fragile, and at that point, I would simply include the hash >> itself. >> >> >> (Obviously, if you were really including a cleartext-signed hash of the >> message, Eve wouldn't need to perform an efail attack at all, as she >> could simply test the hash against the list of people running for >> president) >> >> >> Best regards >> >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From aheinecke at intevation.de Thu May 17 08:10:17 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 17 May 2018 08:10:17 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <13d09c0e-0908-5f4a-f992-840d0f1ae741@gmail.com> References: <201805150845.03646.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> <13d09c0e-0908-5f4a-f992-840d0f1ae741@gmail.com> Message-ID: <1620707.v6A0ujqYWW@esus> Hi, On Wednesday, May 16, 2018 4:15:45 PM CEST martijn.list wrote: > On 15-05-18 14:31, Andre Heinecke wrote: > > - Any hash over the plaintext. > > > > To get such a hash we can most easily use a signature, regardless of any trust > > in the signature. The hash does not need to be encrypted. > > > > If we have no hash we won't offer to save a decrypted file from a GUI or show > > it in an HTML enabled mail client. This would disallow encrypt, then sign > > schemes but in practice everyone uses sign then encrypt anyway. > > Adding a hash will not help in the general case because other S/MIME > clients will not support it. I don't propose to extend the standard. I would only reuse the the hash of a multipart/signed part in an S/MIME mail or from a signature in the case of files. > I have done some experiments with the "Generic exfiltration" attack and > have been able to replicate the attack. Injecting new blocks is easy. > However after every injected block, there is a block of random data. > This block of random data can be used to detect whether the message was > attacked with EFAIL in most cases. The S/MIME RFCs strongly suggest that > every MIME part should be 7-bit. If a decrypted message therefore > contains data > 127 or < 32 excluding CR/LF/TAB, the message might have > been injected with additional blocks. For the "Generic exfiltration" > EFAIL attack, you need at least 2 blocks of data so there will be at > least 32 bytes of random data. The changes that all those bytes fall > within the 7-bit range is slim so I think this check would work to > detect most (if not all) EFAIL attacks. The only problem you might run > into is if a sender encrypted a message containing 8-bit characters > (i.e., the message was not canonicalized to 7-bit). > > I have written a short blog item about this here > > https://www.ciphermail.com/blog/efail-how-to-detect-you-are-being-attacked.html > > Any comments on whether this will work? From your blog it sounds like this is only specified for multipart/signed inside the encrypted part. If it is signed can't you just check the signature and only show the signed parts? Also for Gpg4win I'm thinking a bit about files. We offer through Kleopatra CMS file encryption, which would have similar problems :-/ . 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 aheinecke at intevation.de Thu May 17 08:25:41 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 17 May 2018 08:25:41 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <1526484647.993.14.camel@16bits.net> References: <201805150845.03646.bernhard@intevation.de> <2125424.XCCKADsp3X@esus> <1526484647.993.14.camel@16bits.net> Message-ID: <8984961.8eMYduYLoO@esus> Hi, On Wednesday, May 16, 2018 5:30:47 PM CEST ?ngel wrote: > On 2018-05-16 at 14:09 +0200, Andre Heinecke wrote: > > Not really. I also don't think that it needs to be encrypted. > > > > Basically: Alice sends Bob encrypted data and also sends Bob "This is > > the hash of the plaintext" by signing the plaintext. > > > > Then Bobs client can know "This plaintext matches the hash Alice told > > me about". -> It has not been manipulated. > > Even if Eve can manipulate the Hash that Alice sends to Bob she can't > > create a valid Hash for the original plaintext + her modifications. > > At first sight, it looks enough, since it would require already knowing > the plaintext. However, it is not. You are providing an oracle that > allows confirming whether a content is the one suspected by the > attacker. For the usual S/MIME mail case I would say that this is mostly mitigated because the hash is encrypted in that case. As the only case we would accept for mail would be sign then encrypt and would only show the signed parts. But in general you are right about the problems of an unencrypted hash as I have proposed / suggested it and thank you for pointing it out. I still think that the situation might be improved if we would strongly suggest / force users to provide signatures for CMS encrypted files, too. This should be done anyway, especially for active content like HTML or a binary. On the other hand the situation with this is not really changed with EFail. If you handle unsigned files you can't trust the file by cryptography alone. And we already warn when we handle unsigned content in Kleopatra. So we might only enforce this for active content in mails for Outlook. > Suppose we are in the context of a poll, where Alice sent Bob "The > president should be Charlie". At the end of the vote, Bob publishes the > encrypted mails, for auditing reasons. > Eve wants to know for whom did Alice vote, so she -suspecting she voted > for Charlie-, extracts the encrypted content, adds her own hash for the > guessed plaintext, and sends it to the victim (she can perform any > cipher malleability attack by simply adjusting the final hash). > If the content is decrypted, it means she guessed right. Otherwise, the > encrypted contents were different, the decryption failed and she will > try the attack again with another candidate. (She may even be able to > test several guesses in a single malicious email) > > You need both pieces to be linked. It could be enough to just include in > the hash computation a "secret IV" that is stored in the encrypted part, > but it seems fragile, and at that point, I would simply include the hash > itself. > > > (Obviously, if you were really including a cleartext-signed hash of the > message, Eve wouldn't need to perform an efail attack at all, as she > could simply test the hash against the list of people running for > president) I agree with you and all others here that proper AE would be much much better. I'm just thinking about a quick solution to improve the situation for Gpg4win users without relying on any support from other clients. 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 bernhard at intevation.de Thu May 17 08:39:23 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 17 May 2018 08:39:23 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <1284e588-ebb4-4d26-5788-e66b8e920778@sixdemonbag.org> References: <201805150845.03646.bernhard@intevation.de> <1284e588-ebb4-4d26-5788-e66b8e920778@sixdemonbag.org> Message-ID: <201805170839.28198.bernhard@intevation.de> Am Donnerstag 17 Mai 2018 02:40:58 schrieb Robert J. Hansen: > > IMHO the correct solution would be to switch to a true Authenticated > > Encryption mode - like AES-OCB or AES-GCM. > > Tell it to the Working Group, please. ?We don't get to write the RFC by > ourselves. As Werner pointed out: There is already RFC6476 which uses the SMIMECapabilities attribute as defined in STD 70 (aka rfc5751) to define a "Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)" and there is RFC8103 providing another one. So we would need to get S/MIME application vendors to implement one of these. Best, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From martijn.list at gmail.com Thu May 17 09:16:37 2018 From: martijn.list at gmail.com (martijn.list) Date: Thu, 17 May 2018 09:16:37 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <1620707.v6A0ujqYWW@esus> References: <201805150845.03646.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> <13d09c0e-0908-5f4a-f992-840d0f1ae741@gmail.com> <1620707.v6A0ujqYWW@esus> Message-ID: On 17-05-18 08:10, Andre Heinecke wrote: > Hi, > > On Wednesday, May 16, 2018 4:15:45 PM CEST martijn.list wrote: >> On 15-05-18 14:31, Andre Heinecke wrote: >>> - Any hash over the plaintext. >>> >>> To get such a hash we can most easily use a signature, regardless of any > trust >>> in the signature. The hash does not need to be encrypted. >>> >>> If we have no hash we won't offer to save a decrypted file from a GUI or > show >>> it in an HTML enabled mail client. This would disallow encrypt, then sign >>> schemes but in practice everyone uses sign then encrypt anyway. >> >> Adding a hash will not help in the general case because other S/MIME >> clients will not support it. > > I don't propose to extend the standard. I would only reuse the the hash of a > multipart/signed part in an S/MIME mail or from a signature in the case of > files. > >> I have done some experiments with the "Generic exfiltration" attack and >> have been able to replicate the attack. Injecting new blocks is easy. >> However after every injected block, there is a block of random data. >> This block of random data can be used to detect whether the message was >> attacked with EFAIL in most cases. The S/MIME RFCs strongly suggest that >> every MIME part should be 7-bit. If a decrypted message therefore >> contains data > 127 or < 32 excluding CR/LF/TAB, the message might have >> been injected with additional blocks. For the "Generic exfiltration" >> EFAIL attack, you need at least 2 blocks of data so there will be at >> least 32 bytes of random data. The changes that all those bytes fall >> within the 7-bit range is slim so I think this check would work to >> detect most (if not all) EFAIL attacks. The only problem you might run >> into is if a sender encrypted a message containing 8-bit characters >> (i.e., the message was not canonicalized to 7-bit). >> >> I have written a short blog item about this here >> >> https://www.ciphermail.com/blog/efail-how-to-detect-you-are-being-attacked.html >> >> Any comments on whether this will work? > > From your blog it sounds like this is only specified for multipart/signed > inside the encrypted part. If it is signed can't you just check the signature > and only show the signed parts? No it works for general content types. The multipart/signed content type was only used for the example. You can modify a block (16 bytes in case of AES128) without introducing a random block. Inserting a new block however will introduce a random block after the inserted block. For an attack you need at least two blocks (probably a lot more) so there is plenty of random data in the decrypted mime. Because the attacker can modify the decrypted MIME, it is possible to remove the multipart/signed content type. For example by adding a number of newlines. The final decrypted message is therefore no longer a signed message so checking the signature will not work in the general case. Kind regards, Martijn Brinkers From bernhard at intevation.de Thu May 17 10:26:09 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 17 May 2018 10:26:09 +0200 Subject: danger of decrypted files without integrity protection Message-ID: <201805171026.13915.bernhard@intevation.de> Pondering how dangerous manipulated decrypted files are I've done the following experiment on a GNU system: echo "File loading external references? Yes, if you can see the following image: " >test.html firefox test.html chromium test.html both times the image was shown. dpkg -s firefox-esr chromium | grep Version Version: 52.8.0esr-1~deb9u1 Version: 66.0.3359.117-1~deb9u1 Even if the originally encrypted file was something else, it could be wrapped into html by an attacker and even if the browser's SOP would not allow to load external references listed in local file by default, you could additionally try adding one of the https://en.wikipedia.org/wiki/Same-origin_policy#Relaxing_the_same-origin_policy methods that work on a local file. Seems decrypted files that had no integrity protection are dangerous because they could be manipulated to send decrypted plaintext anyware once the users opens them. 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:20:33 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 10:20:33 +0200 Subject: EFail mitigations for S/MIME In-Reply-To: <1284e588-ebb4-4d26-5788-e66b8e920778@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 16 May 2018 20:40:58 -0400") References: <201805150845.03646.bernhard@intevation.de> <508889170.5A78I2nhO6@esus> <87603nygy7.fsf@wheatstone.g10code.de> <2125424.XCCKADsp3X@esus> <1526484647.993.14.camel@16bits.net> <1284e588-ebb4-4d26-5788-e66b8e920778@sixdemonbag.org> Message-ID: <87in7msnfy.fsf@wheatstone.g10code.de> On Thu, 17 May 2018 02:40, rjh at sixdemonbag.org said: > Tell it to the Working Group, please. We don't get to write the RFC by > ourselves. No need to tell it the working group. AuthEnvelopedData is specified since 2007 along with at least 3 other RFCs with the detailed specification of the algorithm: - RFC-5083 specifies the new content type - RFC-5084 specifies its use with AES-CCM and AES-GCM - RFC-6476 specifies its use with a MAC - RFC-8103 specifies its use with ChaCha20-Poly1305 Because CMS has no reliable working preference system, the real challenge is to get all major nendors to agree on one or two algorithms and and implement them. Due to the brittleness of all counter modes I would go with a MAC. Uri: Do you know an RFC specifying the use with OCB? 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 gpg-devel at nopicturesplease.de Thu May 17 11:18:40 2018 From: gpg-devel at nopicturesplease.de (Holger Smolinski) Date: Thu, 17 May 2018 11:18:40 +0200 Subject: danger of decrypted files without integrity protection In-Reply-To: <201805171026.13915.bernhard@intevation.de> References: <201805171026.13915.bernhard@intevation.de> Message-ID: <317b8fb6-5fb8-5c20-bb69-36ebb0ae7f17@smolinski.name> Am 17.05.2018 um 10:26 schrieb Bernhard Reiter: > Pondering how dangerous manipulated decrypted files are > I've done the following experiment on a GNU system: > > echo "File loading external references? Yes, if you can see the following image: " >test.html > firefox test.html > chromium test.html > > both times the image was shown. > > [...] > > Seems decrypted files that had no integrity protection are > dangerous because they could be manipulated to send decrypted > plaintext anyware once the users opens them. > > Best Regards, > Bernhard As far as I understand efail, there are two variants. 1st variant is attacking plain or multipart encrypted messages by wrapping them into a multipart message, which afterwards causes the mai client to leak the decrypted content. - For this variant there is not much GnuPG can do, as long as its scope remains confined to encrypted message bodies and mail parts. The 'proper' way to fix this would be fixing the mail clients to strictly respect boundaries between parts of multipart messages. 2nd variant is attacking CFB mode by injecting CFB gadgets that decrypt to some markup, which cause the mail client to leak decrypted content. This should be easily prevented by proper signature verification as the gadget injection leads to modified plaintext. - email clients should guide users to use encryption only with signed contents AND verify the signatures before parsing the mail. - GnuPG could refuse (or: require --force) to encrypt without signing, but this might also break other existing legitimate use cases. - CFB/CBC could be replaced in the standard by operation modes that are not vulnerable to gadget injection. But we still would need to support legacy modes for old encrypted mail decryption for a while... I'd object GnuPG to generally interpret email message formats, also because we cannot gracefully handle suspicious results. Beyond that, I could imagine a more secure email transport protocol, which generally prohibits any modification of documents by attackers. This can be achieved by true and mandatory end-to-end encryption and content signing. Regards ??? Holger -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Thu May 17 11:29:26 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 17 May 2018 10:29:26 +0100 Subject: danger of decrypted files without integrity protection In-Reply-To: <317b8fb6-5fb8-5c20-bb69-36ebb0ae7f17@smolinski.name> References: <201805171026.13915.bernhard@intevation.de> <317b8fb6-5fb8-5c20-bb69-36ebb0ae7f17@smolinski.name> Message-ID: <1e062151-e2bc-6387-5b2f-c25ce451938d@andrewg.com> On 17/05/18 10:18, Holger Smolinski wrote: > 2nd variant is attacking CFB mode by injecting CFB gadgets that > decrypt to some markup, which cause the mail client to leak > decrypted content. This should be easily prevented by proper > signature verification as the gadget injection leads to modified > plaintext. We need to be careful here to distinguish signatures (that declare an identity) from integrity protection. Signatures are not required for integrity, and in many cases are not desirable because they break anonymity. Integrity protection such as AE and MDC are perfectly good solutions that don't require a pubkey signature. AE is the "proper" way to do it as integrity failures can be detected sooner in the decryption process, but MDC (IFF handled properly by the calling program, which admittedly is not always the case) is a reasonable fallback. The solution that we've all known about for ages is to get authenticated encryption into the standard, but that's not going to happen tomorrow. -- 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 bernhard at intevation.de Thu May 17 14:59:13 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 17 May 2018 14:59:13 +0200 Subject: danger of decrypted files without integrity protection In-Reply-To: <317b8fb6-5fb8-5c20-bb69-36ebb0ae7f17@smolinski.name> References: <201805171026.13915.bernhard@intevation.de> <317b8fb6-5fb8-5c20-bb69-36ebb0ae7f17@smolinski.name> Message-ID: <201805171459.18038.bernhard@intevation.de> Am Donnerstag 17 Mai 2018 11:18:40 schrieb Holger Smolinski: > 2nd variant is attacking CFB mode by injecting CFB gadgets The CFB mode with MDC as GnuPG is using by default for 15 years protects against this. (As discussed in other posts already.) The point of my post is that the CBC mode that all known CMS implementations use for S/MIME does not have this protection for emails without inner signature. So files coming out of this can leak decrypted plaintext or otherwise use a backchannel or get "active". Browsers offer no additional protection. So decrypting files outside an email client may lead to dangerous files. 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 Thu May 17 15:42:39 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 17 May 2018 15:42:39 +0200 Subject: next AE cipher COLM? Message-ID: <201805171542.43731.bernhard@intevation.de> Would it make sense to consider COLM for being the next authenticated encryption algorithm? COLM v1 is a finalist of https://competitions.cr.yp.to/caesar-submissions.html and Christian Forler claims (around https://media.ccc.de/v/34c3-9142-resilienced_kryptographie#t=2375) that it is single parse and has better general properties than OCB or EAX mode. In addition there is patent claim for the used PMAC construction https://en.wikipedia.org/wiki/PMAC_(cryptography) Best, Bernhar -- 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 Thu May 17 16:30:09 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 17 May 2018 16:30:09 +0200 Subject: danger of decrypted files without integrity protection In-Reply-To: References: <201805171026.13915.bernhard@intevation.de> Message-ID: <201805171630.09963.bernhard@intevation.de> Am Donnerstag 17 Mai 2018 15:05:35 schrieb Greg Troxel: > In your example, you asked a browser to render html, which has different > norms than rendering incoming (and hence not requested by the user) > email. ?Even a relatively paranoid browser with uMatrix will render > images from different origins. It is a detail to the questions: * is decrypting an email manually outside of a mailer safe? -> no - for files that potentially will call home on opening * do webbrowsers follow external links when coming from local disk? -> yes (in the sample) -- 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 16:47:31 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 17 May 2018 15:47:31 +0100 Subject: next AE cipher COLM? In-Reply-To: <201805171542.43731.bernhard@intevation.de> References: <201805171542.43731.bernhard@intevation.de> Message-ID: On 17/05/18 14:42, Bernhard Reiter wrote: > Would it make sense to consider > COLM for being the next authenticated encryption algorithm? Given the shortage of manpower in the OpenPGP community, is it not more advisable to stick to algorithms with a few miles on the clock, such as GCM, even if they may not be strictly ideal? There will never be an ideal encryption algorithm after all, just ones with known problems and ones with unknown problems... ;-) -- 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 gdt at lexort.com Thu May 17 15:05:35 2018 From: gdt at lexort.com (Greg Troxel) Date: Thu, 17 May 2018 09:05:35 -0400 Subject: danger of decrypted files without integrity protection In-Reply-To: <201805171026.13915.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 17 May 2018 10:26:09 +0200") References: <201805171026.13915.bernhard@intevation.de> Message-ID: Bernhard Reiter writes: > Pondering how dangerous manipulated decrypted files are > I've done the following experiment on a GNU system: > > echo "File loading external references? Yes, if you can see the following image: " >test.html > firefox test.html > chromium test.html > > both times the image was shown. In your example, you asked a browser to render html, which has different norms than rendering incoming (and hence not requested by the user) email. Even a relatively paranoid browser with uMatrix will render images from different origins. If you are calling decrypted content without integrity protection (and probably, without Data Origin Authenication) protection dangerous, why are you not also calling unencrypted unauthenticated content dangerous? The larger real issue here is treating incoming bits as a program and interpreting it (to include fetching remote content), rather than simply displaying it. Mail use of html should not fetch images (which are also likely to contain tracking identifiers) or execute javascript. (This is all separate from the discussion about combining multiple arriving html documents into one document for rendering.) From uri at mit.edu Thu May 17 16:52:37 2018 From: uri at mit.edu (Uri Blumenthal) Date: Thu, 17 May 2018 14:52:37 +0000 Subject: next AE cipher COLM? In-Reply-To: References: <201805171542.43731.bernhard@intevation.de>, Message-ID: <60DF5A7C-3F8A-4FDC-BF4E-B4A70E567A91@mit.edu> Yes I prefer GCM or OCB - both well-studied. There's an updated RFC draft on OCB. I haven't seen yet an RFC defining how to use OCB in CMS - but technically it would be no different from GCM (just need to figure what OID to assign to it ;-). Sent from my test iPhone > On May 17, 2018, at 10:48, Andrew Gallagher wrote: > >> On 17/05/18 14:42, Bernhard Reiter wrote: >> Would it make sense to consider >> COLM for being the next authenticated encryption algorithm? > > Given the shortage of manpower in the OpenPGP community, is it not more > advisable to stick to algorithms with a few miles on the clock, such as > GCM, even if they may not be strictly ideal? There will never be an > ideal encryption algorithm after all, just ones with known problems and > ones with unknown problems... ;-) > > -- > Andrew Gallagher > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Thu May 17 19:27:04 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 May 2018 19:27:04 +0200 Subject: next AE cipher COLM? In-Reply-To: (Andrew Gallagher's message of "Thu, 17 May 2018 15:47:31 +0100") References: <201805171542.43731.bernhard@intevation.de> Message-ID: <87a7synqfr.fsf@wheatstone.g10code.de> On Thu, 17 May 2018 16:47, andrewg at andrewg.com said: > advisable to stick to algorithms with a few miles on the clock, such as > GCM, even if they may not be strictly ideal? There will never be an I wrote it several times over the last days: We have working and interoperable implementations of the new AEAD mode [1]. Along with a very well optimized implementation in Libgcrypt master. No need to open that case again. It is unfortuanate that we need to have algorithm preferencees and to define two of them but that is required to avoid a patent trap. Adding another patented algorithm with zero experience in the field is not helpful. And please don't mention GCM - counter based algorithms are way too brittle for solid cryptography. Remember the RC4 lessons. Salam-Shalom, Werner [1] Ribose NetPGP (rnp), GnuPG 2.3, openpgp.js -- # 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 gdt at lexort.com Thu May 17 19:43:26 2018 From: gdt at lexort.com (Greg Troxel) Date: Thu, 17 May 2018 13:43:26 -0400 Subject: danger of decrypted files without integrity protection In-Reply-To: <201805171630.09963.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 17 May 2018 16:30:09 +0200") References: <201805171026.13915.bernhard@intevation.de> <201805171630.09963.bernhard@intevation.de> Message-ID: Bernhard Reiter writes: > Am Donnerstag 17 Mai 2018 15:05:35 schrieb Greg Troxel: >> In your example, you asked a browser to render html, which has different >> norms than rendering incoming (and hence not requested by the user) >> email. ?Even a relatively paranoid browser with uMatrix will render >> images from different origins. > > It is a detail to the questions: > * is decrypting an email manually outside of a mailer safe? > -> no - for files that potentially will call home on opening Decrypting is not the problem. The problem is evaluating the file either with a program that interprets it and does unsafe things, or that is exploitable (e.g. because it is buggy, perhaps because the format is too complicated). All of these issues are also present with handling files that were not recently decrypted. From rjh at sixdemonbag.org Thu May 17 20:16:17 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 17 May 2018 14:16:17 -0400 Subject: next AE cipher =?UTF-8?Q?COLM=3F?= In-Reply-To: <87a7synqfr.fsf@wheatstone.g10code.de> References: <201805171542.43731.bernhard@intevation.de> <87a7synqfr.fsf@wheatstone.g10code.de> Message-ID: > And please don't mention GCM - counter based algorithms are way too > brittle for solid cryptography. Remember the RC4 lessons. To say nothing of the implementation difficulty. The more complex the algorithm, the less the chance it'll be implemented correctly. As someone who's implemented GCM a couple of times, it's not a simple mode. It's tremendously fiddly. Complicated code leads to complicated failure modes and testing difficulties. From gdt at lexort.com Thu May 17 21:48:28 2018 From: gdt at lexort.com (Greg Troxel) Date: Thu, 17 May 2018 15:48:28 -0400 Subject: danger of decrypted files without integrity protection In-Reply-To: <20180517185152.ljw1-%steffen@sdaoden.eu> (Steffen Nurpmeso's message of "Thu, 17 May 2018 20:51:52 +0200") References: <201805171026.13915.bernhard@intevation.de> <201805171630.09963.bernhard@intevation.de> <20180517185152.ljw1-%steffen@sdaoden.eu> Message-ID: Steffen Nurpmeso writes: > Greg Troxel wrote: > |Bernhard Reiter writes: > |> Am Donnerstag 17 Mai 2018 15:05:35 schrieb Greg Troxel: > |>> In your example, you asked a browser to render html, which has different > |>> norms than rendering incoming (and hence not requested by the user) > |>> email. ?Even a relatively paranoid browser with uMatrix will render > |>> images from different origins. > |> > |> It is a detail to the questions: > |> * is decrypting an email manually outside of a mailer safe? > |> -> no - for files that potentially will call home on opening > | > |Decrypting is not the problem. The problem is evaluating the file > |either with a program that interprets it and does unsafe things, or that > |is exploitable (e.g. because it is buggy, perhaps because the format is > |too complicated). All of these issues are also present with handling > |files that were not recently decrypted. > > Not being able to detect that injections happened because > decrypting silently succeeds because of missing i.-p. is the > problem on the S/MIME side (isn't it). Yes, that is a problem -- thinking you have integrity protection when you don't. I suspect, though, that almost everyone with that problem is accepting unencrypted mail also. So I didn't mean to suggest that there was nothing to fix -- only that "processing decrypted files is dangerous" is a subset of "processing files is dangerous". Even with integrity/dao protection, the notion that an authorized sender could not have sent a malicous file is an unwarranted conclusion -- certainly their machine could have been compromised, or they could have got it from somewhere else. (I'm not sure if that notion is wrapped up in this discussion or not.) From steffen at sdaoden.eu Thu May 17 20:51:52 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 17 May 2018 20:51:52 +0200 Subject: danger of decrypted files without integrity protection In-Reply-To: References: <201805171026.13915.bernhard@intevation.de> <201805171630.09963.bernhard@intevation.de> Message-ID: <20180517185152.ljw1-%steffen@sdaoden.eu> Greg Troxel wrote: |Bernhard Reiter writes: |> Am Donnerstag 17 Mai 2018 15:05:35 schrieb Greg Troxel: |>> In your example, you asked a browser to render html, which has different |>> norms than rendering incoming (and hence not requested by the user) |>> email. ?Even a relatively paranoid browser with uMatrix will render |>> images from different origins. |> |> It is a detail to the questions: |> * is decrypting an email manually outside of a mailer safe? |> -> no - for files that potentially will call home on opening | |Decrypting is not the problem. The problem is evaluating the file |either with a program that interprets it and does unsafe things, or that |is exploitable (e.g. because it is buggy, perhaps because the format is |too complicated). All of these issues are also present with handling |files that were not recently decrypted. Not being able to detect that injections happened because decrypting silently succeeds because of missing i.-p. is the problem on the S/MIME side (isn't it). --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 uri at mit.edu Fri May 18 04:16:44 2018 From: uri at mit.edu (Uri Blumenthal) Date: Fri, 18 May 2018 02:16:44 +0000 Subject: next AE cipher COLM? In-Reply-To: References: <201805171542.43731.bernhard@intevation.de> <87a7synqfr.fsf@wheatstone.g10code.de> Message-ID: As a cryptographer and a mathematician, I find both GCM and OCB modes quite fine. In general, IMHO ?counter based algorithms? (assuming you mean CTR mode) are the best performance-wise, and applicability-wise. Having formal mathematical proofs of correctness doesn?t hurt either (or did you notice?). I fail to see any similarities with RC4, and cannot guess what lessons you might be referring to. Although, if you found a weakness in GCM mode - by all means, please share it with the wider audience. Or is it that you find it more difficult to code than ECB? Any cryptographic software is ?fiddly? if you pay (or if you *don?t* pay!) enough attention. On May 17, 2018, at 14:16 , Robert J. Hansen > wrote: And please don't mention GCM - counter based algorithms are way too brittle for solid cryptography. Remember the RC4 lessons. To say nothing of the implementation difficulty. The more complex the algorithm, the less the chance it'll be implemented correctly. As someone who's implemented GCM a couple of times, it's not a simple mode. It's tremendously fiddly. Complicated code leads to complicated failure modes and testing difficulties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Fri May 18 09:08:22 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 18 May 2018 09:08:22 +0200 Subject: danger of decrypted files without integrity protection In-Reply-To: References: <201805171026.13915.bernhard@intevation.de> <20180517185152.ljw1-%steffen@sdaoden.eu> Message-ID: <201805180908.22567.bernhard@intevation.de> Am Donnerstag 17 Mai 2018 21:48:28 schrieb Greg Troxel: > I didn't mean to suggest that there was nothing to fix -- only that > "processing decrypted files is dangerous" is a subset of "processing > files is dangerous". I disagree. What efails reminds us of is that a decrypted file may contain cleverly placed pieces that will send a decrypted contents somewhere else, so it is more problematic because it may expose something that was intented to be kept confidential. If the decryption client will decrypt several different message parts in one go, then it could even be tricked to decrypt several messages parts. 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 Fri May 18 09:14:14 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 18 May 2018 09:14:14 +0200 Subject: next AE cipher COLM? In-Reply-To: <87a7synqfr.fsf@wheatstone.g10code.de> References: <201805171542.43731.bernhard@intevation.de> <87a7synqfr.fsf@wheatstone.g10code.de> Message-ID: <201805180914.14694.bernhard@intevation.de> Thanks for documenting the argument. I believe it is worth documenting it, because if a switch is done, it is done for many years to come. Am Donnerstag 17 Mai 2018 19:27:04 schrieb Werner Koch: > Adding another patented algorithm with zero experience in > the field is not helpful. The patent situation on COLM seems to be better than the one on OCB. For OCB Mr. Rogaway still holds patents (with several grants to "Open Source" licenses, but it is not completely clear what this means). For COLM and the involved PMAC he and John Black have waived their patent rights. 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 Fri May 18 09:19:32 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 18 May 2018 09:19:32 +0200 Subject: next AE cipher COLM? In-Reply-To: References: <201805171542.43731.bernhard@intevation.de> Message-ID: <201805180919.32426.bernhard@intevation.de> > Although, if you found a weakness in GCM mode - by all means, please share > it with the wider audience. Christian Forler and R?diger Weis report on problems with GCM around 28:00 in their 2017 CCC talk here: https://media.ccc.de/v/34c3-9142-resilienced_kryptographie#t=1748 where their cite three papers. -- 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 Fri May 18 10:12:53 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 May 2018 10:12:53 +0200 Subject: next AE cipher COLM? In-Reply-To: (Uri Blumenthal's message of "Fri, 18 May 2018 02:16:44 +0000") References: <201805171542.43731.bernhard@intevation.de> <87a7synqfr.fsf@wheatstone.g10code.de> Message-ID: <87lgchl6uy.fsf@wheatstone.g10code.de> On Fri, 18 May 2018 04:16, uri at mit.edu said: > I fail to see any similarities with RC4, and cannot guess what lessons > you might be referring to. Although, if you found a weakness in GCM RC4 has so many preconditions for safe use that it has never been used in a safe way. But it was easy to implement. GCM is of course easier to use and way better designed but still the reuse of the IV with the same key leaks the plaintext. And it is the most complicated mode to implement which I consider bad for security. OCB is a clean and simple design which does not leak the plaintest on accidental IV reuse. Shalom-Salam, Werner p.s. I have received questions on performance. Here is what Libgcrypt master yields on a i5-2410M using AES (enc has additional data): | nanosecs/byte mebibytes/sec cycles/byte CBC enc | 1.79 ns/B 531 MiB/s 4.13 c/B S/MIME CBC dec | 0.28 ns/B 3472 MiB/s 0.63 c/B CFB enc | 1.77 ns/B 538 MiB/s 4.08 c/B OpenPGP (rfc4880) CFB dec | 0.27 ns/B 3562 MiB/s 0.62 c/B CCM enc | 1.80 ns/B 531 MiB/s 4.13 c/B CCM dec | 2.07 ns/B 462 MiB/s 4.75 c/B EAX enc | 1.79 ns/B 531 MiB/s 4.13 c/B rfc4880bis EAX dec | 2.07 ns/B 461 MiB/s 4.75 c/B GCM enc | 0.68 ns/B 1413 MiB/s 1.55 c/B GCM dec | 0.95 ns/B 1008 MiB/s 2.18 c/B OCB enc | 0.28 ns/B 3360 MiB/s 0.65 c/B rfc4880bis OCB dec | 0.30 ns/B 3148 MiB/s 0.70 c/B -- # 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 muelli at cryptobitch.de Fri May 18 12:02:47 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Fri, 18 May 2018 12:02:47 +0200 Subject: danger of decrypted files without integrity protection In-Reply-To: <201805180908.22567.bernhard@intevation.de> References: <201805171026.13915.bernhard@intevation.de> <20180517185152.ljw1-%steffen@sdaoden.eu> <201805180908.22567.bernhard@intevation.de> Message-ID: <1526637767.14168.2.camel@cryptobitch.de> Hi, On Fri, 2018-05-18 at 09:08 +0200, Bernhard Reiter wrote: > Am Donnerstag 17 Mai 2018 21:48:28 schrieb Greg Troxel: > > I didn't mean to suggest that there was nothing to fix -- only that > > "processing decrypted files is dangerous" is a subset of "processing > > files is dangerous". > > I disagree. What efails reminds us of is that a decrypted > file may contain cleverly placed pieces that will send a decrypted > contents > somewhere else, so it is more problematic because it may expose > something that was intented to be kept confidential. But that's exactly what makes it a subset of the more general problem as per the email before. So I can't see where your disagreement comes from. Cheers, Tobi From uri at mit.edu Fri May 18 12:56:01 2018 From: uri at mit.edu (Uri Blumenthal) Date: Fri, 18 May 2018 10:56:01 +0000 Subject: next AE cipher COLM? In-Reply-To: <87lgchl6uy.fsf@wheatstone.g10code.de> References: <201805171542.43731.bernhard@intevation.de> <87a7synqfr.fsf@wheatstone.g10code.de> , <87lgchl6uy.fsf@wheatstone.g10code.de> Message-ID: <6E4F340E-3F5B-4546-917F-5D798E8D8FC6@mit.edu> If nonce reuse is a concern (which really shouldn't apply to OpenPGP or S/MIME, because each message should get its own unique random symmetric key - so the likelihood of collision is rather low), there's AES-GCM-SIV that's misuse-resistant (again, comes with security proofs). OCB had been released to some open source, and if need be - one can ask Phil Rogaway to make an explicit statement on its use in GnuPG (my gut feeling is he'd be happy to permit it). And yes, OCB shows excellent performance even on CPUs without AES-NI and PCMUL. P.S. Did but look at COLM - swamped with real work (plus: if I find a problem - it means it's broken; if I find no issue - it means nothing). COLM may be the best thing since sliced bread, but I personally prefer something with a longer history. Sent from my test iPhone > On May 18, 2018, at 04:22, Werner Koch wrote: > > On Fri, 18 May 2018 04:16, uri at mit.edu said: > >> I fail to see any similarities with RC4, and cannot guess what lessons >> you might be referring to. Although, if you found a weakness in GCM > > RC4 has so many preconditions for safe use that it has never been used > in a safe way. But it was easy to implement. > > GCM is of course easier to use and way better designed but still the > reuse of the IV with the same key leaks the plaintext. And it is the > most complicated mode to implement which I consider bad for security. > > OCB is a clean and simple design which does not leak the plaintest on > accidental IV reuse. > > > Shalom-Salam, > > Werner > > > > p.s. > I have received questions on performance. Here is what Libgcrypt master > yields on a i5-2410M using AES (enc has additional data): > > | nanosecs/byte mebibytes/sec cycles/byte > CBC enc | 1.79 ns/B 531 MiB/s 4.13 c/B S/MIME > CBC dec | 0.28 ns/B 3472 MiB/s 0.63 c/B > CFB enc | 1.77 ns/B 538 MiB/s 4.08 c/B OpenPGP (rfc4880) > CFB dec | 0.27 ns/B 3562 MiB/s 0.62 c/B > CCM enc | 1.80 ns/B 531 MiB/s 4.13 c/B > CCM dec | 2.07 ns/B 462 MiB/s 4.75 c/B > EAX enc | 1.79 ns/B 531 MiB/s 4.13 c/B rfc4880bis > EAX dec | 2.07 ns/B 461 MiB/s 4.75 c/B > GCM enc | 0.68 ns/B 1413 MiB/s 1.55 c/B > GCM dec | 0.95 ns/B 1008 MiB/s 2.18 c/B > OCB enc | 0.28 ns/B 3360 MiB/s 0.65 c/B rfc4880bis > OCB dec | 0.30 ns/B 3148 MiB/s 0.70 c/B > > -- > # Please read: Daniel Ellsberg - The Doomsday Machine # > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From muelli at cryptobitch.de Fri May 18 15:03:39 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Fri, 18 May 2018 15:03:39 +0200 Subject: next AE cipher COLM? In-Reply-To: <6E4F340E-3F5B-4546-917F-5D798E8D8FC6@mit.edu> References: <201805171542.43731.bernhard@intevation.de> <87a7synqfr.fsf@wheatstone.g10code.de> , <87lgchl6uy.fsf@wheatstone.g10code.de> <6E4F340E-3F5B-4546-917F-5D798E8D8FC6@mit.edu> Message-ID: <1526648619.23965.12.camel@cryptobitch.de> Hi, On Fri, 2018-05-18 at 10:56 +0000, Uri Blumenthal wrote: > which really shouldn't apply to OpenPGP or S/MIME, because each > message should get its own unique random symmetric key Mind you: people use OpenPGP not only for email but also for backups. That's why two-pass schemes are not suitable, because you cannot stream large amounts of data. There are still one-pass schemes which make nonce reuse less fatal as with AES-GCM. Cheers, Tobi From muelli at cryptobitch.de Fri May 18 16:36:58 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Fri, 18 May 2018 16:36:58 +0200 Subject: next AE cipher COLM? In-Reply-To: <87lgchl6uy.fsf@wheatstone.g10code.de> References: <201805171542.43731.bernhard@intevation.de> <87a7synqfr.fsf@wheatstone.g10code.de> <87lgchl6uy.fsf@wheatstone.g10code.de> Message-ID: <1526654218.5232.4.camel@cryptobitch.de> Hi, On Fri, 2018-05-18 at 10:12 +0200, Werner Koch wrote: > OCB is a clean and simple design which does not leak the plaintest on > accidental IV reuse. > It may not leak the actual plaintext right away but it degenerates to ECB which some people consider to be equally bad. Cheers, Tobi From ilf at zeromail.org Sat May 19 14:54:18 2018 From: ilf at zeromail.org (ilf) Date: Sat, 19 May 2018 14:54:18 +0200 Subject: website and versions Message-ID: <20180519125418.GB1490@zeromail.org> https://git.gnupg.org/ still sais: > View the GnuPG modern (2.1) code > View the GnuPG stable (2.0) code > View the GnuPG classic (1.4) code This should probably be changed to "GnuPG modern (2.2)" and "GnuPG classic (1.4)", removing 2.0 and 2.1. -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From thibault at thb.lt Sat May 19 14:58:48 2018 From: thibault at thb.lt (Thibault Polge) Date: Sat, 19 May 2018 14:58:48 +0200 Subject: Possible error or ambiguity in "Automated signature checking" doc Message-ID: <87d0xrdcon.fsf@thb.lt> Hi, I'm working on a parser for the output of gpg --verify --status-fd and the documentation at [1] doesn't match the output I get from GnuPG. According to this page, if "signature [is] valid but at least one certificate has expired", I should expect to see EXPKEYSIG, VALIDSIG, TRUST_FULLY; but actual logs don't include any TRUST_*. Eg, with an expired subkey of a still valid key, I get: [GNUPG:] NEWSIG expired-subkey at badsig.example.com [GNUPG:] KEYEXPIRED 1262392402 [GNUPG:] KEY_CONSIDERED 98CEF64929BD15E2E615814E56FB8134143D7A68 0 [GNUPG:] KEYEXPIRED 1262392402 [GNUPG:] SIG_ID PcUpJdyvZiBI1mGBT7YS1p+710E 2010-01-01 1262306010 [GNUPG:] KEYEXPIRED 1262392402 [GNUPG:] KEY_CONSIDERED 98CEF64929BD15E2E615814E56FB8134143D7A68 0 [GNUPG:] EXPKEYSIG 83BAA10B93D9A003 Expired-Subkey Badsig [GNUPG:] VALIDSIG 57FABA5D48DB0C6239D504FC83BAA10B93D9A003 2010-01-01 1262306010 0 4 0 1 8 01 98CEF64929BD15E2E615814E56FB8134143D7A68 [GNUPG:] KEYEXPIRED 1262392402 [GNUPG:] KEY_CONSIDERED 98CEF64929BD15E2E615814E56FB8134143D7A68 0 The output with an expired key is similar. There are a few more ambiguities in this page: - The word "certificate" in the same sentence is unclear. Is it a (sub)key or something else? - Also, the case where the signature *and* the key have expired should be documented. The current documentation seems to make them mutually exclusive, which they're not. - I'm not sure I understand why the only value for TRUST_* is TRUST_FULLY. At the very least TRUST_ULTIMATE should be accepted too, but really everything but NEVER may be good depending on the context. It should at least be clarified that TRUST_FULLY and TRUST_NEVER are not the only possible values. If someone could clarify this, I'd be happy to sent a PR to improve the documentation. Thanks! [1] -- Thibault -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dgouttegattat at incenp.org Sat May 19 21:43:25 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 19 May 2018 20:43:25 +0100 Subject: [PATCH scute] Build a second library which uses the signing key. In-Reply-To: <7affff88ed4366c5c0399ece0a5d1a0fb729ec0d.camel@googlemail.com> References: <7affff88ed4366c5c0399ece0a5d1a0fb729ec0d.camel@googlemail.com> Message-ID: <20180519194325.7035-1-dgouttegattat@incenp.org> Hi, > This patch introduces the configure switch --enable-sigkey which > enables building of scutesig.so which uses the signature key. Thanks. However I propose (see the patch below) a slightly modified version in which the --enable-signing-key flag simply changes the key to use from the authentication key to the signing key, without building a second library. This avoid further code duplication in src/Makefile.am and makes a less intrusive patch. If you need both a scute using the authentication key and a scute using the signing key, then you just have to configure and build twice (first without the --enable-signing-key flag, then with it) and rename one of the two libraries accordingly. -- >8 -- Subject: [PATCH scute] Allow to use the signing key. * configure.ac: New flag --enable-signing-key. * src/slots.c (slot_init): Use the signing key. (session_sign): Likewise. -- This patch allows to build a version of Scute which uses the signing key instead of the authentication key. Suggested-by: Dirk Gottschalk Signed-off-by: Damien Goutte-Gattat --- configure.ac | 7 +++++++ src/slots.c | 11 +++++++++++ 2 files changed, 18 insertions(+) diff --git a/configure.ac b/configure.ac index 3615a49..7848690 100644 --- a/configure.ac +++ b/configure.ac @@ -313,6 +313,13 @@ else fi AM_CONDITIONAL(HAVE_GPGSM, test "$GPGSM" != "no") +# Use signing key? +AC_ARG_ENABLE([signing-key], + AS_HELP_STRING([--enable-signing-key], + [Use signing key instead of authentication key])) +if test "$enable_signing_key" = yes ; then + AC_DEFINE(ENABLE_SIGNING_KEY,1,[Whether to use the signing key.]) +fi dnl Check for GPGSM version requirement. GPGSM_VERSION=unknown diff --git a/src/slots.c b/src/slots.c index fc69d15..f414331 100644 --- a/src/slots.c +++ b/src/slots.c @@ -385,7 +385,12 @@ slot_init (slot_iterator_t id) gpg_error_t err = 0; struct slot *slot = scute_table_data (slots, id); +#if ENABLE_SIGNING_KEY + err = scute_gpgsm_get_cert (slot->info.grip1, 1, add_object, slot); +#else err = scute_gpgsm_get_cert (slot->info.grip3, 3, add_object, slot); +#endif + if (err) goto init_out; @@ -1033,8 +1038,14 @@ session_sign (slot_iterator_t id, session_iterator_t sid, } sig_len = *pulSignatureLen; +#if ENABLE_SIGNING_KEY + err = scute_agent_sign (slot->info.grip1, pData, ulDataLen, + pSignature, &sig_len); +#else err = scute_agent_sign (slot->info.grip3, pData, ulDataLen, pSignature, &sig_len); +#endif + /* FIXME: Oh well. */ if (gpg_err_code (err) == GPG_ERR_INV_ARG) return CKR_BUFFER_TOO_SMALL; -- 2.14.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From fejj at gnome.org Sat May 19 20:42:54 2018 From: fejj at gnome.org (Jeffrey Stedfast) Date: Sat, 19 May 2018 14:42:54 -0400 Subject: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG In-Reply-To: <0FD3E4E1-4C61-44BC-8B67-9996DE9D5DF2@microsoft.com> References: <87y3kb471j.fsf@fifthhorseman.net> <9201448a-83f1-2bf5-14d4-6b862a13e31e@gnome.org> <87o9l742kv.fsf@fifthhorseman.net> <0FD3E4E1-4C61-44BC-8B67-9996DE9D5DF2@microsoft.com> Message-ID: I kinda dropped the ball on this a while back but due to the recent Efail news, I resurrected my patch and have now committed it: https://github.com/jstedfast/gmime/commit/57d16f7ca9ff76e2c46c518db43b6822a2ea075a There is now a GMIME_VERIFY_DISABLE_ONLINE_CERTIFICATE_CHECKS flag that sets gpgsm into offline mode. Question: Should this behavior be the default? I.e. should I invert the logic for DISABLE_ONLINE_CERTIFICATE_CHECKS into *ENABLE*_ONLINE_CERTIFICATE_CHECKS? I'm wondering if perhaps that might be more prudent. Unfortunately, I think that means it opens the client up to other potential risks such as letting revoked certificates go undiscovered. Comments? Suggestions? Jeff On 2/3/2018 1:48 PM, Jeffrey Stedfast wrote: > I've added code locally to set offline mode but reading the docs: > > https://www.gnupg.org/documentation/manuals/gpgme/Offline-Mode.html > > it suggests that setting offline mode only works for CMS and not OpenPGP? Can anyone from the GPGME team verify this? If so, I'll drop the flags that would indicate that this works in OpenPGP mode. > > Jeff > > ?On 2/2/18, 2:24 PM, "gmime-devel-list on behalf of Daniel Kahn Gillmor" wrote: > > On Fri 2018-02-02 13:13:32 -0500, Jeffrey Stedfast wrote: > >> * tell GMime to disable crl checks > > > > I'd be willing to add an API to disable CRL checks if there's a way I > > can pass that along to gpgme. > > thanks! > > >> * tell GMime not to verify S/MIME signatures at all > > > > Willing to add an API for this as well (although I guess it's not > > necessary if an API to disable CRL checks is added?) > > i would rather not disable signature verification if we can do it > without metadata leakage. > > > Well, I suppose that, like S/MIME signature verification, it would also > > disable PGP key-server lookups? > > ah, right, i should be clearer about the use cases. I'm thinking right > now about the use of GMime for *reading* mail. (Maybe we can talk about > composing mail separately?) > > Is there any point during mail reading that you expect GMime to trigger > a PGP keyserver lookup? > > > It might be best if there was a way to disable CRL checks on a per > > gpgme_ctx_t basis as opposed to globally, but I can have GMime use the > > global option until such an option exists (note: might be racey if you > > try and verify signatures on multiple threads). > > gpgme_set_offline is actually per-gpgme_ctx_t: > > -- Function: void gpgme_set_offline (gpgme_ctx_t CTX, int YES) > > Sorry that i omitted that from the shorthand in my earlier message. > > But how would i use that with GMime? As of GMime 3 i'm in the practice > of not not having to handle the GMimeCryptoCtx directly, because Gmime > does the Right Thing anyway :) -- i'd like to keep that nice behavior! > > GMime should consider it as a new value for GMimeVerifyFlags? But i > notice that g_mime_multipart_encrypted_decrypt () only takes a > GMimeDecryptFlags, and it probably affects this too. I'll send a > separate message to gmime-devel about this. > > > I'll wait for the GnuPG/GPGME devs to comment before making changes to > > GMime. > > your message doesn't appear to have been let through to the gnupg-devel@ > mailing list yet [0], so perhaps it's in moderation. > > --dkg > > [0] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnupg.org%2Fpipermail%2Fgnupg-devel%2F2018-February%2F&data=02%7C01%7Cjestedfa%40microsoft.com%7Ca93726fccf3341b635ba08d56a72a2c3%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636531962953290821&sdata=31FiENC95WdhP0le8lNFj%2BMG92pmesnANJic2TFnzLA%3D&reserved=0 > > From dirk.gottschalk1980 at googlemail.com Sun May 20 01:06:03 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 20 May 2018 01:06:03 +0200 Subject: [PATCH scute] Build a second library which uses the signing key. In-Reply-To: <20180519194325.7035-1-dgouttegattat@incenp.org> References: <7affff88ed4366c5c0399ece0a5d1a0fb729ec0d.camel@googlemail.com> <20180519194325.7035-1-dgouttegattat@incenp.org> Message-ID: Hi. Am Samstag, den 19.05.2018, 20:43 +0100 schrieb Damien Goutte-Gattat: > Hi, > > > This patch introduces the configure switch --enable-sigkey which > > enables building of scutesig.so which uses the signature key. > > Thanks. > > However I propose (see the patch below) a slightly modified version > in which the --enable-signing-key flag simply changes the key to > use from the authentication key to the signing key, without building > a second library. This avoid further code duplication in > src/Makefile.am and makes a less intrusive patch. Yes, but... > If you need both a scute using the authentication key and a scute > using the signing key, then you just have to configure and build > twice (first without the --enable-signing-key flag, then with it) > and rename one of the two libraries accordingly. ...this was the Problem in my case. I needed both and needed them to coexist. Different names of the shared object help me to differ both of them. I tried to make the name of the library file conditional, but autotools don't like this and I also had to duplicate the instructions in Makefila.am in this case. I agree that this is not the best possible way. The perfect way would be to put both in one library, but, after viewing the code, I think this is basically not possible, since this is a Mozilla-Plugin and so it is bound to the functions which are called by Firefox, Thunderbird, LibreOffice and so on. I don't like the idea of renaming the libraries after installation, but it seems the best way to avoid duplicate code. An alternative to renaming would be to define a different --libdir=*** while configuring the package and install into different sub-directories. I think this should be the recommended way to install both libraries on the same system. Renaming the files could increase the risk of mistakes made by user. 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 dgouttegattat at incenp.org Sun May 20 18:55:54 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 20 May 2018 17:55:54 +0100 Subject: [PATCH scute] Build a second library which uses the signing key. In-Reply-To: References: Message-ID: <20180520165554.16103-1-dgouttegattat@incenp.org> On 05/20/2018 12:06 AM, Dirk Gottschalk wrote: > I tried to make the name of the library file conditional, but > autotools don't like this Indeed, I don't think there is support for this in Autotools. > I don't like the idea of renaming the libraries after > installation [...] Renaming the files could increase the risk > of mistakes made by user. Another drawback of asking the user to do the renaming is that each user may choose a different name, which may complicate support. I think I like your original approach better. I refactored the src/Makefile.am part to avoid code duplication. Now I just want to do some more testing before applying to master. -- >8 -- Subject: [PATCH scute] Allow to use the signing key. * configure.ac: New flag --enable-signing-key. * src/Makefile.am: Build scutesig, which uses the signing key. * src/slots.c (slot_init): Use the signing key if building scutesig. (session_sign): Likewise. -- This patch allows to build scutesig.so, a version of Scute which uses the signing key, along with the normal scute.so which uses the authentication key. Suggested-by: Dirk Gottschalk Signed-off-by: Damien Goutte-Gattat --- configure.ac | 5 +++++ src/Makefile.am | 9 +++++++++ src/slots.c | 11 +++++++++++ 3 files changed, 25 insertions(+) diff --git a/configure.ac b/configure.ac index 3615a49..8c8f1b1 100644 --- a/configure.ac +++ b/configure.ac @@ -313,6 +313,11 @@ else fi AM_CONDITIONAL(HAVE_GPGSM, test "$GPGSM" != "no") +# Use signing key? +AC_ARG_ENABLE([signing-key], + AS_HELP_STRING([--enable-signing-key], + [Build a version of Scute using the signing key])) +AM_CONDITIONAL([ENABLE_SCUTESIG], [test "$enable_signing_key" = yes]) dnl Check for GPGSM version requirement. GPGSM_VERSION=unknown diff --git a/src/Makefile.am b/src/Makefile.am index 9ceef93..8063ab9 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -133,3 +133,12 @@ scute_la_LIBADD = $(scute_libadd) \ scute_la_CPPFLAGS = -I$(srcdir)/../include \ @LIBASSUAN_CFLAGS@ @GPG_ERROR_CFLAGS@ scute_la_SOURCES = $(sources) + +if ENABLE_SCUTESIG +lib_LTLIBRARIES += scutesig.la +scutesig_la_LDFLAGS = $(scute_la_LDFLAGS) +scutesig_la_DEPENDENCIES = $(scute_la_DEPENDENCIES) +scutesig_la_LIBADD = $(scute_la_LIBADD) +scutesig_la_CPPFLAGS = $(scute_la_CPPFLAGS) -DENABLE_SIGNING_KEY +scutesig_la_SOURCES = $(scute_la_SOURCES) +endif diff --git a/src/slots.c b/src/slots.c index fc69d15..f414331 100644 --- a/src/slots.c +++ b/src/slots.c @@ -385,7 +385,12 @@ slot_init (slot_iterator_t id) gpg_error_t err = 0; struct slot *slot = scute_table_data (slots, id); +#if ENABLE_SIGNING_KEY + err = scute_gpgsm_get_cert (slot->info.grip1, 1, add_object, slot); +#else err = scute_gpgsm_get_cert (slot->info.grip3, 3, add_object, slot); +#endif + if (err) goto init_out; @@ -1033,8 +1038,14 @@ session_sign (slot_iterator_t id, session_iterator_t sid, } sig_len = *pulSignatureLen; +#if ENABLE_SIGNING_KEY + err = scute_agent_sign (slot->info.grip1, pData, ulDataLen, + pSignature, &sig_len); +#else err = scute_agent_sign (slot->info.grip3, pData, ulDataLen, pSignature, &sig_len); +#endif + /* FIXME: Oh well. */ if (gpg_err_code (err) == GPG_ERR_INV_ARG) return CKR_BUFFER_TOO_SMALL; -- 2.14.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From muelli at cryptobitch.de Mon May 21 15:17:49 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Mon, 21 May 2018 15:17:49 +0200 Subject: gpgme: detect missing primary key Message-ID: <1526908669.4828.7.camel@cryptobitch.de> Hi, I am using gpgme and I want to detect when the actual key for signing some other key is not present, e.g. after having followed https://wiki.d ebian.org/Subkeys. gpg --list-secret-keys shows sec# rsa2048 2018-02-13 [SC] D6951AD1A148A16C1B1FFACABA64A52A51061371 uid [ unknown] foobar ssb rsa2048 2018-02-13 [E] ssb rsa2048 2018-02-13 [S] presumingly the "sec#" indicates the missing primary key. With gpgme I get this: In [4]: list(ctx.keylist(secret=True)) Out[4]: [Key(can_authenticate=0, can_certify=1, can_encrypt=1, can_sign=1, chain_id=None, disabled=0, expired=0, fpr='D6951AD1A148A16C1B1FFACABA64A52A51061371', invalid=0, is_qualified=0, issuer_name=None, issuer_serial=None, keylist_mode=1, owner_trust=0, protocol=0, revoked=0, secret=1, subkeys=[SubKey(can_authenticate=0, can_certify=1, can_encrypt=0, can_sign=1, card_number=None, curve=None, disabled=0, expired=0, expires=0, fpr='D6951AD1A148A16C1B1FFACABA64A52A51061371', invalid=0, is_cardkey=0, is_qualified=0, keygrip='39B99ED24E2D2AC200A296712B1A6D756C4ABC3C', keyid='BA64A52A51061371', length=2048, pubkey_algo=1, revoked=0, secret=0, timestamp=1518519237), SubKey(can_authenticate=0, can_certify=0, can_encrypt=1, can_sign=0, card_number=None, curve=None, disabled=0, expired=0, expires=0, fpr='0192F548677FE38FE46B095E5A531CC30D4F7810', invalid=0, is_cardkey=0, is_qualified=0, keygrip='14CDE4A9EC7F2716AAB134247CA778321F343E73', keyid='5A531CC30D4F7810', length=2048, pubkey_algo=1, revoked=0, secret=1, timestamp=1518519237), SubKey(can_authenticate=0, can_certify=0, can_encrypt=0, can_sign=1, card_number=None, curve=None, disabled=0, expired=0, expires=0, fpr='D04938AFB2DCD015AFD79C12B9B9338F1984FBE1', invalid=0, is_cardkey=0, is_qualified=0, keygrip='51A932F25B04A04C2C75014D58028D4C51451576', keyid='B9B9338F1984FBE1', length=2048, pubkey_algo=1, revoked=0, secret=1, timestamp=1518519280)], uids=[UID(address='foo at bar', comment='', email='foo at bar', invalid=0, name='foobar', revoked=0, signatures=[], tofu=[], uid='foobar ', validity=0)])] Nothing seems to indicate the missing primary key. Unless I am missing something. How would I detect the above mentioned scenario? I've quickly grepped through gpgme and in keylist.c I can only find "sec" being parsed, not "sec#". Cheers, Tobi From muelli at cryptobitch.de Mon May 21 18:32:07 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Mon, 21 May 2018 18:32:07 +0200 Subject: gpgme: detect missing primary key In-Reply-To: <1526908669.4828.7.camel@cryptobitch.de> References: <1526908669.4828.7.camel@cryptobitch.de> Message-ID: <1526920327.4828.12.camel@cryptobitch.de> Hi, I've actually found it now while digging through the gpgme code. src/keylist.c has a parse_sec_field15 function which essentially does this: else if (*field == '#') { subkey->secret = 0; key->secret = 1; } And indeed, this is the check to perform: In [10]: k = list(ctx.keylist(secret=True))[0] In [11]: k.secret Out[11]: 1 In [12]: k.can_certify Out[12]: 1 In [13]: k.subkeys[0].can_certify Out[13]: 1 In [14]: k.subkeys[0].secret Out[14]: 0 Cheers, Tobi On Mon, 2018-05-21 at 15:17 +0200, Tobias Mueller wrote: > Hi, > > I am using gpgme and I want to detect when the actual key for signing > some other key is not present, e.g. after having followed https://wiki > .d > ebian.org/Subkeys. > > gpg --list-secret-keys shows > > sec# rsa2048 2018-02-13 [SC] > D6951AD1A148A16C1B1FFACABA64A52A51061371 > uid [ unknown] foobar > ssb rsa2048 2018-02-13 [E] > ssb rsa2048 2018-02-13 [S] > > > presumingly the "sec#" indicates the missing primary key. > > With gpgme I get this: > > In [4]: list(ctx.keylist(secret=True)) > Out[4]: [Key(can_authenticate=0, can_certify=1, can_encrypt=1, > can_sign=1, chain_id=None, disabled=0, expired=0, > fpr='D6951AD1A148A16C1B1FFACABA64A52A51061371', invalid=0, > is_qualified=0, issuer_name=None, issuer_serial=None, keylist_mode=1, > owner_trust=0, protocol=0, revoked=0, secret=1, > subkeys=[SubKey(can_authenticate=0, can_certify=1, can_encrypt=0, > can_sign=1, card_number=None, curve=None, disabled=0, expired=0, > expires=0, fpr='D6951AD1A148A16C1B1FFACABA64A52A51061371', invalid=0, > is_cardkey=0, is_qualified=0, > keygrip='39B99ED24E2D2AC200A296712B1A6D756C4ABC3C', > keyid='BA64A52A51061371', length=2048, pubkey_algo=1, revoked=0, > secret=0, timestamp=1518519237), SubKey(can_authenticate=0, > can_certify=0, can_encrypt=1, can_sign=0, card_number=None, > curve=None, > disabled=0, expired=0, expires=0, > fpr='0192F548677FE38FE46B095E5A531CC30D4F7810', invalid=0, > is_cardkey=0, > is_qualified=0, keygrip='14CDE4A9EC7F2716AAB134247CA778321F343E73', > keyid='5A531CC30D4F7810', length=2048, pubkey_algo=1, revoked=0, > secret=1, timestamp=1518519237), SubKey(can_authenticate=0, > can_certify=0, can_encrypt=0, can_sign=1, card_number=None, > curve=None, > disabled=0, expired=0, expires=0, > fpr='D04938AFB2DCD015AFD79C12B9B9338F1984FBE1', invalid=0, > is_cardkey=0, > is_qualified=0, keygrip='51A932F25B04A04C2C75014D58028D4C51451576', > keyid='B9B9338F1984FBE1', length=2048, pubkey_algo=1, revoked=0, > secret=1, timestamp=1518519280)], uids=[UID(address='foo at bar', > comment='', email='foo at bar', invalid=0, name='foobar', revoked=0, > signatures=[], tofu=[], uid='foobar ', validity=0)])] > > > Nothing seems to indicate the missing primary key. > Unless I am missing something. > > How would I detect the above mentioned scenario? > > I've quickly grepped through gpgme and in keylist.c I can only find > "sec" being parsed, not "sec#". > > > Cheers, > Tobi > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From dkg at fifthhorseman.net Mon May 21 21:23:15 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 21 May 2018 15:23:15 -0400 Subject: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG In-Reply-To: References: <87y3kb471j.fsf@fifthhorseman.net> <9201448a-83f1-2bf5-14d4-6b862a13e31e@gnome.org> <87o9l742kv.fsf@fifthhorseman.net> <0FD3E4E1-4C61-44BC-8B67-9996DE9D5DF2@microsoft.com> Message-ID: <877enwke3g.fsf@fifthhorseman.net> On Sat 2018-05-19 14:42:54 -0400, Jeffrey Stedfast wrote: > I kinda dropped the ball on this a while back but due to the recent > Efail news, I resurrected my patch and have now committed it: > > https://github.com/jstedfast/gmime/commit/57d16f7ca9ff76e2c46c518db43b6822a2ea075a > > There is now a GMIME_VERIFY_DISABLE_ONLINE_CERTIFICATE_CHECKS flag that > sets gpgsm into offline mode. > > Question: Should this behavior be the default? I.e. should I invert the > logic for DISABLE_ONLINE_CERTIFICATE_CHECKS into > *ENABLE*_ONLINE_CERTIFICATE_CHECKS? > > I'm wondering if perhaps that might be more prudent. > > Unfortunately, I think that means it opens the client up to other > potential risks such as letting revoked certificates go undiscovered. I lean toward the default being no metadata leakage. I agree that there is a risk about revoked certificates going undetected, but that's something that the certificate scheme needs to deal with separately, i think, and it's not appropriate to deal with it at message investigation time. thanks for working on this, Jeff. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ineiev at gnu.org Tue May 22 11:54:26 2018 From: ineiev at gnu.org (Ineiev) Date: Tue, 22 May 2018 05:54:26 -0400 Subject: [GPA][PATCH] option->description in confdialog.c In-Reply-To: <20160326094338.GA21716@gnu.org> References: <20160326094338.GA21716@gnu.org> Message-ID: <20180522095426.GK8919@gnu.org> Hello, On Sat, Mar 26, 2016 at 05:43:38AM -0400, Ineiev wrote: > > I was testing i18n in GPA and noticed that some group labels are > truncated; I cheched confdialog.c and found out that there is > a 80-character limit for them: > ... > { > if (option->flags & GPGME_CONF_GROUP) > { > char name[80]; > ... > > Now, if we use Cyrillics it's only 40 letters, which tends to be > insufficient for Slavic languages; I'd suggest allocating memory > dynamically. > > Then, I saw that commas in the labels are shown as '%2c', in > other words, the descriptions should be unescaped (this also applies > to other pieces of confdialog.c). (I used current GPGME HEAD.) > > At last, there is a bug in the percent_unescape function itself: > the resulting string is not closed by '\0' in its end, and when > the unescaping is not trivial, the the string shows a duplicate tail. Rebased against current HEAD, split into 3 patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-percent-unescaping.patch Type: text/x-diff Size: 719 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Eliminate-arbitrary-length-limit-on-labels.patch Type: text/x-diff Size: 2214 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Unescape-description-texts.patch Type: text/x-diff Size: 2167 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From look at my.amazin.horse Tue May 22 21:44:09 2018 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 22 May 2018 21:44:09 +0200 Subject: Keyservers and GDPR Message-ID: <20180522194409.tmrteipcsoorisns@calamity> Hey there, (cross-posting on all the cool pgp lists) so Dominik and I have been thinking a bit about how GDPR might affect OpenKeychain, and its interoperability with public keyservers. Turns out this is a hard question - in the end we couldn't answer whether publishing a tool that offers keyserver interoperability really made us a "data controller"? But let's start with keyservers first: "Processing" of data in the GDPR sense includes storage and distribution. Names and email addresses are personally identifiable information (PII). This makes the provider of a keyserver a data processor in the sense of the GDPR. Now, since the PII that is uploaded is not used to fulfill contractual obligations, keyservers actually need informed consent from the user about what is going to happen with that data. It's unclear how such consent might look like given the API interface. But what's worse, in the current implementation of SKS and the public keyserver pool, it is impossible by design to remove a user's data once it is published. This conflicts with the "right to be forgotten". My personal conclusion is that keyservers that support user id packets are, quite simply, incompatible with GDPR law. Has anyone else thought about this? It's fairly unlikely that there will be actual consequences since keyservers aren't widely used, but running a keyserver on this assumption is hardly reassuring. From the view of an app, the GDPR requires "privacy by design" and "privacy by default". This conflicts with a workflow that asks the user for their email address and name, and then irremovably uploads this information to a public listing. On the other hand, it can be argued that this is a tool that only does what the user asks it to do, the decision and responsibility lies with the user. Looking at some extreme cases: a Browser surely doesn't take responsibility for what the user inputs on websites. But a Twitter client does take responsibility for informing the user when they publish their location in their tweets. For OpenKeychain, we plan to move uploading of key material a bit farther out of the way and do a better job at informing the user what's going to happen. But that's a stopgap measure, since the user can't simply be asked to waive their rights. Hopefully we can soon move away from keyservers for key discovery or distribution. Thoughts? - V PS: randomly signing this message /o/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From bernhard at intevation.de Wed May 23 08:27:04 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 23 May 2018 08:27:04 +0200 Subject: Keyservers and GDPR In-Reply-To: <20180522194409.tmrteipcsoorisns@calamity> References: <20180522194409.tmrteipcsoorisns@calamity> Message-ID: <201805230827.08302.bernhard@intevation.de> Hi Vincent, Am Dienstag 22 Mai 2018 21:44:09 schrieb Vincent Breitmoser: > My personal conclusion is that keyservers that support user id packets are, > quite simply, incompatible with GDPR law. Has anyone else thought about > this? thinking about earlier data privacy laws (which were quite similiar to GDPR in many respects) and pubkey servers got me to no clear conclusion. > For OpenKeychain, we plan to move uploading of key material a bit farther > out of the way and do a better job at informing the user what's going to > happen. If our goal is to automate the common case in an end-to-end crypto mail communication, then asking the user a data privacy agreement question is a stumbling block. I would degrate the user experience a lot. Note that if you use WKD with your email provider and just the email address in the key id (as supported by a policy option), there is no additional personal data saved nor communicated. The email provider already has your email address and the person asking via WKD also. In addition serving of the public key on behalf of ther user could be added to the terms of service of the email provider. Overal I think WKD is doing quite well on the data privacy side and will allow a good user experience by not asking each time to publish a new pubkey for oneself. 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 nd at syndicat.com Wed May 23 07:27:34 2018 From: nd at syndicat.com (Niels Dettenbach (Syndicat IT & Internet)) Date: Wed, 23 May 2018 07:27:34 +0200 Subject: Keyservers and GDPR In-Reply-To: <20180522194409.tmrteipcsoorisns@calamity> References: <20180522194409.tmrteipcsoorisns@calamity> Message-ID: <8F7E12CF-206E-4BCF-8119-701610E49590@syndicat.com> Am 22. Mai 2018 21:44:09 MESZ schrieb Vincent Breitmoser : >Now, since the PII that is uploaded is not used to fulfill contractual >obligations I'm not a lawyer, but i see this vice versa. Users upload their keys for the purpose of their usage in the "web of trust" and expect their availability (storage, processing)there for this. A contract with the server owner/admin IS emerged with the transfer of the data in the conventional keyserver protocol without any further "written" contract. Extended, written explicite order is required if the keyserver (their owner) want to use that data for other purposes, not covered by the specs. This is my view. But clearifying this needs a good las expert with a good understanding in the specs and the whole process. just my two cents. Niels. -- Niels Dettenbach Syndicat IT & Internet http://www.Syndicat.com From patrick at enigmail.net Wed May 23 11:07:10 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 23 May 2018 11:07:10 +0200 Subject: Keyservers and GDPR In-Reply-To: <20180522194409.tmrteipcsoorisns@calamity> References: <20180522194409.tmrteipcsoorisns@calamity> Message-ID: <8f9b3617-5e52-e880-8a62-c2a2bcede122@enigmail.net> On 22.05.18 21:44, Vincent Breitmoser wrote: [...] > My personal conclusion is that keyservers that support user id packets are, > quite simply, incompatible with GDPR law. Has anyone else thought about this? > It's fairly unlikely that there will be actual consequences since keyservers > aren't widely used, but running a keyserver on this assumption is hardly > reassuring. There are actually two different types of keyservers, which should be clearly distinguished. 1. the pool of SKS keyservers: as anyone can upload anybody's key, and as it does not allow to delete keys, it's IMHO by not compatible with GDPR. 2. other types of keyservers like the run by Mailvelope (and possibly others that I don't know of), that verify the keys they receive and allow to delete keys, are compatible with GDPR, or can be made compatible easily. -Patrick From ilf at zeromail.org Wed May 23 11:27:15 2018 From: ilf at zeromail.org (ilf) Date: Wed, 23 May 2018 11:27:15 +0200 Subject: Keyservers and GDPR In-Reply-To: <20180522194409.tmrteipcsoorisns@calamity> References: <20180522194409.tmrteipcsoorisns@calamity> Message-ID: <20180523092715.GC1663@zeromail.org> tl;dr: Keep calm and keep running keyservers. Vincent Breitmoser: > (cross-posting on all the cool pgp lists) (I wonder, if this really needs to be an all the four lists. I think sks-devel@ might be the most appropriate. Having said that, I'm only replying to gnupg-devel@ because I'm not subscribed to sks-devel at . Feel free to relay my message.) > My personal conclusion is that keyservers that support user id packets > are, quite simply, incompatible with GDPR law. There is a ton of FUD about the GDPR out there right now. Most of it frivolous. (Actually, a lot of it is deliberate fearmongering by people who happen to sell legal advice on the GDPR.) First of all, the GDPR is not completely new. All EU member states already have data protection laws, some - like Germany - already very strong ones. The concepts (PII, responsibilities, technological and organisational measures, information and documentation obligations) have already been in place with the old Data Protection Directive from 1995, which the GDPR is updating. I admit that the GDPR can be read and interpreted in a fatalist way. But most people leaning that way seem to not have read the older laws. Laws are not set in stone. Laws include leeways, deliberate or unintended. Laws do not depend on their interpretation by laypeople. There is a huge dedicated system for its interpretation, conflict resolve, judgement and enforcement. In the case of the GDPR, the very first step of that system are National Data Protection Authorities (DPA). They have the power - and the responsibility - to investigate possible violations of the GDPR. They have been understaffed for years, in many countries dangerously so. They are getting a lot more powers and responsibilities with the GDPR, but their resources are growing way slower than their tasks. They are simply understaffed and overworked. So from all the possible GDPR violations they will be notified about, they will work off the biggest and most obvious ones first. Their focus will be on the Facebooks - and not on small nerd projects or personal websites. They have the power to say "we don't care about this weird thing called keyserver" - and the probably will. Now even if someone found data protection law infringements with a keyserver, filed a specific and well-worded legal complaint with a DPA, and a DPA found the resources to look into it, and the DPA found some violation of the GDPR (four big IFs!) - the DPAs will not go around and issue sanctions and fine people. First of all, their job is not to generate revenues by fines. Their job is to enforce data protection law. If a DPA did find an issue with a keyserver - or the very concept - they would reach out and talk to the people running the servers. They would hear their perspective, learn more about the very concept - and try to work out a viable solution to provide the service without possible data protection infringements. This is their job and their goal. The most feared sanction of some undefined GDPR violation is a fine. As I layed out, DPAs don't want to issue fines, they want to stop privacy violations. And they will not blindly issue a fine without talking to you first. That being said, they obviously do have the power to issue fines. After due process. However, this power is also not new, it has also existed in many countries. And DPAs don't run around and fine people left and right (you would have heard about that), they exercise their power in a balanced way. And fines are always in relation to the economic and personal circumstances of the - then guilty and obstinate - data protection violators. I guess most keyservers are run by non-profit individuals or institutions. Even if a company runs a keyserver, it doesn't make money with that service. Therefore, I think the chance of *any* fine is negligible - and the chance of an unreasonably high fine is almost zero. And if it ever came to this, the community and public alarmed by public outcry would probably donate more than the fine issued. To sum up: Keep calm and keep running keyservers. You'll be fine. More elaboration in German: https://netzpolitik.org/2018/bussgelder-bei-datenschutzverstoessen-angst-vor-einem-phantom/ Disclaimer: IANAL. This is not legal advice. -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ilf at zeromail.org Wed May 23 11:32:55 2018 From: ilf at zeromail.org (ilf) Date: Wed, 23 May 2018 11:32:55 +0200 Subject: Keyservers and GDPR In-Reply-To: <20180523092715.GC1663@zeromail.org> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> Message-ID: <20180523093255.GD1663@zeromail.org> ilf: > To sum up: Keep calm and keep running keyservers. You'll be fine. I forgot one point: The one thing you *should* take care about is to publish a privacy statement on your keyservers website, listing the data your server logs. There are a lot of templates out there, a popular German one is https://datenschutz-generator.de/ (so pupolar it seems overloaded). -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From marcelf at selfnet.de Wed May 23 10:29:10 2018 From: marcelf at selfnet.de (Marcel Fest) Date: Wed, 23 May 2018 10:29:10 +0200 Subject: Keyservers and GDPR In-Reply-To: <201805230827.08302.bernhard@intevation.de> References: <20180522194409.tmrteipcsoorisns@calamity> <201805230827.08302.bernhard@intevation.de> Message-ID: <6d23efd5-1253-62be-4861-89c19a320154@selfnet.de> >> My personal conclusion is that keyservers that support user id packets are, >> quite simply, incompatible with GDPR law. Has anyone else thought about >> this? > thinking about earlier data privacy laws (which were quite similiar to GDPR in > many respects) and pubkey servers got me to no clear conclusion. > >> For OpenKeychain, we plan to move uploading of key material a bit farther >> out of the way and do a better job at informing the user what's going to >> happen. > If our goal is to automate the common case in an end-to-end crypto > mail communication, then asking the user a data privacy agreement question > is a stumbling block. I would degrate the user experience a lot. What about keys uploaded by a third party without the consent of the person concerned with his name and email addresses. Best Regards Marcel Fest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nd at syndicat.com Wed May 23 12:12:22 2018 From: nd at syndicat.com (Niels Dettenbach) Date: Wed, 23 May 2018 12:12:22 +0200 Subject: Keyservers and GDPR In-Reply-To: <6d23efd5-1253-62be-4861-89c19a320154@selfnet.de> References: <20180522194409.tmrteipcsoorisns@calamity> <201805230827.08302.bernhard@intevation.de> <6d23efd5-1253-62be-4861-89c19a320154@selfnet.de> Message-ID: <2822602.dZc056ry67@gongo> Am Mittwoch, 23. Mai 2018, 10:29:10 CEST schrieb Marcel Fest: > What about keys uploaded by a third party without the consent > of the person concerned with his name and email addresses. I see this as part of the specs. If it makes any sense to build a feature allow to mark "public" keys as "non public" this would be a technical question. -- --- Niels Dettenbach Syndicat IT & Internet http://www.syndicat.com PGP: https://syndicat.com/pub_key.asc --- -------------- 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 kristian.fiskerstrand at sumptuouscapital.com Wed May 23 12:03:32 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 23 May 2018 12:03:32 +0200 Subject: Keyservers and GDPR In-Reply-To: <20180523092715.GC1663@zeromail.org> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> Message-ID: On 05/23/2018 11:27 AM, ilf wrote: > tl;dr: Keep calm and keep running keyservers. > > Vincent Breitmoser: >> (cross-posting on all the cool pgp lists) > > (I wonder, if this really needs to be an all the four lists. I think > sks-devel@ might be the most appropriate. Having said that, I'm only > replying to gnupg-devel@ because I'm not subscribed to sks-devel at . Feel > free to relay my message.) As I think this has a valuable viewpoint I'm posting it to sks-devel. And yes, this is mostly in line with my own thinking, I don't expect the need for radical changes unless we see actual attempts to go after the infrastructure. > >> My personal conclusion is that keyservers that support user id packets >> are, quite simply, incompatible with GDPR law. > > There is a ton of FUD about the GDPR out there right now. Most of it??? > frivolous. (Actually, a lot of it is deliberate fearmongering by people > who happen to sell legal advice on the GDPR.) > > First of all, the GDPR is not completely new. All EU member states > already have data protection laws, some - like Germany - already very? > strong ones. The concepts (PII, responsibilities, technological and > organisational measures, information and documentation obligations) have > already been in place with the old Data Protection Directive from 1995, > which the GDPR is updating. I admit that the GDPR can be read and > interpreted in a fatalist way. But most people leaning that way seem to > not have read the older laws. > > Laws are not set in stone. Laws include leeways, deliberate or > unintended. Laws do not depend on their interpretation by laypeople. > There is a huge dedicated system for its interpretation, conflict > resolve, judgement and enforcement. > > In the case of the GDPR, the very first step of that system are National > Data Protection Authorities (DPA). They have the power - and the > responsibility - to investigate possible violations of the GDPR. They > have been understaffed for years, in many countries dangerously so. They > are getting a lot more powers and responsibilities with the GDPR, but > their resources are growing way slower than their tasks. They are simply > understaffed and overworked. So from all the possible GDPR violations > they will be notified about, they will work off the biggest and most > obvious ones first. Their focus will be on the Facebooks - and not on > small nerd projects or personal websites. They have the power to say "we > don't care about this weird thing called keyserver" - and the probably > will. > > Now even if someone found data protection law infringements with a > keyserver, filed a specific and well-worded legal complaint with a DPA, > and a DPA found the resources to look into it, and the DPA found some > violation of the GDPR (four big IFs!) - the DPAs will not go around and > issue sanctions and fine people. First of all, their job is not to > generate revenues by fines. Their job is to enforce data protection law. > If a DPA did find an issue with a keyserver - or the very concept - they > would reach out and talk to the people running the servers. They would > hear their perspective, learn more about the very concept - and try to > work out a viable solution to provide the service without possible data > protection infringements. This is their job and their goal. > > The most feared sanction of some undefined GDPR violation is a fine. As > I layed out, DPAs don't want to issue fines, they want to stop privacy > violations. And they will not blindly issue a fine without talking to > you first. That being said, they obviously do have the power to issue > fines. After due process. However, this power is also not new, it has > also existed in many countries. And DPAs don't run around and fine > people left and right (you would have heard about that), they exercise > their power in a balanced way. And fines are always in relation to the > economic and personal circumstances of the - then guilty and obstinate - > data protection violators. I guess most keyservers are run by? > non-profit individuals or institutions. Even if a company runs a > keyserver, it doesn't make money with that service. Therefore, I think > the chance of *any* fine is negligible - and the chance of an > unreasonably high fine is almost zero. And if it ever came to this, the > community and public alarmed by public outcry would probably donate more > than the fine issued. > > To sum up: Keep calm and keep running keyservers. You'll be fine. > > More elaboration in German: > https://netzpolitik.org/2018/bussgelder-bei-datenschutzverstoessen-angst-vor-einem-phantom/ > > > Disclaimer: IANAL. This is not legal advice. > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- ---------------------------- 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 ---------------------------- "I disapprove of what you say, but I will defend to the death your right to say it." Evelyn Beatrice Hall (summarizing Voltaire -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From calestyo at scientia.net Wed May 23 13:16:40 2018 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Wed, 23 May 2018 13:16:40 +0200 Subject: Keyservers and GDPR In-Reply-To: <2822602.dZc056ry67@gongo> References: <20180522194409.tmrteipcsoorisns@calamity> <201805230827.08302.bernhard@intevation.de> <6d23efd5-1253-62be-4861-89c19a320154@selfnet.de> <2822602.dZc056ry67@gongo> Message-ID: <8943e14b4e50da496e61281200033027b1fab03a.camel@scientia.net> On Wed, 2018-05-23 at 12:12 +0200, Niels Dettenbach via Gnupg-devel wrote: > If it makes any sense to build a feature allow to mark "public" keys > as "non > public" this would be a technical question. But that has the same problem as deleting keys... It mustn't be done for security reasons, as otherwise attackers could remove any revocations from the keyservers. Cheers, Chris. From ilf at zeromail.org Wed May 23 15:40:52 2018 From: ilf at zeromail.org (ilf) Date: Wed, 23 May 2018 15:40:52 +0200 Subject: [Autocrypt] Keyservers and GDPR In-Reply-To: <20180522194409.tmrteipcsoorisns@calamity> References: <20180522194409.tmrteipcsoorisns@calamity> Message-ID: <20180523134051.GE1663@zeromail.org> Vincent Breitmoser: > But what's worse, in the current implementation of SKS and the public > keyserver pool, it is impossible by design to remove a user's data > once it is published. This conflicts with the "right to be forgotten". The right-to-be-forgotten (RTBF) and the design of append-only logs like keyservers and blockchain? obviously present a challenge on how to combine both. But this is also nothing to panic about. Especially since virtually all German DPAs use OpenPGP themselves: https://www.bfdi.bund.de/SharedDocs/Publikationen/BfDIKey.asc?__blob=publicationFile&v=1 https://www.lda.bayern.de/media/pgp_schluessel_dsa.asc https://www.datenschutz-berlin.de/email/mailbox_blnbdi.asc http://www.lda.brandenburg.de/media_fast/4055/LDABbgpublickey.asc https://www.datenschutz-hamburg.de/fileadmin/user_upload/documents/pgp-schluessel_hmbbfdi.asc https://datenschutz.hessen.de/sites/datenschutz.hessen.de/files/PGP-Schluessel.txt https://www.datenschutz-mv.de/static/DS/Dateien/pgp_lds_mv.asc https://www.lfd.niedersachsen.de/download/32009/Unser_PGP-Schluessel_neu_ab_01.09.2015_.txt https://www.ldi.nrw.de/metanavi_Kontakt/key_ldi.asc https://www.datenschutz.rlp.de/fileadmin/lfdi/Dokumente/pubkey_lfdi-rlp.asc https://datenschutz.saarland.de/fileadmin/pgp/datenschutzzentrum-key_.asc https://www.saechsdsb.de/images/stories/sdb_inhalt/behoerde/SaechsDSB.txt https://www.datenschutzzentrum.de/uploads/uld/uld.asc https://www.tlfdi.de/mam/tlfdi/start/tlfdi_schluessel_ab_dez_2015.txt Also, all of those keys are also on the keyserver pool. As they should be. I just "checked". :) Again: Don't panic. -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From andrewg at andrewg.com Wed May 23 16:06:35 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 23 May 2018 15:06:35 +0100 Subject: [Autocrypt] Keyservers and GDPR In-Reply-To: <20180523134051.GE1663@zeromail.org> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523134051.GE1663@zeromail.org> Message-ID: <9ce72b2b-75ee-661b-16d1-bf977532363a@andrewg.com> On 23/05/18 14:40, ilf wrote: > > Again: Don't panic There are several grounds for handling data other than explicit user consent, but more importantly the legal bar is "reasonable effort" and not "absolute compliance". It is unlikely that keyservers will be first in line, so let's keep one eye on the newspapers and see how it goes. I'm more concerned about the prospect of child porn image IDs. Let's deal with that one first. (IANAL, etc.) -- 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 dirk.gottschalk1980 at googlemail.com Wed May 23 15:31:58 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Wed, 23 May 2018 15:31:58 +0200 Subject: Keyservers and GDPR In-Reply-To: <8943e14b4e50da496e61281200033027b1fab03a.camel@scientia.net> References: <20180522194409.tmrteipcsoorisns@calamity> <201805230827.08302.bernhard@intevation.de> <6d23efd5-1253-62be-4861-89c19a320154@selfnet.de> <2822602.dZc056ry67@gongo> <8943e14b4e50da496e61281200033027b1fab03a.camel@scientia.net> Message-ID: Hi. Am Mittwoch, den 23.05.2018, 13:16 +0200 schrieb Christoph Anton Mitterer: > On Wed, 2018-05-23 at 12:12 +0200, Niels Dettenbach via Gnupg-devel > wrote: > > If it makes any sense to build a feature allow to mark "public" > > keys > > as "non > > public" this would be a technical question. > But that has the same problem as deleting keys... > It mustn't be done for security reasons, as otherwise attackers could > remove any revocations from the keyservers. Well, that's true. the only option would be to allow only the key owner to upload or delete his key and allow other users only to attach new signatures or something like this. Revocation should also only be possible by the owner or a permitted revoker. But this would cause massive protocol changes and this would take it's time. On the other hand, I don't see any Problems with GDPR at all. I don't think that they even thought about such cases. The most protocols would be no longer legal after it takes place. ^^ GDPR is, just IMHO, an epic Fail and does not address reality. It is usable for Websites, but nothing else. There woud have to be so much exceptions for every protocol, that the list of exceptions would be loinger than the GDPR itself. ^^ 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 kristian.fiskerstrand at sumptuouscapital.com Wed May 23 20:34:47 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 23 May 2018 20:34:47 +0200 Subject: expiry of x.509 cert for git.gnupg.org Message-ID: <75479b7e-f30e-50a7-2c31-8f694ea89e80@sumptuouscapital.com> Hi, Is it just me or did cert for https://git.gnupg.org expire some days ago? :) -- ---------------------------- 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 don't drive your business, you will be driven out of business" (B. C. Forbes) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wiktor at metacode.biz Wed May 23 20:35:27 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 23 May 2018 20:35:27 +0200 Subject: Questions about Web Key Directory I-D version 06 Message-ID: <908a7ed6-a1b7-d906-ebcd-e2a055a28515@metacode.biz> Hello, I'm implementing Web Key Directory support in OpenKeychain and have some questions about the current version of the draft: 06 [0]. 1. The draft does not specify if redirects should be followed, for example, for this URL: https://example.org/.well-known/openpgpkey/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q If the HTTP response is a redirect code (301, etc.) should it be followed? As far as I can see both gnupg and servers in the wild (e.g. kernel.org) utilize redirects. Are there any restrictions to these redirects (e.g. only to https schemes? or is http also allowed?). 2. The I-D mentions in several places Content-Type: application/octet-string, I think this is a typo, it should be application/octet-stream. Sub-question: is there no better media type? I've browsed the IANA registry, sadly application/pgp-keys is only for armored keys (RFC 3156 [1]). Thank you for your time! Kind regards, Wiktor [0]: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ [1]: https://tools.ietf.org/html/rfc3156#section-7 -- */metacode/* From calestyo at scientia.net Wed May 23 23:04:05 2018 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Wed, 23 May 2018 23:04:05 +0200 Subject: Keyservers and GDPR In-Reply-To: References: <20180522194409.tmrteipcsoorisns@calamity> <201805230827.08302.bernhard@intevation.de> <6d23efd5-1253-62be-4861-89c19a320154@selfnet.de> <2822602.dZc056ry67@gongo> <8943e14b4e50da496e61281200033027b1fab03a.camel@scientia.net> Message-ID: <8806e13276e01e0e31cdafd942c0a9f0f211a227.camel@scientia.net> On Wed, 2018-05-23 at 15:31 +0200, Dirk Gottschalk via Gnupg-devel wrote: > Well, that's true. the only option would be to allow only the key > owner > to upload or delete his key That would in fact be a good thing... perhaps even with some form of challenge response (i.e. the owner must sign something as a response). In addition.... it should be possible for a key owner, to delete his UID subpackets from the keyservers... (any revoc subpackets/etc. should be kept forever). But in fact even this may not be fully enough to fulfil that stupid EU laws. > On the other hand, I don't see any Problems with GDPR at all. I don't > think that they even thought about such cases. The most protocols > would > be no longer legal after it takes place. ^^ I'm not an expert... but from my naive understanding I'd say that the GDPR basically outlaws keyservers as they're now. I've stopped mine for now. Cheers, Chris. From kristian.fiskerstrand at sumptuouscapital.com Wed May 23 23:45:56 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 23 May 2018 23:45:56 +0200 Subject: Keyservers and GDPR In-Reply-To: <8806e13276e01e0e31cdafd942c0a9f0f211a227.camel@scientia.net> References: <20180522194409.tmrteipcsoorisns@calamity> <201805230827.08302.bernhard@intevation.de> <6d23efd5-1253-62be-4861-89c19a320154@selfnet.de> <2822602.dZc056ry67@gongo> <8943e14b4e50da496e61281200033027b1fab03a.camel@scientia.net> <8806e13276e01e0e31cdafd942c0a9f0f211a227.camel@scientia.net> Message-ID: <4c68152d-2eb4-e71e-e038-a48386a16505@sumptuouscapital.com> On 05/23/2018 11:04 PM, Christoph Anton Mitterer wrote: > That would in fact be a good thing... perhaps even with some form of > challenge response (i.e. the owner must sign something as a response). yes and no.. it basically changes keyservers to becoming certificate authorities. And unless they do signature / certification on the keyblock this state isn't kept anywhere.. but it is basically the PGP Global Directory. From a security perspective I'm not impressed about it, and there are several caveats, in particular related to expecting a domain name being in the original owner's control forever. So revocation of a previous owner wouldn't be recorded. It also excludes any non-email UIDs, e.g just a plain name or a pseudonym/handle in other channels (twitter?) -- ---------------------------- 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 ---------------------------- "Be a yardstick of quality. Some people aren't used to an environment where excellence is expected." (Steve Jobs) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Thu May 24 00:14:39 2018 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 23 May 2018 23:14:39 +0100 Subject: Keyservers and GDPR In-Reply-To: <4c68152d-2eb4-e71e-e038-a48386a16505@sumptuouscapital.com> References: <20180522194409.tmrteipcsoorisns@calamity> <201805230827.08302.bernhard@intevation.de> <6d23efd5-1253-62be-4861-89c19a320154@selfnet.de> <2822602.dZc056ry67@gongo> <8943e14b4e50da496e61281200033027b1fab03a.camel@scientia.net> <8806e13276e01e0e31cdafd942c0a9f0f211a227.camel@scientia.net> <4c68152d-2eb4-e71e-e038-a48386a16505@sumptuouscapital.com> Message-ID: > On 23 May 2018, at 22:45, Kristian Fiskerstrand wrote: > > It also excludes any non-email UIDs, e.g > just a plain name or a pseudonym/handle in other channels (twitter?) Or monkeysphere ssh host keys... A From calestyo at scientia.net Thu May 24 00:42:12 2018 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Thu, 24 May 2018 00:42:12 +0200 Subject: Keyservers and GDPR In-Reply-To: <4c68152d-2eb4-e71e-e038-a48386a16505@sumptuouscapital.com> References: <20180522194409.tmrteipcsoorisns@calamity> <201805230827.08302.bernhard@intevation.de> <6d23efd5-1253-62be-4861-89c19a320154@selfnet.de> <2822602.dZc056ry67@gongo> <8943e14b4e50da496e61281200033027b1fab03a.camel@scientia.net> <8806e13276e01e0e31cdafd942c0a9f0f211a227.camel@scientia.net> <4c68152d-2eb4-e71e-e038-a48386a16505@sumptuouscapital.com> Message-ID: On Wed, 2018-05-23 at 23:45 +0200, Kristian Fiskerstrand wrote: > yes and no.. it basically changes keyservers to becoming certificate > authorities. ?? Why this? A CA is trusted by others and assures the identity of subjects. The challenge/response I'm talking about, would just assure that only the owner can publish the key to the network. It would in no way make any assurance about the identity. > And unless they do signature / certification on the > keyblock this state isn't kept anywhere.. Sure... it's just the proof, that the owner of the key actually wishes its publication. Of course the owner could still set up a fake User ID, effectively publishing another user's personal data.. but I guess then we'd be save in terms of privacy laws. > but it is basically the PGP > Global Directory. I don't think PGP GD requires prof that an uploader is the key owner. The only difference with that is that it doesn't syncronise with other keyservers (which is a major deficiency from a security PoV)... and didn't it remove keys after a while (if the users didn't reupload).. but then removal is complete (IIRC)... which is again a major deficiency, as revocations are also removed. > From a security perspective I'm not impressed about it, and there are > several caveats, in particular related to expecting a domain name > being > in the original owner's control forever You mean the PGP GD model? Well I haven't said we should do it as they do it (i.e. sending a mail to people asking them for reupload)... instead... if a user wants to keep his UIDs published, his client would need to do the reupload every now and then.. say once a year. If he doesn't,... the UIDs would get removed from the keyserver network (but NOT the revocation sigs). I'm not sure whether other sigs on the key should be removed (especially thinking about the certifcation sigs the person of the removed key made on other people)... these could basically allow to "trace" his contacts... and may therefore interfere with privacy laws. OTOH... when the UIDs are gone... it's already pseudo-anonymous... so might be fine. > So revocation of a previous > owner wouldn't be recorded. It also excludes any non-email UIDs, e.g > just a plain name or a pseudonym/handle in other channels (twitter?) As said above... I don't think challenge/response should be like PGP GD does it with sending mails. This would also impose much more burden on the keyservers (and even more legal risks... "unwanted mail" and so on). I'd rather think about: when some person wants to upload its key... its client must attach a signed standardised message like: "I herby certify that this is my key, my own valid identities and that I allow it to published globally to all servers of the SKS keyserver network for 1 year or until I revoke permission. Even then, only the UserIDs will be removed and all other data remains. ." (Some lawyer should draft a suitable text) And only if the current date/time is in a +/- 30 min time frame... and if the sig validates... the keyserver would accept the UIDs. The whole thing would *not* apply to just upgrades... like new certification sigs. Cheers, Chris. From dirk.gottschalk1980 at googlemail.com Thu May 24 01:04:04 2018 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Thu, 24 May 2018 01:04:04 +0200 Subject: expiry of x.509 cert for git.gnupg.org In-Reply-To: <75479b7e-f30e-50a7-2c31-8f694ea89e80@sumptuouscapital.com> References: <75479b7e-f30e-50a7-2c31-8f694ea89e80@sumptuouscapital.com> Message-ID: Yes, it's expired. git.gnupg.org verwendet ein ung?ltiges Sicherheitszertifikat. Das Zertifikat ist am 20. Mai 2018, 08:52 abgelaufen. Die aktuelle Zeit ist 24. Mai 2018, 01:02. Fehlercode: SEC_ERROR_EXPIRED_CERTIFICATE Am Mittwoch, den 23.05.2018, 20:34 +0200 schrieb Kristian Fiskerstrand: > Hi, > > Is it just me or did cert for https://git.gnupg.org expire some days > ago? :) > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -- 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 ben at adversary.org Thu May 24 12:15:41 2018 From: ben at adversary.org (Ben McGinnes) Date: Thu, 24 May 2018 20:15:41 +1000 Subject: Keyservers and GDPR In-Reply-To: <20180523092715.GC1663@zeromail.org> References: <20180522194409.tmrteipcsoorisns@calamity> <20180523092715.GC1663@zeromail.org> Message-ID: <20180524101541.egll3kfmzqoxrjgq@adversary.org> On Wed, May 23, 2018 at 11:27:15AM +0200, ilf wrote: > > There is a ton of FUD about the GDPR out there right now. Most of it > frivolous. (Actually, a lot of it is deliberate fearmongering by > people who happen to sell legal advice on the GDPR.) Somehow this comes as absolutely no surprise whatsoever. > To sum up: Keep calm and keep running keyservers. You'll be fine. Thanks for an excellent practical overview of the background of the law and what it's building on. That's the kind of information which is not really known by most people outside of the EU and so we're all just hearing "new law and it must be followed outside of the EU if it affects anyone inside the EU" (on pain of fines and/or total geo-blocking or whatever). There's a *lot* of panic in other FOSS projects as well, which this explanation shows really is based on that kind of FUD. I believe I may be using the list archive's URL for your post (and the privacy data usage statement follow-up) to at least try to help calm a few people down. ? 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 fgrieu at gmail.com Thu May 24 10:53:27 2018 From: fgrieu at gmail.com (Francois Grieu) Date: Thu, 24 May 2018 10:53:27 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption Message-ID: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> In the wake of efail ( https://efail.de/ ), I think it could be useful to add options to gpg (the command-line tool) that [1] cause gpg to supress any deciphered output that is not integrity-protected by at least one of MDC or trusted signature; I do realize this requires buffering when using gpg as a pipe. [2] cause gpg to exit with non-zero status whenever an input was deciphered (output or not) and was not integrity-protected as above. Any thoughts (like: some of that exists, and I missed it) ? ? Francois Grieu From gpg-devel at nopicturesplease.de Thu May 24 18:39:09 2018 From: gpg-devel at nopicturesplease.de (Holger Smolinski via [gnupg-devel]) Date: Thu, 24 May 2018 18:39:09 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> Message-ID: <04669e85-cd14-438f-b6e7-6da009b7d74f@nopicturesplease.de> Am 24.05.2018 um 10:53 schrieb Francois Grieu: > In the wake of efail ( https://efail.de/ ), I think it could be useful > to add options to gpg (the command-line tool) that > > [1] cause gpg to supress any deciphered output that is not > integrity-protected by at least one of MDC or trusted signature; I do > realize this requires buffering when using gpg as a pipe. > > [2] cause gpg to exit with non-zero status whenever an input was > deciphered (output or not) and was not integrity-protected as above. > > Any thoughts (like: some of that exists, and I missed it) ? I'd vote for [2] without output generation as default behavior and also add an override option. That would allow external programs like enigmail to - either treat this as a failed decryption for security reasons [default] - or voluntarily accept the unsafe behavior and establish safety on their own. Regards, ??? Holger -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From uri at mit.edu Thu May 24 22:34:49 2018 From: uri at mit.edu (Uri Blumenthal) Date: Thu, 24 May 2018 20:34:49 +0000 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <04669e85-cd14-438f-b6e7-6da009b7d74f@nopicturesplease.de> References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com>, <04669e85-cd14-438f-b6e7-6da009b7d74f@nopicturesplease.de> Message-ID: <78C74203-92DF-4F82-89BA-C054583BC6B0@mit.edu> +1 to what Holger said. [2] by default, with the ability to override, preferably via config. I do *not* want to enforce the presence of a signature (to preserve the possibility of anonymity) - but I do want a true AE. Sent from my test iPhone > On May 24, 2018, at 14:04, Holger Smolinski via [gnupg-devel] wrote: > >> Am 24.05.2018 um 10:53 schrieb Francois Grieu: >> >> In the wake of efail ( https://efail.de/ ), I think it could be useful >> to add options to gpg (the command-line tool) that >> >> [1] cause gpg to supress any deciphered output that is not >> integrity-protected by at least one of MDC or trusted signature; I do >> realize this requires buffering when using gpg as a pipe. >> >> [2] cause gpg to exit with non-zero status whenever an input was >> deciphered (output or not) and was not integrity-protected as above. >> >> Any thoughts (like: some of that exists, and I missed it) ? > I'd vote for [2] without output generation as default behavior and also > add an override option. > > That would allow external programs like enigmail to > - either treat this as a failed decryption for security reasons [default] > - or voluntarily accept the unsafe behavior and establish safety on > their own. > > Regards, > Holger > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From gpg-devel at nopicturesplease.de Thu May 24 23:13:46 2018 From: gpg-devel at nopicturesplease.de (Holger Smolinski via [gnupg-devel]) Date: Thu, 24 May 2018 23:13:46 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <78C74203-92DF-4F82-89BA-C054583BC6B0@mit.edu> References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <04669e85-cd14-438f-b6e7-6da009b7d74f@nopicturesplease.de> <78C74203-92DF-4F82-89BA-C054583BC6B0@mit.edu> Message-ID: <662e7709-5738-98a8-34cf-bcda1b4e8ba9@nopicturesplease.de> Am 24.05.2018 um 22:34 schrieb Uri Blumenthal: > I do *not* want to enforce the presence of a signature (to preserve the possibility of anonymity) - but I do want a true AE. +1 - anonymity is important, and AE is the way to prohibit variant 2 (the one with gadget injection) variant 1 (wrapping) is more difficult to handle, as secured content is presented and parsed in a potentially unsecured environment. Any solution will have to ensure, that the entire message (including the non-encrypted parts) has not been modified between the sender and the recipient. I'd suggest clients to wrap any (partially) encrypted message in a fully encrypted (and AE'ed by the sender) single part envelope message, and consequently neverever parse any surroundings of an encrypted envelope beyond decrypting the contents of that single part. At least that will secure future messages against variant 1 leaks - messages stored unpacked from the envelope (like old stored messages) will still be vulnerable. Regards Holger -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From tobias at radolfstrasse.de Fri May 25 08:48:25 2018 From: tobias at radolfstrasse.de (Tobias) Date: Fri, 25 May 2018 08:48:25 +0200 Subject: Identifying Non-MDC keys Message-ID: <000201d3f3f4$614b2200$23e16600$@radolfstrasse.de> Hi, currently all discussions are about detecting non-MDC messages. I am searching a way of detecting non-MDC keys in my keyring. Yes, I know that GnuPG warns me if I create a message that is not integrity protected. But in the all-day use this is too late (I want to write my email now and do not start searching for up-to-date keys). How can I list all keys in my keyring that do not have the MDC preference set? Is it somewhere hidden with the --with-colons output? Thanks Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri May 25 15:55:03 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 May 2018 09:55:03 -0400 Subject: expiry of x.509 cert for git.gnupg.org In-Reply-To: <75479b7e-f30e-50a7-2c31-8f694ea89e80@sumptuouscapital.com> References: <75479b7e-f30e-50a7-2c31-8f694ea89e80@sumptuouscapital.com> Message-ID: <87vabbg7rc.fsf@fifthhorseman.net> On Wed 2018-05-23 20:34:47 +0200, Kristian Fiskerstrand wrote: > Is it just me or did cert for https://git.gnupg.org expire some days ago? :) I can confirm that it is exired from my vantage point as well. Werner, can you ensure that your ACME client on git.gnupg.org is properly automated so that the cert gets refreshed before expiry? --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 Fri May 25 20:01:27 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 25 May 2018 14:01:27 -0400 Subject: Identifying Non-MDC keys In-Reply-To: <000201d3f3f4$614b2200$23e16600$@radolfstrasse.de> References: <000201d3f3f4$614b2200$23e16600$@radolfstrasse.de> Message-ID: > I am searching a way of detecting non-MDC keys in my keyring. The following PowerShell script may be of interest to you. ===== # find_missing_mdc.ps1 # # Copyright 2018, Rob Hansen # # Permission to use, copy, modify, and/or distribute this # software for any purpose with or without fee is hereby # granted, provided that the above copyright notice and # this permission notice appear in all copies. # # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS # ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO # EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, # INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, # WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER # TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE # USE OR PERFORMANCE OF THIS SOFTWARE. function Find-GnuPG { If ($PSVersionTable["Platform"] -eq "Win32NT") { If (Test-Path "HKLM:\Software\WOW6432Node\GnuPG") { $gpgdir = Join-Path ` -Path (Get-ItemPropertyValue ` -Path "HKLM:\Software\WOW6432Node\GnuPG" ` "Install Directory") ` -ChildPath "bin" return Join-Path -Path $gpgdir "gpg.exe" } ElseIf (Test-Path "HKLM:\Software\WOW6432Node\GNU\GnuPG") { $gpgdir = Get-ItemPropertyValue ` -Path "HKLM:\Software\WOW6432Node\Gnu\GnuPG" ` "Install Directory" return Join-Path -Path $gpgdir "gpg2.exe" } } ElseIf ($PSVersionTable["Platform"] -eq "Unix") { ForEach ($path in $env:PATH.split(':')) { ForEach ($item in Get-ChildItem -File -Name ` -Path $path -Filter gpg*) { If ($item -eq "gpg" -Or $item -eq "gpg2") { return Join-Path $path $item } } } } Write-Host "Error: couldn't find GnuPG" Exit } function Find-Cert-Preferences { $keyids = [ordered]@{} $gpg = Find-GnuPG (&$gpg --keyid-format long --fixed-list-mode --with-colons ` --list-key | Select-String -Pattern "^pub:").ForEach({ $match = [regex]::match($_, "([A-F0-9]{16})") $keyids[($match.Groups[1].Value)] = [ordered]@{} }) ForEach ($keyid in $keyids.keys) { ForEach ($uidrow in (&$gpg --keyid-format long ` --fixed-list-mode --with-colons --no-tty --edit-key ` $keyid showpref quit | Select-String -Pattern "^uid:")) { If ($uidrow.Line -match "^uid:r") { Continue } $elements = $uidrow.Line.Split(':') $username = $elements[9] $prefs = $elements[12] If (-Not $keyids[$keyid].Contains($username)) { $keyids[$keyid][$username] = "" } $keyids[$keyid][$username] += $prefs } } return $keyids } function Find-Missing-MDC { $certs = Find-Cert-Preferences ForEach ($keyid in $certs.Keys) { ForEach ($user in $certs[$keyid].Keys) { If ((-Not ($certs[$keyid][$user] -match "mdc")) -And (-Not (($certs[$keyid][$user] -match "S7") -Or ($certs[$keyid][$user] -match "S8") -Or ($certs[$keyid][$user] -match "S9") -Or ($certs[$keyid][$user] -match "S10") -Or ($certs[$keyid][$user] -match "S11") -Or ($certs[$keyid][$user] -match "S12") -Or ($certs[$keyid][$user] -match "S13")))) { Write-Output "$user (0x$keyid)" Break } } } } Find-Missing-MDC ===== Save that as "find_missing_mdc.ps1". Then open a PowerShell session and type: PS /Users/rjh> . /path/to/find_missing_mdc.ps1 the initial dot is important. Period, space, path to find_missing_mdc.ps1. If it finds any UIDs which are: * not revoked * don't explicitly list MDC in their prefs * only use pre-MDC algorithms ... it'll give you a warning and a list of affected key IDs. Wrote it on OS X, should also work on Windows 7+. From rjh at sixdemonbag.org Fri May 25 21:09:18 2018 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 25 May 2018 15:09:18 -0400 Subject: Identifying Non-MDC keys In-Reply-To: References: <000201d3f3f4$614b2200$23e16600$@radolfstrasse.de> Message-ID: <302b94e3-a482-2766-04d0-96f40dd82601@sixdemonbag.org> > Wrote it on OS X, should also work on Windows 7+. Can now confirm: Windows 10 x64 works fine. From patrick at enigmail.net Sun May 27 17:32:31 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 27 May 2018 17:32:31 +0200 Subject: Doodle Request for Dates of the 4th OpenPGP Email Summit Message-ID: <96a3929b-3d4a-3311-a346-0d679ebe7db2@enigmail.net> Hi all It's time for another OpenPGP Email Summit! So far, we had 3 such events [1], all organized by Nico Josuttis. The last summit is almost two years ago. I'd like to pick up the ball now, and organize the next event. The event is planned to happen in Brussels in October. The target audience is developers and software architects working on email clients and web service providers that encrypt emails using OpenPGP. As space will be quite limited, we can only accept 1-2 guys from each project. I ask all those who are interested in coming to participate in the following poll: https://doodle.com/poll/444tuxq8au2hwe4m The poll will be open until next Sunday, 2018-06-03. Best regards, -Patrick [1] https://wiki.gnupg.org/OpenPGPEmailSummits -------------- 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 11:14:12 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 May 2018 11:14:12 +0200 Subject: Doodle Request for Dates of the 4th OpenPGP Email Summit In-Reply-To: <96a3929b-3d4a-3311-a346-0d679ebe7db2@enigmail.net> (Patrick Brunschwig's message of "Sun, 27 May 2018 17:32:31 +0200") References: <96a3929b-3d4a-3311-a346-0d679ebe7db2@enigmail.net> Message-ID: <87zi0kjg63.fsf@wheatstone.g10code.de> On Sun, 27 May 2018 17:32, patrick at enigmail.net said: > I ask all those who are interested in coming to participate in the > following poll: > https://doodle.com/poll/444tuxq8au2hwe4m [ Using Doodle? Come on, there are lots of free and privacy respecting similar services. ] According to https://wiki.gnupg.org/OpenPGPEmailSummit201810 this meeting will again be held under Chatham House Rules. This is not acceptable to me. Although we are deep into privacy, the implementation, design and discussions need to be public. There is no way to implement trusted privacy solutions without full transparency. 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 11:24:25 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 May 2018 11:24:25 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> (Francois Grieu's message of "Thu, 24 May 2018 10:53:27 +0200") References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> Message-ID: <87vab8jfp2.fsf@wheatstone.g10code.de> On Thu, 24 May 2018 10:53, fgrieu at gmail.com said: > [1] cause gpg to supress any deciphered output that is not > integrity-protected by at least one of MDC or trusted signature; I do > realize this requires buffering when using gpg as a pipe. Buffering is not the task of gpg and simply not possible. This needs to be done by another layer. I already remarked elsewhere that I plan to do this to GPGME when using in certain ways (ie. in memory or on files). > [2] cause gpg to exit with non-zero status whenever an input was > deciphered (output or not) and was not integrity-protected as above. This is already the case unless a user is using a very old key and never updated the expiration date or the preferences. I have some doubts that such a key will be used with proper OPSEC. Note also that tehre are widley used OpenPGP implementaions which support only AES and major interoperablity problems have not been reported. This is another indication that the use of the legacy algorithsm (IDEA, 3DES, CAST5) are quite rare. Anyway, in master we now fail hard for _all_ cipher algorithm, regardless of any preferences. We need to discuss whether to backport this to 2.2. I meanwhile tend to say yes. 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 28 11:30:55 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 May 2018 11:30:55 +0200 Subject: Questions about Web Key Directory I-D version 06 In-Reply-To: <908a7ed6-a1b7-d906-ebcd-e2a055a28515@metacode.biz> (Wiktor Kwapisiewicz via Gnupg-devel's message of "Wed, 23 May 2018 20:35:27 +0200") References: <908a7ed6-a1b7-d906-ebcd-e2a055a28515@metacode.biz> Message-ID: <87r2lwjfe8.fsf@wheatstone.g10code.de> On Wed, 23 May 2018 20:35, gnupg-devel at gnupg.org said: > If the HTTP response is a redirect code (301, etc.) should it be > followed? As far as I can see both gnupg and servers in the wild I'd say yes. This is a part of the HTTP specification and thus not explicity mentioned in the I-D. > (e.g. kernel.org) utilize redirects. Are there any restrictions > to these redirects (e.g. only to https schemes? or is http also > allowed?). http is never allowed anywhere for any purpose. Restrictions are the max. number of allowed redirections; this is implementation defined. > 2. The I-D mentions in several places Content-Type: > application/octet-string, I think this is a typo, it should be > application/octet-stream. Thanks for noting. I found one place and fixed it. > Sub-question: is there no better media type? I've browsed the IANA > registry, sadly application/pgp-keys is only for armored keys (RFC 3156 [1]). application/octet-stream is the easiest thing and usual the default a server will use if if can't figure out otherwise. 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 ilf at zeromail.org Mon May 28 11:49:31 2018 From: ilf at zeromail.org (ilf) Date: Mon, 28 May 2018 11:49:31 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <87vab8jfp2.fsf@wheatstone.g10code.de> References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <87vab8jfp2.fsf@wheatstone.g10code.de> Message-ID: <20180528094931.GH4902@zeromail.org> Werner Koch: > We need to discuss whether to backport this to 2.2. I meanwhile tend to > say yes. FWIW, I'm for it. -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tobias at radolfstrasse.de Mon May 28 11:50:31 2018 From: tobias at radolfstrasse.de (Tobias) Date: Mon, 28 May 2018 11:50:31 +0200 Subject: AW: Identifying Non-MDC keys In-Reply-To: <302b94e3-a482-2766-04d0-96f40dd82601@sixdemonbag.org> References: <000201d3f3f4$614b2200$23e16600$@radolfstrasse.de> <302b94e3-a482-2766-04d0-96f40dd82601@sixdemonbag.org> Message-ID: <001201d3f669$512737c0$f375a740$@radolfstrasse.de> Hi Robert, thanks for the script. It seems to require Powershell 6.0 as you are using the "platform" attribute from PSVersionTable. After installation of a new PowerShell it is also running on my Windows 7. Thanks Tobias > -----Urspr?ngliche Nachricht----- > Von: Gnupg-devel [mailto:gnupg-devel-bounces at gnupg.org] Im Auftrag von > Robert J. Hansen > Gesendet: Freitag, 25. Mai 2018 21:09 > An: gnupg-devel at gnupg.org > Betreff: Re: Identifying Non-MDC keys > > > Wrote it on OS X, should also work on Windows 7+. > > Can now confirm: Windows 10 x64 works fine. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From patrick at enigmail.net Mon May 28 12:09:42 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 28 May 2018 12:09:42 +0200 Subject: Doodle Request for Dates of the 4th OpenPGP Email Summit In-Reply-To: <87zi0kjg63.fsf@wheatstone.g10code.de> References: <96a3929b-3d4a-3311-a346-0d679ebe7db2@enigmail.net> <87zi0kjg63.fsf@wheatstone.g10code.de> Message-ID: <7561c9d2-6a48-f486-8450-fdfa3c4df74f@enigmail.net> On 28.05.18 11:14, Werner Koch wrote: > On Sun, 27 May 2018 17:32, patrick at enigmail.net said: > >> I ask all those who are interested in coming to participate in the >> following poll: >> https://doodle.com/poll/444tuxq8au2hwe4m > > [ Using Doodle? Come on, there are lots of free and privacy respecting > similar services. ] > > According to https://wiki.gnupg.org/OpenPGPEmailSummit201810 this > meeting will again be held under Chatham House Rules. This is not > acceptable to me. Although we are deep into privacy, the > implementation, design and discussions need to be public. There is no > way to implement trusted privacy solutions without full transparency. I'm open to changing the rules, I actually simply copied this from the last meeting. But I see your point - I'll fix it. -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 ben at adversary.org Mon May 28 13:16:19 2018 From: ben at adversary.org (Ben McGinnes) Date: Mon, 28 May 2018 21:16:19 +1000 Subject: Keyservers and GDPR In-Reply-To: References: <20180522194409.tmrteipcsoorisns@calamity> <201805230827.08302.bernhard@intevation.de> <6d23efd5-1253-62be-4861-89c19a320154@selfnet.de> <2822602.dZc056ry67@gongo> <8943e14b4e50da496e61281200033027b1fab03a.camel@scientia.net> <8806e13276e01e0e31cdafd942c0a9f0f211a227.camel@scientia.net> <4c68152d-2eb4-e71e-e038-a48386a16505@sumptuouscapital.com> Message-ID: <20180528111619.2hyqacfbfddfymcr@adversary.org> On Thu, May 24, 2018 at 12:42:12AM +0200, Christoph Anton Mitterer wrote: > On Wed, 2018-05-23 at 23:45 +0200, Kristian Fiskerstrand wrote: > > yes and no.. it basically changes keyservers to becoming certificate > > authorities. > ?? Why this? > > A CA is trusted by others and assures the identity of subjects. > The challenge/response I'm talking about, would just assure that only > the owner can publish the key to the network. I take it you just mean something like signing a token with the key you're trying to upload? Sure, assuming it doesn't also prevent signature updates, for all the obvious reasons. > Of course the owner could still set up a fake User ID, effectively > publishing another user's personal data.. but I guess then we'd be > save in terms of privacy laws. > > > > but it is basically the PGP > > Global Directory. > I don't think PGP GD requires prof that an uploader is the key owner. > The only difference with that is that it doesn't syncronise with other > keyservers (which is a major deficiency from a security PoV)... and > didn't it remove keys after a while (if the users didn't reupload).. > but then removal is complete (IIRC)... which is again a major > deficiency, as revocations are also removed. > > > > > From a security perspective I'm not impressed about it, and there are > > several caveats, in particular related to expecting a domain name > > being > > in the original owner's control forever > You mean the PGP GD model? Well I haven't said we should do it as > they do it (i.e. sending a mail to people asking them for > reupload)... Good, it does get a bit ridiculous and the load would be a bit silly. > instead... if a user wants to keep his UIDs published, > his client would need to do the reupload every now and then.. say > once a year. If he doesn't,... the UIDs would get removed from the > keyserver network (but NOT the revocation sigs). Hang on, you're proposing the keyservers edit keys that aren't updated to remove the UIDs? Two questions: 1. How could end users continue to trust the servers knowing that their key data may be edited at all? For instance if law enforcement want to isolate a person from contact and issue some kind of compliance order to remove the UIDs since there's precendent, what then? 2. How would you actually update this when resynchronising with other servers will simply (or should simply) restore that data? > I'm not sure whether other sigs on the key should be removed They should not, only the person/entity making the signature should be modifying it. > (especially thinking about the certifcation sigs the person of the > removed key made on other people)... these could basically allow to > "trace" his contacts... and may therefore interfere with privacy > laws. OTOH... when the UIDs are gone... it's already > pseudo-anonymous... so might be fine. You're already veering into dangerous enough territory with any kind of key modification as it is. > I'd rather think about: when some person wants to upload its key... its > client must attach a signed standardised message like: [SNIP] > And only if the current date/time is in a +/- 30 min time frame... and > if the sig validates... the keyserver would accept the UIDs. This bit I kind of don't mind. > The whole thing would *not* apply to just upgrades... like new > certification sigs. Presumably it would apply to adding and revoking subkeys, the UIDs, modifying any expiration times of the primary key or subkeys, changes to cipher, digest and algorithm preferences (including cert-digest) and so on, but *not* to the addition of signatures or revocation of the same. Deletion of data should not be permitted because it opens the entire nework up to a whole slew of attacks and legal vulnerabilities which would be rather bad. 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 ilf at zeromail.org Mon May 28 17:34:33 2018 From: ilf at zeromail.org (ilf) Date: Mon, 28 May 2018 17:34:33 +0200 Subject: Doodle Request for Dates of the 4th OpenPGP Email Summit In-Reply-To: <7561c9d2-6a48-f486-8450-fdfa3c4df74f@enigmail.net> References: <96a3929b-3d4a-3311-a346-0d679ebe7db2@enigmail.net> <87zi0kjg63.fsf@wheatstone.g10code.de> <7561c9d2-6a48-f486-8450-fdfa3c4df74f@enigmail.net> Message-ID: <20180528153433.GJ4902@zeromail.org> From Wikipedia: "At a meeting held under the Chatham House Rule, anyone who comes to the meeting is free to use information from the discussion, but is not allowed to reveal who made any comment." IIRC, this was only needed to enable the Google End-To-End team to attend, but since that's now officially dead, there is no more need? https://security.googleblog.com/2017/02/e2email-research-project-has-left-nest_24.html Patrick Brunschwig: >> According to https://wiki.gnupg.org/OpenPGPEmailSummit201810 this >> meeting will again be held under Chatham House Rules. > I'm open to changing the rules, I actually simply copied this from the > last meeting. But I see your point - I'll fix it. -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From patrick at enigmail.net Mon May 28 17:47:57 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 28 May 2018 17:47:57 +0200 Subject: [Autocrypt] Doodle Request for Dates of the 4th OpenPGP Email Summit In-Reply-To: <20180528153433.GJ4902@zeromail.org> References: <96a3929b-3d4a-3311-a346-0d679ebe7db2@enigmail.net> <87zi0kjg63.fsf@wheatstone.g10code.de> <7561c9d2-6a48-f486-8450-fdfa3c4df74f@enigmail.net> <20180528153433.GJ4902@zeromail.org> Message-ID: <9a5d85a0-352b-a923-0fb5-dfe5d9b29c57@enigmail.net> On 28.05.18 17:34, ilf wrote: > Patrick Brunschwig: >>> According to https://wiki.gnupg.org/OpenPGPEmailSummit201810 this >>> meeting will again be held under Chatham House Rules. >> I'm open to changing the rules, I actually simply copied this from the >> last meeting. But I see your point - I'll fix it. > IIRC, this was only needed to enable the Google End-To-End team to > attend, but since that's now officially dead, there is no more need? > https://security.googleblog.com/2017/02/e2email-research-project-has-left-nest_24.html That's right. I changed the rules now: "This is a public meeting. As we want to be fully transparent, anything discussed during the meeting is considered public." -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 Mon May 28 18:05:21 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 May 2018 18:05:21 +0200 Subject: [Autocrypt] Doodle Request for Dates of the 4th OpenPGP Email Summit In-Reply-To: <9a5d85a0-352b-a923-0fb5-dfe5d9b29c57@enigmail.net> (Patrick Brunschwig's message of "Mon, 28 May 2018 17:47:57 +0200") References: <96a3929b-3d4a-3311-a346-0d679ebe7db2@enigmail.net> <87zi0kjg63.fsf@wheatstone.g10code.de> <7561c9d2-6a48-f486-8450-fdfa3c4df74f@enigmail.net> <20180528153433.GJ4902@zeromail.org> <9a5d85a0-352b-a923-0fb5-dfe5d9b29c57@enigmail.net> Message-ID: <87r2lvix4u.fsf@wheatstone.g10code.de> On Mon, 28 May 2018 17:47, patrick at enigmail.net said: > That's right. I changed the rules now: "This is a public meeting. As we > want to be fully transparent, anything discussed during the meeting is > considered public." :-) 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 Tue May 29 08:14:40 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 29 May 2018 08:14:40 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <87vab8jfp2.fsf@wheatstone.g10code.de> References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <87vab8jfp2.fsf@wheatstone.g10code.de> Message-ID: On 28.05.18 11:24, Werner Koch wrote: > On Thu, 24 May 2018 10:53, fgrieu at gmail.com said: > >> [1] cause gpg to supress any deciphered output that is not >> integrity-protected by at least one of MDC or trusted signature; I do >> realize this requires buffering when using gpg as a pipe. > > Buffering is not the task of gpg and simply not possible. This needs to > be done by another layer. I already remarked elsewhere that I plan to > do this to GPGME when using in certain ways (ie. in memory or on files). > >> [2] cause gpg to exit with non-zero status whenever an input was >> deciphered (output or not) and was not integrity-protected as above. > > This is already the case unless a user is using a very old key and never > updated the expiration date or the preferences. I have some doubts that > such a key will be used with proper OPSEC. Note also that tehre are > widley used OpenPGP implementaions which support only AES and major > interoperablity problems have not been reported. This is another > indication that the use of the legacy algorithsm (IDEA, 3DES, CAST5) are > quite rare. Anyway, in master we now fail hard for _all_ cipher > algorithm, regardless of any preferences. > > We need to discuss whether to backport this to 2.2. I meanwhile tend to > say yes. Enigmail fails with this since about two weeks, also for older versions of GnuPG. I had a number of bug reports/support requests since then, but overall it was less than I feared. Some people still have very old keys. The major pain point for them is access to their old emails. This can be overcome, for example by having specific functions in the user-facing application that ignore the GnuPG status. That said, yes I'm in favor of backporting this, but we need to make the developers of tools using GnuPG aware of the change early enough such that they can prepare their software. Otherwise we'll leave behind a number of unhappy users. -Patrick From bernhard at intevation.de Tue May 29 08:39:11 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 29 May 2018 08:39:11 +0200 Subject: Questions about Web Key Directory I-D version 06 In-Reply-To: <908a7ed6-a1b7-d906-ebcd-e2a055a28515@metacode.biz> References: <908a7ed6-a1b7-d906-ebcd-e2a055a28515@metacode.biz> Message-ID: <201805290839.15956.bernhard@intevation.de> Wiktor, Am Mittwoch 23 Mai 2018 20:35:27 schrieb Wiktor Kwapisiewicz via Gnupg-devel: > I'm implementing Web Key Directory support in OpenKeychain and have > some questions about the current version of the draft: 06 [0]. > [0]: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ please also note that there is an open discussion point with WKD draft 06: As noted on https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept#Ask_the_mail_service_provider_.28MSP.29 I currently recommend to implement serving WKD without DNS SRV record for compatibility with webclients like Mailvelope and Enigmail for now. 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 ineiev at gnu.org Tue May 29 08:52:14 2018 From: ineiev at gnu.org (Ineiev) Date: Tue, 29 May 2018 02:52:14 -0400 Subject: [GPA][PATCH] option->description in confdialog.c In-Reply-To: <20180522095426.GK8919@gnu.org> References: <20160326094338.GA21716@gnu.org> <20180522095426.GK8919@gnu.org> Message-ID: <20180529065212.GH8919@gnu.org> On Tue, May 22, 2018 at 05:54:26AM -0400, Ineiev wrote: > On Sat, Mar 26, 2016 at 05:43:38AM -0400, Ineiev wrote: > > > > I was testing i18n in GPA and noticed that some group labels are > > truncated; I cheched confdialog.c and found out that there is > > a 80-character limit for them: ... > > Then, I saw that commas in the labels are shown as '%2c', in ... > > At last, there is a bug in the percent_unescape function itself: ... > Rebased against current HEAD, split into 3 patches. Ping. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From ca+gnupg-devel at esmtp.org Wed May 30 15:18:53 2018 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Wed, 30 May 2018 06:18:53 -0700 Subject: [PATCH] doc: "the the" Message-ID: <20180530131853.GA7556@x2.esmtp.org> [Resending to hopefully the right(?) address, at least according to README] --- 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 ca+gnupg-devel at esmtp.org Wed May 30 17:33:34 2018 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Wed, 30 May 2018 08:33:34 -0700 Subject: [PATCH]: doc: spelling errors Message-ID: <20180530153334.GA10754@x2.esmtp.org> [Resending to the bug address listed in README] On Sat, May 19, 2018, Claus Assmann wrote: --- 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 wk at gnupg.org Thu May 31 13:28:32 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 May 2018 13:28:32 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: (Patrick Brunschwig's message of "Tue, 29 May 2018 08:14:40 +0200") References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <87vab8jfp2.fsf@wheatstone.g10code.de> Message-ID: <87po1cdpy7.fsf@wheatstone.g10code.de> On Tue, 29 May 2018 08:14, patrick at enigmail.net said: > Enigmail fails with this since about two weeks, also for older versions > of GnuPG. I had a number of bug reports/support requests since then, but > overall it was less than I feared. Some people still have very old keys. Good. Today I pushed changes for 2.2.8 which will now always require the MDC and which will print a hint in case an old cipher algorithm is the cause for the missing MDC: gpg: WARNING: message was not integrity protected gpg: Hint: If this message was created before the year 2003 it is likely that this message is legitimate. This is because back then integrity protection was not widely used. gpg: Use the option '--ignore-mdc-error' to decrypt anyway. [GNUPG:] ERROR nomdc_with_legacy_cipher 152 gpg: decryption forced to fail! [GNUPG:] DECRYPTION_FAILED [GNUPG:] END_DECRYPTION > in favor of backporting this, but we need to make the developers of > tools using GnuPG aware of the change early enough such that they can > prepare their software. Otherwise we'll leave behind a number of unhappy I would suggest that you parse that new ERROR status line and print a warning like the above if the first arg is "nomdc_with_legacy_cipher". I have not yet decided whether and how to do this in gpgme. May be a context specific flag to pass --ignore-mdc-error and a flag in the decryption result. 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 gpg-devel at nopicturesplease.de Thu May 31 16:04:58 2018 From: gpg-devel at nopicturesplease.de (Holger Smolinski via [gnupg-devel]) Date: Thu, 31 May 2018 16:04:58 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <87po1cdpy7.fsf@wheatstone.g10code.de> References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <87vab8jfp2.fsf@wheatstone.g10code.de> <87po1cdpy7.fsf@wheatstone.g10code.de> Message-ID: <32d2904f-a848-c6bf-b09a-437aa8c64129@nopicturesplease.de> Am 31.05.2018 um 13:28 schrieb Werner Koch: > On Tue, 29 May 2018 08:14, patrick at enigmail.net said: > >> Enigmail fails with this since about two weeks, also for older versions >> of GnuPG. I had a number of bug reports/support requests since then, but >> overall it was less than I feared. Some people still have very old keys. > > Good. Today I pushed changes for 2.2.8 which will now always require > the MDC and which will print a hint in case an old cipher algorithm is > the cause for the missing MDC: Thanks all, I had similar issues with enigmail using new GPG keys - my peer has been using OpenPGP and eingmail recently refused to decrypt the message for the reason of missing MDC protection, regardless of whether using --ignore-mdc-errors or not. As my personal workaround I have disabled the check in enigmail, but now I will check these fixes. Regards, Holger From patrick at enigmail.net Thu May 31 16:51:22 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 31 May 2018 16:51:22 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <87po1cdpy7.fsf@wheatstone.g10code.de> References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <87vab8jfp2.fsf@wheatstone.g10code.de> <87po1cdpy7.fsf@wheatstone.g10code.de> Message-ID: <47ee925a-c8f0-bf40-9105-3b36b5f74fde@enigmail.net> On 31.05.18 13:28, Werner Koch wrote: > On Tue, 29 May 2018 08:14, patrick at enigmail.net said: > >> Enigmail fails with this since about two weeks, also for older versions >> of GnuPG. I had a number of bug reports/support requests since then, but >> overall it was less than I feared. Some people still have very old keys. > > Good. Today I pushed changes for 2.2.8 which will now always require > the MDC and which will print a hint in case an old cipher algorithm is > the cause for the missing MDC: > > gpg: WARNING: message was not integrity protected > gpg: Hint: If this message was created before the year 2003 it is > likely that this message is legitimate. This is because back > then integrity protection was not widely used. > gpg: Use the option '--ignore-mdc-error' to decrypt anyway. > [GNUPG:] ERROR nomdc_with_legacy_cipher 152 > gpg: decryption forced to fail! > [GNUPG:] DECRYPTION_FAILED > [GNUPG:] END_DECRYPTION Great, thanks! May I suggest that for GnuPG 2.3 you implement some more rules? For example: * refuse encrypting emails if MDC is not enabled in the key prefs * remove options like --ignore-mdc-error, --ignore-mdc-warning and --allow-multiple-messages, or at least require them to be combined with something like --dangerous-options -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 patrick at enigmail.net Thu May 31 17:05:33 2018 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 31 May 2018 17:05:33 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <47ee925a-c8f0-bf40-9105-3b36b5f74fde@enigmail.net> References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <87vab8jfp2.fsf@wheatstone.g10code.de> <87po1cdpy7.fsf@wheatstone.g10code.de> <47ee925a-c8f0-bf40-9105-3b36b5f74fde@enigmail.net> Message-ID: <366d2940-ac2c-fec5-df0b-e1c506577654@enigmail.net> On 31.05.18 16:51, Patrick Brunschwig wrote: > On 31.05.18 13:28, Werner Koch wrote: >> On Tue, 29 May 2018 08:14, patrick at enigmail.net said: >> >>> Enigmail fails with this since about two weeks, also for older versions >>> of GnuPG. I had a number of bug reports/support requests since then, but >>> overall it was less than I feared. Some people still have very old keys. >> >> Good. Today I pushed changes for 2.2.8 which will now always require >> the MDC and which will print a hint in case an old cipher algorithm is >> the cause for the missing MDC: >> >> gpg: WARNING: message was not integrity protected >> gpg: Hint: If this message was created before the year 2003 it is >> likely that this message is legitimate. This is because back >> then integrity protection was not widely used. >> gpg: Use the option '--ignore-mdc-error' to decrypt anyway. >> [GNUPG:] ERROR nomdc_with_legacy_cipher 152 >> gpg: decryption forced to fail! >> [GNUPG:] DECRYPTION_FAILED >> [GNUPG:] END_DECRYPTION > > Great, thanks! > > May I suggest that for GnuPG 2.3 you implement some more rules? For example: > * refuse encrypting emails if MDC is not enabled in the key prefs s/emails/anything/ -- GnuPG is not only for emails ;-) > * remove options like --ignore-mdc-error, --ignore-mdc-warning and > --allow-multiple-messages, or at least require them to be combined > with something like --dangerous-options -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 wiktor at metacode.biz Thu May 31 18:11:17 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Thu, 31 May 2018 18:11:17 +0200 Subject: Questions about Web Key Directory I-D version 06 In-Reply-To: <201805290839.15956.bernhard@intevation.de> References: <908a7ed6-a1b7-d906-ebcd-e2a055a28515@metacode.biz> <201805290839.15956.bernhard@intevation.de> Message-ID: <0f2dc493-99b5-7876-0c88-3e0c47432d24@metacode.biz> > please also note that there is an open discussion point with WKD draft 06: > As noted on > https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept#Ask_the_mail_service_provider_.28MSP.29 > I currently recommend to implement serving WKD without DNS SRV record for compatibility with webclients like Mailvelope and Enigmail for now. It's interesting that you bring this now as I've just recently implemented WKD in openpgpjs [0] and yes, I didn't do DNS SRV (for obvious reasons - they are not supported browsers). There is one issue though, browsers and extensions still need appropriate CORS settings to work: Access-Control-Allow-Origin header must be set to '*' on both 200 and 404 responses. (see [0] for details). I believe extensions would also need these headers [1] although I didn't check. [0]: https://github.com/openpgpjs/openpgpjs/pull/714 [1]: https://developer.chrome.com/extensions/xhr#requesting-permission As for the DNS SRV I understand the motivation of added flexibility but from what I've seen from other .well-known URLs HTTP load balancing and the ability to redirect requests already give sufficient flexibility. DNS SRV lookup complicates the otherwise very simple and clean protocol. My two changes implementing WKD lookup (for openpgpjs and OpenKeychain) do only "simple" basic flow, no DNS SRV. Kind regards, Wiktor -- */metacode/* -------------- 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 20:44:05 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 May 2018 20:44:05 +0200 Subject: Feature suggestion: options to require MDC or trusted signature on decryption In-Reply-To: <47ee925a-c8f0-bf40-9105-3b36b5f74fde@enigmail.net> (Patrick Brunschwig's message of "Thu, 31 May 2018 16:51:22 +0200") References: <705db6da-0999-4cd0-f45c-23a1cfa83a29@gmail.com> <87vab8jfp2.fsf@wheatstone.g10code.de> <87po1cdpy7.fsf@wheatstone.g10code.de> <47ee925a-c8f0-bf40-9105-3b36b5f74fde@enigmail.net> Message-ID: <87d0xbd5sa.fsf@wheatstone.g10code.de> On Thu, 31 May 2018 16:51, patrick at enigmail.net said: > May I suggest that for GnuPG 2.3 you implement some more rules? For example: > * refuse encrypting emails if MDC is not enabled in the key prefs RFC-4880 can be read to allow using MDC even without the feature flag. For RFC-4880bis non-MDC will be deprected: This packet is obsolete. An implementation MUST not create this packet. An implementation MAY process such a packet but it MUST return a clear diagnostic that a non-integrity protected packet has been processed. The implementation SHOULD also return an error in this case and stop processing. > * remove options like --ignore-mdc-error, --ignore-mdc-warning and > --allow-multiple-messages, or at least require them to be combined > with something like --dangerous-options Already done. The MDC options in 2.3 and 2.2 are now NOPs. The allow-multiple options and the --pgpg6 options are NOPs in 2.3. For testing --rfc2440 can be used which has always had the effect not to create an MDC. 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: