The great debate: embracing vs. moving away from PGP in trainings


(Continuing the discussion from the security resources thread.)

This is a question specifically for security trainings.

The question whether to embrace or move away from PGP is increasingly contested in the information security community for all of the obvious reasons. When you get started using PGP / GnuPG it can be difficult to set up and learn. In the long-term, it's easy to make costly mistakes that could diminish your overall security, or that simply lock you out of your email. Metadata is still a challenge. Finally, unless all your besties are system admins, activists, or techy journalists, these issues are further compounded when you throw network effects into the mix. Simultaneously, despite its clunkiness, it's been a persistent staple in security trainings and guides.

The questions is, should we embrace PGP (specifically with trainings), or move on? Perhaps we should move away in specific contexts, or when training specific groups, but retain it for others. Any thoughts?


For people who really need poor usability and fairly massive social network and metadata leakage :wink: , at least reop ( is simple, small, and has only 1 significant dependency. That dependency, libsodium, is best-in-class. reop fills all the PGP use cases better than PGP, AFAICT.

For trainings, I really don't see why we'd burden people with anything other than Use Signal, It Is Good. Having done some of these trainings, I've found that people have extremely limited bandwidth for these rather heavyweight new concepts. PGP immediately blows the cognitive load budget.

The future needs to be in metadata security, which means we need to move on. The sooner the better. :slight_smile:


Burn it with fire?

Seriously, though, this is a great topic. Thank you for posting it.

I've held several information security training sessions with activists. I've grown to loathe teaching PGP, not because it takes time and effort to teach someone to use it, but because I feel bad when motivated and well meaning people blame themselves for getting it wrong. Those people who do walk away from the training with the ability to use PGP inevitably find that they have no one to talk to, because it's too difficult for their contacts to figure out how to use it.

This all leads to the tragi-comic result that the people who do end up using PGP are all the ones who are willing to put up with its eccentricities, and so this self-selecting group conveniently blames everyone else for not adopting it.

PGP still has really important uses and it's important to support GnuPG development with donations for those reasons alone - every package downloaded by every Debian based server in the world (so most of them, including this web server) is integrity checked with PGP. It is a great swiss army knife of a tool for all sorts of tasks, excluding emailing normal people. PGP is like ssh; it's a vital tool for developers and system administrators. What it's not is a sane way to email people securely.

Signal all the things.


I would argue that the world should hustle to fund and change Debian package signing (and related things) to using binary transparency (and, hey, source transparency?). I don't think even geeks and sysadmins can use PGP correctly; at a Drunken Cryptographers meet-up some years back, we all agreed that we were terrified of PGP/GnuPG and did not trust ourselves to use it correctly. And reop was born out of a project specifically to not use GnuPG for package signing.

[Irrelevant Debian security feels redacted to enhance your reading experience]


This is a remarkable rant from an expert:

Tl;dr "It's time for PGP to die."

Operationally, my experience with PGP has been disastrous. I'm lucky nothing truly bad has come from these failures, but hey, someone might eventually get ahold of a private key and cause problems with my messages of years ago, so there's still time!

The one problem it still solves reasonably well is reaching out to a security expert when you don't have their phone number and the metadata is not a significant problem.


Aren't we making things a bit easy for ourselves here, by just saying "PGP considered harmful, let's move on". I don't know about the contexts that you guys work in, but in virtually all of the organisations I've worked in, the actual business is conducted via email. I don't just mean that one crucial conversation with a new source that goes on for 90 minutes, but the everyday grind of stuff to be done.

Now, of course, it's really fun to just say that e-mail is over and we should all use Signal now. But now we've turned an "add crypto to your mail client" problem into a "adopt a different social network, and a different modality of communication" problem. This is one step shy of suggesting everybody switch from Facebook to Diaspora: nice sentiment, but not going to fly.

So maybe we do have to work with E-Mail, I feel it's pretty much a given.


Hmmm, was all with the Open Whispers System because it looks so much simpler.

But you make a good point about email still being part of the everyday grind.

However as someone who has to battle to get people to even use Facebook or Twitter (or even email back in the 1990s), I always get told that people are just too busy to learn new things.

When it comes to advocacy maybe we need to build in the policy-level crowd and, I dunno, compare losses from security disaster with the penny-to-the-pound costs of extra security training.


Getting everyone in an office to use Signal is absolutely easier than getting everyone to use PGP. There's no specific workflow that you can do in email that you can't do in Signal - attachments, multi-party messages -they're all there.

Using a chat application at work, even one with a desktop application, is a culture shift, but I would say two things to that: first, if we take a look at Slack adoption, it's clear that many people are willing to use chat-like applications for work, and second, if the pain point is getting one's team to use new technology, then PGP is the last thing you want. Even if a tech sets everyone up so that their mail clients are good to go with PGP, anytime a user needs to email a new contact they need to:

gpg --search-keys --keyserver
gpg: searching for "person" from hkp server
(1) Person < >
Keys 1 of 1 for "person". Enter number(s), N)ext, or Q)uit >

After they press 1, they need to type:

gpg --fingerprint

And then verify that that fingerprint corresponds to the publicly posted fingerprint of their correspondent, or type:

gpg --list-sigs

And then check to see if anyone they know (whose key's fingerprint they have already validated) has signed ""'s key. You can also do the equivalent of the above in one of the clunky graphical user interfaces written for PGP, but the experience is just as bad.

With Signal, you don't even have to worry about identifiers, because it uses your phone number and runs a set intersection on your contacts. The comparison with Diaspora isn't really apt; Signal's social network is already there and we're already in it: we all have phone numbers.

If the problem is getting people in one's office to all use a new technology, then PGP is a terrible solution.

Besides all of that, there are many good reasons that we should hasten email's demise in the first place. It's easily spoofable when used without PGP (so, most of the time). Unless you are sending email exclusively between accounts with large webmail providers, STARTTLS is often not enabled on the email server, which means that your email is sent entirely in the clear without even the benefit of SSL encryption at some point in its travels, even if your connection to your webmail provider is encrypted with SSL. If you are corresponding with an activist in Bahrain, whose email is:

and their mail provider is GoDaddy, then their mail server doesn't have STARTTLS. If they are using a mail client instead of webmail, then any links or attachments that you add in your email to them can be replaced with malicious ones by the Bahraini government.

Of course, you could solve this problem by using PGP, but good luck with that. I challenge anyone to successfully recruit more than 10% of their regular contacts to adopt PGP. I've tried it. It doesn't work.


If it's important to people to use email, I would recommend gmail + 2fa in a heartbeat over PGP. It's way more likely to be secure in practice. PGP is just insanely error prone and complicated. In my experience people just stop using it anyway.


Hey Ethan, I think you're slightly misrepresenting what I said. I don't mean to suggest that PGP is a great solution and that we should all adopt it as-is. It's pretty much crap, and the number of ways it'll fail on you is ... surprising.

I just meant to be clear that "it's OK, Paul Graham said email is dead and so we don't need to think about that one any more" would be making it a bit simple, by moving the goal post.

The way that PGP thought about PKI was a disaster. OK. But the experience of using PGP with Apple Mail, Mailvelope etc. is a moving target, and it's getting better by the day. Things like seem to be working on that in new ways, and if we pushed the rest of the stack (i.e. MUAs) to make sense of it, I could see light at the end of the PGP tunnel yet.


Fair enough. I'm don't mean to say that if you are using PGP now, that you should stop using it (I would be a hypocrite for saying that, I use PGP). Rather, the original post asked whether it makes sense to invest more effort and time in training people to use and adopt PGP. I don't think that makes sense at this point. That's all.


I don't teach GPG/PGP in general security training. It's simply not a good tool for sending messages to other people. The whole email skeumorphism and usability nightmare means that there's always a better option, like — in an overwhelming majority of cases — Gmail.

Not to say that GPG is useless. It's a perfectly fine tool for nerds verifying git commits or software binaries, or deciding whether to add someone's SSH key to a server. But that's all it's good for: nerds.


I gave a talk just over a year ago to a masters of journalism class at NYU. When working on that talk, one of the tools that I had used as an example, and recommended the students look at was Keybase.

If you're adamantly against PGP, I doubt Keybase would change your mind, but it has looked to me as potentially a way to introduce PGP to people who have issue grasping the concept technically. The biggest concern I do have with it is that, in order to overcome the technical problems of PGP, they do rely on in-browser javascript based crypto and keeping private keys on a Keybase server.

But given this system, you can at least introduce and teach PGP concepts and help people understand how to send encrypted messages. Once they have the basics down, you can always move to using Keybase from the command line, revoke server side private key, etc.

Anyone (with much more knowledge than I) have opinions on Keybase and using it as a way to teach PGP?


It depends on your threat model.

I’d say in general PGP is probably too much to get people to use. I wrote the guide in the other thread because I knew I would forget how to do things in the future and need a good and always up to date reference.

Good PGP with a hardware key is essential for developers working with ssh and git. Outside that, it depends on your threat model and source.

I don’t think it makes sense to teach it to everyone, it’s easy to stuff up. Tools like Signal are superb from a UX perspective and should be taught to everyone.

PGP should be mentioned, as everyone should be aware of it - in case they need it.

In terms of actually using PGP, if you don’t or can’t generate your key on an air gapped machine, and use a hardware token with subkeys then you shouldn’t use PGP. Go full paranoid, or don't bother (hence the guide's name).

PGP is complex, but give you full control of the private key. If you need that, then use PGP. If you don’t need that, then it might not be worth the hassle.

That brings me to keybase. I love what they’re trying to do (keybaseFS looks very promising), but I find their key model confusing. Until that’s resolved it’s hard to get into it.


I've been using Matt Mitchell's PGP starter kit during trainings and it's been useful (it's designed for someone to work through on their own). I usually give a primer about threat modeling, why email is insecure, what PGP is, and why it might be important for a 10 minutes and then let students work on their own to install it. If they don't finish, they keep access to the doc and I give them my fingerprint so they can test it with me.

I think the hardest part is figuring out how to add PGP to the workflow and knowing when to use it (based on your threat model). I tell folks that it takes practice.

Here's Matt's doc -


Frankly I don't get the whole burn PGP/GPG with fire mindset. I understand the argument against and for and to me it comes back to is it the right tool for the job? I have had very good success using this tool, without operational issue. (It should be noted that I've been doing this since 97, and have been schooled in the strict protocols for use.)
Is this a tool for beginners, I wouldn't say so, does it provide confidentiality yes, pseudonymity yes. Is the on wire signature high, you betcha. Is it good for sending long form discussion email back in forth between individuals, yes! Sorry no, PFS, but that's why you rotate keys.
It's a tool, it's got a strict set requirements for it's use, it's not robust. But being able to use it properly is a life skill.


Heard, and noted.

Just because a lot of journos are like me - technically deficient - doesn't mean the more complicated protocols are not worth learning.

Especially for those dealing with multi-state threats. And anything over a million dollars is potentially multistate. So, yeah, pretty much all of us.