N'auriez vous pas croisé l'acronyme PGP (ou GPG) au détour d'un post, d'une discussion ou d'un article sur le chiffrement ou sur l'authentification, vu un courriel "signé numériquement", ou voulez-vous peut-être enfin comprendre ce que ces histoires de clés privées et clés publiques veulent vraiment dire.
PGP est l'un des piliers historiques de la cryptographie grand public. Il n'est ni mort, ni dépassé (malgré ce qu'on peut lire parfois ça et là), mais il a beaucoup évolué et 2026 est une année importante pour l'écosystème PGP/GPG.
Cet article en fait le tour, en partant du contexte historique et en finissant sur l'état actuel des différents outils qui existent actuellement.
Un peu d'histoire
PGP, les années 90
PGP, pour Pretty Good Privacy, naît en 1991 sous les doigts magiques de Phil Zimmermann, 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 US, et donc soumis aux mêmes restrictions d'exportation qu'un missile (oui, oui, c'est aussi absurde que ça en a l'air !).
Zimmermann publie pourtant le code source de PGP gratuitement, par conviction. Il pense avant tout aux journalistes, aux activistes, aux dissidents (politiques ou syndicaux), et à toutes les personnes qui n'ont pas les moyens de s'offrir une protection cryptographique digne de ce nom à cette époque.
Et comme vous pouvez vous en douter, le gouvernement US de l'époque ‹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, et nous insistons bien sur 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 pour beaucoup : 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 (l'organisme ouvert en charge de la rédaction des standards d'internet) accepte en 1997 le principe d'un standard ouvert, qui aboutit à la première RFC OpenPGP (la RFC 2440) publiée en 1998.
PGP, OpenPGP, GnuPG
Trois noms voisins, trois choses différentes...
En pratique :
- 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 en 1997 par Werner Koch, la version 1.0 sort en 1999. Le projet est financé pendant des années sur les fonds propres de Koch jusqu'à ce qu'un article en 2015 attire l'attention sur ce mécanisme critique tenu par un seul homme.
- Et PGP reste le standard fermé, commercial de Broadcom.
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.
Nous lui préférons PGP/GPG quand nous devons être précis.
La cryptographie asymétrique
Nous sommes désolé, mais vous ne pouvez pas approcher PGP / GPG sans appréhender le mécanisme de base en cryptographie qui permet de faire fonctionner PGP...
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 :
ayo
Sinon, voici une remise à plat rapide.
Le principe des 2 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...).
Deux usages, deux scénarios
Avec ce couple de clés, PGP couvre 2 besoins très différents :
- Prouver qui vous êtes, c'est l'authenticité (assurée par la signature),
- Garantir le secret d'un message, c'est la confidentialité (assurée par le chiffrement).
Les deux méritent une explication concrète.
Scénario 1 : Alice signe un courriel à destination de Bob
Mettons un expéditeur - Alice - souhaitant transmettre un courriel à un destinataire - Bob.
- Alice, l'émettrice, a préalablement généré sa paire de clés (publique et privée). Alice aura également au préalable permis à Bob de rapatrier sa clé publique, par le moyen qui leur convient.
- Alice écrit son message et applique une fonction de hachage sur celui-ci, mettons SHA-256, pour obtenir l'empreinte.
- Alice vient ensuite chiffrer cette empreinte avec sa clé privée, pour obtenir une signature numérique.
- Alice transmet le message, auquel cette signature est ajoutée.
- Bob - le destinataire - calcule l'empreinte du message reçu, avec le même algorithme SHA-256 qu'Alice.
- Bob utilise la clé publique d'Alice pour déchiffrer la signature numérique et obtenir l'empreinte qu'Alice a obtenue en (2).
- Bob peut ainsi :
- vérifier l'auteur de la donnée grâce aux métadonnées de la clé et à la signature : cela s'appelle l'identification, et concourt à l'authenticité de la donnée et de l'expéditeur,
- comparer les 2 empreintes (intégrité) : si l'empreinte a changé, la donnée est corrompue, il y a donc perte d'intégrité. Dans le cas contraire, la donnée est intègre et fiable.
Scénario 2 : Alice envoie une photocopie de sa carte d'identité à Bob
Reprenons nos 2 protagonistes, Alice qui cette fois-ci souhaite envoyer un courriel à notre ami Bob, contenant une photocopie de sa carte d'identité (qu'elle souhaite garder confidentielle et on la comprend !).
- Bob, le destinataire, aura préalablement généré une paire de clés (clé publique et clé privée) et aura transmis la clé publique à Alice l'émettrice.
- Alice a écrit son message et ajouté sa photocopie en pièce jointe, et entre-temps a généré une clé symétrique à usage unique (appelée aussi clé de session).
- Alice chiffre le message intégral grâce à la clé symétrique du point (2).
- Alice va également chiffrer cette clé symétrique par la clé publique de Bob, reçue préalablement.
- Le message est envoyé à Bob avec la clé symétrique (pour rappel chiffrée elle-même par la clé publique de Bob).
- Le message est reçu par Bob. Il déchiffre sans problème la clé symétrique grâce à sa clé privée.
- Bob peut donc à ce moment-là déchiffrer le message en lui-même grâce à la clé symétrique maintenant connue.
Le chiffrement asymétrique peut se résumer ainsi :
- Nous signons avec une clé privée et nous vérifions une signature avec la clé publique correspondante,
- Nous chiffrons avec la clé publique de l'autre, nous déchiffrons avec notre clé privée.
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.
C'est là que 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 crée et gère un magasin de clés (le fichier pubring.kbx dans ~/.gnupg). Il s'agit ni plus ni moins d'un "annuaire' qui contient toutes les clés publiques que vous avez ajoutées sur la machine : 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, comme suit :
- 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 peuvent être transmises sur différentes machines ou être révoquées si l'une d'elles venait à être compromise. Mais ici, vous ne perdez pas pour autant l'identité ou la chaine d'identité que vous avez patiemment construite.
C'est brillant, mais lourd...
La révocation
Que se passe-t-il si vous perdez une sous-clé, si votre ordinateur est volé ou même 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 que "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, elle est ici : 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 va un peu plus loin et 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 par exemple ?).
- légère ou marginale : pour des personnes que vous connaissez moins bien mais en qui vous avez une relative confiance.
- aucune confiance : ici, vous aurez compris.
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.
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 / GPG a beaucoup bougé ces 2 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.
La séparation RFC9580 vs LibrePGP
En gros, c'est l'événement le plus important pour l'écosystème et il mérite son paragraphe dédié.
Pour le cours d'histoire, dans les grandes lignes : récemment, l'IETF a modernisé OpenPGP (nouvelle RFC 9580) afin d'intégrer des algorithmes plus solides comme Argon2 (dérivation de clés) et l'AEAD (chiffrement authentifié) pour corriger les faiblesses historiques du protocole. Néanmoins, le mainteneur de GnuPG (Werner Koch de son petit nom) lance son draft concurrent, LibrePGP, principalement du fait qu'il juge AEAD insuffisamment robuste (surtout avec l'introduction de GCM) et parce qu'il s'oppose à la multiplication des algorithmes.
Le résultat ? 2 formats rivaux coexistent maintenant, avec des choix techniques divergents... Eh oui, le monde de l'open source fragilise une fois de plus son écosystème et crée in fine de réels risques d'incompatibilité entre messages chiffrés. Le paysage se divise donc aujourd'hui comme ceci :
- GnuPG suit LibrePGP par défaut (le choix de Werner Koch),
- Sequoia-PGP, OpenPGP.js et rpm-sequoia suivent la nouvelle RFC 9580,
- Et plusieurs distributions Linux (notamment Debian/Fedora) patchent GnuPG via le projet FreePG, pour le rendre compatible RFC 9580 sans attendre la bibliothèque amont
Oui, je sais, toujours et encore de la complexité 😔 !
Mais les usages classiques (signatures, chiffrement RSA/ECC traditionnel) restent compatibles entre les deux bibliothèques.
La transition post-quantique
L'autre grand chantier en cours, c'est l'arrivée des algorithmes résistants aux ordinateurs quantiques. Vous en entendrez de plus en plus parler car c'est aujourd'hui devenu un enjeu crucial pour le futur de la sécurité.
Petit rappel : un ordinateur quantique suffisamment puissant (qui n'existe pas encore, mais on s'en approche doucement) pourrait casser l'algorithme RSA et la cryptographie à courbes elliptiques (ECC) en quelques heures. Le résultat ici est que cela menacerait tous les messages OpenPGP chiffrés aujourd'hui et avant.
Les spécialistes et chercheurs ont publié leurs recherches depuis de nombreuses années maintenant et les NIST a en 2024 publié les premiers standards post-quantiques (ex. : ML-KEM FIPS 203 pour établir des clés, ML-DSA FIPS 204 pour signer etc. n'entrons pas trop dans le technique). OpenPGP les a repris dans la RFC 9980 (non, ne confondez pas avec la 9580 ci-dessus!!) en 2026. De son côté, Sequoia-PGP préparait cette prise en charge dès 2025. Cela avance bien mais reste délicat à implémenter.
De son côté, l'ANSSI (pour rappel l'agence de sécurité en France) recommande l'hybridation : une combinaisons d'algorithme classique (RSA, ECC) avec un algorithme post-quantique, au lieu de remplacer simplement l'un par l'autre. Cela reste plus pratique à l'usage et convient pour une adoption plus rapide. Avant un passage intégral lorsque nous aurons du recul sur les algorithmes. L'urgence concerne les données qui doivent rester confidentielles longtemps, car elles peuvent très bien être interceptées aujourd'hui et déchiffrées plus tard
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 même... Le risque d'erreur est également plutôt élevé, et ce n'est pas par hasard que pratiquement la totalité des outils de communication grand public tentent de s'en passer ou que PGP est tant décrié.
Pour le chiffrement de fichiers ou la signature de logiciels, des alternatives plus simples sont déjà disponibles :
- Age propose un format de chiffrement de fichiers minimaliste, sans les 7 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. Simple, basique.
- Sequoia-PGP est une réécriture moderne d'OpenPGP en Rust, qui suit la RFC 9580 et offre une bibliothèque utilisable dans d'autres projets, avec des branches post-quantiques en développement justement.
Pour le côté messagerie chiffrée, PGP n'est plus l'outil de choix depuis longtemps. Signal et son protocole du même nom (à base d'OMEMO...) apportent E2EE et forward secrecy (çàd que vos anciens messages restent secrets même si une clé est compromise plus tard) et une expérience utilisateur que PGP n'égalera jamais.
De leurs côtés, Proton Mail s'appuie sur OpenPGP tout en cachant la complexité inhérente ; et Tuta a fait un autre choix et utilise un protocole maison à base d'AES et de Kyber (chiffrement post-quantique déployé depuis 2024), incompatible avec OpenPGP mais qui chiffre davantage de métadonnées.
- la signature de paquets logiciels ou de code,
- l'archivage chiffré sur une longue période,
- la communication entre journalistes ou avec sources sensibles,
- et plus généralement toutes les situations où la décentralisation est un 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.
Et pour replacer PGP dans le grand schéma de la sécurité de l'information, les deux autres volets de la triade CIA :
ayo
Et pour aller voir une alternative moderne à PGP côté chiffrement de fichiers :
Contributeur(s) : Ayo, marmotte, Theudric