Skip to content
ecdsa.com
← All articles

OpenPGP in 2026: RFC 9580, v6 keys and the GnuPG split

OpenPGP has two diverging dialects and a new post-quantum standard. We generated v4, v6 and post-quantum keys with Sequoia sq 1.4.1, GnuPG 2.4.9 and GnuPG 2.5.24 built from its signed source, and fed each one to the others. The results decide what you can safely publish.

Short answer. The IETF revised OpenPGP in RFC 9580 (July 2024): v6 keys with SHA-256 fingerprints, Ed25519 and X25519 as mandatory algorithms, salted signatures, Argon2 and authenticated encryption. Post-quantum algorithms followed in RFC 9980 (2026), mostly for v6 keys. GnuPG did not adopt RFC 9580; it follows LibrePGP, its own continuation with v5 keys and its own Kyber encryption, and supports only part of RFC 9980, behind --allow-9980. Sequoia implements RFC 9580 and RFC 9980 but still creates v4 keys by default. In practice: for keys that others must verify with whatever they have (Git hosts, package managers, release pages), use a v4 Ed25519/Cv25519 key today; it works everywhere we tested. Use v6 or post-quantum keys only inside ecosystems where every verifier runs Sequoia or another RFC 9580 implementation.

The lab ran in debian:forky-20261005-slim with the Debian packages sq 1.4.1 (sequoia-openpgp 2.4.1, Nettle backend) and gnupg 2.4.9, plus GnuPG 2.5.24 compiled in the same image from the release tarball after gpg --verify reported a good signature from "Werner Koch (dist signing 2020)". All keys were generated for this article.

Two standards since 2023

OpenPGP's previous specification, RFC 4880, dates from 2007. Its revision split the community. The IETF working group produced what became RFC 9580; GnuPG's developers, disagreeing with parts of it, continued the earlier draft as LibrePGP (draft-koch-librepgp, an individual Internet-Draft by Werner Koch and Ronald Henry Tse, revision 06 of September 2026), with version 5 keys and a different authenticated encryption mode. The two are incompatible for new key and message formats and compatible for the old ones: everyone still reads and writes v4 keys and v4 signatures.

RFC 9580 is direct about the old format: "OpenPGP implementations SHOULD create keys with version 6 format. Version 4 keys are deprecated; an implementation SHOULD NOT generate a version 4 key but SHOULD accept it" (§5.5.2). It defines key packet versions 2, 3, 4 and 6; version 5 exists only in LibrePGP. Its other changes:

  • Ed25519 (algorithm 27) and X25519 (25) are mandatory to implement; RSA "keys are deprecated and SHOULD NOT be generated but may be interpreted", DSA and ElGamal must not be generated (§9.1).
  • v6 fingerprints are "the 256-bit SHA2-256 hash" of the key (§5.5.4.3); v4 fingerprints are 160-bit SHA-1.
  • v6 signatures carry a random salt, so the signed hash cannot be predicted in advance.
  • Encrypted data uses SEIPD version 2 with AEAD (OCB mandatory), and passphrases can use Argon2.

Sequoia: v6 keys on request

sq key generate creates a v4 key by default. Its help text says why: "Currently, the default is RFC4880. However, once support for RFC9580 is rolled out further, the default will change in a future version of sq." With --profile rfc9580 it creates a v6 key:

Two keys with sq 1.4.1: the default profile and RFC 9580
sq key generate --own-key --without-password --name "Alice" --email alice@example.org --output alice-v4.pgp --rev-cert alice-v4.rev
sq key generate --own-key --without-password --profile rfc9580 --name "Alice" --email alice@example.org --output alice-v6.pgp --rev-cert alice-v6.rev
sq inspect alice-v4.pgp
sq inspect alice-v6.pgp
sq packet dump alice-v6.pgp
Output (filtered)
### default profile (RFC 4880)
      Fingerprint: D3AE271931915949BEC2B3EBE329E5163B93B0F5
  Public-key algo: EdDSA
           Subkey: 0C7A47DD70202F80B0FA90B4E5C2206CA540055E
  Public-key algo: EdDSA
           Subkey: 8E35A51EC584304842AD4D13528B152570EC6FAC
  Public-key algo: EdDSA
### --profile rfc9580
      Fingerprint: 01117FE27C0ACB8EEBCE0D6FE03730724C57DA9E25D0963276EAB7A9F7EE2FB3
  Public-key algo: Ed25519
           Subkey: 23542B454F5CEDE06B81D42A874CFCF5CAB1E1D59E905CF0FC11AC21DE44A9F0
  Public-key algo: X25519
Secret-Key Packet, new CTB, 75 bytes
    Version: 6
    Pk algo: Ed25519

The difference is visible in the fingerprints: 40 hex digits (SHA-1) for v4, 64 (SHA-256) for v6. The v4 key uses the older EdDSA algorithm identifier (22, "EdDSALegacy" in RFC 9580), the v6 key the new dedicated Ed25519 (27) and X25519 (25). A detached signature made with the v6 key shows the salt:

sq sign, then sq packet dump of the signature and sq verify
Signature Packet, new CTB, 152 bytes
    Version: 6
    Pk algo: Ed25519
    Hash algo: SHA512
      Issuer Fingerprint: A3B490FC8C54F12C1E4955E520071CDC4ECA7F76BC87729C2F7BA5305EAC6FC7
    Salt: 62A29ACDACACD8ACF2D7ECDAAF3A10A6F577EDA3338E349D537190C437875B0F
Authenticated signature made by 01117FE27C0ACB8EEBCE0D6FE03730724C57DA9E25D0963276EAB7A9F7EE2FB3 (Alice)
1 authenticated signature.

Post-quantum keys are in the library: sequoia-openpgp 2.4.0 "adds support for post-quantum cryptography as defined in RFC 9980", and sq lists mldsa65-ed25519 and mldsa87-ed448 cipher suites. But the PQC code exists only in the OpenSSL and RustCrypto backends, and Debian builds Sequoia with Nettle:

sq key generate --profile rfc9580 --cipher-suite mldsa65-ed25519 (Debian sq 1.4.1)
  Error: Unsupported public key algorithm: ML-DSA-65+Ed25519

Which cryptographic backend your distribution chose decides whether you have post-quantum OpenPGP at all; sq version prints it.

GnuPG: LibrePGP, Kyber and the 2.4 to 2.5 transition

GnuPG 2.5 became the stable series on 30 December 2025, when GnuPG announced that "the oldstable 2.4 series will reach end-of-life in just 6 months" (gnupg.org); the current release is 2.5.24 (23 September 2026). Distributions move slowly: Debian's testing branch still ships 2.4.9. Its default key is a v4 Ed25519 key with a Cv25519 subkey:

gpg 2.4.9 --quick-gen-key 'Bob <bob@example.org>' default default 1y, then --list-packets
pub   ed25519 2026-10-22 [SC] [expires: 2027-10-22]
sub   cv25519 2026-10-22 [E]
	version 4, algo 22, created 1792651599, expires 0
	version 4, algo 18, created 1792651599, expires 0

GnuPG added post-quantum encryption in 2.5: a composite of ML-KEM (Kyber) and a classical curve, in the LibrePGP format. Its post-quantum work so far covers encryption; the release notes list no post-quantum signature keys. Its documentation describes RFC 9980 support, added in 2.5.23 behind --allow-9980, with unusual frankness: "Due the bloated specification the use of this option is not suggested. The standard GnuPG mode is more oriented at the classic PGP and thus LibrePGP specification which also provide PQC support but in a more lean and PGP-style way."

Interoperability, tested

We exchanged every key between the three implementations. First, GnuPG 2.4.9 reading Sequoia's keys and signatures:

gpg 2.4.9 --import and --verify of sq's v4 and v6 keys
gpg: key E329E5163B93B0F5: public key "Alice" imported
gpg:               imported: 1
gpg: packet(6) with unknown version 6
gpg: read_block: read error: Invalid packet
--- gpg --verify of a v4 signature made by sq
gpg:                using EDDSA key 0C7A47DD70202F80B0FA90B4E5C2206CA540055E
gpg: Good signature from "Alice" [unknown]
--- gpg --verify of the v6 signature
gpg: packet(2) with unknown version 6
gpg: no signature found

Then GnuPG 2.5.24's post-quantum keys, read by GnuPG 2.4.9 and by sq 1.4.1:

Three post-quantum keys from gpg 2.5.24 (algorithm and packet version from --list-packets)
### gpg --quick-gen-key ... pqc
pub   brainpoolP384r1 2026-10-22 [SC] [expires: 2027-10-22]
sub   ky768_bp256 2026-10-22 [E]
version 4, algo 19, created 1792651785, expires 0
version 5, algo 8, created 1792651785, expires 0, pkbytes 1265
  gpg 2.4.9 --import, then --list-keys:
    gpg:               imported: 1
    pub   brainpoolP384r1 2026-10-22 [SC] [expires: 2027-10-22]
    sub   unknown_8 2026-10-22 [E]
  sq 1.4.1 inspect:
    Public-key algo: ECDSA
    Unknown component: ... tag: PublicSubkey, error: Malformed packet: unknown version ...
### gpg --allow-9980 --quick-gen-key ... pqc9980
pub   ietf27 2026-10-22 [SC] [expires: 2027-10-22]
sub   mlk768_bp384 2026-10-22 [E]
version 6, algo 27, created 1792651785, expires 0, pkbytes 32
version 5, algo 39, created 1792651785, expires 0, pkbytes 1281
  gpg 2.4.9 --import, then --list-keys:
    gpg: packet(6) with unknown version 6
    gpg: import from 'frank.pgp' failed: Invalid keyring
  sq 1.4.1 inspect:
    Public-key algo: Ed25519
    Unknown component: ... tag: PublicSubkey, error: Malformed packet: unknown version ...
### gpg --allow-9980: v6 Ed25519 primary + mlk768 and mlk768_bp384 subkeys
version 6, algo 27, created 1792651848, expires 0, pkbytes 32
version 5, algo 35, created 1792651848, expires 0, pkbytes 1216
version 5, algo 39, created 1792651848, expires 0, pkbytes 1281

What this shows:

  • v4 keys and signatures work everywhere. sq's default key and its signatures verified in GnuPG 2.4.9.
  • v6 keys stop at GnuPG 2.4, with packet(6) with unknown version 6. Anyone who imports your v6 key into a 2.4 keyring gets nothing; a v6 signature is "no signature found".
  • GnuPG's default PQC key is LibrePGP-only. pqc created a brainpoolP384r1 primary key with a Kyber-768 plus brainpoolP256r1 subkey (algorithm 8) in a v5 packet. GnuPG 2.4.9 imports it but lists the subkey as unknown_8, so it cannot encrypt to it; Sequoia rejects the v5 packet.
  • Even "9980 mode" did not produce something Sequoia reads. With --allow-9980, GnuPG 2.5.24 created a v6 primary key, but wrote its ML-KEM subkeys, including mlk768 (algorithm 35, ML-KEM-768+X25519 from RFC 9980), as version 5 packets, which RFC 9580 does not define and Sequoia refuses. The pqc9980 default also picks algorithm 39, ML-KEM-768 with brainpoolP384r1, which is not among RFC 9980's own algorithms. As of GnuPG 2.5.24, an RFC 9980 key from GnuPG and an RFC 9980 implementation do not meet.

Encryption and decryption inside GnuPG 2.5 worked with all of these keys; the problem is only between implementations.

Post-quantum OpenPGP: what RFC 9980 defines

RFC 9980 (Proposed Standard, 2026) adds composite and standalone algorithms:

IDAlgorithmRequirementKeys
30ML-DSA-65+Ed25519MUSTv6
31ML-DSA-87+Ed448SHOULDv6
32–34SLH-DSA-SHAKE-128s, 128f, 256sMAYv6
35ML-KEM-768+X25519MUSTv4 or v6
36ML-KEM-1024+X448SHOULDv6

Composite means both parts must succeed: an attacker has to break ML-KEM and X25519, or ML-DSA and Ed25519. Encryption is the urgent half, because encrypted messages can be stored now and decrypted later (harvest now, decrypt later). Signatures can wait until verifiers support them, and long-lived signatures can be re-made later. Because ID 35 is also allowed on v4 subkeys, an existing v4 key can add a post-quantum encryption subkey without replacing its primary key.

Practical recommendations

  1. Signing keys for releases, Git commits and packages: v4 Ed25519, created by GnuPG 2.4/2.5 (default) or sq (default profile). Every verifier we tested accepts them. Debian's APT now verifies archive signatures with Sequoia's sqv by default (APT 3.0, Debian 13), and as of 1 February 2026 rejects SHA-1-bound and v3 signatures, so re-sign anything old (LWN on APT 3.0).
  2. Do not publish v6 keys to audiences you do not control until their tools are on Sequoia, OpenPGP.js 6 (which implements RFC 9580) or another RFC 9580 implementation; GnuPG 2.4 users cannot import them.
  3. Encryption with post-quantum protection works today only within one dialect: GnuPG-to-GnuPG with LibrePGP Kyber, or Sequoia with an OpenSSL or RustCrypto backend for RFC 9980. Decide by who decrypts.
  4. Check your backend and versions (gpg --version, sq version); distribution packages lag upstream by a year or more.
  5. Prefer simpler tools where OpenPGP's flexibility is not needed: SSH signatures for Git commits, Sigstore for release provenance, age for file encryption. The comparisons SSH vs GPG commit signing, Sigstore vs GPG and age vs GPG cover the trade-offs; ssh-keygen in 2026 covers the SSH side.
  6. Publish the full fingerprint where people can check it (your website, release notes), and distribute the key through WKD or keys.openpgp.org. A keyserver delivers keys; it does not vouch for them.

Verifying a download, the way it should be done

F-Droid publishes a detached signature next to its APK and the fingerprint of its signing key on its website. The verification takes three commands:

Verify F-Droid.apk with its .asc (GnuPG 2.4.9)
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 37D2C98789D8311948394E3E41E7044E1DBA2E89
gpg --verify F-Droid.apk.asc F-Droid.apk
gpg --list-packets F-Droid.apk.asc
Output (filtered)
gpg: key 41E7044E1DBA2E89: public key "F-Droid <admin@f-droid.org>" imported
gpg: Signature made Mon Oct 12 12:58:48 2026 UTC
gpg:                using RSA key 802A9799016112346E1FEFF47A029E54DD5DCE7A
gpg: Good signature from "F-Droid <admin@f-droid.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
Primary key fingerprint: 37D2 C987 89D8 3119 4839  4E3E 41E7 044E 1DBA 2E89
     Subkey fingerprint: 802A 9799 0161 1234 6E1F  EFF4 7A02 9E54 DD5D CE7A
:signature packet: algo 1, keyid 7A029E54DD5DCE7A
	version 4, created 1791809928, md5len 0, sigclass 0x00
	digest algo 10, begin of digest 4b be

The "WARNING: This key is not certified" line is normal: GnuPG's web of trust has no path to this key. What makes the check meaningful is comparing the primary key fingerprint with the one on F-Droid's verification page (identical), and requiring the full fingerprint when fetching the key, since the keyserver hands out whatever matches. The signature itself is a v4 RSA signature (algorithm 1) over SHA-512 (digest algorithm 10): old format, current hash, readable by every implementation. If the key is missing you get Can't check signature: No public key; if the file changed, BAD signature.

Sources