GPG Is Terrible
A discussion at work reminded me that I hadn't looked at the state of the art for email and communications security in a while. Turns out the options haven't changed much: S/MIME, which relies on x.509 PKI and is therefore unusable unless you want to pay for a certificate from someone with lots of incentives to screw you, or GPG.
S/MIME in the wild is a total non-starter. GPG, on the other hand, is merely really, really bad.
(You may want to take this with a side of the other perspective.)
Body Security And Nothing Else
GPG encrypts and signs email message bodies. That's it, that's all it does when integrated with email. Email messages contain lots of other useful, potentially sensitive data: the subject line, for example. GPG still exposes all of the headers for the world to see, and conversely does nothing to detect or prevent header tampering by idiot mailers.
(Yes. Signed headers would mean that mailing lists can no longer inject
[listname] crud into your messages. Feature, not bug; we should be, and in
many cases already are, storing that in a header of its own, not littering
the subject line. We also need to keep improving mail tooling, to better
handle those headers.)
In return for doing about half of its One Job, GPG demands a lot from its users.
The Real Name Policy
The GPG community has a massive “legal names” fixation. Widespread GPG documentation, and years of community inertia, stand behind expecting people to put their legal name in their GPG key, and conversely expecting people to verify the identity in a GPG key (generally by checking government ID) before signing it.
As the #nymwars folks can tell you, this policy is harmful and limiting. There are good theoretical reasons to validate an identity before using its keys to secure messages, but legal identities can be anywhere from awkward to dangerous to use.
GPG does not technically restrict users from creating autonymous keys, but the community at large discourages their use unless they can be traced back to some legal identity. Autonyms keys tend to go unsigned by any other key, cutting them off from the GPG trust network's validation effect.
As @wlonk put it:
I care about communicating with the coherent theory of mind behind @so-and-so.
GPG makes issuing new identities simultaneously too easy and too hard for users. It's hard, because the only way to issue a new identity on an existing key (and thus associated with and able to share correspondence with an existing identity) requires that the user have access to their personal root key. There's no way to create ad-hoc identities and bind them after the fact, making it hard to implement opportunistic tools. (OTR's on-demand key generation fails to the opposite extreme.) It's easy, because there's no mechanism beyond the web of trust itself to vet newly-created keys or identities; the GPG community compounds this by demanding that everyone carefully vet legal identities, making it very time-consuming to deploy a new name.
Finding Paul Revere
It turns out autonymity in GPG would be pretty fragile even if GPG's user community didn't insist on puncturing it at every opportunity, since GPG irrevocably publishes the social graph of its users to every keyserver they use. You don't even have to publish it yourself; anyone who has a copy of your public key can upload a copy for you, revealing to the world the identities of everyone who knows you well enough to sign your key, and when they signed it.
A lot of people can be meaningfully identified by that information alone, even without publishing their personal identity.
The Web Of Vulnerable CAs
Each GPG user is also a unilateral signing authority. GPG's trust model means that a compromised key can be used to confer validity onto any other key, compromising potentially many other users by causing them to trust illegitimate keys. GPG assumes everyone will be constantly on watch for unusual signing activity, and perfectly aware of the safety of their own keys at all times.
Given that the GPG signature graph is largely public, it should be possible to moderate signatures using clique analysis, limiting the impact of a trusted party who signs inauthentic identities. Unfortunately, GPG makes it challenging to implement this by providing almost no support for iteratively deepening the local keyring by downloading signers' keys as needed.
Sending a GPG-signed message to a non-GPG-using normal human being is a great way to confuse the hell out of them. You have two options:
- In-band “cleartext” signing, which litters the email body with technical noise, or
- PGP/MIME, which delivers a meaningless-looking “signature.asc” attachment.
In both cases, the recipient is left with a bunch of information they (a) can't use and (b) can't hide or remove. It might as well say “virus.dat” for all the meaning it conveys.
Some of this is not GPG's fault, exactly, but after over a decade, surely either advocacy or compromise with major mail vendors should have been possible.
(Accidentally sending an encrypted email to a non-GPG-using recipient is, thankfully, hard enough to be irrelevant unless someone is actively spoofing their identity.)
Webmail Need Not Apply
Well, unless you want to write the message text in an editor, copy and paste it into GPG, and copy and paste the encrypted blob back out into your message. (Hope your webmail's online editor doesn't mangle dashes or quotes for you!)
Apparently Google's finally fixing that for Chrome users, so that's something.
Mobile Need Not Apply
Safely distributing GPG keys to mobile applications is more or less
impossible, and integration with mobile mail applications is nonexistant.
Hope you only ever read your mail from a Real Computer!
vollkorn points out that the above is inaccurate. He posted a couple of options for GPG on Android, and the state of the art for iOS GPG apps is apparently better than I was able to find. See his comment for details.