I refused PGP

Original author: Filippo Valsorda
  • Transfer
About the author: Filippo Walsorda is engaged in cryptography and TLS, calls himself “urandom ambassador”, is a member of the Cloudflare crypto group, and has raised the well - known Heartbleed vulnerability testing service . You might have met him at cryptography and computer security conferences or under the @FiloSottile nickname on Github and on Twitter

After years of torment with GnuPG with varying levels of enthusiasm, I came to the conclusion that it is not worth it, and I give up. At least regarding the concept of long-term PGP keys.

It's not about the program itself gpgand not about cryptographic tools in principle. Many wrote on this topic. I'm talking about the PGP Long-Term Key Model, be it guaranteed by a trust network, fingerprints of public keys or the TOFU model - it doesn’t matter. I say that it is not suitable for me personally.

If you received a link to this article in response to your encrypted letter or in response to a request for a public key, you can immediately proceed to the “What's Next” section.

Believe me, I tried. I went through everything. Tried Enigmail. I had offline master keys on a dedicated Raspberry Pi with short-term subkeys. I wrote special programs for making handwritten backups of offline keys on paper (which I will publish sooner or later). I had YubiKey hardware keys. All my days it took me to develop the rules for using PGP public keys.

I spent two hours traveling by train to the closest Biglumber user in Italy to get my first signature in a solid set. I have a signature from the most associated key in the set. I went to key signing exchanges on several continents. I even organized a couple of these.

I even had the audacity to say that I understand PGP. In 2013, I prepared a batch format in order to reduce short identifiers . I invented complex systems in an unhealthy way, so that the device’s subkey was tied to both my personal master key and the corporate master key. I compiled usability and security tickets for GnuPG and its various distributions.

By all indications, I should be the perfect PGP user. A competent enthusiast surrounded by a community of like-minded people.

But that just didn't work.

Firstly, the problem of the lack of popularity of encryption, about which others talked a lot, has not disappeared. I received a maximum of two encrypted letters per year.

Then, the problem of inconvenience. Easily tolerated critical errors. Confused server listings with keys many years ago. “I cannot read this letter on my phone.” “Or on a laptop, I left the keys, which I’m not using, on another machine.”

But the real problems that I saw are much more subtle. I never felt that my long-term keys are safe. The more time passed, the less confidence in each of them. YubiKey keys can be intercepted in a hotel room. Offline keys can remain in a distant drawer or safe. May announce new vulnerabilities. They can connect to USB devices.

The security of long-term keys corresponds to the minimum common divisor of your lifelong security actions. This is a weak link.

To make matters worse, existing long-term key handling practices, such as collecting key signatures and printing public key fingerprints on business cards, contradict other patterns of behavior that would otherwise be considered an obvious hygienic routine: often change keys, have different keys on different devices , apply compartmentalization (different profiles of thinking in different areas, for example, at work and at home - approx. per . ). Existing long-term key handling practices actually expand the attack vector, as they push for key backups.

We are talking about playing a cat and mouse in infrastructure, but this concept also applies to keys! If I suspect a hack, I want to be able to drop the laptop and start from scratch with minimal loss. The worst possible outcome is to bind the user to a key that he considers to be potentially compromised, because the cost of replacing the key is too high.

And all this for what?

“Of course, for the sake of long-term trust.”

Yes, and about that. I have never, never, ever used a trust network to validate a public key. And remember, I have a well-connected key. I did not do any formal research, but I’m pretty sure that everyone who used PGP to contact me did or could do (if asked) one of the following things:

  • pulled the most liked key from the key server, most likely not even by TLS;
  • uses a different key if you answer him with the words "this is my new key";
  • will send the letter in clear text, if you ask him with an excuse like "I'm on a trip."

Rides and trips are especially hostile to long-term keys, making this type of a fresh start impossible .

Moreover, I’m not even sure that there is an attacker against whom long-term keys make sense. Your average average enemy probably will not be able to conduct a MitM attack on private messages on Twitter (this means that you can opportunistically use private messages to exchange fingerprints of public keys, while still maintaining privacy). Mossad will do Mossad things with your car, no matter which key you use.

After all, nowadays I care more about direct secrecy, the possibility of rejection and ephemerality, than about unbreakable trust. Are you sure you can protect a long-term key forever? Because when an attacker decides to make you his target and succeeds, he will gain access not only to all your messages from now on, but to all past messages too.

What's next


I will not stoop to text letters. Quite the contrary. But I will no longer guard my long-term key.

Basically, I will use Signal or WhatsApp, which offer significantly better iOS endpoint protection, ephemerality and painless key rotation.

If you want to contact me safely, it is best to ask for a Signal number through a private message on Twitter . If necessary, we can determine the appropriate way to compare prints.

If we meet in person and need to establish a secure channel, we will simply exchange a secret passphrase for use in the most suitable program: OTR, Pond, Ricochet.

If it turns out that we really need PGP, we will install some suitable keys, rather in the styleOperational PGP . The same goes for any signed releases or canaries that I can support in the future.

To exchange files we use Magic Wormhole, OnionShare or suitable PGP keys through a secure channel that we already have. The goal here is to avoid using not gpgPGP key management models.

If you really need to quickly send me a message, I can save the Keybase key , but I do not promise. I like to build trust in your social profiles more, because this way keys are rotated in a more natural way. And in any case, this is probably the way most will contact me.

I also do not refuse YubiKey hardware keys. I really like my new YubiKey 4 with a finger touch sensor, which I use to store SSH keys, passwords and boot the machine. But these things are 100% under my control.

About my old keys and transition


I broke protection on all offline storages of my keys. I have no reason to think that they are compromised, but you should stop using them right away.

Below are the signatures for the Markdown version of this document (article "Giving up on PGP") from all the keys that I can still find.

In the coming weeks, I will import all the signatures I received, make all the signatures I promised, and then I will make reviews on the key servers. I will change my Keybase key. In the end, I will destroy the secret keys.

See you at Signal. (Or on 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 [will be when I recover the passphrase from another country]

Note. I plan to expand the “What's Next” section over time, because the tools appear and disappear. A signed file .mdwill not change, an unsigned file will .diffappear below for ease of verification.

Also popular now: