GPG: signer un fichier, chiffrer un message

Si tu as déjà installé un paquet sous Linux, vérifié un ISO téléchargé ou croisé un commit Git marqué « Verified », tu as utilisé PGP sans forcément le savoir. Derrière ces trois lettres se cache l’un des piliers historiques de la cryptographie grand public: un système qui permet à la fois de chiffrer (rendre un contenu illisible pour tout le monde sauf son destinataire) et de signer (prouver qu’un fichier vient bien de toi et qu’on ne l’a pas modifié).

Dans cet article, on va démystifier PGP, comprendre son fonctionnement en deux minutes, puis passer directement à la pratique avec deux exemples concrets en ligne de commande : signer un fichier que l’on distribue, et échanger un message chiffré entre deux personnes. Tout se fait avec gpg, disponible sur toutes les distributions.

PGP, GPG, OpenPGP : on parle de quoi ?

Ces trois termes reviennent sans cesse et prêtent à confusion. Voici la distinction, une fois pour toutes:

• PGP (Pretty Good Privacy) : le logiciel original, créé par Phil Zimmermann en 1991. C’est aujourd’hui une marque commerciale (longtemps chez Symantec, désormais Broadcom).
• OpenPGP : le standard ouvert issu de PGP, normalisé par l’IETF (RFC 4880, révisée par la RFC 9580 en 2024). C’est la spécification, pas un logiciel.
• GPG / GnuPG (GNU Privacy Guard) : l’implémentation libre de ce standard, développée par Werner Koch depuis 1997. C’est le logiciel que tu utilises réellement via la commande gpg.

En résumé: quand on dit « chiffrer en PGP » sous Linux, on utilise presque toujours GPG. Le terme PGP est resté dans le langage courant comme nom générique, un peu comme « frigidaire » pour réfrigérateur.

Le principe en deux minutes

PGP repose sur la cryptographie asymétrique. Chaque personne possède une paire de clés :

• une clé privée, secrète, protégée par une passphrase, que tu ne partages jamais
• une clé publique, que tu diffuses librement.

Ces deux clés sont mathématiquement liées, et c’est ce lien qui permet deux opérations complémentaires:

• Chiffrer: on chiffre avec la clé publique du destinataire; lui seul pourra déchiffrer avec sa clé privée. C’est ce qui garantit la confidentialité.
• Signer: on signe avec sa propre clé privée; n’importe qui pourra vérifier la signature avec ta clé publique. C’est ce qui garantit l’authenticité et l’intégrité.

Une subtilité technique: chiffrer un gros fichier directement en asymétrique serait lent. PGP utilise donc un chiffrement hybride. Le contenu est chiffré avec un algorithme symétrique rapide (AES) au moyen d’une clé de session aléatoire, et c’est seulement cette petite clé de session qui est chiffrée avec la clé publique du destinataire. On combine ainsi la vitesse du symétrique et la commodité de l’asymétrique. Tout cela est transparent: gpg s’en occupe pour toi.

Installation et génération de sa paire de clés

GnuPG est généralement déjà présent. Sinon:

# Debian / Ubuntu
sudo apt install gnupg

# Fedora / distributions atomiques (Bazzite, Silverblue…)
sudo dnf install gnupg2   # ou : rpm-ostree install gnupg2

On génère ensuite sa paire de clés de façon interactive:

gpg --full-generate-key

GnuPG te pose quelques questions. Mes recommandations:

• Type: choisis ECC (sign and encrypt) avec la courbe Curve 25519 si ta version le propose (GnuPG 2.3+). C’est moderne, rapide et sûr. À défaut, RSA 4096 reste un choix solide.
• Expiration: ne mets jamais « n’expire jamais ». Une durée de 2 ans est raisonnable (on peut toujours la prolonger.)
• Nom et e-mail: ils constituent ton identité (User ID).
• Passphrase: longue et unique. C’est le dernier rempart si ta clé privée fuite.

Une fois la clé créée, deux réflexes indispensables. D’abord, générer tout de suite un certificat de révocation (il te permettra d’invalider ta clé si tu perds l’accès ou si elle est compromise), et le stocker en lieu sûr:

gpg --output revoke-ju.asc --gen-revoke ju@example.com

Ensuite, repérer l’empreinte (fingerprint) de ta clé, qui sert d’identifiant fiable pour la vérification:

gpg --fingerprint ju@example.com

Exemple 1 — Signer un fichier que l’on distribue

Le scénario: je publie sur le blog un script d’installation, hardening.sh. Je veux que quiconque le télécharge puisse vérifier qu’il vient bien de moi et qu’il n’a pas été modifié en route (par un miroir compromis, une attaque man-in-the-middle, etc.). C’est exactement ce que font les dépôts APT/DNF avec chaque paquet.

Côté auteur: créer la signature

On produit une signature détachée: un petit fichier séparé qui accompagne le fichier d’origine, sans le modifier. L’option --armor produit une sortie en texte ASCII (extension .asc), pratique à publier.

gpg --armor --detach-sign hardening.sh

Résultat: un fichier hardening.sh.asc. Je publie les deux fichiers côte à côte (le script et sa signature), ainsi que ma clé publique.

J’exporte ma clé publique pour la mettre à disposition:

gpg --armor --export ju@example.com > ju-pubkey.asc

On peut aussi la publier sur un serveur de clés à validation d’e-mail (recommandé aujourd’hui):

gpg --keyserver hkps://keys.openpgp.org --send-keys <KEYID>

Côté visiteur: vérifier la signature

La personne qui télécharge le script importe d’abord ma clé publique:

gpg --import ju-pubkey.asc

Puis elle vérifie le fichier contre sa signature:

gpg --verify hardening.sh.asc hardening.sh

Si tout est bon, la sortie ressemble à ceci:

gpg: Signature made Wed 16 Jul 2026 10:12:03 CEST
gpg:                using EDDSA key 3AA5...F00D
gpg: Good signature from "Ju <ju@example.com>"

Le message Good signature garantit deux choses: le fichier n’a pas été altéré d’un seul octet, et il a bien été signé par la clé privée correspondant à cette clé publique.

Le point de vigilance tu verras souvent un avertissement du type WARNING: This key is not certified with a trusted signature. C’est normal — il signifie simplement que tu n’as pas certifié personnellement cette clé. La vraie question reste entière: cette clé publique appartient-elle bien à la bonne personne ? Il faut le vérifier par un canal indépendant, en comparant l’empreinte (fingerprint) affichée sur une source de confiance. C’est tout l’enjeu du modèle de confiance, sur lequel on revient plus bas.

Exemple 2 — Échanger un message chiffré

Le scénario: Alice veut envoyer à Bob un message confidentiel que personne d’autre ne pourra lire, même si le message est intercepté. La règle d’or à garder en tête: on chiffre toujours avec la clé publique du destinataire, jamais avec la sienne.

Étape 1 — Bob partage sa clé publique

Bob exporte sa clé publique et l’envoie à Alice (par mail, la publie sur son site, un serveur de clés…) :

gpg --armor --export bob@example.com > bob-pubkey.asc

Étape 2 — Alice importe la clé de Bob

gpg --import bob-pubkey.asc

Avant d’aller plus loin, Alice vérifie l’empreinte de la clé de Bob par un autre canal (un appel, un message signé, une carte de visite…) pour s’assurer qu’elle a bien la vraie clé de Bob:

gpg --fingerprint bob@example.com

Étape 3 — Alice chiffre (et signe) son message

Alice rédige son message dans message.txt, puis le chiffre pour Bob. On ajoute --sign pour que Bob soit aussi certain que le message vient d’Alice : on obtient à la fois confidentialité et authenticité.

gpg --armor --sign --encrypt --recipient bob@example.com message.txt

Résultat: un fichier message.txt.asc qui ressemble à un bloc de texte illisible commençant par -----BEGIN PGP MESSAGE-----. Alice envoie ce fichier à Bob par le canal de son choix, même un canal non sécurisé, puisque le contenu est chiffré.

Étape 4 — Bob déchiffre

Bob déchiffre avec sa clé privée (GnuPG lui demandera sa passphrase):

gpg --decrypt message.txt.asc

GnuPG affiche le message en clair et, comme Alice a signé, confirme l’expéditeur:

Salut Bob, voici les identifiants pour le serveur de test.
gpg: Good signature from "Alice <alice@example.com>"

Et voilà: un aller-retour complet où seul Bob a pu lire le message, avec la garantie qu’il venait bien d’Alice. Si Alice veut aussi que Bob puisse lui répondre de façon chiffrée, il lui suffit d’inverser les rôles, Bob aura besoin de la clé publique d’Alice.

Variante: signer un message texte lisible

Si tu veux seulement signer un message (sans le chiffrer) tout en le gardant lisible, typiquement pour un e-mail ou un post public, utilise --clearsign :

gpg --clearsign message.txt

Le texte reste lisible, encadré par un bloc de signature que n’importe qui peut vérifier avec gpg --verify.

La question de la confiance: le Web of Trust

Tout le système repose sur une hypothèse fragile: être sûr qu’une clé publique appartient bien à la bonne personne. Si un attaquant te refile sa propre clé en se faisant passer pour Bob, tu chiffreras tes messages pour l’attaquant. C’est l’attaque de l’homme du milieu appliquée aux clés.

Contrairement à TLS/HTTPS, qui s’appuie sur des autorités de certification hiérarchiques, PGP a inventé un modèle décentralisé : le Web of Trust. L’idée est que les utilisateurs se certifient mutuellement. Quand tu as vérifié en personne l’empreinte de la clé de Bob, tu peux la signer :

gpg --sign-key bob@example.com

Ta signature atteste publiquement « je confirme que cette clé est bien celle de Bob ». En agrégeant ces attestations, on construit un graphe de confiance. C’était l’esprit des fameuses key signing parties des années 2000. En pratique, ce modèle n’a jamais atteint la masse critique, et la plupart des gens se contentent aujourd’hui de vérifier l’empreinte par un canal indépendant.

Ce que PGP fait bien… et ses limites

PGP/GPG n’est pas la solution universelle. Il faut connaître ses angles morts :

• Ergonomie difficile : la gestion des clés reste rebutante, et les erreurs fatales sont faciles (envoyer en clair par erreur, chiffrer avec la mauvaise clé…). C’est la critique historique, résumée par l’étude « Why Johnny Can’t Encrypt » (1999).
• Pas de forward secrecy : les clés sont durables. Si ta clé privée fuite un jour, tous les messages passés chiffrés vers cette clé deviennent déchiffrables. Les messageries modernes (Signal et son Double Ratchet) renouvellent les clés à chaque message.
• Métadonnées exposées : PGP ne chiffre que le corps du message. Pour un e-mail, l’objet, l’expéditeur, le destinataire et la date restent en clair (souvent plus parlants que le contenu lui-même)
• Écosystème vieillissant : la faille EFAIL (2018) a montré la fragilité de l’intégration dans les clients mail, et la communauté s’est même divisée entre les formats RFC 9580 et LibrePGP.

Pour la messagerie interpersonnelle, la recommandation actuelle penche plutôt vers Signal. Mais pour la signature de code, la vérification d’intégrité et le chiffrement de fichiers au repos, PGP/GPG reste un standard incontournable, sans véritable remplaçant universel — même si des outils plus simples comme age ou minisign grignotent certaines de ces niches.

Pour aller plus loin

Quelques usages qui prolongent naturellement ce qu’on vient de voir : signer ses commits Git (git commit -S), chiffrer une archive avant de l’envoyer sur un stockage distant (gpg --encrypt dans un script de sauvegarde), utiliser une sous-clé GPG stockée sur une YubiKey comme clé SSH, ou encore gérer ses mots de passe avec pass, qui repose entièrement sur GPG.

Le plus simple pour s’approprier l’outil reste de générer une paire de clés et de se signer un fichier à soi-même. En cinq minutes, les concepts de clé publique, clé privée et signature deviennent beaucoup plus concrets. Et une fois le réflexe acquis, on comprend enfin ce que Linux fait silencieusement en arrière-plan à chaque apt upgrade.