Aller au contenu
ecdsa.com
← Tous les articles

OpenPGP en 2026 : RFC 9580, clés v6 et scission de GnuPG

OpenPGP compte deux dialectes divergents et un nouveau standard post-quantique. Nous avons généré des clés v4, v6 et post-quantiques avec Sequoia sq 1.4.1, GnuPG 2.4.9 et GnuPG 2.5.24, compilé à partir de ses sources signées, puis soumis chacune d’elles aux autres implémentations. Les résultats déterminent ce que vous pouvez publier sans risque.

En bref. L’IETF a révisé OpenPGP dans la RFC 9580 (juillet 2024) : clés v6 avec empreintes SHA-256, Ed25519 et X25519 comme algorithmes obligatoires, signatures salées, Argon2 et chiffrement authentifié. Les algorithmes post-quantiques ont suivi dans la RFC 9980 (2026), surtout pour les clés v6. GnuPG n’a pas adopté la RFC 9580 ; il suit LibrePGP, sa propre continuation, avec des clés v5 et son propre chiffrement Kyber, et ne prend en charge qu’une partie de la RFC 9980, uniquement avec l’option --allow-9980. Sequoia implémente la RFC 9580 et la RFC 9980, mais crée toujours des clés v4 par défaut. En pratique, pour les clés que d’autres doivent vérifier avec les outils dont ils disposent (hébergeurs Git, gestionnaires de paquets, pages de publication des versions), utilisez aujourd’hui une clé v4 Ed25519/Cv25519 : elle fonctionne partout où nous avons testé. N’utilisez des clés v6 ou post-quantiques qu’au sein d’écosystèmes où chaque vérificateur utilise Sequoia ou une autre implémentation de la RFC 9580.

Nos essais ont tourné dans debian:forky-20261005-slim avec les paquets Debian sq 1.4.1 (sequoia-openpgp 2.4.1, backend Nettle) et gnupg 2.4.9, ainsi qu’avec GnuPG 2.5.24, compilé dans la même image à partir de l’archive tar de la version, après que gpg --verify a signalé une signature valide de « Werner Koch (dist signing 2020) ». Toutes les clés ont été générées pour cet article.

Deux standards depuis 2023

La spécification précédente d’OpenPGP, la RFC 4880, date de 2007. Sa révision a divisé la communauté. Le groupe de travail de l’IETF a produit ce qui est devenu la RFC 9580 ; les développeurs de GnuPG, en désaccord avec une partie du texte, ont poursuivi le projet antérieur sous le nom de LibrePGP (draft-koch-librepgp, un Internet-Draft individuel de Werner Koch et Ronald Henry Tse, révision 06 de septembre 2026), avec des clés de version 5 et un mode de chiffrement authentifié différent. Les deux sont incompatibles pour les nouveaux formats de clé et de message, et compatibles pour les anciens : tout le monde lit et écrit encore des clés v4 et des signatures v4.

La RFC 9580 est sans détour sur l’ancien format : « Les implémentations OpenPGP devraient (SHOULD) créer des clés au format version 6. Les clés version 4 sont obsolètes ; une implémentation ne devrait pas (SHOULD NOT) générer de clé version 4, mais devrait (SHOULD) l’accepter » (§5.5.2). Elle définit les versions 2, 3, 4 et 6 du paquet de clé ; la version 5 n’existe que dans LibrePGP. Ses autres changements :

  • Ed25519 (algorithme 27) et X25519 (25) sont obligatoires à implémenter ; les clés RSA « sont obsolètes et ne devraient pas (SHOULD NOT) être générées, mais peuvent être interprétées », et les clés DSA et ElGamal ne doivent pas être générées (§9.1).
  • Les empreintes v6 sont « le condensat SHA2-256 de 256 bits » de la clé (§5.5.4.3) ; les empreintes v4 sont des condensats SHA-1 de 160 bits.
  • Les signatures v6 contiennent un sel aléatoire, si bien que le condensat signé ne peut pas être prédit à l’avance.
  • Les données chiffrées utilisent SEIPD version 2 avec AEAD (OCB obligatoire), et les phrases de passe peuvent recourir à Argon2.

Sequoia : des clés v6 sur demande

sq key generate crée une clé v4 par défaut. Son texte d’aide explique pourquoi : « Actuellement, la valeur par défaut est RFC4880. Cependant, une fois que la prise en charge de RFC9580 sera plus largement déployée, la valeur par défaut changera dans une future version de sq. » Avec --profile rfc9580, il crée une clé v6 :

Deux clés avec sq 1.4.1 : le profil par défaut et 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
Sortie (filtrée)
### 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

La différence se voit dans les empreintes : 40 chiffres hexadécimaux (SHA-1) pour la v4, 64 (SHA-256) pour la v6. La clé v4 utilise l’ancien identifiant d’algorithme EdDSA (22, « EdDSALegacy » dans la RFC 9580), la clé v6 les nouveaux identifiants dédiés Ed25519 (27) et X25519 (25). Une signature détachée faite avec la clé v6 laisse voir le sel :

sq sign, puis sq packet dump de la signature et 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.

Les clés post-quantiques sont présentes dans la bibliothèque : sequoia-openpgp 2.4.0 « ajoute la prise en charge de la cryptographie post-quantique telle que définie dans la RFC 9980 », et sq propose les suites cryptographiques mldsa65-ed25519 et mldsa87-ed448. Mais le code PQC n’existe que dans les backends OpenSSL et RustCrypto, et Debian compile Sequoia avec Nettle :

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

Le backend cryptographique retenu par votre distribution décide si vous disposez ou non d’OpenPGP post-quantique ; sq version l’affiche.

GnuPG : LibrePGP, Kyber et le passage de la 2.4 à la 2.5

GnuPG 2.5 est devenu la série stable le 30 décembre 2025, quand GnuPG a annoncé que « la série oldstable 2.4 arrivera en fin de vie dans 6 mois seulement » (gnupg.org) ; la version actuelle est la 2.5.24 (23 septembre 2026). Les distributions suivent lentement : la branche testing de Debian fournit encore la 2.4.9. La clé par défaut de cette version est une clé v4 Ed25519 avec une sous-clé Cv25519 :

gpg 2.4.9 --quick-gen-key 'Bob <bob@example.org>' default default 1y, puis --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 a ajouté le chiffrement post-quantique dans la 2.5 : un composite de ML-KEM (Kyber) et d’une courbe classique, au format LibrePGP. Ses travaux post-quantiques couvrent pour l’instant le chiffrement ; les notes de version ne mentionnent aucune clé de signature post-quantique. Sa documentation décrit la prise en charge de la RFC 9980, ajoutée dans la 2.5.23 et activée par l’option --allow-9980, avec une franchise inhabituelle : « En raison de la spécification boursouflée, l’utilisation de cette option n’est pas conseillée. Le mode GnuPG standard est davantage orienté vers la spécification PGP classique, et donc LibrePGP, qui fournit aussi la prise en charge de la PQC, mais d’une manière plus légère et dans le style de PGP. »

L’interopérabilité à l’essai

Nous avons échangé chaque clé entre les trois implémentations. D’abord, GnuPG 2.4.9 face aux clés et aux signatures de Sequoia :

gpg 2.4.9 --import et --verify des clés v4 et v6 de sq
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

Ensuite, les clés post-quantiques de GnuPG 2.5.24, lues par GnuPG 2.4.9 et par sq 1.4.1 :

Trois clés post-quantiques de gpg 2.5.24 (algorithme et version de paquet d’après --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

Ce que cela montre :

  • Les clés et les signatures v4 fonctionnent partout. La clé par défaut de sq et ses signatures ont été vérifiées dans GnuPG 2.4.9.
  • Les clés v6 butent sur GnuPG 2.4, avec packet(6) with unknown version 6. Quiconque importe votre clé v6 dans un trousseau 2.4 n’obtient rien ; une signature v6 donne « no signature found ».
  • La clé PQC par défaut de GnuPG n’existe qu’en LibrePGP. pqc a créé une clé principale brainpoolP384r1 avec une sous-clé Kyber-768 plus brainpoolP256r1 (algorithme 8) dans un paquet v5. GnuPG 2.4.9 l’importe, mais affiche la sous-clé comme unknown_8 et ne peut donc pas chiffrer à destination de celle-ci ; Sequoia rejette le paquet v5.
  • Même le « mode 9980 » n’a rien produit que Sequoia sache lire. Avec --allow-9980, GnuPG 2.5.24 a créé une clé principale v6, mais a écrit ses sous-clés ML-KEM, dont mlk768 (algorithme 35, ML-KEM-768+X25519 de la RFC 9980), sous forme de paquets version 5, que la RFC 9580 ne définit pas et que Sequoia refuse. Par défaut, pqc9980 retient en outre l’algorithme 39, ML-KEM-768 avec brainpoolP384r1, qui ne figure pas parmi les algorithmes propres à la RFC 9980. En l’état de GnuPG 2.5.24, une clé RFC 9980 issue de GnuPG et une implémentation de la RFC 9980 ne se rejoignent pas.

Le chiffrement et le déchiffrement au sein de GnuPG 2.5 ont fonctionné avec toutes ces clés ; le problème se situe uniquement entre implémentations.

OpenPGP post-quantique : ce que définit la RFC 9980

La RFC 9980 (norme proposée, 2026) ajoute des algorithmes composites et autonomes :

IDAlgorithmeExigenceClés
30ML-DSA-65+Ed25519DOIT (MUST)v6
31ML-DSA-87+Ed448DEVRAIT (SHOULD)v6
32–34SLH-DSA-SHAKE-128s, 128f, 256sPEUT (MAY)v6
35ML-KEM-768+X25519DOIT (MUST)v4 ou v6
36ML-KEM-1024+X448DEVRAIT (SHOULD)v6

« Composite » signifie que les deux composantes doivent réussir : un attaquant doit casser ML-KEM et X25519, ou ML-DSA et Ed25519. Le chiffrement est la moitié urgente, car les messages chiffrés peuvent être stockés maintenant et déchiffrés plus tard (récolter maintenant, déchiffrer plus tard). Les signatures peuvent attendre que les vérificateurs les prennent en charge, et les signatures à longue durée de vie pourront être refaites plus tard. Comme l’ID 35 est aussi autorisé sur les sous-clés v4, une clé v4 existante peut recevoir une sous-clé de chiffrement post-quantique sans remplacer sa clé principale.

Recommandations pratiques

  1. Clés de signature pour les versions publiées, les commits Git et les paquets : v4 Ed25519, créées par GnuPG 2.4/2.5 (default) ou par sq (profil par défaut). Tous les vérificateurs que nous avons testés les acceptent. L’APT de Debian vérifie désormais par défaut les signatures des dépôts avec le sqv de Sequoia (APT 3.0, Debian 13), et, depuis le 1er février 2026, rejette les signatures liées à SHA-1 et les signatures v3 : re-signez donc tout ce qui est ancien (LWN sur APT 3.0).
  2. Ne publiez pas de clés v6 pour des destinataires que vous ne maîtrisez pas tant que leurs outils ne reposent pas sur Sequoia, OpenPGP.js 6 (qui implémente la RFC 9580) ou une autre implémentation de la RFC 9580 ; les utilisateurs de GnuPG 2.4 ne peuvent pas les importer.
  3. Le chiffrement avec protection post-quantique ne fonctionne aujourd’hui qu’au sein d’un même dialecte : de GnuPG à GnuPG avec le Kyber de LibrePGP, ou Sequoia avec un backend OpenSSL ou RustCrypto pour la RFC 9980. Décidez en fonction de qui déchiffre.
  4. Vérifiez votre backend et vos versions (gpg --version, sq version) ; les paquets des distributions ont un an de retard ou plus sur les versions amont.
  5. Préférez des outils plus simples là où la flexibilité d’OpenPGP n’est pas nécessaire : les signatures SSH pour les commits Git, Sigstore pour la provenance des versions, age pour le chiffrement de fichiers. Les comparatifs SSH ou GPG pour signer les commits, Sigstore ou GPG et age ou GPG détaillent les compromis ; ssh-keygen en 2026 traite du côté SSH.
  6. Publiez l’empreinte complète là où chacun peut la vérifier (votre site web, les notes de version), et distribuez la clé via WKD ou keys.openpgp.org. Un serveur de clés distribue des clés ; il ne s’en porte pas garant.

Vérifier un téléchargement dans les règles

F-Droid publie une signature détachée à côté de son APK, et l’empreinte de sa clé de signature sur son site web. La vérification tient en trois commandes :

Vérifier F-Droid.apk avec son .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
Sortie (filtrée)
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

La ligne « WARNING: This key is not certified » est normale : la toile de confiance de GnuPG n’offre aucun chemin vers cette clé. Ce qui donne son sens à la vérification, c’est la comparaison de l’empreinte de la clé principale avec celle de la page de vérification de F-Droid (identique), et l’exigence de l’empreinte complète lors de la récupération de la clé, puisque le serveur de clés renvoie tout ce qui correspond. La signature elle-même est une signature RSA v4 (algorithme 1) avec SHA-512 (algorithme de condensat 10) : format ancien, hachage actuel, lisible par toutes les implémentations. Si la clé manque, vous obtenez Can't check signature: No public key ; si le fichier a été modifié, BAD signature.

Sources