Kurz gesagt. Die IETF hat OpenPGP in RFC 9580 (Juli 2024) überarbeitet: v6-Schlüssel mit SHA-256-Fingerabdrücken, Ed25519 und X25519 als verpflichtende Algorithmen, Signaturen mit Salt, Argon2 und authentifizierte Verschlüsselung. Post-Quanten-Algorithmen folgten in RFC 9980 (2026), überwiegend für v6-Schlüssel. GnuPG hat RFC 9580 nicht übernommen; es folgt LibrePGP, seiner eigenen Fortführung mit v5-Schlüsseln und einer eigenen Kyber-Verschlüsselung, und unterstützt RFC 9980 nur zum Teil und nur mit --allow-9980. Sequoia implementiert RFC 9580 und RFC 9980, erzeugt standardmäßig aber weiterhin v4-Schlüssel. In der Praxis heißt das: Für Schlüssel, die andere mit der Software prüfen müssen, die sie gerade haben (Git-Hoster, Paketmanager, Release-Seiten), nimm heute einen v4-Schlüssel mit Ed25519/Cv25519; er funktioniert überall, wo wir getestet haben. Setze v6- oder Post-Quanten-Schlüssel nur in Ökosystemen ein, in denen jeder Verifizierer Sequoia oder eine andere Implementierung von RFC 9580 verwendet.
Die Testumgebung lief in debian:forky-20261005-slim mit den Debian-Paketen sq 1.4.1 (sequoia-openpgp 2.4.1, Nettle-Backend) und gnupg 2.4.9, dazu GnuPG 2.5.24, das wir im selben Image aus dem Release-Tarball kompiliert haben, nachdem gpg --verify eine gültige Signatur von „Werner Koch (dist signing 2020)“ gemeldet hatte. Alle Schlüssel wurden für diesen Artikel erzeugt.
Zwei Standards seit 2023
Die vorherige Spezifikation von OpenPGP, RFC 4880, stammt aus dem Jahr 2007. An ihrer Überarbeitung hat sich die Community gespalten. Die IETF-Arbeitsgruppe erarbeitete den Text, aus dem RFC 9580 wurde. Die Entwickler von GnuPG waren mit Teilen davon nicht einverstanden und führten den früheren Entwurf als LibrePGP fort (draft-koch-librepgp, ein individueller Internet-Draft von Werner Koch und Ronald Henry Tse, Revision 06 vom September 2026). LibrePGP verwendet Schlüssel der Version 5 und einen anderen Modus für authentifizierte Verschlüsselung. Bei den neuen Schlüssel- und Nachrichtenformaten sind beide inkompatibel, bei den alten kompatibel: Alle lesen und schreiben weiterhin v4-Schlüssel und v4-Signaturen.
RFC 9580 äußert sich zum alten Format unmissverständlich: „OpenPGP-Implementierungen SOLLTEN Schlüssel im Format der Version 6 erzeugen. Schlüssel der Version 4 sind veraltet; eine Implementierung SOLLTE KEINEN Schlüssel der Version 4 erzeugen, SOLLTE ihn aber akzeptieren“ (§5.5.2). Der RFC definiert die Versionen 2, 3, 4 und 6 des Schlüsselpakets; Version 5 gibt es nur in LibrePGP. Die weiteren Änderungen:
- Ed25519 (Algorithmus 27) und X25519 (25) müssen implementiert werden; für RSA gilt: „Schlüssel sind veraltet und SOLLTEN NICHT erzeugt werden, dürfen aber interpretiert werden“, DSA und ElGamal dürfen nicht erzeugt werden (§9.1).
- Der v6-Fingerabdruck ist „der 256-Bit-Hash SHA2-256“ des Schlüssels (§5.5.4.3), der v4-Fingerabdruck ein 160-Bit-Hash mit SHA-1.
- Signaturen der Version 6 enthalten ein zufälliges Salt, sodass sich der signierte Hash nicht vorab bestimmen lässt.
- Verschlüsselte Daten verwenden SEIPD in Version 2 mit AEAD (OCB verpflichtend), und Passphrasen können Argon2 nutzen.
Sequoia: v6-Schlüssel auf Wunsch
sq key generate erzeugt standardmäßig einen v4-Schlüssel. Der Hilfetext nennt den Grund: „Derzeit ist die Voreinstellung RFC4880. Sobald die Unterstützung für RFC9580 jedoch weiter ausgerollt ist, ändert sich die Voreinstellung in einer künftigen Version von sq.“ Mit --profile rfc9580 entsteht ein v6-Schlüssel:
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
### 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
Der Unterschied zeigt sich an den Fingerabdrücken: 40 Hexadezimalziffern (SHA-1) bei v4, 64 (SHA-256) bei v6. Der v4-Schlüssel verwendet die ältere Algorithmuskennung EdDSA (22, „EdDSALegacy“ in RFC 9580), der v6-Schlüssel die neuen, eigens dafür vorgesehenen Kennungen Ed25519 (27) und X25519 (25). Eine abgetrennte Signatur, die mit dem v6-Schlüssel erstellt wurde, zeigt das Salt:
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-Quanten-Schlüssel sind in der Bibliothek vorhanden: sequoia-openpgp 2.4.0 „ergänzt die Unterstützung für Post-Quanten-Kryptografie nach RFC 9980“, und sq führt die Cipher Suites mldsa65-ed25519 und mldsa87-ed448 auf. Der PQC-Code steckt aber nur in den Backends für OpenSSL und RustCrypto, und Debian baut Sequoia mit Nettle:
Error: Unsupported public key algorithm: ML-DSA-65+Ed25519
Welches kryptografische Backend deine Distribution gewählt hat, entscheidet, ob du überhaupt OpenPGP mit Post-Quanten-Verfahren hast; sq version gibt es aus.
GnuPG: LibrePGP, Kyber und der Wechsel von 2.4 auf 2.5
GnuPG 2.5 wurde am 30. Dezember 2025 zur stabilen Serie, als GnuPG ankündigte, dass „die Oldstable-Serie 2.4 in nur 6 Monaten ihr Supportende erreicht“ (gnupg.org); das aktuelle Release ist 2.5.24 (23. September 2026). Distributionen ziehen langsam nach: Der Testing-Zweig von Debian liefert noch 2.4.9 aus. Der Standardschlüssel von 2.4.9 ist ein v4-Schlüssel mit Ed25519 und einem Cv25519-Unterschlüssel:
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 hat mit 2.5 Post-Quanten-Verschlüsselung eingeführt: ein Composite-Verfahren aus ML-KEM (Kyber) und einer klassischen Kurve im LibrePGP-Format. Die Post-Quanten-Arbeit von GnuPG betrifft bisher die Verschlüsselung; die Versionshinweise nennen keine Post-Quanten-Signaturschlüssel. Die Dokumentation beschreibt die Unterstützung für RFC 9980, die mit 2.5.23 hinzukam und nur mit --allow-9980 aktiv ist, mit ungewöhnlicher Offenheit: „Wegen der aufgeblähten Spezifikation wird die Verwendung dieser Option nicht empfohlen. Der Standardmodus von GnuPG orientiert sich stärker am klassischen PGP und damit an der LibrePGP-Spezifikation, die ebenfalls PQC unterstützt, aber auf schlankere Weise und im Stil von PGP.“
Interoperabilität im Test
Wir haben jeden Schlüssel zwischen den drei Implementierungen ausgetauscht. Zuerst liest GnuPG 2.4.9 die Schlüssel und Signaturen von Sequoia:
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
Dann die Post-Quanten-Schlüssel von GnuPG 2.5.24, gelesen von GnuPG 2.4.9 und von sq 1.4.1:
### 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
Was das zeigt:
- v4-Schlüssel und -Signaturen funktionieren überall. Der Standardschlüssel von sq und seine Signaturen ließen sich in GnuPG 2.4.9 prüfen.
- v6-Schlüssel scheitern an GnuPG 2.4, mit
packet(6) with unknown version 6. Wer deinen v6-Schlüssel in einen Schlüsselbund von 2.4 importiert, erhält nichts; eine v6-Signatur ergibt „no signature found“. - Der PQC-Standardschlüssel von GnuPG ist reines LibrePGP.
pqcerzeugte einen Primärschlüssel mit brainpoolP384r1 und einem Unterschlüssel aus Kyber-768 und brainpoolP256r1 (Algorithmus 8) in einem v5-Paket. GnuPG 2.4.9 importiert ihn, führt den Unterschlüssel aber alsunknown_8auf und kann deshalb nicht für ihn verschlüsseln; Sequoia weist das v5-Paket zurück. - Selbst der „9980-Modus“ ergab nichts, was Sequoia lesen kann. Mit
--allow-9980erzeugte GnuPG 2.5.24 einen v6-Primärschlüssel, schrieb dessen ML-KEM-Unterschlüssel, daruntermlk768(Algorithmus 35, ML-KEM-768+X25519 aus RFC 9980), aber als Pakete der Version 5, die RFC 9580 nicht definiert und die Sequoia ablehnt. Die Voreinstellungpqc9980wählt außerdem Algorithmus 39, ML-KEM-768 mit brainpoolP384r1, der nicht zu den Algorithmen von RFC 9980 selbst gehört. Stand GnuPG 2.5.24 finden ein Schlüssel nach RFC 9980 aus GnuPG und eine Implementierung von RFC 9980 nicht zueinander.
Verschlüsselung und Entschlüsselung innerhalb von GnuPG 2.5 funktionierten mit all diesen Schlüsseln; das Problem besteht nur zwischen den Implementierungen.
OpenPGP mit Post-Quanten-Verfahren: was RFC 9980 definiert
RFC 9980 (Proposed Standard, 2026) ergänzt Composite- und eigenständige Algorithmen:
| ID | Algorithmus | Anforderung | Schlüssel |
|---|---|---|---|
| 30 | ML-DSA-65+Ed25519 | MUSS | v6 |
| 31 | ML-DSA-87+Ed448 | SOLLTE | v6 |
| 32–34 | SLH-DSA-SHAKE-128s, 128f, 256s | KANN | v6 |
| 35 | ML-KEM-768+X25519 | MUSS | v4 oder v6 |
| 36 | ML-KEM-1024+X448 | SOLLTE | v6 |
Composite bedeutet, dass beide Teile erfolgreich sein müssen: Ein Angreifer muss ML-KEM und X25519 brechen oder ML-DSA und Ed25519. Die Verschlüsselung ist die dringliche Hälfte, denn verschlüsselte Nachrichten lassen sich jetzt speichern und später entschlüsseln (harvest now, decrypt later). Signaturen können warten, bis die Verifizierer sie unterstützen, und langlebige Signaturen lassen sich später neu erstellen. Weil ID 35 auch für v4-Unterschlüssel zulässig ist, kann ein vorhandener v4-Schlüssel einen Post-Quanten-Unterschlüssel zur Verschlüsselung erhalten, ohne dass sein Primärschlüssel ersetzt werden muss.
Empfehlungen für die Praxis
- Signaturschlüssel für Releases, Git-Commits und Pakete: v4 mit Ed25519, erzeugt mit GnuPG 2.4/2.5 (
default) oder sq (Standardprofil). Jeder Verifizierer, den wir getestet haben, akzeptiert sie. APT in Debian prüft Archivsignaturen inzwischen standardmäßig mitsqvvon Sequoia (APT 3.0, Debian 13) und weist seit dem 1. Februar 2026 an SHA-1 gebundene Signaturen und v3-Signaturen zurück; signiere also alles Alte neu (LWN zu APT 3.0). - Veröffentliche keine v6-Schlüssel für Empfänger, deren Software du nicht bestimmst, solange ihre Tools nicht auf Sequoia, OpenPGP.js 6 (das RFC 9580 implementiert) oder einer anderen Implementierung von RFC 9580 laufen; wer GnuPG 2.4 nutzt, kann sie nicht importieren.
- Verschlüsselung mit Post-Quanten-Schutz funktioniert heute nur innerhalb eines Dialekts: von GnuPG zu GnuPG mit Kyber nach LibrePGP oder mit Sequoia und einem OpenSSL- oder RustCrypto-Backend für RFC 9980. Entscheide danach, wer entschlüsselt.
- Prüfe dein Backend und deine Versionen (
gpg --version,sq version); die Pakete der Distributionen hinken den Upstream-Versionen ein Jahr oder mehr hinterher. - Nimm einfachere Tools, wo du die Flexibilität von OpenPGP nicht brauchst: SSH-Signaturen für Git-Commits, Sigstore für die Provenance von Releases, age für die Verschlüsselung von Dateien. Die Vergleiche SSH vs. GPG beim Signieren von Commits, Sigstore vs. GPG und age vs. GPG wägen die Vor- und Nachteile ab; ssh-keygen im Jahr 2026 behandelt die SSH-Seite.
- Veröffentliche den vollständigen Fingerabdruck dort, wo andere ihn prüfen können (deine Website, die Versionshinweise), und verteile den Schlüssel über WKD oder keys.openpgp.org. Ein Schlüsselserver liefert Schlüssel aus; er bürgt nicht für sie.
So prüfst du einen Download richtig
F-Droid veröffentlicht neben seinem APK eine abgetrennte Signatur und auf seiner Website den Fingerabdruck seines Signaturschlüssels. Die Prüfung braucht drei Befehle:
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
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
Die Zeile „WARNING: This key is not certified“ ist normal: Das Web of Trust von GnuPG kennt keinen Pfad zu diesem Schlüssel. Aussagekräftig wird die Prüfung durch zwei Dinge: Du vergleichst den Fingerabdruck des Primärschlüssels mit dem auf der Seite von F-Droid zur Prüfung von Downloads (identisch), und du verlangst beim Abrufen des Schlüssels den vollständigen Fingerabdruck, denn der Schlüsselserver gibt alles heraus, was passt. Die Signatur selbst ist eine v4-RSA-Signatur (Algorithmus 1) über SHA-512 (Digest-Algorithmus 10): altes Format, zeitgemäßer Hash, von jeder Implementierung lesbar. Fehlt der Schlüssel, erhältst du Can't check signature: No public key; wurde die Datei verändert, BAD signature.
Quellen
- RFC 9580: OpenPGP (Juli 2024): §5.5.2 (Schlüsselversionen), §5.5.4 (Fingerabdrücke), §9.1 (Algorithmen), Tabelle 27
- RFC 9980: Post-Quanten-Kryptografie in OpenPGP (2026) und sein Eintrag im IETF Datatracker
- GnuPG: Neuigkeiten, Datei NEWS (2.5.0 Kyber, 2.5.23
--allow-9980),doc/gpg.texiim Release 2.5.24 - Sequoia: NEWS von sequoia-openpgp (2.0.0 RFC 9580, 2.4.0 RFC 9980),
sq key generate --help(1.4.1) - LWN: Neuerungen in APT 3.0; F-Droid: Heruntergeladene APKs prüfen