1. 23
  1. 27

    there is a fair amount of evidence that people who have a pressing need can use OpenPGP successfully.

    The bar is continuously set lower and lower by PGP enthusiasts.

    1. 2

      This is not to say that OpenPGP, its various implementations, and the applications that integrate it don’t have problems. They do. The OpenPGP working group needs to finish the cryptographic refresh and finally standardize AEAD. We need email clients that are built with security-oriented workflows for people who have powerful adversaries. And, we need popular mail clients to adopt opportunistic encryption similar to Signal for ordinary users.

      Also, we could discuss the possibility of ditching PGP and use something else (like Age)… still over email.

      1. 4

        S/MIME works reasonably well, if you can get a certificate. It works very well for signing emails, which is the thing I care the most about: my bank or solicitor can easily afford to pay for a cert and set up the infrastructure to roll out signing certificates for all employees’ email so that any communication with customers is signed. It’s less good for encryption, because there’s no good way of discovering a key (and key management for decryption is exciting, especially if you want to be able to revoke keys from certain devices if you lose them).

    2. 11

      My number one worry with encrypted email is that I will lose access to it permanently.

      My number two worry with encrypted email is that nobody uses it so there’s no point.

      My number three worry is traffic analysis, but it’s a long way behind one and two.

      1. 8

        I’ve created so many public keys over the years because some thing (like the Ubuntu CoC or “signed” commits in GitHub) requires it and I’ve lost access to literally every one of them, mostly because I use a public key about once every five years. I would literally never set up email encryption because of your reason number one.

        1. 16

          What doesn’t help is the relative opaqueness of how gpg and its “keyring” works. With ssh it’s easy: I just have a ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519.pub file, and public keys for verification are in ~/.ssh/authorized_keys. That’s pretty much all there’s to it.

          I’ve never lost access to a ssh key or been confused how this works. With gpg it’s so much harder.

          1. 5

            I agree with this so, so much. SSH is almost trivial to understand, and there are even concrete benefits to setting it up and using it!

            1. 11

              It’s simple to use for simple cases but a bunch of things are complicated with SSH, for example:

              • If a key is compromised, how do I revoke access to it from all of the machines that have it in their authorised-keys file?
              • If I want to have one key per machine, how do I add that key to all of the machines I want it to access?
              • How do I enforce regular key rollover?

              You can do these things with PKI but now your key management is both complicated and very different from ‘normal’ SSH.

              SSH is also solving a much simpler problem because it only needs to support the online use case. If I connect to a machine with SSH and it rejects my key, I know immediately and it’s my problem. The protocol is interactive and will try any keys I let it, so I can do key rollover by generating a new key, allowing SSH to use both, and eventually replacing the public key on every machine I connect to with the new one. If I send an encrypted email with the wrong key, the recipient gets nonsense.

              The offline design is the root cause of a lot of the problems with email. It was designed for a world where the network was somewhat ad-hoc and most machines were disconnected. When my father’s company first got Interne email, they ran an internal mail server with a backup MX provided by their ISP. When someone sent an email, it would go to their ISP, when they dialed in (with a modem, which they did every couple of hours) the backup MX would forward email to them and they’d send outgoing mail, which would go via the same multi-hop relaying process. Now, email servers are assumed to be online all of the time and it would be completely fine to report to the sender’s mail client if the recipient’s mail server is not reachable and ask them to try again later. If you define a protocol around that assumption from the start, it’s completely fine to build an end-to-end key-exchange protocol in and a huge number of the problems with encrypted email go away.

            2. 1

              With SSH however, it’s trivial to create a new key, and get it installed on the new server. Because SSH keys don’t worry about a decentralized “web of trust” in way OpenPGP does, there is no historical or technological baggage to require you carrying around your SSH keypair. I’ve been through so many SSH keys over the years on personal and corporate systems, yet never once has it ever bothered me.

            3. 8

              This is one reason I started signing every email I send years ago and also how sign every git commit. It forces my key to be a core part of my workflow

              1. 3

                Similarly, I also use gpg to encrypt documents, and to encrypt passwords in pass. You’ll also rarely need to interact with it for Arch packages. Can’t beat its ubiquity.

              2. 2

                If you want you can make a “master” key that you keep in one place permanently and at backup locations, and then sign stuff with subkeys signed by the master key. That way you will never lose anything if you lose a subkey but not the masterkey. Not a great solution but still helpful

            4. 7

              “Yes, we want”… there’s want and want. Want as in “this has high enough priority that we’ll sacrifice these things for it: ”, and want as in “we’ll sacrifice nothing, this is the lowest-priority item we know, but we still consider it a positive trait”.

              Reading that, I get the impression that the PGP people think their “want” is the first kind, but their list of desirable things they’ll sacrifice is empty, so it actually is the other kind.

              1. 3

                Having worked with PGP for years, I think S/MIME makes more sense for 95% of the cases. We need something like LetsEncrypt but for S/MIME with similar challenge-types. S/MIME class > 1 provides authentication (e.g. you present your passport to the CA or something), but we don’t really need that in most cases (just like we don’t really need extended validation (EV) certificates in SSL in most cases). S/MIME class 1 is enough as it simply validates the “From”-address on the one hand and allows end-to-end-encryption on the other.

                Of course, if you lose your key, you won’t be able to decrypt your stuff, but that’s obvious, isn’t it? One possibility is to do it like Matrix, where you can store all your keys on a server but protect them with a passphrase. Those too paranoid for that won’t have to, though, but I’m talking about the 95%.

                1. 2

                  You can have CAs in the PGP ecosystem as well. CAcert operates one, as did/does gswot.

                  1. 2

                    Neither of which have worked out. I have been a CACert Assurer since 2014, where there was still some momentum in hopes of getting the CACert root into OS and browser certificate stores. Let’s be honest, people only wanted CACert, because it was free. When LetsEncrypt entered the scene, CACert became irrelevant. I only knew of one site that used the cert, which was https://tedunangst.com/, and he also switched to LetsEncrypt. For all practical purposes, CACert is dead.

                    The Gossamer Spider Web of Trust (GSWoT) not only is dead, it never left the ground. First, the GSWoT website doesn’t support HTTPS, which let’s be honest, has been unacceptable for several years now. Second, links to news.gmane.org mailing lists, both for the project, and the PGP Basics list went offline mid 2016. Finally, the project launched in 2007, and between then and 2012, has only managed to secure 39 Introducers, and sign 56 PGP keys.

                    Personal experience with GSWoT, I had a phone call from Stephen Weber himself in 2014. I was not a CACert Assurer, nor a notary public (I am both now). As such, the only way to become a GSWoT Introducer was to get my key signed by 3 Introducers. Except there are no Introducers close to where I live, which would require significant travel. This seemed a bit unrealistic for a brand new project unless you were part of the founding group of members.

                    My key 0x22EEE0488086060F (created in 2004) was already in the PGP Strong Set, and ranked well. None of the Introducers at that time we’re in the Strong Set, which seemed to be problematic. So I reached out with an application, and asked if an exception could be made for me. Stephen called me, and was cordial, but wanted to make it clear that GSWoT wasn’t some sort of exclusive boys club. If I wanted to be an Introducer, I had to go through the outlined process.

                    I understand protecting the integrity of the project and Introducers. I’ve since held many PGP key signing parties since that phone call, some of them with over 200 participants. I could have been very influential in introducing the project, but their strict application process prevented me from becoming part of it.

                    It’s been several years since that phone call, and very little to nothing has changed with the project.

                    1. 1

                      That’s and interesting perspective, thanks. By the time I took over gswot (sorry I don’t specifically remember our call) it had been running successfully for some time but interest had waned. I was trying to keep it on life support, but honestly I think I’m the only one who cared much which is why I ended up as admin. The project isn’t completely dead, but there probably wasn’t room for a second community CA. As you say, even the bigger one (CAcert) is mostly only useful for pgp now and the PGP community has never been into CAs so that’s downhill too.

                      My point in my comment wasn’t that we should resurrect these particular community CAs, but that we don’t need to switch tech to get a different PKI model. If you want CAs in pgp land, the tech does it great, just someone needs to want it :)

                      1. 1

                        The CACert statistics show that interest has certainly waned. Unfortunately, CACert has some legitimate security problems:

                        • Its own website uses its own CA for HTTPS, which browsers don’t trust. As such, the connection is not secure.
                        • CACert accounts do not support 2FA, which definitely should, given the legal ramifications of certificate assurance.
                        • CACert still signs PGP keys with SHA-1, despite a published attack on this specific use case.

                        Also, I went through my email, and it appears I made my Introducer application in 2014, not 2011 as my memory seems to recall. I updated my reply.

                2. 3
                  1. Despite training, email recipients will reply in plaintext. MUAs make doing anything else very difficult.
                  2. Even if the body of the email is properly encrypted, the mail headers are not. Senders announce the contents of the encrypted mail all the time in the subject, never mind the rest of the header data is plaintext.
                  3. OpenPGP keys are not forward secret. Any and all past intercepted encrypted emails can and will be broken when your OpenPGP key is compromised.
                  4. DKIM provides transparent non-repudiation (accidentally, interestingly enough), making OpenPGP and S/MIME signing of emails unnecessary.
                  5. OpenPGP’s AEAD construction via its home-brew MDC is broken.
                  6. Email cannot be secured as demonstrated via EFAIL. The mitigation is either to suppress loading active content in your email, or remove OpenPGP or S/MIME plugins from your MUA, and process the encrypted content out-of-band.
                  1. 1

                    Email cannot be secured as demonstrated via EFAIL.

                    That feels like an exaggeration.

                    I guess the main problem is that most users are not willing to spend resources in improving the security ecosystem, be it in form of money or volunteer work. Which leads to central software being critical to our security being understaffed and insufficiently maintained.

                  2. 0

                    That’s okay, there are people who will keep beating you until you stop wanting it.