Cryptographie appliquée

PGP expliqué en 2026 : guide complet pratique

PGP et OpenPGP 2026 : Web of Trust, GnuPG, chiffrement et signature email, Git signed commits, alternatives modernes (age, Sigstore), état et déclin PGP.

Naim Aouaichia
17 min de lecture
  • PGP
  • OpenPGP
  • GnuPG
  • Chiffrement email
  • Web of Trust
  • age
  • Sigstore
  • RFC 9580

PGP (Pretty Good Privacy) est le logiciel de chiffrement et signature créé par Phil Zimmermann en 1991, devenu standard OpenPGP via IETF (RFC 2440 en 1998, RFC 4880 en 2007, RFC 9580 modernisé en juillet 2024) et implémenté en open source par GnuPG (GPG) depuis 1997. Il fournit chiffrement asymétrique (RSA historique, EdDSA/Curve25519 modernes), signatures numériques, chiffrement symétrique hybride et un modèle de confiance décentralisé unique dans l'industrie : le Web of Trust. En 2026, PGP est en déclin relatif pour ses usages grand public (email end-to-end remplacé par Signal, signatures artefacts concurrencées par Sigstore, chiffrement fichiers remplacé par age) mais reste massivement déployé pour des cas spécifiques : signatures de commits Git (adopté par GitHub et GitLab), signatures de packages OS (Debian apt, Red Hat rpm, Arch pacman), signatures de releases GitHub, workflows journalistiques confidentiels (ProtonMail, SecureDrop, Thunderbird). Cet article détaille l'histoire PGP depuis 1991, le principe Web of Trust comparé à PKI X.509, GnuPG comme implémentation de référence, les cas d'usage 2026 qui résistent, les limitations UX et techniques (Efail 2018), les alternatives modernes (age pour fichiers, Sigstore pour artefacts, Signal pour messaging, S/MIME pour email entreprise), les commandes pratiques GPG essentielles, RFC 9580 (2024) qui modernise OpenPGP avec algorithmes elliptiques, et les pièges récurrents à éviter.

Histoire et standards

PGP a une histoire riche en 35 ans, marquée par des luttes légales, des forks open source, et une évolution technique continue.

1991 — Phil Zimmermann publie PGP 1.0

Au début des années 1990, Phil Zimmermann, militant anti-prolifération nucléaire, publie PGP 1.0 comme freeware téléchargeable sur BBS puis Internet. Réaction immédiate du gouvernement américain : enquête pour exportation illégale de cryptographie (PGP utilisait RSA + IDEA, considérés alors comme munitions). Zimmermann fait face à des poursuites criminelles jusqu'en 1996, quand l'affaire est classée sans suite.

1993-1996 — Controverses légales et diffusion

PGP devient un symbole de la liberté cryptographique. Zimmermann publie le code source en livre (protégé par le Premier Amendement de la Constitution US), contournant les restrictions d'exportation. Le logiciel se diffuse mondialement.

1997-1998 — Standardisation IETF et GnuPG

Le groupe de travail OpenPGP de l'IETF publie RFC 2440 en novembre 1998, standardisant le format. Werner Koch lance GnuPG (Gnu Privacy Guard) la même année comme implémentation open source libre de PGP.

2007 — RFC 4880 modernise OpenPGP

RFC 4880 (novembre 2007) remplace RFC 2440. Ajouts principaux : support SHA-2 family, ECDSA, UTF-8 dans les user IDs. Standard dominant jusque 2024.

2010 — Symantec acquiert PGP Inc

PGP Corporation (la société commerciale) acquise par Symantec pour 300 M$ en avril 2010. Devient Symantec Encryption Desktop, puis propriété Broadcom en 2019. Fait diminuer la visibilité commerciale de PGP au profit des alternatives.

2018 — Efail

Efail (CVE-2017-17688, CVE-2017-17689) révèle des vulnérabilités dans les clients email utilisant PGP/S/MIME. Pas dans PGP lui-même mais impact marketing majeur. Marque le début du déclin PGP grand public.

2024 — RFC 9580 modernise OpenPGP

RFC 9580 (juillet 2024) remplace RFC 4880. Modernisation majeure : algorithmes elliptiques Ed25519/X25519 préférés, AEAD (Authenticated Encryption), deprecation RSA-1024 et SHA-1. Support GnuPG depuis version 2.5 (janvier 2025).

Web of Trust : le modèle décentralisé

Le Web of Trust est le modèle de confiance unique de PGP, radicalement différent de la PKI X.509 centralisée utilisée pour TLS.

Principe

Chaque utilisateur signe les clés publiques des utilisateurs qu'il rencontre physiquement et vérifie (pièce d'identité, présence en personne). La confiance se propage par chaînes de signatures : si Alice fait confiance à Bob qui a signé la clé de Charlie, Alice peut faire confiance (partiellement) à Charlie.

                    Web of Trust
                    
         Alice ──signe──▶ Bob
           │                │
           │ signe           │ signe
           ▼                 ▼
        Charlie ──signe──▶ David

           │ fait confiance

        Eve (trust partiel via Alice → Charlie)

Niveaux de confiance

GnuPG permet de spécifier des niveaux de confiance pour chaque clé importée :

NiveauSignification
UltimatePropre clé de l'utilisateur
FullPleine confiance (ami proche, vérifié personnellement)
MarginalConfiance limitée (connaissance professionnelle)
UnknownClé importée mais pas encore vérifiée
NeverClé explicitement non fiable

GnuPG considère une clé comme valide si elle est signée par :

  • 1 full trust introducer, OU
  • 3 marginal trust introducers.

Key Signing Parties

Événements physiques où les participants vérifient mutuellement leurs identités (passport, ID card) et signent les clés publiques des uns et des autres. Historiquement importants dans la communauté libre (Debian, FSF, Tor) pour construire le Web of Trust.

Web of Trust vs PKI X.509

DimensionWeb of Trust (PGP)PKI X.509 (TLS)
ModèleDécentralisé, pair-à-pairCentralisé, CA autorités
AuthoritéSignatures mutuelles utilisateursCA racines dans navigateurs
ScalabilitéLimitée (key signing parties)Massive (millions de sites)
UXComplexe pour grand publicTransparente
RésiliencePas de single point of failureCompromission CA = impact large
Adoption 2026Communautés techniques nicheQuasi-universelle Internet
Key lifecycleManuel (génération, partage, révocation)Automatisé (ACME)

GnuPG : l'implémentation de référence

GnuPG (GnuPG Privacy Guard) est l'implémentation open source de référence d'OpenPGP, développée depuis 1997 par Werner Koch (allemand).

Caractéristiques

  • Licence : GPL v3+ (libre).
  • Maintenance : Werner Koch + GnuPG e.V. (association allemande).
  • Plateformes : Linux, macOS, Windows, FreeBSD, OpenBSD, Android.
  • Intégrations : Thunderbird, KMail, GPGTools (macOS), Gpg4win (Windows), pratiquement toute distribution Linux.

Versions 2026

VersionPublicationParticularité
GnuPG 2.4.x2023Branche stable, RFC 4880
GnuPG 2.5.xjanvier 2025Support RFC 9580 (EdDSA, AEAD modernes)

Migration recommandée 2026 : GnuPG 2.5+ pour bénéficier des algorithmes modernes.

Alternative moderne : Sequoia PGP

Sequoia PGP (2017+) est une implémentation Rust moderne d'OpenPGP, développée par d'anciens contributeurs GnuPG. Avantages :

  • Code Rust (mémoire safe, moins de CVE).
  • API moderne pour intégration dans applications.
  • Performance supérieure.
  • Support RFC 9580 précoce.

Adopté par Debian (migration gpg → Sequoia en cours) pour signer packages.

Commandes pratiques GnuPG

Opérations GPG essentielles en ligne de commande.

Génération de clé

# Génération moderne avec Ed25519 + Curve25519 (recommandé 2026)
gpg --full-generate-key --expert
# Choisir :
# - Kind of key : ECC and ECC
# - Curve : Curve25519 (default)
# - Validity : 2 years (renouvellement périodique conseillé)
# - Real name, Email, Comment
# - Passphrase forte (gère un secret manager)
 
# Alternative moderne simplifiée (depuis GnuPG 2.3)
gpg --quick-generate-key "Alice Dupont <alice@example.test>" ed25519
 
# Vérifier la clé générée
gpg --list-secret-keys --keyid-format LONG

Export / import de clés

# Export clé publique (format ASCII armor)
gpg --armor --export alice@example.test > alice-public.asc
 
# Export clé privée (ATTENTION : protéger avec passphrase)
gpg --armor --export-secret-keys alice@example.test > alice-private.asc
 
# Import clé publique d'un contact
gpg --import bob-public.asc
 
# Récupérer clé publique depuis keyserver (keys.openpgp.org)
gpg --keyserver hkps://keys.openpgp.org --recv-keys <KEYID>

Signature

# Signature détachée d'un fichier
gpg --armor --detach-sign important-document.pdf
# Crée important-document.pdf.asc
 
# Vérifier signature détachée
gpg --verify important-document.pdf.asc important-document.pdf
 
# Signature clearsign (texte incorporé)
gpg --clearsign message.txt
# Crée message.txt.asc contenant le texte + signature
 
# Signature inline (tout dans un fichier binaire)
gpg --sign document.pdf
# Crée document.pdf.gpg

Chiffrement

# Chiffrement pour un destinataire spécifique
gpg --encrypt --recipient bob@example.test --armor document.pdf
# Crée document.pdf.asc
 
# Chiffrement pour plusieurs destinataires
gpg --encrypt --recipient alice@example.test --recipient bob@example.test document.pdf
 
# Déchiffrement
gpg --decrypt document.pdf.gpg > document.pdf

Signature + chiffrement combinés

# Signer ET chiffrer (pattern email PGP classique)
gpg --encrypt --sign --armor --recipient bob@example.test message.txt

Révocation de clé

# Générer un certificat de révocation (à faire dès création de la clé)
gpg --output revocation-cert.asc --gen-revoke alice@example.test
 
# Utiliser le certificat pour révoquer la clé (si compromise ou perdue)
gpg --import revocation-cert.asc
 
# Publier la révocation
gpg --keyserver hkps://keys.openpgp.org --send-keys <KEYID>

Cas d'usage qui résistent en 2026

Malgré le déclin grand public, PGP reste massivement utilisé pour des cas spécifiques.

1. Signatures de commits Git

GitHub et GitLab supportent la vérification de commits signés PGP depuis plusieurs années. Affichage "Verified" badge sur les commits.

# Configuration Git pour signer automatiquement
git config --global user.signingkey <KEYID>
git config --global commit.gpgsign true
git config --global tag.gpgsign true
 
# Les commits sont automatiquement signés
git commit -m "feat: nouvelle feature"
# Signature ajoutée via commit object
 
# Vérifier la signature d'un commit
git log --show-signature
 
# Ajouter clé publique à GitHub
# Settings → SSH and GPG keys → New GPG key
gpg --armor --export <KEYID> | pbcopy  # Copie dans presse-papier

Plusieurs projets open source majeurs (Linux kernel, Debian, Arch, OpenBSD) exigent des commits signés pour contributions.

2. Signatures de packages OS

Tous les package managers Linux majeurs reposent sur PGP pour vérifier l'authenticité des packages :

DistributionPackage managerMécanisme
Debian / Ubuntuapt/etc/apt/trusted.gpg.d/ + apt-key (déprécié) ou signed-by
Red Hat / CentOS / Fedorayum / dnf/etc/pki/rpm-gpg/
Arch LinuxpacmanMaster Keys + signatures développeurs
OpenSUSEzypperPGP keys

Sans PGP, un attaquant man-in-the-middle pourrait servir des packages modifiés. La signature PGP + vérification côté client empêche cela.

3. Signatures de releases GitHub

Projets sérieux signent leurs releases (tarball, binaires) avec PGP. Permet aux utilisateurs de vérifier que le téléchargement n'a pas été altéré.

# Exemple : vérifier release Ubuntu
wget https://releases.ubuntu.com/24.04/SHA256SUMS
wget https://releases.ubuntu.com/24.04/SHA256SUMS.gpg
gpg --keyserver keyserver.ubuntu.com --recv-keys 843938DF228D22F7B3742BC0D94AA3F0EFE21092
 
gpg --verify SHA256SUMS.gpg SHA256SUMS
# gpg: Good signature from "Ubuntu CD Image Automatic Signing Key..."
 
sha256sum -c SHA256SUMS
# ubuntu-24.04-desktop-amd64.iso: OK

4. Workflows journalistiques confidentiels

SecureDrop (Freedom of the Press Foundation) : plateforme utilisée par The Guardian, Washington Post, Le Monde, New York Times pour recevoir des documents de lanceurs d'alerte. Repose sur PGP pour le chiffrement end-to-end des documents soumis.

ProtonMail : service email chiffré utilisant OpenPGP sous le capot (utilisateurs pro uniquement, web UI transparente).

5. Signatures Sigstore Cosign (historique)

Sigstore Cosign supporte aussi les signatures PGP pour compatibilité avec workflows existants, bien que le pattern keyless OIDC soit préféré en 2026.

Alternatives modernes à PGP

Cinq outils modernes qui remplacent PGP pour des cas d'usage spécifiques.

age — Chiffrement de fichiers moderne

age (Filippo Valsorda, ex-Cryptography Engineer chez Google, depuis 2019) est la reinvention moderne du chiffrement de fichiers.

  • Simplicité : un seul algorithme (X25519 + ChaCha20-Poly1305), pas de négociation.
  • UX CLI épurée : une commande pour chiffrer, une pour déchiffrer.
  • Pas de mainteneur unique de Web of Trust.
# Installation (Homebrew, apt, binary)
brew install age
 
# Génération paire de clés
age-keygen -o key.txt
# Public key: age1qqq...
# Clé privée dans key.txt (protéger)
 
# Chiffrer un fichier
age -r age1qqq... -o message.age message.txt
 
# Déchiffrer
age -d -i key.txt message.age > message.txt
 
# Avec passphrase (pas de clés)
age -p -o backup.age important.pdf
 
# Pour plusieurs destinataires
age -r alice_public_key -r bob_public_key -o shared.age document.pdf

Adopté par SOPS (Mozilla) pour remplacer PGP dans secrets encryption DevOps, github.com/FiloSottile/age pour l'écosystème, rage est le portage Rust.

Sigstore — Signatures d'artefacts sans gestion de clés

Sigstore (OpenSSF, depuis 2021) remplace PGP pour les signatures d'artefacts logiciels modernes.

  • Keyless : pas de gestion de clés longue durée, identité via OIDC (GitHub Actions, Google, Microsoft).
  • Transparency log : Rekor logs immuables publics pour audit.
  • Composants : Cosign (CLI), Fulcio (CA), Rekor (transparency log).
# Signer un artefact (container image) sans clé, via GitHub Actions OIDC identity
cosign sign --yes my-registry.example.test/app:v1.2.3
 
# Vérifier
cosign verify \
  --certificate-identity-regexp='^https://github.com/org/repo/' \
  --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
  my-registry.example.test/app:v1.2.3

Adopté par Kubernetes, PyPI (trusted publishing), npm, RubyGems pour signer releases. Remplace progressivement PGP pour signatures releases GitHub.

Signal — Messaging confidentiel

Signal Protocol (Moxie Marlinspike, Trevor Perrin, 2013+) est le protocole de messagerie chiffrée end-to-end de référence. Utilisé par Signal, WhatsApp, Facebook Messenger (secret chats), Skype.

  • Forward secrecy : Double Ratchet, chaque message a une clé unique.
  • UX transparente : aucune friction utilisateur.
  • Metadata protection : sealed sender.

Remplace PGP pour messaging confidentiel individuel. Pas pour artefacts logiciels ou signatures documents formels.

S/MIME — Email chiffré entreprise

S/MIME (Secure/Multipurpose Internet Mail Extensions) est l'alternative PKI X.509 pour email chiffré. Intégré natif dans Outlook, Apple Mail, Thunderbird.

  • PKI X.509 centralisée : certificats émis par CA (DigiCert, Sectigo).
  • UX transparente : signature et chiffrement automatiques si certificats présents.
  • Enterprise-friendly : gestion via MDM, Exchange, Active Directory.

Déployé dans grands groupes pour email interne sensible. Ne couvre pas les communications externes avec parties n'ayant pas de certificat S/MIME.

Keyoxide — Vérification d'identité moderne

Keyoxide (2020+) : alternative moderne au Web of Trust en associant clés PGP à identités publiques (GitHub, Bluesky, Twitter, domaines web) via preuves cryptographiques.

Adopté par communauté libre pour simplifier la vérification d'identité sans key signing parties physiques.

Limitations de PGP

Critiques documentées et reconnues de PGP.

UX complexe

  • Génération de clés exige choix techniques (algorithme, taille, validité).
  • Gestion des keyrings (trousseaux) complexe.
  • Vérification manuelle des signatures laborieuse.
  • Utilisateurs non-techniques abandonnent rapidement.

Algorithmes historiques

  • Par défaut, PGP accepte encore SHA-1 et RSA-1024 pour compatibilité legacy (à désactiver explicitement).
  • Longtemps pas de support AEAD moderne (RFC 9580 corrige cela, 2024).

SKS Keyservers problèmes historiques

En 2019, le SKS (Synchronizing Key Server) network a subi une attaque : upload massif de signatures malveillantes sur clés populaires (incluant Robert Hansen, Daniel Kahn Gillmor) causant des DoS pour users GnuPG. Démontre la fragilité du modèle Web of Trust décentralisé.

Remplacement progressif par keys.openpgp.org (2019+, modération activée) et Web Key Directory (WKD) (distribution via HTTPS depuis le domaine du owner).

Efail (mai 2018)

CVE-2017-17688, CVE-2017-17689 : exfiltration de contenu déchiffré via HTML injection dans clients email. Pas une faiblesse de PGP intrinsèque mais des clients email. Impact réputationnel majeur sur adoption PGP email grand public.

Moxie Marlinspike "GPG and me" (2015)

Article critique célèbre de Moxie Marlinspike (créateur Signal) : "GPG is not a path forward for encryption". Points soulevés :

  • Modèle de confiance fragile.
  • UX inadaptée aux utilisateurs moyens.
  • Pas de forward secrecy.
  • Architecture figée dans les années 90.
  • Proposition : abandonner PGP pour email, utiliser Signal.

Article devenu référentiel dans la communauté crypto, accélère le déclin PGP grand public.

RFC 9580 : OpenPGP modernisé (2024)

Publication de RFC 9580 en juillet 2024 modernise OpenPGP après 17 ans de RFC 4880.

Changements principaux

ÉvolutionRFC 4880RFC 9580
SignaturesRSA, DSA, ECDSA+ EdDSA (Ed25519, Ed448) préféré
Chiffrement asymétriqueRSA, Elgamal+ ECDH X25519, X448
AEADCFB mode legacyOCB, EAX, GCM modernes
HashSHA-2 family+ SHA-3 optionnel, SHA-1 interdit pour signatures
Keys expiredPas de rollover standardiséKey update mechanism

Impact utilisateurs

  • Migration progressive depuis GnuPG 2.5 (janvier 2025) et Sequoia PGP moderne.
  • Compatibility bridge pendant années 2025-2028.
  • Nouvelle recommandation 2026 : générer clés en Ed25519/Curve25519 plutôt que RSA.

Pièges fréquents avec PGP en 2026

Cinq erreurs observées dans les déploiements PGP.

1. Utilisation de RSA-1024 legacy

Des clés RSA-1024 générées avant 2010 subsistent encore. Strictement déprécié depuis 2014 (NIST SP 800-57), recommandation NIST : RSA-2048 minimum, RSA-3072 pour long-terme. En 2026, générer en Ed25519 plutôt que RSA.

2. Passphrase faible

La passphrase de la clé privée est le secret de plus haute valeur. Passphrase faible = attaquant qui obtient le fichier peut la cracker via hashcat/John the Ripper. Passphrase forte (15+ caractères aléatoires, gérée par password manager) obligatoire.

3. Pas de certificat de révocation

Si la clé privée est perdue ou compromise sans certificat de révocation pré-généré, impossible de révoquer. La clé publique reste considérée valide par Web of Trust indéfiniment. Toujours générer le certificat de révocation à la création et le stocker hors ligne (papier imprimé coffre-fort).

4. Confondre signature et chiffrement

Beaucoup d'utilisateurs débutants confondent :

  • Signer un document : prouver qu'il vient de vous (signature avec votre clé privée, vérifiable par votre clé publique).
  • Chiffrer pour un destinataire : seul le destinataire peut le déchiffrer (chiffrement avec la clé publique du destinataire).

Erreur fréquente : tenter de "chiffrer avec sa propre clé privée" (non-sens). Utiliser les bonnes commandes GnuPG : --sign vs --encrypt --recipient.

5. Utiliser PGP pour email grand public

En 2026, déconseillé pour messagerie personnelle. UX médiocre, adoption quasi-nulle parmi utilisateurs moyens, Signal et Wire offrent meilleur rapport sécurité/convivialité. PGP reste pertinent pour journalistes, lanceurs d'alerte, communautés techniques — pas usage quotidien.

Migration PGP → alternatives modernes

Stratégie de migration par cas d'usage.

Cas d'usageSolution 2026 recommandée
Messaging personnelSignal, Wire
Email sensible grand publicSignal (si possible), sinon PGP avec client moderne (Thunderbird + Enigmail)
Email enterpriseS/MIME (intégré Outlook, Apple Mail)
Chiffrement fichiersage (CLI moderne)
Signatures de commits GitPGP (Ed25519) ou Sigstore gitsign
Signatures de releasesSigstore Cosign (moderne) ou PGP (legacy)
Signatures packages OSPGP (standard établi, pas d'alternative en production)
Communications journalistiques confidentiellesPGP (via SecureDrop, ProtonMail)
Secrets en DevOpsSOPS + age (moderne) ou SOPS + PGP (legacy)

Points clés à retenir

  • PGP (Pretty Good Privacy) créé en 1991 par Phil Zimmermann, standardisé IETF OpenPGP depuis 1998 (RFC 2440), modernisé en juillet 2024 (RFC 9580). GnuPG (GPG) est l'implémentation open source de référence.
  • Web of Trust : modèle de confiance décentralisé pair-à-pair unique, distinct de PKI X.509 centralisée (TLS). Résistant à la compromission CA mais UX complexe, adoption limitée communautés techniques.
  • En 2026, PGP en déclin grand public (Signal remplace messaging, age remplace chiffrement fichiers, Sigstore remplace signatures artefacts) mais reste massivement utilisé pour signatures commits Git, packages OS (apt, rpm, pacman), releases GitHub, workflows journalistiques confidentiels.
  • RFC 9580 (2024) modernise OpenPGP avec Ed25519/X25519 préférés, AEAD moderne. Support GnuPG depuis version 2.5 (janvier 2025).
  • Alternatives modernes par cas d'usage : age pour fichiers, Sigstore pour artefacts, Signal pour messaging, S/MIME pour email entreprise. PGP reste pertinent pour signatures packages OS, commits Git, journalistes.

Pour aller plus loin

Questions fréquentes

  • PGP est-il encore utilisé en 2026 ?
    Oui, mais en déclin relatif. PGP reste déployé pour des cas spécifiques : signatures de commits Git (GitHub, GitLab adoptent intensivement), signatures de packages OS (Debian, Ubuntu, Red Hat, Arch), signatures de releases GitHub, signatures de containers Docker Hub, workflows journalistiques confidentiels (ProtonMail, Thunderbird). Pour email end-to-end grand public, PGP est largement remplacé par Signal (messaging), S/MIME (email entreprise), ou simplement TLS entre serveurs mail. Pour signatures d'artefacts logiciels modernes, Sigstore Cosign gagne rapidement du terrain depuis 2021. Le déclin UX de PGP est documenté, mais les cas d'usage machine-to-machine (signatures automatisées) restent massifs.
  • Quelle différence entre PGP, OpenPGP et GnuPG ?
    PGP (Pretty Good Privacy) est le nom historique du logiciel créé par Phil Zimmermann en 1991, initialement commercial puis acquis par Symantec en 2010 (Symantec Encryption Desktop, aujourd'hui Broadcom). OpenPGP est le standard ouvert basé sur PGP, standardisé IETF depuis RFC 2440 (1998), mis à jour RFC 4880 (2007), puis RFC 9580 (juillet 2024) avec algorithmes modernes. GnuPG (GPG) est l'implémentation open source de référence d'OpenPGP, développée par Werner Koch depuis 1997, déployée par défaut sur la quasi-totalité des distributions Linux. En pratique 2026, 'PGP' désigne souvent GnuPG/OpenPGP.
  • Web of Trust vs PKI centralisée (X.509) : quelle différence ?
    Web of Trust (PGP) est un modèle de confiance décentralisé : chaque utilisateur signe les clés publiques des autres utilisateurs qu'il rencontre physiquement (meet the person, check passport, sign key). La confiance se construit par la communauté via chains de signatures. Avantage : pas de single point of failure, résistant à la compromission d'une autorité unique. Inconvénient : UX complexe, courbe d'apprentissage abrupte, key signing parties peu scalables. PKI X.509 (TLS certificats) est un modèle centralisé : quelques CA de confiance (Let's Encrypt, DigiCert) émettent des certificats qui sont acceptés par tous les clients. Avantage : scalable, automatisable, UX transparente. Inconvénient : compromission CA = compromission massive. En pratique 2026, PKI X.509 domine largement pour toute communication grand public ; PGP Web of Trust reste utilisé par communautés techniques niche.
  • Pourquoi Efail a-t-il marqué le déclin de PGP pour email ?
    Efail (CVE-2017-17688, CVE-2017-17689, mai 2018) est une série de vulnérabilités dans les clients email utilisant OpenPGP et S/MIME qui permettaient à un attaquant d'exfiltrer le contenu déchiffré via HTML injection. Les vulnérabilités étaient principalement côté clients email (Thunderbird, Outlook, Apple Mail), pas dans PGP lui-même, mais ont pointé du doigt l'UX cauchemardesque de PGP email : les utilisateurs devaient désactiver HTML, faire confiance aux plugins tiers, maintenir leurs clés. Moxie Marlinspike (Signal) et d'autres avaient déjà critiqué PGP sévèrement (article 'GPG and me' 2015). Efail a accéléré la migration vers Signal pour messaging confidentiel individuel, laissant PGP pour cas d'usage machine et communautés techniques exigeantes.
  • Comment signer mes commits Git avec PGP ?
    Processus en 4 étapes. 1) Générer une paire PGP : `gpg --full-generate-key` (choisir ECC Ed25519 recommandé en 2026). 2) Exporter la clé publique et l'ajouter à GitHub/GitLab : `gpg --armor --export <KEYID>` puis coller dans Settings → SSH and GPG keys. 3) Configurer Git : `git config --global user.signingkey <KEYID>` puis `git config --global commit.gpgsign true`. 4) Commit : `git commit -m 'message'` signe automatiquement. GitHub affiche 'Verified' badge sur les commits signés. Alternative moderne 2026 : Sigstore gitsign (keyless signing via OIDC GitHub Actions identity, sans gestion de clés).
  • age et Sigstore remplacent-ils PGP ?
    Partiellement pour des cas spécifiques. age (Filippo Valsorda, 2019) remplace PGP pour le chiffrement de fichiers : syntaxe simple, algorithmes modernes (X25519 + ChaCha20-Poly1305), UX CLI épurée. Adopté par SOPS Mozilla, GitHub Actions encrypted secrets, diverses tools DevOps. Sigstore (OpenSSF, 2021) remplace PGP pour signatures d'artefacts : Cosign pour containers, gitsign pour commits Git, keyless via OIDC identity, transparency log Rekor. Adopté par Kubernetes, PyPI, npm, RubyGems, pour signer releases. age et Sigstore ne couvrent pas tous les cas PGP (pas de chiffrement email, pas de Web of Trust), mais couvrent les usages modernes dev-centric. Pattern 2026 : age pour fichiers, Sigstore pour artefacts, Signal pour messaging, PGP pour email sensible communautés techniques.

Écrit par

Naim Aouaichia

Expert cybersécurité et fondateur de Zeroday Cyber Academy

Expert cybersécurité avec un master spécialisé et un parcours hybride : développement, DevOps, DevSecOps, SOC, GRC. Fondateur de Hash24Security et Zeroday Cyber Academy. Formateur et créateur de contenu technique sur la cybersécurité appliquée, la sécurité des LLM et le DevSecOps.