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.
-

Issuing Identities

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.

Interoperability

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.