Recently there have been two very good, and opposing, articles written on the state of Pretty Good Privacy (PGP) and whether or not it is worth using in 2016/2017 and beyond.
You can find the original article, I’m throwing in the towel on PGP, and I work in security, at Ars Technica here but I’ve reproduced it below in case the link stops working at some point. You can also find the follow up piece, Why I’m not giving up on PGP, also at Ars Technica here and again I’ve reproduced it below just in case.
I’m throwing in the towel on PGP
After years of wrestling with GnuPG with varying levels of enthusiasm, I came to the conclusion that it’s just not worth it, and I’m giving up—at least on the concept of long-term PGP keys. This editorial is not about the
gpgtool itself, or about tools at all. Many others have already written about that. It’s about the long-term PGP key model—be it secured by Web of Trust, fingerprints or Trust on First Use—and how it failed me.
Trust me when I say that I tried. I went through all the setups. I used Enigmail. I had offline master keys on a dedicated Raspberry Pi with short-lived subkeys. I wrote custom tools to make handwritten paper backups of offline keys (which I’ll publish sooner or later). I had YubiKeys. Multiple. I spent days designing my public PGP policy.
I traveled two hours by train to meet the closest Biglumber user in Italy to get my first signature in the strong set. I have a signature from the most connected key in the set. I went to key-signing parties in multiple continents. I organized a couple.
I have the arrogance of saying that I understand PGP. In 2013 I was dissecting the packet format to brute force short IDs. I devised complex silly systems to make device subkeys tie to both my personal and company master keys. I filed usability and security issues in GnuPG and its various distributions.
All in all, I should be the perfect user for PGP: competent, enthusiast, embedded in a similar community. But it just didn’t work.
First, there’s the adoption issue others talked about extensively. I get, at most, two encrypted e-mails a year.
Then, there’s the UX problem: easy crippling mistakes; messy keyserver listings from years ago; “I can’t read this e-mail on my phone” or “on the laptop;” “I left the keys I never use on the other machine.”
But the real issues, I realized, are more subtle. I never felt confident in the security of my long-term keys. The more time passed, the more I would feel uneasy about any specific key. Yubikeys would get exposed to hotel rooms. Offline keys would sit in a far away drawer or safe. Vulnerabilities would be announced. USB devices would get plugged in.
A long-term key is as secure as the minimum common denominator of your security practices over its lifetime. It’s the weak link.
Worse, long-term key patterns, like collecting signatures and printing fingerprints on business cards, discourage practices that would otherwise be obvious hygiene: rotating keys often, having different keys for different devices, compartmentalization. Such practices actually encourage expanding the attack surface by making backups of the key.
We talk about Pets vs. Cattle in infrastructure; those concepts would apply just as well to keys! If I suspect I’m compromised, I want to be able to toss the laptop and rebootstrap with minimum overhead. The worst outcome possible for a scheme is making the user stick with a key that has a suspicion of compromise, because the cost of rotating would be too high.
And all this for what gain?
“Well, of course, long-term trust.”
Yeah, about that. I never, ever, ever successfully used the WoT to validate a public key. And remember, I have a well-linked key. I haven’t done a formal study, but I’m almost positive that everyone that used PGP to contact me has, or would have done (if asked), one of the following:
- pulled the best-looking key from a keyserver, most likely not even over TLS
- used a different key if replied with “this is my new key”
- re-sent the e-mail unencrypted if provided an excuse like “I’m traveling”
Travel in particular is hostile to long-term keys, making this kind of fresh start impractical.
Moreover, I’m not even sure there’s an attacker that long-term keys make sense against. Your average adversary probably can’t MitM Twitter DMs (which means you can use them to exchange fingerprints opportunistically, while still protecting your privacy). The Mossad will do Mossad things to your machine, whatever key you use.
Finally, these days I think I care much more about forward secrecy, deniability, and ephemerality than I do about ironclad trust. Are you sure you can protect that long-term key forever? Because when an attacker decides to target you and succeeds, they won’t have access just from that point forward; they’ll have access to all your past communications, too. And that’s ever more relevant.
I’m not dropping to plaintext. Quite the opposite. But I won’t be maintaining any public long-term key.
Mostly I’ll use Signal or WhatsApp, which offer vastly better endpoint security on iOS, ephemerality, and smoother key rotation.
If you need to securely contact me, your best bet is to DM me asking for my Signal number. If needed we can decide an appropriate way to compare fingerprints.
If we meet in person and need to set up a secure channel, we will just exchange a secret passphrase to use with what’s most appropriate: OTR, Pond, Ricochet.
If it turns out we really need PGP, we will set up some ad-hoc keys, more à la Operational PGP. Same for any signed releases or canaries I might maintain in the future.
To exchange files, we will negotiate Magic Wormhole, OnionShare, or ad-hoc PGP keys over the secure channel we already have. The point is not to avoid the
gpgtool, but the PGP key management model.
If you really need to cold-contact me, I might maintain a Keybase key, but no promises. I like rooting trust in your social profiles better since it makes key rotation much more natural and is probably how most people know me anyway.
I’m also not dropping YubiKeys. I’m very happy about my new YubiKey 4 with touch-to-operate, which I use for SSH keys, password storage, and machine bootstrap. But these things are one hundred percent under my control.
About my old keys and transitioning
I broke the offline seal of all my keys. I don’t have reason to believe they are compromised, but you should stop using them now.
Below are detached signatures for the Markdown version of this document from all keys I could still find.
In the coming weeks I’ll import all signatures I received, make all the signatures I promised, and then publish revocations to the keyservers. I’ll rotate my Keybase key. Eventually, I’ll destroy the private keys.
See you on Signal. (Or Twitter.)
Giving up on PGP.md
Giving up on PGP.md.B8CC58C51CAEA963.asc
Giving up on PGP.md.C5C92C16AB6572C2.asc
Giving up on PGP.md.54D93CBC8AA84B5A.asc
Giving up on PGP.md.EBF01804BCF05F6B.asc [coming once I recover the passphrase from another country]
Note: I expect the “Moving forward” section to evolve over time, as tools come and go. The signed
.mdfile won’t change, an unauthenticated
.diffwill appear below for verification convenience.
Why I’m not giving up on PGP
Every once in a while, a prominent member of the security community publishes an article about how horrible OpenPGP is. Matthew Green wrote one in 2014 and Moxie Marlinspike wrote one in 2015. The most recent was written by Filippo Valsorda, here on the pages of Ars Technica, which Matthew Green says “sums up the main reason I think PGP is so bad and dangerous.”
In this article I want to respond to the points that Filippo raises. In short, Filippo is right about some of the details, but wrong about the big picture. For the record, I work on GnuPG, the most popular OpenPGP implementation.
Forward secrecy isn’t always desirable
Filippo’s main complaint has to do with OpenPGP’s use of long-term keys. Specifically, he notes that due to the lack of forward secrecy, the older a key is, the more communication will be exposed by its compromise. Further, he observes that OpenPGP’s trust model includes incentives to not replace long-term keys.
First, it’s true that OpenPGP doesn’t implement forward secrecy (or future secrecy). But, OpenPGP could be changed to support this. Matthew Green and Ian Miers recently proposed puncturable forward secure encryption, which is a technique to add forward secrecy to OpenPGP-like systems. But, in reality, approximating forward secrecy has been possible since OpenPGP adopted subkeys decades ago. (An OpenPGP key is actually a collection of keys: a primary key that acts as a long-term, stable identifier, and subkeys that are cryptographically bound to the primary key and are used for encryption, signing, and authentication.)
Guidelines on how to approximate forward secrecy were published in 2001 by Ian Brown, Adam Back, and Ben Laurie. Although their proposal is only for an approximation of forward secrecy, it is significantly simpler than Green and Miers’ approach, and it works in practice.
As far as I know, Brown et al.’s proposal is not often used. One reason for this is that forward secrecy is not always desired. For instance, if you encrypt a backup using GnuPG, then your intent is to be able to decrypt it in the future. If you use forward secrecy, then, by definition, that is not possible; you’ve thrown away the old decryption key. In the recent past, I’ve spoken with a number of GnuPG users including 2U and 1010data. These two companies told me that they use GnuPG to protect client data. Again, to access the data in the future, the encryption keys need to be retained, which precludes forward secrecy.
This doesn’t excuse the lack of forward secrecy when using GnuPG to protect e-mail, which is the use case that Filippo concentrates on. The reason that forward secrecy hasn’t been widely deployed here is that e-mail is usually left on the mail server in order to support multi-device access. Since mail servers are not usually trusted, the mail needs to be kept encrypted. The easiest way to accomplish this is to just not strip the encryption layer. So, again, forward secrecy would render old messages inaccessible, which is often not desired.
But, let’s assume that you really want something like forward secrecy. Then following Brown et al.’s approach, you just need to periodically rotate your encryption subkey. Since your key is identified by the primary key and not the subkey, creating a new subkey does not change your fingerprint or invalidate any signatures, as Filippo states. And, as long as your communication partners periodically refresh your key, rotating subkeys is completely transparent.
Ideally, you’ll want to store your primary key on a separate computer or smartcard so that if your computer is compromised, then only the subkeys are compromised. But, even if you don’t use an offline computer, and an attacker also compromises your primary key, this approach provides a degree of future secrecy: your attacker will be able to create new subkeys (since she has your primary key), and sign other keys, but she’ll probably have to publish them to use them, which you’ll eventually notice, and she won’t be able to guess any new subkeys using the existing keys.
Physical attacks vs. cyber attacks
So, given that forward secrecy is possible, why isn’t it enabled by default? We know from Snowden that when properly implemented, “encryption … really is one of the few things that we can rely on.” In other words, when nation states crack encryption, they aren’t breaking the actual encryption, they are circumventing it. That is, they are exploiting vulnerabilities or using national security letters (NSLs) to break into your accounts and devices. As such, if you really care about protecting your communication, you are much better off storing your encryption keys on a smartcard then storing them on your computer.
Given this, it’s not clear that forward secrecy is that big of a gain, since smartcards won’t export private keys. So, when Filippo says that he is scared of an evil maid attack and is worried that someone opened his safe with his offline keys while he was away, he’s implicitly stating that his threat model includes a physical, targeted attack. But, while moving to the encrypted messaging app Signal gets him forward secrecy, it means he can’t use a smartcard to protect his keys and makes him more vulnerable to a cyber attack, which is significantly easier to conduct than a physical attack.
Another problem that Filippo mentions is that key discovery is hard. Specifically, he says that key server listings are hard to use. This is true. But, key servers are in no way authenticated and should not be treated as authoritative. Instead, if you need to find someone’s key, you should ask that person for their key’s fingerprint. Unfortunately, our research suggests that for many GnuPG users, picking up the phone is too difficult.
So, after our successful donation campaign two years ago, we used some of the money to develop a new key discovery technique called the Web Key Directory (WKD). Basically, the WKD provides a canonical way to find a key given an e-mail address via HTTPS. This is not as good as checking the fingerprint, but since only the mail provider and the user can change the key, it is a significant improvement over the de facto status quo. WKD has already been deployed by Posteo, and other mail providers are in the process of integrating it (consider asking your mail provider to support it).
Other people have identified the key discovery issue, too. Micah Lee, for instance, recently published GPG Sync, and the INBOME group and the pretty Easy privacy (p≡p) project are working on opportunistically transferring keys via e-mail.
Signal isn’t our saviour
Filippo also mentions the multi-device problem. It’s true that using keys on multiple devices is not easy. Part of the problem is that OpenPGP is not a closed ecosystem like Signal, which makes standardising a secret key exchange protocol much more difficult. Nevertheless, Tankred Hase did some work on private key synchronisation while at whiteout.io. But, if you are worried about targeted attacks as Filippo is, then keeping your keys on a computer, never mind multiple computers, is not for you. Instead, you want to keep your keys on a smartcard. In this case, using your keys from multiple computers is easy: just plug the token in (or use NFC)! This assumes that there is an OpenPGP-capable mail client on your platform of choice. This is the case for all of the major desktop environments, and there is also an excellent plug-in for K9 on Android called OpenKeychain. (There are also some solutions available for iOS, but I haven’t evaluated them.)
Even if you are using Signal, the multi-device problem is not completely solved. Currently, it is possible to use Signal from a desktop and a smartphone or a tablet, but it is not possible to use multiple smartphones or tablets.
One essential consideration that Filippo doesn’t adequately address is that contacting someone on Signal requires knowing their mobile phone number. Many people don’t want to make this information public. I was recently chatting with Jason Reich, who is the head of OPSEC at BuzzFeed, and he told me that he spends a lot of time teaching reporters how to deal with the death and rape threats that they regularly receive via e-mail. Based on this, I suspect that many reporters would opt to not publish their phone number even though it would mean missing some stories. Similarly, while talking to Alex Abdo, a lawyer from the ACLU, I learned that he receives dozens of encrypted e-mails every day, and he is certain that some of those people would not have contacted him or the ACLU if they couldn’t remain completely anonymous.
Another point that Filippo doesn’t cover is the importance of integrity; he focused primarily on confidentiality (i.e., encryption). I love the fact that messages that I receive from DHL are signed (albeit using S/MIME and not OpenPGP). This makes detecting phishing attempts trivial. I wish more businesses would do this. Of course, Signal also provides integrity protection, but I definitely don’t want to give all businesses my phone number given their record of protecting my e-mail address. Moreover, most of this type of communication is done using e-mail, not Signal.
I want to be absolutely clear that I like Signal. When people ask me how they can secure their communication, I often recommend it. But, I view Signal as complementary to OpenPGP. First, e-mail is unlikely to go away any time soon. Second, Signal doesn’t allow transferring arbitrary data including documents. And, importantly, Signal has its own problems. In particular, the main Signal network is centralised, not federated like e-mail, the developers actively discourage third-party clients, and you can’t choose your own identity. These decisions are a rejection of a free and open Internet, and pseudononymous communication.
In conclusion, Filippo has raised a number of important points. But, with respect to long-term OpenPGP keys being fatally flawed and forward secrecy being essential, I think he is wrong and disagree with his compromises in light of his stated threat model. I agree with him that key discovery is a serious issue. But, this is something that we’ve been working to address. Most importantly, Signal cannot replace OpenPGP for many people who use it on a daily basis, and the developers’ decision to make Signal a walled garden is problematic. Signal does complement OpenPGP, though, and I’m glad that it’s there.
Now obviously I’m not a computer security expert, just an enthusiast, but I see very valid points made in both articles. In this specific case however I feel like the gentleman arguing against the use of PGP is looking for a cryptographic Holy Grail of sorts – that is a one-size-fits-all piece of technology which is something PGP certainly is not. The problem as I see it though is that even looking beyond PGP there is no such thing as a one-size-fits-all solution that works in every case. For instance obviously PGP is not an ideal technology to use in all cases but then again neither are some of AES’ block cipher modes, etc. and I think we can generally agree that AES is pretty decent otherwise.
My point being that computer security requires somewhat custom fit solutions in order to be at its most effective for a given context. If that means that you don’t choose PGP for a specific use case because there is a better alternative then that makes perfect sense. If on the other hand you don’t choose an alternative, like Signal for example, for the same reason that too is also OK. The point is that in both outcomes we still choose something because even an imperfect solution can offer quite a bit more security than no solution at all.