Si vous êtes ici, c'est probablement parce que vous avez croisé l'acronyme PGP au détour d'un post, d'une discussion ou d'un article sur le chiffrement, vu un courriel "signé numériquement", ou que vous voulez enfin comprendre ce que ces histoires de clé privée et de clé publique veulent vraiment dire.

Alors, bienvenue, vous êtes au bon endroit 😀

PGP est l'un des piliers historiques de la cryptographie grand public. Il n'est ni mort, ni dépassé (malgré ce qu'on lit parfois), mais il a beaucoup évolué et 2026 est une année charnière pour son écosystème. Cet article fait le tour, en partant du contexte historique et en finissant sur l'état actuel des outils.

💡
Cet article est le pendant théorique du tutoriel pratique. Pour la prise en main en ligne de commande, rendez-vous sur Utilisation de GPG dans son quotidien.

Un peu d'histoire

PGP, les années 90

PGP, pour Pretty Good Privacy, naît en 1991 sous les doigts de Phil Zimmermann, militant antinucléaire et défenseur de la vie privée aux États-Unis. À cette époque, le chiffrement fort est purement et simplement classé comme arme de guerre par les autorités américaines, soumis aux mêmes restrictions d'exportation qu'un missile (oui, c'est aussi absurde que ça en a l'air).

Zimmermann publie pourtant le code source de PGP gratuitement, par conviction. Il pense aux journalistes, aux activistes, aux dissidents (politiques ou syndicaux), à toutes les personnes qui n'ont pas les moyens de s'offrir une protection cryptographique digne de ce nom. Le gouvernement US ouvre une enquête criminelle contre lui qui durera 3 ans avant d'être abandonnée sans suite.

Entre-temps, PGP a fait le tour du monde.

Du logiciel libre au logiciel propriétaire

PGP devient rapidement un produit commercial. Il passe successivement entre les mains de Network Associates (1997), de PGP Corporation (formée en 2002 par d'anciens membres de l'équipe), puis de Symantec (rachat en 2010 pour 300 millions de dollars), et aujourd'hui de Broadcom (qui a absorbé la division Enterprise de Symantec en 2019). Cette dérive propriétaire pose un problème évident : un standard cryptographique qui dépend du bon vouloir d'une entreprise n'en est pas vraiment un !

C'est pour cette raison que l'IETF accepte en 1997 le principe d'un standard ouvert, qui aboutit à la première RFC OpenPGP (la 2440) publiée en 1998.

OpenPGP décrit le format des messages chiffrés, des signatures et des clés, indépendamment de toute implémentation particulière. À partir de là, n'importe qui peut écrire un logiciel compatible.

GnuPG (parfois abrégé GPG, pour GNU Privacy Guard) est l'implémentation libre de référence d'OpenPGP. Lancée fin 1997 par Werner Koch, sa version 1.0 sort en septembre 1999. Le projet est financé pendant des années sur les fonds propres de Koch jusqu'à ce qu'un article de ProPublica en 2015 attire l'attention du monde sur cette infrastructure critique tenue par un seul homme.

Aujourd'hui GnuPG est l'outil que vous trouvez par défaut dans à peu près toutes les distributions GNU/Linux et qui est abondamment utilisé dans la signature des paquets logiciels que vous installez chaque jour.

PGP, OpenPGP, GnuPG

Trois noms voisins, trois choses différentes... Voici la distinction qui revient le plus souvent dans la confusion :

Nom Nature Statut
PGP Logiciel commercial historique Propriétaire, propriété de Broadcom
OpenPGP Standard ouvert (RFC 9580) Spécification publique de l'IETF
GnuPG / GPG Implémentation libre d'OpenPGP Logiciel libre, GPL
💡
Quand un article parle de "chiffrer un courriel avec PGP", il parle dans 99% des cas d'une utilisation d'OpenPGP via GnuPG. L'usage du mot "PGP" est devenu un terme générique pour la famille entière.

La cryptographie asymétrique

PGP repose entièrement sur la cryptographie asymétrique. Si vous avez lu notre article sur le chiffrement, vous en connaissez déjà les bases :

Le Chiffrement
Article traitant des notions de chiffrement dans son ensemble et les outils recommandés.

Sinon, voici une remise à plat rapide.

Le principe des deux clés

En cryptographie symétrique (l'autre famille), une seule clé sert à chiffrer ET à déchiffrer. C'est rapide, c'est efficace, mais ça pose un problème pratique : comment transmettre cette clé à votre correspondant sans qu'elle ne soit interceptée ?

La cryptographie asymétrique répond à ce problème en utilisant 2 clés liées mathématiquement :

  • une clé privée que vous gardez précieusement et que vous ne transmettez jamais, à qui que ce soit
  • une clé publique, dérivée de la précédente, que vous pouvez diffuser librement
L'astuce : ce qu'une clé fait, seule l'autre peut le défaire.

Et il est mathématiquement très difficile de retrouver la clé privée à partir de la seule clé publique (très, très difficile, au point que les ordinateurs actuels ne savent pas le faire en un temps raisonnable, mais nous y reviendrons sur la partie post-quantique...).

🚨
Nous le répétons : une clé privée ne se transmet JAMAIS, sous aucun prétexte, sur aucun réseau. Si quelqu'un d'autre l'obtient, il peut signer en votre nom et déchiffrer ce qui vous est destiné. C'est l'équivalent numérique de votre signature manuscrite et de la clé de votre boîte aux lettres en même temps.

Deux usages, deux scénarios

Avec ce couple de clés, PGP couvre deux besoins très différents : prouver qui vous êtes (signature) et garantir le secret d'un message (chiffrement). Les deux méritent une explication concrète.

Scénario 1 : Alice signe un courriel pour Bob

Alice veut envoyer un message à Bob, et surtout que Bob soit certain que le message vient bien d'elle et n'a pas été altéré en route.

  • Alice a généré sa paire de clés à l'avance et a transmis sa clé publique à Bob.
  • Alice écrit son courriel et calcule son empreinte (un hash, par exemple SHA-256, qui produit une suite courte caractéristique du message).
  • Alice chiffre cette empreinte avec sa clé privée. Le résultat s'appelle la signature numérique.
  • Alice envoie le courriel et la signature à Bob.
  • Bob calcule de son côté l'empreinte du message reçu avec le même algorithme.
  • Bob déchiffre la signature avec la clé publique d'Alice, ce qui lui redonne l'empreinte calculée à l'étape 2.
  • Bob compare les deux empreintes. Si elles correspondent, deux choses sont prouvées : le message vient bien d'Alice (authentification) et il n'a pas été modifié en route (intégrité).
💡
La signature ne chiffre pas le message lui-même : il reste lisible par tout le monde. Elle prouve seulement son origine et son intégrité. Si vous voulez aussi le secret, il faut combiner avec le scénario suivant.

Scénario 2 : Alice envoie une photocopie de carte d'identité à Bob

Cette fois, Alice doit transmettre un document confidentiel. Personne d'autre que Bob ne doit pouvoir le lire.

  • Bob a généré sa propre paire de clés et transmis sa clé publique à Alice.
  • Alice génère une clé symétrique de session, à usage unique, qui servira à chiffrer le contenu lui-même (la cryptographie symétrique étant beaucoup plus rapide pour un gros fichier).
  • Alice chiffre le courriel et la pièce jointe avec cette clé de session.
  • Alice chiffre la clé de session avec la clé publique de Bob.
  • Le tout (message chiffré + clé de session chiffrée) est envoyé à Bob.
  • Bob déchiffre la clé de session avec sa clé privée.
  • Bob déchiffre enfin le message avec la clé de session retrouvée.

Pour résumer cette double mécanique :

  • on signe avec une clé privée, on vérifie une signature avec la clé publique correspondante
  • on chiffre avec la clé publique d'un destinataire, on déchiffre avec sa clé privée
Dans la pratique, ces deux usages se combinent naturellement. La plupart des clients de courrier signent et chiffrent en même temps, de manière transparente. Pas besoin de gérer manuellement les clés de session, l'outil le fait.

La toile de confiance, le vrai sujet

Tout ce qui précède repose sur un préalable un peu fragile :

Comment savez-vous que la clé publique d'Alice est bien celle d'Alice et pas celle d'un imposteur ?

Si quelqu'un substitue sa propre clé publique à celle d'Alice avant que vous l'enregistriez, toutes vos communications "avec Alice" passeront en réalité par lui. C'est le problème classique de la cryptographie asymétrique.

PGP répond à ce problème par un mécanisme original, la toile de confiance ("Web of Trust" chez nos chers amis anglais).

Le magasin de clés

Sur votre machine, GnuPG entretient un magasin de clés (le fichier pubring.kbx dans ~/.gnupg). C'est l'annuaire de toutes les clés publiques que vous connaissez : les vôtres, celles de vos correspondants, celles des développeurs dont vous voulez vérifier les paquets.

Lorsque vous ajoutez une clé publique à ce magasin, vous pouvez choisir de la signer avec votre propre clé privée, comme un notaire qui contresigne un document. Vous attestez ainsi que cette clé appartient bien à la personne dont elle porte le nom (parce que vous l'avez vue physiquement, avez vérifié son empreinte sur un canal de confiance, etc.).

La structure clé maître + sous-clés

Une bonne hygiène PGP repose sur une clé maître dédiée à la certification et plusieurs sous-clés spécialisées :

  • une sous-clé pour la signature ([S]), qui sert à signer vos courriels et fichiers
  • une sous-clé pour le chiffrement ([E]) qui reçoit les messages chiffrés à votre attention
  • éventuellement une sous-clé pour l'authentification ([A]) pour les usages SSH ou similaires
  • éventuellement une sous-clé de compatibilité si vos correspondants utilisent un client logiciel daté

L'intérêt de cette séparation est concret : la clé maître reste hors-ligne sur une clé USB chiffrée rangée dans un tiroir et n'est sortie qu'occasionnellement pour signer une nouvelle clé d'un correspondant. Les sous-clés circulent sur les machines du quotidien et peuvent être révoquées une par une si l'une d'elles est compromise. Vous ne perdez pas pour autant l'identité que vous avez patiemment construite.

🚨
Si votre clé maître est perdue ou compromise, c'est tout l'édifice qui s'écroule. Il faut tout recommencer, prévenir tous vos contacts, retisser la toile de confiance. C'est pour ça qu'on ne plaisante pas avec son stockage.

La révocation

Que se passe-t-il si vous perdez une sous-clé, si votre ordinateur est volé, si vous oubliez la phrase de passe de votre clé maître ? Eh bien, vous révoquez la clé concernée. Concrètement, vous publiez un certificat spécial qui indique aux autres "cette clé n'est plus valide, ne lui faites plus confiance".

C'est la raison pour laquelle on génère un certificat de révocation au moment de la création de la clé maître qu'on stocke à part. Si vous ne pouvez plus accéder à la clé pour la révoquer normalement, ce certificat de secours fait le travail à votre place.

La toile à proprement parler

La vraie plus value de PGP, c'est ce qui se passe quand des dizaines, des centaines de personnes signent mutuellement leurs clés. Il se forme un graphe social cryptographique où la confiance se propage. Si vous faites confiance à Bob et que Bob a signé la clé de Claire, alors vous pouvez raisonnablement faire confiance à la clé de Claire, n'est-ce pas ?

GnuPG vous laisse choisir le niveau de confiance que vous accordez à chaque signataire :

  • ultime : réservée à vos propres clés, jamais à celles des autres
  • entière : pour des personnes en qui vous avez une confiance absolue (un proche que vous voyez physiquement)
  • légère ou marginale : pour des personnes que vous connaissez moins bien
  • aucune confiance : pour signaler explicitement que vous n'avez pas vérifié. Une clé est considérée comme valide si elle a été signée soit par vous-même, soit par suffisamment de personnes en qui vous avez une confiance entière ou marginale.
💡
Bon malheureusement, cette brillante idée de la toile de confiance n'a jamais vraiment décollé, en dehors des cercles techniques (développeurs, hacktivistes, journalistes d'investigation...).

Pour le grand public, OpenPGP s'utilise plutôt aujourd'hui via la simple vérification d'empreinte de main à main, ou via des annuaires de clés modernes comme keys.openpgp.org.

Un état des lieux en 2026

PGP a beaucoup bougé ces deux dernières années, et il serait malhonnête de prétendre que tout va bien dans le meilleur des mondes.

Les versions actuelles de GnuPG

À l'heure où nous écrivons ces lignes, la situation est la suivante :

  • GnuPG 2.5.19 est la branche stable récente, sortie mi 2026
  • GnuPG 2.4.9 est la branche de maintenance encore supportée, sortie fin 2025
  • GnuPG 2.4 atteint sa fin de vie le 30 juin 2026, après quoi, seules les versions 2.5 et au-delà recevront des correctifs de sécurité

Si votre distribution livre encore GnuPG 2.4, c'est l'occasion de vérifier sa politique de mise à jour ou de migrer vers la branche 2.5.

Le schisme RFC9580 vs LibrePGP

C'est l'événement de la décennie pour l'écosystème et il mérite qu'on s'y attarde.

En 2024, l'IETF a publié la RFC 9580 qui modernise OpenPGP en remplaçant les RFC 4880, 5581 et 6637. Cette nouvelle version intègre des algorithmes plus récents (Argon2 pour la dérivation de clé, AEAD pour le chiffrement authentifié) et règle plusieurs faiblesses connues de l'ancienne spécification.

Le problème, c'est que Werner Koch, le mainteneur historique de GnuPG, a refusé d'adopter la RFC 9580 ! Dès fin 2023, soit avant même la finalisation officielle de la RFC, il annonce un standard concurrent baptisé LibrePGP, fondé sur l'état d'OpenPGP en 2021 et qui conserve d'autres choix techniques (notamment sur l'AEAD).

Résultat : 2 standards coexistent désormais, avec des incompatibilités potentielles entre messages chiffrés.

Côté implémentations, le paysage se divise :

  • GnuPG suit LibrePGP par défaut (le choix de Werner Koch)
  • Sequoia-PGP (la bibliothèque sequoia-openpgp est en v2.2.0 depuis février 2026), OpenPGP.js, rpm-sequoia suivent la RFC 9580
  • Plusieurs distributions Linux (notamment côté Debian/Fedora) patchent GnuPG via le projet FreePG pour le rendre compatible RFC 9580 sans attendre l'amont

Oui, je sais, toujours et encore de la complexité 😔 !

⚠️
Concrètement, si vous utilisez GnuPG d'origine et que votre correspondant utilise un client compatible RFC 9580 (ou inversement), certaines fonctionnalités modernes peuvent ne pas être interopérables. Les usages classiques (signatures, chiffrement RSA/ECC traditionnel) restent compatibles entre les deux camps.

La transition post-quantique

L'autre grand chantier en cours, c'est l'arrivée des algorithmes résistants aux ordinateurs quantiques. Pour rappel, un ordinateur quantique suffisamment puissant (qui n'existe pas encore, mais on s'en approche) pourrait casser RSA et la cryptographie à courbes elliptiques en quelques heures, menaçant rétroactivement tous les messages OpenPGP chiffrés aujourd'hui et avant.

Le NIST a publié le 13 août 2024 trois standards post-quantiques majeurs : ML-KEM (FIPS 203, anciennement Kyber) pour l'établissement de clés, ML-DSA (FIPS 204, ex-Dilithium) et SLH-DSA (FIPS 205, ex-SPHINCS+) pour les signatures. Les implémentations OpenPGP intègrent progressivement ces algorithmes : Sequoia-PGP propose ainsi des branches pqc depuis fin 2025.

L'ANSSI, dans son avis mis à jour fin 2023 et complété fin 2024, recommande explicitement une approche hybride : combiner systématiquement un algorithme classique éprouvé (RSA, ECC) avec un algorithme post-quantique, plutôt que de remplacer brutalement le premier par le second. Le raisonnement est simple : les nouveaux algorithmes n'ont pas encore 20 ans de cryptanalyse derrière eux, plusieurs candidats post-quantiques ont déjà subi des attaques classiques imprévues, et personne ne veut découvrir trop tard que ML-KEM a une faiblesse cachée. L'agence prévoit une transition en 3 phases :

  • Phase 1 (jusqu'à fin 2025) : hybridation comme défense en profondeur
  • Phase 2 (à partir de 2025-2026) : hybridation avec assurance post-quantique sans régression classique
  • Phase 3 (visée à partir de 2027) : obligations PQC pour la qualification des produits

En octobre 2025, l'ANSSI a délivré ses deux premiers Visas de sécurité pour des produits intégrant de la cryptographie post-quantique (Thales et Samsung). Pour le grand public et les usages courants, RSA 4096 ou Ed25519 restent parfaitement adaptés en 2026, l'urgence post-quantique concerne d'abord les données dont la confidentialité doit être préservée bien au-delà de 2030.

Les limites de PGP et ses alternatives

Il faut le dire : PGP est complexe à utiliser correctement. La courbe d'apprentissage est raide, très raide, ultra raide. Le risque d'erreur est également élevé, et ce n'est pas par hasard que la quasi-totalité des outils de communication grand public s'en passent ou que l'outil est tant décrié.

Pour le chiffrement de fichiers ou la signature de logiciels, des alternatives plus simples ont émergé :

  • Age (v1.3.1 en 2026) propose un format de chiffrement de fichiers minimaliste, sans les sept couches de configuration de PGP. Pas de toile de confiance, pas de magasin de clés, juste une commande qui chiffre et une commande qui déchiffre.
  • Sequoia-PGP est une réécriture moderne d'OpenPGP en Rust, qui suit la RFC 9580 et offre une bibliothèque (sequoia-openpgp v2.2.0 en février 2026) utilisable dans d'autres projets, avec des branches post-quantiques en développement.

Pour la messagerie chiffrée, PGP n'est plus l'outil de choix depuis longtemps. Signal et son protocole homonyme apportent le chiffrement de bout en bout par défaut, le forward secrecy (vos anciens messages restent secrets même si une clé est compromise plus tard), et une expérience utilisateur que PGP n'égalera jamais.

Côté courriel, Proton Mail s'appuie sur OpenPGP en arrière-plan tout en cachant la complexité ; Tuta a fait un autre choix et utilise un protocole maison à base d'AES et de Kyber (chiffrement post-quantique déployé depuis mars 2024), incompatible avec OpenPGP mais qui chiffre davantage de métadonnées.

💡
Cela ne veut pas dire que PGP est inutile. Il reste irremplaçable pour la signature des paquets logiciels, l'archivage chiffré au long cours, la communication avec des journalistes ou des sources sensibles, et toutes les situations où la décentralisation et l'absence d'autorité centrale sont des prérequis.

Pour aller plus loin

Cet article reste théorique. Si vous voulez maintenant créer votre première paire de clés, signer un courriel, ou apprendre à publier votre clé sur un serveur, le passage à la pratique vous attend.

Direction le tutoriel pas à pas : Utilisation de GPG dans son quotidien.

Et pour replacer PGP dans le grand schéma de la sécurité de l'information, les deux autres volets de la triade CIA :

Le Chiffrement
Article traitant des notions de chiffrement dans son ensemble et les outils recommandés.
Comprendre l’intégrité des données
Hachage, empreintes et signatures numériques, pour vérifier que vos fichiers n’ont pas été altérés en chemin.

Et pour aller voir une alternative moderne à PGP côté chiffrement de fichiers :

Utilisation de l'outil Age
Ce tutoriel vous montre simplement l'utilisation de l'outil de chiffrement "Age".

Contributeur(s) : Ayo, marmotte, Theudric