GnuPG 2.5.19 et ML-KEM : guide technique pour préparer OpenPGP post-quantique

avril 26, 2026

Le 24 avril 2026, Werner Koch a annoncé GnuPG 2.5.19 dans la liste officielle de GnuPG. L’annonce n’était pas véhémente : elle parlait d’une nouvelle version, de quelques améliorations, de corrections de bugs et d’un passage de la série 2.4 vers une base plus moderne. Cependant, une ligne concentre le changement le plus important : la série 2.5 introduit Kyber, également connu aujourd’hui sous le nom de ML-KEM et standardisé par le NIST sous le nom de FIPS 203, comme algorithme de chiffrement post-quantique.

GnuPG est important car ce n’est pas une curiosité de laboratoire. Il s’agit d’une implémentation gratuite d’OpenPGP et de S/MIME, utilisée pour chiffrer des fichiers, signer des packages, protéger les e-mails, vérifier les versions, automatiser les déploiements et maintenir des chaînes de confiance qui fonctionnent depuis des années. Lorsqu’un outil ayant ce rôle intègre la cryptographie post-quantique dans sa branche principale, la conversation cesse d’être purement académique et entre dans le domaine opérationnel.

L’idée sous-jacente est simple : de nombreuses techniques de chiffrement à clé publique que nous utilisons aujourd’hui dépendent de problèmes mathématiques qu’un ordinateur quantique suffisamment grand pourrait résoudre beaucoup plus efficacement qu’un ordinateur classique. Cela ne veut pas dire que tout va casser demain. Cela signifie que les données cryptées aujourd’hui peuvent avoir une durée de vie plus longue que la protection que nous leur accordons si quelqu’un les capture maintenant et attend de les décrypter plus tard.

Ce risque est souvent appelé récolter maintenant, décrypter plus tard : collecter maintenant, décrypter plus tard. Toutes les données ne méritent pas la même préoccupation. Un mot de passe temporaire, une sauvegarde détruite en quatre-vingt-dix jours ou un message sans valeur future ont un profil différent de celui des contrats, des dossiers médicaux, des secrets commerciaux, des dossiers judiciaires, des plans d’infrastructure, de l’identité des lanceurs d’alerte ou des sauvegardes historiques qui doivent rester privées pendant des décennies.

Le NIST a approuvé trois normes fédérales de cryptographie post-quantique en août 2024 : FIPS 203 pour ML-KEM, FIPS 204 pour ML-DSA et FIPS 205 pour SLH-DSA. FIPS 203 vient de CRYSTALS-Kyber et définit un mécanisme d’encapsulation de clé, c’est-à-dire un moyen d’établir un secret partagé sur un canal public. GnuPG se déplace précisément dans ce domaine lorsqu’une personne chiffre pour une autre en utilisant des clés publiques.

La discussion dans Hacker News a été utile car elle a ancré le sujet dans des questions pratiques : quand est-il conseillé de migrer, quel est le poids des clés et des textes chiffrés, que se passe-t-il avec les cartes à puce et les HSM, comment mélangent-ils ML-KEM et X25519, et ce qu’impliquent les tensions entre les différentes familles OpenPGP. Plus qu’une célébration technique, la conversation a montré que le plus difficile n’est pas de comprendre qu’il faut migrer ; Le plus dur est de trouver tous les endroits où la crypto vit tranquillement.

L’annonce officielle prévient également que l’ancienne série 2.4 arrive en fin de vie deux mois après l’annonce. Cela fait de cette nouvelle plus qu’une simple amélioration facultative : ceux qui emballent, gèrent des postes de travail, maintiennent des scripts ou s’appuient sur GPGME doivent planifier la mise à niveau, les tests et la compatibilité. En matière de sécurité, tout laisser jusqu’au dernier jour réduit rarement les risques.

La manière responsable de lire ces nouvelles n’est pas comme une alarme ou comme une mode. C’est un signe précoce de transition. La cryptographie post-quantique connaîtra une longue période de coexistence avec des algorithmes classiques, avec des formats existants et avec des équipements qui ne se modernisent pas au même rythme. L’avantage de commencer maintenant est que les organisations peuvent apprendre, inventorier et tester sans encore connaître de crise.

Lecture technique de l’annonce

GnuPG 2.5.19 ne doit pas être lu comme une simple version mineure. L’annonce la présente comme une version avec de nouvelles fonctionnalités et correctifs, mais aussi comme la branche qui prépare le passage à une base 2.6 où le support PQC ne sera plus une rareté expérimentale. Pour les équipes intégrant gpg, gpg-agent, dirmngr, scdaemon ou GPGME dans des flux réels, le point critique est la compatibilité opérationnelle.

La mention de Kyber, ML-KEM et FIPS 203 est exacte. Kyber était la proposition originale dans le cadre du processus de normalisation post-quantique du NIST ; ML-KEM est le nom standardisé du mécanisme d’encapsulation de clé basé sur des modules et des réseaux. Il ne remplace pas les chiffreurs symétriques qui protègent la charge utile. Dans un flux OpenPGP, sa valeur réside dans l’établissement de secrets pour les destinataires.

Le détail qui devrait guider l’adoption est l’approche hybride. Lors de la discussion de la communauté, il a été souligné que ML-KEM est souvent combiné avec X25519 ou un autre algorithme classique, de sorte que la sécurité ne dépend pas d’une seule famille mathématique. Cela réduit le risque de parier prématurément sur un nouvel algorithme et, en même temps, réduit l’exposition future à un ordinateur quantique cryptographiquement pertinent.

Compatibilité OpenPGP, formats et dette

Le monde OpenPGP souffre d’une tension bien connue : se moderniser sans trop casser les installations. RFC 4880, RFC 9580, LibrePGP, les implémentations historiques et les nouvelles bibliothèques coexistent avec des priorités différentes. Pour une équipe technique, l’essentiel ne doit pas être de choisir son camp par réflexe, mais plutôt de cartographier les clients, les clés, les serveurs de clés, les frontends et les automatisations impliqués dans chaque échange.

GnuPG affirme que ses nouvelles versions restent compatibles avec les versions précédentes. Cette promesse est utile, mais elle n’élimine pas les preuves. Un message bien chiffré sur une station peut échouer sur un ancien pipeline, sur une image de conteneur gelée, sur une interface de messagerie qui appelle gpg avec des options obsolètes, ou sur un jeton matériel qui ne prend pas en charge les éléments attendus.

La transition PQC modifie également les hypothèses de taille. Les clés publiques, les wrappers et certaines métadonnées peuvent croître. Pour les e-mails et les fichiers en vrac, ce n’est probablement pas un goulot d’étranglement. Pour les protocoles à volume élevé, le stockage de masse de petits messages, les systèmes embarqués ou les canaux avec des limites strictes, la taille entre dans la matrice de décision. OpenPGP n’est généralement pas sur la voie de la latence, mais toutes les utilisations ne sont pas égales.

Inventaire avant migration

Le premier livrable technique n’est pas d’installer la 2.5.19 partout. Il s’agit d’un inventaire cryptographique. Il répertorie où GnuPG est utilisé directement, où il apparaît via GPGME, quels scripts invoquent gpg, quelles tâches vérifient les signatures, quelles sauvegardes chiffrent avec les destinataires PGP, quelles clés résident sur les cartes à puce, quels paquets sont signés et quels systèmes externes attendent un certain format.

Cet inventaire doit enregistrer la durée de vie utile des données, leur criticité, le propriétaire du processus, la version installée, le système d’exploitation, la méthode de distribution, la dépendance matérielle et le plan de restauration. Sans cette base, la migration devient un ensemble de changements locaux. Sur cette base, vous pouvez décider quels flux nécessitent un PQC précoce et lesquels peuvent attendre le cycle normal de la plateforme.

La durée de vie utile des données est le critère le plus manquant dans de nombreuses organisations. Un fichier crypté pour le transport et détruit le lendemain ne présente pas le même risque qu’un contrat signé et archivé pendant vingt ans. Une sauvegarde tournante n’est pas évaluée de la même manière qu’un référentiel historique. La matrice de migration doit être triée en fonction de la confidentialité future et non en fonction de la facilité de mise à jour.

Cartes à puce, HSM et matériel

Les plus grosses frictions apparaîtront probablement au niveau du matériel. Les cartes à puce et les HSM ont de longs cycles de vie, des certifications, un micrologiciel contrôlé et des limites de mémoire ou de calcul. Certains appareils peuvent intégrer la prise en charge du micrologiciel ; d’autres non. Certains fabricants incluent une accélération reprogrammable ; d’autres dépendent du silicium fixe. Pour les clés d’une durée de vie de cinq à dix ans, la décision d’achat de 2026 devrait déjà demander le PQC.

La recommandation pratique est de séparer les rôles clés. Ne mélangez pas une clé de signature racine à long terme avec une clé de chiffrement opérationnelle qui doit évoluer rapidement. Gardez les sous-clés, la rotation et l’expiration bien définies. GnuPG permet des modèles de gestion de clés assez flexibles ; Leur utilisation avec discipline réduit la pression lorsqu’un algorithme, un appareil ou une politique change.

Dans les environnements avec HSM, ajoutez de vrais tests de performances. ML-KEM peut être efficace sur le plan informatique, mais ses tailles et ses chemins d’intégration affectent les tampons, les journaux, les limites de l’API, les sauvegardes, la réplication et l’audit. La question n’est pas seulement de savoir si l’algorithme fonctionne rapidement, mais aussi de savoir si l’ensemble du système qui l’entoure accepte les nouveaux objets sans tronquer, rejeter ou enregistrer les éléments sensibles.

Plan de mise à niveau de l’équipement

Un plan raisonnable commence par les laboratoires. Installez GnuPG 2.5.19 dans des environnements contrôlés, générez des clés de test, chiffrez pour des destinataires mixtes, vérifiez les signatures, testez l’importation et l’exportation, exécutez vos scripts existants et comparez les sorties. Documentez les avertissements, les changements de format, les nouvelles options et dépendances. Répétez l’opération sur Linux, macOS, Windows et les conteneurs si votre organisation les utilise.

Testez ensuite l’interopérabilité avec vos vrais clients : frontends de messagerie, gestionnaires de mots de passe qui utilisent OpenPGP, systèmes de versions, référentiels internes, outils de sauvegarde, S/MIME le cas échéant et automatisations CI/CD. La compatibilité revendiquée ne remplace pas les tableaux de test, car les bogues résident souvent à la périphérie : chiffrement, autorisations d’agent, pinentry, trustdb, routes de socket et politiques de sécurité locales.

La mise à jour devrait également prendre en compte la série 2.4. L’annonce officielle indique qu’il arrive en fin de vie deux mois plus tard. Si vous avez des images de base, des packages internes ou des points de terminaison qui sont toujours bloqués sur la version 2.4, définissez une date de gel, une date de déploiement et une date de correction. Le pire résultat est de découvrir la fin du support lorsqu’un bug opérationnel ou une alerte de sécurité apparaît.

Liste de contrôle technique

Vérifiez les versions avec gpg --version et les bibliothèques de support des documents. Vérifiez si vos pipelines s’installent à partir du système d’exploitation, à partir de leurs propres référentiels ou à partir d’archives tar. Confirme que les signatures de version GnuPG sont validées avec des clés de signature fiables et pas seulement avec des sommes de contrôle copiées à partir d’une page. En matière de sécurité de la chaîne d’approvisionnement, la manière de mettre à jour fait partie du contrôle.

Créez un ensemble de messages de test : destinataire classique, destinataire PQC, destinataires mixtes, gros fichier, petit fichier, signature séparée, signature jointe, chiffrement et signature combinés. Enregistrez les résultats attendus et automatisez les vérifications. Si un outil tiers ne comprend pas un format, ne le découvrez pas avec des données productives ou une urgence commerciale en plus.

Évaluez les politiques d’expiration. Le PQC n’élimine pas la nécessité d’une rotation. Au contraire, une transition ordonnée a besoin de clés avec des dates claires pour éviter les objets éternels que personne n’ose toucher. Il définit comment publier de nouvelles clés, comment révoquer les anciennes, comment communiquer les modifications aux contreparties et comment préserver la capacité de décryptage des fichiers historiques sans continuer à chiffrer avec du matériel faible.

Risques non résolus par ML-KEM

ML-KEM ne répare pas les points de terminaison compromis. Si l’ordinateur de l’utilisateur contient un logiciel malveillant, le texte peut être divulgué avant le cryptage ou après le décryptage. Il ne corrige pas non plus les mauvais mots de passe, les clés privées copiées, les sauvegardes incontrôlées, les secrets coincés dans les tickets ou les processus de vérification ignorés en raison de la pression. La transition post-quantique doit coexister avec les contrôles de sécurité opérationnels classiques.

Cela ne remplace pas non plus les signatures post-quantiques. Au NIST, ML-KEM concerne l’établissement clé ; ML-DSA et SLH-DSA traitent les signatures numériques. OpenPGP utilise à la fois le chiffrement et les signatures, et chaque propriété doit être évaluée séparément. Une feuille de route sérieuse doit distinguer la confidentialité future, l’authenticité future, la non-répudiation, l’archivage à long terme et la vérification des logiciels.

Enfin, cela ne résout pas la fragmentation des normes. L’interopérabilité d’OpenPGP continuera d’être un problème d’ingénierie et de gouvernance. Les équipes qui s’appuient sur le partage externe doivent documenter les profils acceptés, les versions minimales et les procédures d’exception. En cryptographie, ce qui n’est pas écrit finit par devenir une tradition orale, et la tradition orale échoue lors d’incidents.

Conclusion technique

GnuPG 2.5.19 est l’opportunité de démarrer une migration sans drame. L’algorithme concerné est déjà standardisé par le NIST, l’outil l’intègre déjà dans la branche principale et la série 2.4 a déjà une date de fin de vie proche. Cela ne vous oblige pas à activer PQC dans chaque flux demain, mais cela vous oblige à arrêter de le traiter comme une future diapositive.

La stratégie recommandée est la suivante : inventaire, laboratoire, compatibilité, matériel, politiques clés, déploiement et surveillance progressifs. Les équipes qui le font maintenant transformeront l’arrivée de la cryptographie post-quantique en maintenance planifiée. Ceux qui attendent une obligation extérieure ou une crise feront la même migration, mais avec moins de temps et plus de risques.