PGP and Real-World Cryptography

My previous post details setting up Sequoia PGP for email encryption, where I gloss over technical details in favor of waxing poetic about the virtues of privacy. That’s all well and good, but I don’t want to leave such details completely behind because they form an interesting window into the world of asymmetric cryptography.

This whole PGP excursion has ignited within me a desire to learn more about cryptography generally, leading to the book Real-World Cryptography. The author has the following to say about PGP:

The most critical issue is that encryption is not authenticated, which means that anyone intercepting an email that hasn’t been signed might be able to tamper with the encrypted content to some degree, depending on the exact encryption algorithm used. For this reason alone, I would not recommend anyone to use PGP today. (David Wong)

Not a very positive review, I’d say. Further points are well-argued, and the case against PGP is strong. Well, maybe I should rephrase that as the case against email encryption.

More fundamental than PGP is the fact that email is a plaintext protocol. It was never designed with encryption in mind, and that effect has repercussions towards any solution bolted on top. Cryptographic systems aside, using PGP to encrypt email means that you’re still exposing email metadata, even if the message itself is encrypted.¹

Despite this, I was still motivated to investigate some of the author’s criticisms. Has the world of PGP changed since the book was released in 2021? As it turns out, yes! Although the details of those changes are themselves worthy of an unexpectedly deep rabbit hole.

The PGP that Real-World Cryptography discusses is RFC 4880, the 2007 PGP standard. Efforts to improve this standard have arisen over the last decade, but have unfortunately split into two separate groups. On one side, GnuPG maintainer Werner Koch advocates for a conservative approach, spawning LibrePGP. On the other, Proton, Sequoia, and the IETF advocate for a thorough cryptography refresh, RFC 9580. The inability for the two sides to agree on one proposal has left PGP with two.

I don’t want to dive too deep into the semantics between the two different proposals, since it’s bad enough that the standard has become plagued with in-fighting. Instead, I’ll talk about some of the features that both proposals bring to the table to address the points mentioned in Real-World Cryptography.²

Authenticated encryption

Let’s start with authenticated encryption:

PGP does not have authenticated encryption and is, thus, not secure if used without signatures. (David Wong)

To clarify the author’s point, RFC 4880 does include a device for authenticated encryption known as MDC (Modification Detection Code). However, MDC doesn’t provide what the author of Real-World Cryptography would consider cryptographically strong authentication.

Let me zoom out for a second to explain why any authenticated encryption method is important for PGP. The attack looks something like this:

1. Alice sends an encrypted mail to Bob. Alice chooses not to sign the message.
2. Mallory intercepts the encrypted mail. Mallory cannot read the contents of the message, but they can arbitrarily modify the ciphertext itself. They do so.
3. Bob receives the modified ciphertext and decrypts it. Bob has no idea that the message contents were modified in transit by Mallory. The decrypted plaintext no longer matches Alice’s intended message.

Authenticated encryption allows Bob to verify in step 3 whether or not the ciphertext received is consistent with the original message composed by Alice. With MDC, Bob decrypts the message, discovers that it has been tampered with, and knows that there’s a Mallory sitting in the middle of the correspondence.

Going back to David Wong’s point, MDC is not considered a sufficient form of authenticated encryption from a cryptographer’s standpoint. The verification code is included within the ciphertext, so when Bob verifies the message in step 3, Bob must first decrypt the entire message. This leaves an open space where a PGP implementation may accidentally leak message contents and reveal information due to bad error handling.³

In the original spec, the limitations of MDC are considered intentional risk. Within the RFC, the authors note that they chose MDC because they wanted to preserve the deniability of messages. MDC achieves this because unlike alternative authentication mechanisms, there’s no secret key associating the authentication to the original message author (Alice).

OpenPGP addresses this desire to have more security than raw encryption and yet preserve deniability with the MDC system. An MDC is intentionally not a MAC. Its name was not selected by accident. It is analogous to a checksum. (RFC 4880)

Deniability is an important design goal for PGP simply because signing a message is optional. If a user chooses not to sign a message, the system should not implicitly sign said message with its authenticated encryption. Although the contents of the message should be encrypted, they should not be cryptographically linked to its author.

Luckily in 2026 we have authenticated encryption mechanisms that both (a) prevent decryption-oracle attacks and (b) don’t sacrifice deniability. As Daniel Huigens explains in his crypto-refresh post for Proton Mail:

OpenPGP has had authenticated encryption for a long time, using a mechanism called the “Modification Detection Code” (MDC). While this does the job, modern authenticated encryption schemes achieve secrecy and authentication in one integrated algorithm. Such encryption modes, dubbed AEAD algorithms, offer improved performance at the same security level. (Daniel Huigens)

Both LibrePGP and RFC 9580, the two competing modern standards, include AEAD algorithms that replace the MDC scheme from RFC 4880.

Refreshed cryptography

It’s probably clear from the previous section that the two new standards for PGP address concerns related to obsolete cryptography. Once again citing Daniel Huigens,

[RFC 9580] deprecates old cryptographic primitives and algorithms, including the hash algorithms MD5, SHA1, and RipeMD, the symmetric algorithms IDEA, 3DES, and CAST5, and the public-key algorithms ElGamal, DSA, and RSA keys of less than 3072 bits (the security level comparable to Curve25519). These are all considered less secure than their modern alternatives and, as a result, are not fit for use in new data or even the consumption of existing data in some cases. (Daniel Huigens)

That said, the current standards schism between LibrePGP and RFC 9580 is not helping PGP users in adopting updated cryptographic algorithms. Both specs introduce a new key format (v5 and v6 respectively) that are incompatible. As a result, most users are still using v4 keys that use outdated cryptographic algorithms. The whole thing is a bit of a mess, where v4 keys are an awkward interoperability layer between the two incompatible modern formats.

The tl;dr is that so long as you’re using v4 keys, you’re losing the cryptographic improvements made in LibrePGP or RFC 9580. Because those v4 keys are the only compatibility layer between the v5 and v6 proposals, most users are using them. The vicious cycle ensues.

Looking forward

Realistically I don’t recommend anyone to go out of their way to set up PGP, even if it has managed to nerd-snipe me over the past month. You should probably just use Signal.

That said, I think PGP is a great way to start messing around with asymmetric cryptography to help illustrate the concepts. I recommend sq, since it supports RFC 9580 and has excellent documentation. And hey, if you want to set it up with Thunderbird, I have a post for that.

Below are the handful of articles I used as reference when writing this post:

• RFC 4880
• RFC 9580
• A schism in the OpenPGP world
• Modernizing and improving PGP security