Le chiffrement des emails reste l'un des défis de sécurité les plus persistants en entreprise : malgré des décennies de disponibilité, PGP/GPG n'a jamais atteint l'adoption massive que ses créateurs espéraient. Pourtant, en 2026, les cas d'usage professionnels se multiplient — communications sensibles avec des clients, protection des données personnelles exigée par le RGPD, sécurisation des échanges avec des autorités ou des avocats. Phil Zimmermann a créé PGP (Pretty Good Privacy) en 1991, provoquant une affaire juridique aux États-Unis où les algorithmes cryptographiques étaient considérés comme des munitions à l'export. Cette bataille a conduit à la libéralisation de la cryptographie et à la naissance du standard OpenPGP (RFC 4880). GnuPG (GPG) est l'implémentation libre de référence, incluse dans toutes les distributions Linux et disponible sur Windows (Gpg4win) et macOS (GPG Suite). Ce guide couvre la cryptographie asymétrique sous-jacente, le choix des algorithmes modernes (Ed25519 vs RSA-4096), la génération et la gestion des clés, le chiffrement et la signature en ligne de commande, la configuration de Thunderbird avec OpenPGP intégré, la toile de confiance et les limites de PGP en entreprise. Nous abordons aussi les cas d'usage RGPD et la comparaison avec S/MIME.

Histoire de PGP : Phil Zimmermann, la Crypto Wars et OpenPGP

L'histoire de PGP est indissociable de la lutte pour la liberté cryptographique. En juin 1991, Phil Zimmermann publie PGP 1.0 gratuitement sur Internet — le premier outil de chiffrement fort accessible au grand public. Le gouvernement américain réagit en ouvrant une enquête criminelle : les lois ITAR (International Traffic in Arms Regulations) classifiaient la cryptographie forte comme arme de guerre, son export sans licence était illégal.

L'affaire Zimmermann a duré 3 ans (1991-1996) et s'est soldée par un abandon des poursuites. Elle a galvanisé la communauté technique mondiale et contribué à la révision des lois d'export cryptographiques américaines en 2000. Entre-temps, la communauté open source a travaillé à standardiser PGP via l'IETF, aboutissant au standard OpenPGP (RFC 2440 en 1998, remplacé par RFC 4880 en 2007).

GnuPG (GNU Privacy Guard) a été créé par Werner Koch en 1997 comme implémentation libre du standard OpenPGP, financée initialement par le gouvernement allemand. En 2026, GPG 2.4.x est la version de référence, avec support natif des algorithmes modernes (Ed25519, Curve25519, AES-256-GCM).

Le Standard actuel est en transition vers OpenPGP v6 (RFC 9580, ratifiée en 2024) qui modernise les algorithmes par défaut et améliore la sécurité des paires de clés.

Cryptographie Asymétrique : Principes et Fonctionnement

La cryptographie asymétrique (ou à clé publique) repose sur une paire de clés mathématiquement liées :

  • Clé publique : partageable librement. Elle sert à chiffrer des messages destinés au propriétaire de la paire, et à vérifier les signatures numériques créées par la clé privée correspondante.
  • Clé privée : strictement confidentielle. Elle sert à déchiffrer les messages chiffrés avec la clé publique correspondante, et à créer des signatures numériques.

En pratique pour l'email chiffré :

  1. Alice génère sa paire de clés (publique + privée)
  2. Alice publie sa clé publique (email, serveur de clés, WKD)
  3. Bob chiffre un email avec la clé PUBLIQUE d'Alice
  4. Seule Alice peut déchiffrer avec sa clé PRIVÉE

Pour la signature numérique :

  1. Alice signe un email avec sa clé PRIVÉE
  2. N'importe qui peut vérifier la signature avec la clé PUBLIQUE d'Alice
  3. La vérification confirme que le message vient bien d'Alice (authenticité) et n'a pas été modifié (intégrité)

En pratique, PGP n'utilise pas la cryptographie asymétrique pour chiffrer tout le message (trop lent pour les gros fichiers). Il génère une clé symétrique aléatoire (session key), chiffre le message avec AES, puis chiffre la session key avec la clé RSA/ECC du destinataire. Le destinataire déchiffre la session key avec sa clé privée, puis déchiffre le message avec AES. C'est le schéma hybride.

Algorithmes Recommandés en 2026 : Ed25519 vs RSA-4096

Le choix de l'algorithme a un impact sur la taille des clés, la vitesse et la sécurité à long terme :

RSA-4096 : l'ancien standard "sécurisé". Clés de 4096 bits, opérations plus lentes (surtout la génération de clé). Meilleure compatibilité avec les anciens clients PGP (GnuPG <2.1, certains clients macOS). Recommandé uniquement pour l'interopérabilité avec des systèmes anciens.

Ed25519 + Curve25519 (recommandé 2026) : basé sur les courbes elliptiques (ECDSA/EdDSA). Clés 32 fois plus petites que RSA-4096 (256 bits vs 4096 bits) pour une sécurité équivalente ou supérieure. Opérations 10 à 20 fois plus rapides. Résistance supérieure aux attaques par timing. Ed25519 pour la signature, Curve25519 (X25519) pour le chiffrement via ECDH.

Résistance post-quantique : Ed25519 et RSA-4096 ne sont pas résistants à un ordinateur quantique suffisamment puissant (algorithme de Shor). En 2026, aucun ordinateur quantique cryptographiquement pertinent n'existe, mais la transition vers des algorithmes post-quantiques (CRYSTALS-Kyber, CRYSTALS-Dilithium, standardisés par NIST) commence. OpenPGP v6 inclut des provisions pour les futurs algorithmes post-quantiques.

Pour les usages professionnels actuels, Ed25519 + Curve25519 est le bon choix : clés compactes, rapides, sécurisées et supportées par tous les clients modernes (GPG 2.4, Thunderbird 115+, Protonmail, Fastmail).

Installation de GPG selon l'OS

Linux (déjà installé dans la majorité des distributions) :

gpg --version
# GnuPG 2.4.x est la version moderne
# Si GnuPG 1.x : installez gpg2 via votre gestionnaire de packages

# Ubuntu/Debian
apt install gnupg2

# Fedora/RHEL
dnf install gnupg2

Windows — Gpg4win : téléchargez Gpg4win depuis gpg4win.org (version 4.x). Gpg4win inclut GnuPG, Kleopatra (interface graphique), GpgOL (plugin Outlook) et GpgEX (intégration Explorateur Windows). Kleopatra est l'interface recommandée pour les utilisateurs Windows non techniques.

macOS — GPG Suite : disponible sur gpgtools.org. Inclut GPGMail (plugin Apple Mail), GPG Keychain (gestionnaire de clés graphique) et la CLI GPG. GPGMail nécessite un abonnement payant depuis 2018 pour les nouvelles versions macOS.

Alternative cross-platform : Kleopatra est disponible dans Gpg4win sur Windows et comme composant KDE sur Linux. Son interface graphique simplifie la gestion des clés pour les utilisateurs non techniques.

Génération d'une Paire de Clés Ed25519

# Génération rapide (algorithmes par défaut GnuPG 2.4 = Ed25519+Curve25519)
gpg --gen-key
# Entrez : nom complet, email, passphrase forte

# Génération avec toutes les options
gpg --full-gen-key
# (9) ECC (sign and encrypt) → Curve 25519
# Durée de validité : 2y (recommandé — forcer la révision régulière)
# Confirmez avec la passphrase

Structure d'une clé GPG :

  • Clé principale (primary key) : Ed25519 [SC] — Sign + Certify. Sert à signer des documents et à certifier d'autres clés dans la toile de confiance. NE DOIT PAS servir à chiffrer.
  • Sous-clé de chiffrement (encryption subkey) : Curve25519 [E] — créée automatiquement. C'est elle qui chiffre les emails.
  • UID (User ID) : "Prénom Nom <email@domain.com>" — plusieurs UIDs peuvent être ajoutés (adresses email alternatives)
  • Date d'expiration : la clé expire et doit être renouvelée. Recommandation : 2 ans, avec renouvellement avant expiration.
# Lister vos clés
gpg --list-keys --keyid-format LONG

# Output typique :
# pub   ed25519/AAAA1234BBBB5678 2024-01-15 [SC] [expires: 2026-01-15]
#       FINGERPRINT_40_CHARS
# uid           [ultimate] Alice Martin <alice@example.com>
# sub   cv25519/CCCC9012DDDD3456 2024-01-15 [E] [expires: 2026-01-15]

Partage de la Clé Publique et Serveurs de Clés

Pour que d'autres puissent vous envoyer des emails chiffrés, ils doivent avoir accès à votre clé publique :

# Exporter la clé publique en ASCII (à envoyer par email ou publier)
gpg --export --armor alice@example.com > alice_public_key.asc

# Vérifier le contenu
cat alice_public_key.asc
# -----BEGIN PGP PUBLIC KEY BLOCK-----
# ...

Serveur de clés keys.openpgp.org : le serveur de clés recommandé en 2026. Contrairement aux anciens serveurs (SKS Keyservers), il valide les UIDs par email avant publication, évitant le spam de fausses clés.

# Uploader votre clé publique
gpg --keyserver keys.openpgp.org --send-keys VOTRE_FINGERPRINT

# Télécharger la clé d'un correspondant
gpg --keyserver keys.openpgp.org --search-keys alice@example.com

WKD (Web Key Directory) : méthode moderne de distribution automatique des clés. Si votre serveur mail supporte WKD, les clients GPG peuvent récupérer automatiquement votre clé depuis votre domaine (pas besoin de serveur de clés tiers). Protonmail et Fastmail supportent WKD nativement. Pour un domaine personnel, configurez WKD en créant l'endpoint https://VOTRE-DOMAINE/.well-known/openpgpkey/.

Chiffrement et Déchiffrement en Ligne de Commande

# Chiffrer un fichier pour Alice (nécessite sa clé publique)
gpg --encrypt --recipient alice@example.com document_confidentiel.pdf
# Crée document_confidentiel.pdf.gpg

# Chiffrer pour plusieurs destinataires
gpg --encrypt 
  --recipient alice@example.com 
  --recipient bob@company.com 
  document.txt

# Chiffrer ET signer (authenticité + confidentialité)
gpg --encrypt --sign 
  --recipient alice@example.com 
  --local-user votreemail@domain.com 
  document.txt

# Déchiffrer
gpg --decrypt document_confidentiel.pdf.gpg > document_confidentiel.pdf
# GPG demande votre passphrase pour déverrouiller la clé privée

Chiffrement symétrique (sans clé publique) : pour chiffrer un fichier avec un mot de passe partagé (pas de gestion de clés) :

gpg --symmetric --cipher-algo AES256 fichier_archive.tar.gz
# Crée fichier_archive.tar.gz.gpg avec protection par mot de passe

Signature Numérique : Clearsign, Detach-Sign et Vérification

# Signature intégrée au texte (clearsign) — texte lisible + signature
gpg --clearsign message.txt
# Crée message.txt.asc avec texte + signature PGP

# Signature détachée (fichier séparé)
gpg --detach-sign document.pdf
# Crée document.pdf.sig

# Signature + chiffrement binaire
gpg --sign document.txt
# Crée document.txt.gpg (binaire)

# Vérification de signature
gpg --verify message.txt.asc
gpg --verify document.pdf.sig document.pdf

La vérification retourne "Good signature from [nom] [fingerprint]" si valide, ou "BAD signature" si le fichier a été modifié après signature. La signature détachée est préférable pour les fichiers binaires (PDF, ZIP) car elle laisse le fichier original intact.

Le chiffrement GPG des communications sensibles est une bonne pratique de conformité SIEM — les logs de déchiffrement constituent une preuve de due diligence pour les audits RGPD.

Thunderbird avec OpenPGP Intégré : Configuration Pas à Pas

Depuis Thunderbird 78 (2020), OpenPGP est intégré nativement — l'extension Enigmail n'est plus nécessaire. La configuration est simplifiée mais quelques étapes sont requises :

1. Importer ou générer votre clé dans Thunderbird :

Menu Thunderbird → Paramètres du compte → [votre compte] → Chiffrement de bout en bout
→ Ajouter une clé → Importer une clé existante (recommandé si vous avez déjà un trousseau GPG)
  ou Générer une nouvelle clé OpenPGP

2. Configurer le chiffrement par défaut : dans les paramètres du compte, activez "Chiffrer les messages par défaut" si vous voulez que tous vos emails soient chiffrés automatiquement (requiert que tous vos correspondants aient une clé publique disponible). Activez "Signer les messages par défaut" — cela n'affecte pas la lisibilité mais prouve l'authenticité.

3. Importer les clés publiques de vos correspondants :

Menu Outils → Gestionnaire de clés OpenPGP
→ Importer → Depuis un fichier (clé .asc reçue par email)
  ou Chercher sur un serveur de clés → Entrez l'email du correspondant

4. Envoyer un email chiffré : lors de la composition d'un email, si Thunderbird a la clé publique du destinataire, une icône de cadenas apparaît dans la barre d'outils. Activez le chiffrement — l'email sera chiffré avant envoi. Le destinataire doit avoir installé GPG et Thunderbird pour déchiffrer.

Toile de Confiance et Ses Limites

La toile de confiance (Web of Trust) est le mécanisme de validation décentralisé de PGP. Elle repose sur un principe simple : si vous faites confiance à Alice, et qu'Alice a vérifié et signé la clé de Bob, vous pouvez faire confiance à Bob transitivement.

En pratique, la toile de confiance présente des limites importantes :

  • Complexité pour l'utilisateur final : comprendre les niveaux de confiance (ultimate, full, marginal) est contre-intuitif
  • Clé compromise non révoquée : si Alice perd sa clé privée, toutes ses signatures de confiance sont compromises
  • Pas de PKI centralisée : impossible d'imposer des politiques de sécurité à l'échelle d'une organisation
  • Scalabilité nulle : impraticable pour des organisations de plus de quelques dizaines de personnes

Keybase était une alternative centralisée à la toile de confiance, permettant de lier sa clé GPG à ses identités publiques (GitHub, Twitter, site web). Racheté par Zoom en 2020, son développement a ralenti. En 2026, les WKD (Web Key Directory) et les intégrations natives dans les clients mail (Protonmail, Tutanota) ont largement remplacé le besoin de Keybase.

S/MIME vs PGP/GPG : Quel Standard en Entreprise ?

S/MIME (Secure/Multipurpose Internet Mail Extensions) est l'alternative à PGP pour le chiffrement d'email, préférée dans les environnements d'entreprise :

  • PKI centralisée : les certificats S/MIME sont délivrés par une CA interne (Active Directory Certificate Services) ou externe (GlobalSign, Sectigo). L'entreprise contrôle entièrement la chaîne de confiance.
  • Intégration Windows/Office 365 : S/MIME est nativement supporté dans Outlook sans plugin, avec gestion automatique des certificats via GPO Active Directory.
  • Révocation simplifiée : un employé quitte l'entreprise → le certificat est révoqué depuis la CA centrale, immédiatement effectif pour tous les clients.
  • Conformité réglementaire : S/MIME avec une PKI interne est plus facile à justifier lors d'audits ISO 27001 — la chaîne de confiance est documentée et auditée.

PGP/GPG est préférable pour :

  • Communications avec des parties externes (journalistes, avocats, lanceurs d'alerte) qui n'ont pas accès à la PKI interne
  • Individus ou petites structures sans Active Directory
  • Chiffrement de fichiers et d'archives (S/MIME ne gère que les emails)

En pratique, les grandes entreprises utilisent S/MIME en interne et GPG pour les communications sensibles avec l'externe. La gestion des certificats S/MIME dans un environnement Active Directory est documentée dans nos guides dédiés.

Cas d'Usage RGPD : Chiffrement et Due Diligence

Le RGPD n'impose pas explicitement le chiffrement GPG/PGP, mais l'article 32 exige des "mesures techniques appropriées" pour protéger les données personnelles. Le chiffrement des communications sensibles répond à cette obligation.

Cas d'usage RGPD concrets :

  • Transmission de données personnelles par email : envoi de fichiers Excel avec données clients, RH ou médicales → chiffrez avec GPG avant envoi
  • Preuve de due diligence : en cas de violation de données, démontrer que les emails sensibles étaient chiffrés réduit significativement les amendes CNIL et la responsabilité civile
  • Droit d'accès et de portabilité : les exports de données personnelles envoyés à des personnes concernées doivent être sécurisés — GPG est une solution simple

À retenir

  • Ed25519 + Curve25519 est le standard recommandé en 2026 — clés plus petites, plus rapides et plus sûres que RSA-4096
  • Thunderbird 78+ inclut OpenPGP nativement — plus besoin d'Enigmail pour le chiffrement d'email sous Linux/Windows
  • La toile de confiance PGP ne fonctionne pas à l'échelle de l'entreprise — S/MIME avec PKI Active Directory est préférable en interne
  • Le chiffrement GPG des emails sensibles constitue une mesure technique au sens de l'article 32 RGPD — documentez son usage

Questions fréquentes sur GPG et PGP

Ma clé GPG a expiré — comment la renouveler sans perdre mes messages archivés ?

L'expiration d'une clé GPG ne la détruit pas — elle signale que vous devez renouveler votre engagement sur cette clé. Vous pouvez étendre la date d'expiration sans changer la paire de clés : gpg --edit-key VOTRE-EMAIL, puis la commande "expire" et "save". Les messages chiffrés avec votre ancienne clé publique restent déchiffrables avec votre clé privée, même après renouvellement. Publiez la clé renouvelée sur le serveur de clés pour que vos correspondants voient la nouvelle date d'expiration. Important : ne perdez jamais votre clé privée et sa passphrase — sans elles, vos archives chiffrées sont irrécupérables.

Protonmail utilise-t-il GPG/OpenPGP ?

Oui, Protonmail implémente OpenPGP pour le chiffrement de bout en bout. Les emails entre utilisateurs Protonmail sont automatiquement chiffrés. Pour les emails vers des adresses externes, Protonmail peut utiliser la clé GPG publique du destinataire si vous l'importez dans votre profil. Protonmail supporte aussi WKD pour découvrir automatiquement les clés GPG des domaines qui l'implémentent. La particularité de Protonmail est que vos clés privées sont stockées sur leurs serveurs (chiffrées avec votre passphrase) — un modèle différent du GPG traditionnel où vous contrôlez entièrement votre clé privée.

Est-il sécurisé de publier sa clé publique GPG sur un serveur de clés ?

Oui, publier sa clé PUBLIQUE est totalement sécurisé par définition — la clé publique est conçue pour être partagée. Sur keys.openpgp.org (recommandé), la publication nécessite une validation par email, ce qui évite que quelqu'un publie une fausse clé à votre nom. Les anciens serveurs SKS (maintenant dépréciés) permettaient des publications non-validées. Le fingerprint de votre clé (40 caractères hexadécimaux) est votre identifiant sécurisé — partagez-le sur votre site web, carte de visite ou profil GitHub pour que vos correspondants puissent vérifier l'authenticité de la clé téléchargée.

Besoin de déployer le chiffrement d'email en entreprise ?

Ayi NEDJIMI accompagne les entreprises dans le déploiement de solutions de chiffrement d'email — GPG pour les communications externes, S/MIME avec PKI Active Directory pour les communications internes. Conformité RGPD et ISO 27001.

Demander un conseil