OpenPGP's crypto was frozen on a 2007 standard for seventeen years. RFC 9580 ships it in GnuPG stable.

RFC 4880 was published in November 2007. For seventeen years that document was the OpenPGP standard, and for seventeen years every new deployment inherited its algorithm choices: 3DES as a MUST-implement cipher, SHA-1 as a valid signing hash, SEIPD version one with CBC mode and a bolt-on MDC integrity check because the original Symmetrically Encrypted Packet format predated any notion of authenticated encryption. Those choices were defensible in 2007. They are not defensible in 2026.

RFC 9580 published in 2024. GnuPG’s stable branch now ships the implementation. Here is what actually changed.

What RFC 9580 removes

SHA-1 for signatures. The draft-ietf-openpgp-crypto-refresh working group made this the centerpiece of the refresh. SHA-1 collision attacks have been practical since the SHAttered attack in 2017. A conforming RFC 9580 implementation will not generate SHA-1 signatures. It will still verify them for backwards compatibility, which is the correct call, but it will not produce new ones.

3DES. Gone from the required algorithm set. Cipher preference lists that include 3DES will not generate 3DES-encrypted output from a compliant implementation. If your correspondent’s key lists only 3DES, the implementation must fall back to AES-128 at minimum per the new MUST language.

ElGamal encryption keys. The old DSA/ElGamal keypair format that was OpenPGP’s primary key type before elliptic curve support landed is not generated by RFC 9580 implementations. Keys of this type can still be used to decrypt old messages, which is the right call, but they will not appear in newly generated keys.

Version 3 keys and version 4 signature packets for new operations. RFC 9580 introduces version 6 keys and version 6 signature packets. The old formats remain parseable.

What RFC 9580 adds

SEIPD v2. Symmetrically Encrypted Integrity Protected Data, version 2, uses HKDF to derive separate encryption and authentication keys from the session key, then encrypts with AES-256-GCM or ChaCha20-Poly1305. No more CBC mode with an MDC. No more timing-channel exposure from unauthenticated ciphertext. This is the change that matters most for the security of encrypted messages.

Ed448 and X448. For users who need larger margin than the 25519 curves, Ed448 and X448 are in the standard. In practice, Ed25519 and X25519 remain the sane default. The 448-bit variants are there for compliance contexts that mandate a larger security parameter.

Cleaner AEAD for symmetric-key encrypted sessions. The SKESK v6 packet uses Argon2 for password-derived keys instead of the old iterated salted S2K. That is a real improvement for passphrase-protected private keys.

What did not change

The complexity. RFC 9580 is a 150-page standards document covering key formats, packet structures, signature types, armor headers, subpacket types, and a compatibility matrix with RFC 4880 and RFC 2440 that requires careful reading. The new standard is better than the old one, but it is not simple.

OpenPGP still supports RSA-2048, RSA-3072, RSA-4096, and DSA keys in the legacy verify path. It still has a packet format that requires parsing variable-length old-format and new-format packet headers with different length encoding schemes because the 1991 specification is still in the compatibility baseline. The number of ways to express the same encrypted message has not gone down.

The Web of Trust is still dead. The SKS keyserver network was destroyed by certificate flooding in 2019. Keys.openpgp.org operates with a GDPR-compatible upload-and-verify model that does not carry UID signatures from third parties by default, which effectively ends WoT-based trust for most users. That is not RFC 9580’s problem to solve and it did not try to solve it.

The fundamental problem with OpenPGP encrypted email is not the algorithm suite. It is that SMTP infrastructure, mailing list exploder behavior, server-side search, spam filters, and the operational expectation that your employer can read your email on their systems are all hostile to end-to-end encryption. Phil Zimmermann shipped PGP 1.0 in 1991. Thirty-five years of the killer app not arriving is a signal about the use case, not the crypto.

For the use case that still matters: file encryption

If you want to encrypt a file and hand it to someone, use age. It does not implement OpenPGP. It has a key format expressible in one line, an encrypt/decrypt API that is hard to use wrong, and a specification short enough to audit in an afternoon. The Rust implementation (rage) exists if you want static linking. Use it.

GnuPG is for interoperability with the OpenPGP ecosystem specifically. Package signatures, Debian keyring verification, sending encrypted mail to someone who already has a public key on a keyserver. For those things, you need GnuPG. For everything else, simpler tools have been better for years.

Rotating old keys

If you are running GnuPG with a DSA primary key, or an RSA-2048 key from 2012, or a DSA/ElGamal keypair from before elliptic curve support existed, now is the time to rotate. The --quick-generate-key path in current GnuPG generates Ed25519 primary and X25519 encryption subkeys with SHA-512 digests and SEIPD v2 encrypted sessions by default.

Keep the old key for decryption of old messages. The passphrase and secret key material do not go away. But stop using it as the signing key and stop publishing it as the preferred encryption target.

The crypto in the OpenPGP ecosystem is finally better than it was in 2007. The SHA-1 removal from OpenSSH last week and this RFC 9580 deployment are part of the same long cleanup: getting SHA-1 out of authentication and signing infrastructure before more of it ends up in incident reports. The certificate lifetime compression happening in TLS is a different forcing function pushing the same direction. None of these are fast. All of them are happening.

Generate the new key. Upload it. Send the revocation certificate for the old one. It takes twenty minutes and you have been putting it off since 2019.