Encryption

The OpenPGP Crypto Refresh: What RFC 9580 Actually Changed

June 23, 2026 8 min read Haven Team

OpenPGP is the format behind decades of encrypted email and signed software releases. For most of that time it was frozen at RFC 4880, a specification from 2007 that carried defaults older still. In 2024, RFC 9580, often called the crypto refresh, finally modernized it. The update was overdue, technically sound, and it also fractured the ecosystem in a way worth understanding.


OpenPGP's longevity is its strength and its problem. The format outlived the cryptographic assumptions it was born with. By the late 2010s, the standard still treated some choices as normal that the rest of cryptography had moved past: a homegrown integrity mechanism instead of modern authenticated encryption, SHA-1 baked into key fingerprints, and no clean way to negotiate newer algorithms. The crypto refresh was the project to drag the format into line with current practice without throwing away what worked.

From a Bolt-On Integrity Check to Real AEAD

The most important change is how messages are protected against tampering. Old OpenPGP encrypted data and wrapped it in something called the Modification Detection Code, an integrity check added in the early 2000s after researchers showed that PGP ciphertext could be altered undetected. The MDC worked, but it was a patch grafted onto a mode that was not designed to authenticate anything.

RFC 9580 adopts proper authenticated encryption with associated data (AEAD), the same class of construction that modern protocols like TLS 1.3 rely on. The standard specifies AEAD modes built on AES, including GCM and the encrypt-then-authenticate OCB and EAX constructions. Instead of encrypting and then bolting on a separate integrity check, AEAD makes confidentiality and integrity a single, analyzed operation. Tampered ciphertext fails to decrypt cleanly rather than slipping through.

Why this is the headline change

The 2018 EFAIL disclosures exploited weaknesses around how some clients handled OpenPGP integrity and MIME rendering. Moving to real AEAD removes a category of malleability at the format level, so an attacker cannot silently modify ciphertext and have it decrypt to something useful.

Version 6 Keys and the End of SHA-1 Fingerprints

The refresh introduces version 6 keys and signatures. The change that matters most here is the fingerprint. A key fingerprint is the short identifier people compare to confirm they have the right key, the value you check against a business card or a verified profile. Version 4 keys derived that fingerprint using SHA-1, a hash that has been broken for collision resistance for years.

Version 6 keys derive fingerprints with SHA-256 and rework the surrounding structure so the format no longer leans on SHA-1 for anything security-critical. Fingerprints are longer as a result, which is the cost of dropping a weak hash. This matters for the whole trust model, because if an attacker can engineer two keys with the same fingerprint, the act of verifying a fingerprint stops proving what people assume it proves.

Aspect RFC 4880 (legacy) RFC 9580 (crypto refresh)
Integrity protection MDC bolt-on (SHA-1 based) AEAD (GCM / OCB / EAX)
Key fingerprint hash SHA-1 SHA-256
Modern elliptic curves Via later extensions X25519 / Ed25519 / X448 first-class
Key derivation for passphrases Iterated-salted S2K Argon2 supported

Modern Curves and Better Passphrase Hardening

RFC 9580 brings the modern elliptic curves into the core specification as first-class citizens: X25519 and X448 for key agreement, Ed25519 and Ed448 for signatures. These were available before through extensions, but standardizing them in the base format means interoperable implementations can rely on them rather than treating them as optional add-ons.

The update also allows Argon2 for deriving the symmetric key that protects a private key with a passphrase. Argon2 is memory-hard, which means it resists the custom hardware that makes brute-forcing older derivation functions cheap. If your private key file is stolen, a strong passphrase run through Argon2 is far more expensive to crack than the same passphrase through the legacy iterated hashing.

The Part That Split the Ecosystem

Here is where it gets political. The crypto refresh did not arrive as one unanimous standard. During its development, a disagreement inside the working group led to a fork. One camp, associated largely with the GnuPG project, shipped an alternative design sometimes labeled LibrePGP, which uses a different AEAD packet format. The IETF stream produced RFC 9580. The two are not fully interoperable in their new modes.

The practical effect is that a message or key using the newest features can be readable by one family of implementations and not the other, depending on which AEAD framing was used. This is the messy reality behind the clean RFC number. The cryptography in both directions is reasonable; the fragmentation is the cost of a standards process that did not converge.

Backward compatibility was a core constraint of the refresh. A modern implementation still has to read decades of existing version 4 keys and old ciphertext, because there is no flag day for a format this widely deployed.

What This Means If You Use PGP

For everyday users, the migration is gradual and mostly handled by your tools. Modern OpenPGP libraries and clients are adding RFC 9580 support, generating version 6 keys, and using AEAD for new messages while still reading old material. You generally do not need to do anything urgent, but a few things are worth knowing:

The broader lesson is one we keep running into across protocols: long-lived formats accumulate old assumptions, and modernizing them is slow, careful, and occasionally contentious. OpenPGP carried 1990s defaults into the 2020s because changing a format that protects irreplaceable archives and signing chains is genuinely hard. The crypto refresh is the standard catching up. The same forces that made it necessary are why some communications platforms moved to newer protocols like MLS for chat while keeping PGP where its interoperability with the wider email world still earns its place.

Try Haven free for 15 days

Encrypted email and chat in one app. No credit card required.

Get Started →