It’s been more than five years since The PGP Problem was published, and I still hear from people who believe that using PGP (whether GnuPG or another OpenPGP implementation) is a thing they should be doing.

It isn’t.

The part of the free and open source software community that thinks PGP is just dandy are the same kind of people that happily use XMPP+OMEMO, Matrix, or weird Signal forks that remove forward secrecy and think it’s fine.

Not to mince words: The same people who believe PGP is good are also famously not great at cryptography engineering.

I’m not here to litigate the demerits of PGP. The Latacora article I linked above makes the same arguments I would make today, and is a more entertaining read.

It is of my opinion as a security engineer that specializes in applied cryptography that nobody should use PGP, because there’s always a better tool for the job you want to use PGP for.

If you can accept that every billionaire is the result of a failed system, that’s how cryptographers feel about people using PGP.

Instead, let’s examine the “use cases” of PGP and what you should be using instead. (Some of this is redundant with the Latacora article, but I’m also writing it 5 years later, so some things have changed.)

Instead of PGP, Use This

Signing Software Distributions

Use Sigstore.

Note that this is an ecosystem-wide consideration, not something that specific individuals must manually opt into for each of their hobby projects.

If you’re a Python developer, you can just use PEP 740 to get attestations with Trusted Publishers, which gives you Sigstore for free. For most developers, this is as simple as setting up a GitHub Action to publish to PyPI.

This is a developing trend: Other programming language and package management ecosystems are following suit. I expect to see Sigstore attestations baked into NPM and Maven before the next US presidential election. With any luck, your favorite programming language could be on this list too.

Sigstore doesn’t just give you a signature that you check with a long-lived public key, nor does it require you to do the Web Of Trust rigamarole.

Rather, Sigstore gives you a lot for free. Sigstore was designed around ephemeral signing certificates rather than a long-lived private key. It was purpose-built for preventing supply-chain attacks against open source software.

Combined with Reproducible Builds, Sigstore solves the triangle of secure code delivery.

Alternatively, use minisign. If your package ecosystem doesn’t support Sigstore yet, you can get by with minisign (which is signify-compatible) until they modernize.

Signing Git Tags/Commits

Use SSH Signatures, not PGP signatures.

With Ed25519.

Identity Verification

I’m actively working on something better!

If you want the ability to vend a transparently verifiable public key for a given user, that’s one of the use cases for the Public Key Directory I’m designing in order to build end-to-end encryption for the Fediverse.

Although this is purpose-built for the Fediverse, I’ve deliberately included support for Auxiliary Data messages, whose formats will be specified by protocol extensions.

Rather than trying to grok the Web-of-Trust, you can simply have your software check that multiple independent Public Key Directories have verified the record, since its inclusion is published in an append-only transparency log, secured by a Merkle tree.

My design doesn’t preclude any manual key verification, or key-signing parties, or whatever other PGP cultural weirdness you want to do with these public keys. It just establishes a baseline trustworthiness even if you’re not a paranoid computer nerd.

My project isn’t finished yet. In the meantime, you can manually check public keys when using the other recommendations on this page.

Sending Files Between Computers

Use Magic Wormhole.

You could also use SSH + rsync to do this job. That’s fine too.

Encrypting Backups

Tarsnap is the default recommendation here.

There are a lot of other encrypted backup tools that work fine, if you don’t want to give Colin Percival your business. I don’t have a financial stake in any of them.

Encrypting Application Data

Use Tink or libsodium.

Avoid: OpenPGP, OpenSSL and its competitors.

Not a lot to say here. I’ve written a lot about this over the years. Misuse-resistant cryptography libraries–especially ones that make key management less painful for users–are the way to go.

Encrypting Files

Use age.

Age is what PGP file encryption would be if PGP didn’t suck shit.

Age has two modes: Public-key encryption, and password-based key derivation.

Here’s a quick comparison table between what age offers, and what PGP uses in the installed base:

	age	PGP
Data encryption mode	AEAD (ChaPoly)	CAST5 (64-bit block cipher) in CFB mode with a strippable SHA1 “MDC”
Key-commitment	Yes (via the header)	Pah! You wish! Dream on. PGP isn’t even AEAD.
Password KDF memory hard?	Yes, with scrypt.	No.
Vulnerable to chosen-ciphertext attacks?	No.	Yes, but PGP proponents stupidly consider this a good thing.
Supports 90’s era cryptography?	No.	Yes.
Releases unauthenticated plaintext?	No.	Yes.
Uses versioned protocols rather than “cipher agility”?	Yes.	No. See: 90’s era cryptography.
Most common implementations are memory-safe?	Yes (Go, Rust).	No (C).

Like, it’s not even close.

Some PGP proponents will insist that AEAD is possible now, but as long as the installed base of PGP remains backwards compatible with the lowest common denominator, that’s what your software uses.

Just use age. Or rage, if you’re a Rust enthusiast.

(And if you have concerns about “which age key should I trust?”, I’m already planning an age-v1 extension for the Public Key Directory project.)

Private Messaging

Use Signal.

Security teams around the world insist that they need PGP for bug bounty submissions or security operations, but Signal does this job better than PGP ever did.

Once upon a time, you needed to give people a phone number to use Signal, but that hasn’t been the case for a long time. Still, many people have missed that memo and think it’s a requirement.

My Signal username is soatok.45. Go ahead and message me. You won’t learn my phone number that way.

In the near future, I plan on developing end-to-end encryption for direct messages on the Fediverse (including Mastodon). This is what motivated my work on the Public Key Directory to begin with. But this is not intended to be a Signal competitor by any measure. It’s a bar-raising activity, nothing more.

Encrypted Email

Don’t encrypt email. From the Latacora article:

Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.

There isn’t a recommendation for encrypted email because that’s not a thing people should be doing.

Now, there exists a minority of extremely technical computer user for which Signal is a nonstarter (because you need a smartphone and valid phone number to enroll in the first place).

Because those people are generally not the highest priority of cryptographers who are focused on the privacy of people in poor countries where smartphones are more common than desktop computers, there isn’t really a good recommendation for private messaging that meets their constraints.

Not Matrix.

Not XMPP+OMEMO.

Watch This Space

With all that said, I am actually designing an encrypted messaging protocol that will have an email-like user experience, except:

1. Everything is always end-to-end encrypted.
2. It’s not backwards compatible with insecure email.
3. It doesn’t use PGP, or any 1990’s era cryptography.

I can’t promise a release date yet. I’m prioritizing end-to-end encryption for the Fediverse before I write the specification for that project (tentatively called AWOO, but the cryptography underpinning both projects should be similar).

Maybe 2026? We’ll see!

If someone beats me to the punch, and their design is actually good, I’ll update the post and replace this with a specific recommendation.

Against PGP

I don’t know how to get the message out louder or clearer about how cryptographers feel about PGP than what I wrote here.

Latacora wrote their criticism in 2019. As I write this, 2024 is almost over. When will the PGP-induced madness end?

---

Header art credits: CMYKat and the GnuPG logo.