Bienvenue dans ce tutoriel consacré à GPG et à son usage quotidien. Ce n'est pas le sujet le plus léger du monde, mais vous allez voir : avec une méthode propre, on peut déjà éviter beaucoup d'erreurs classiques.

Ici, nous utilisons GnuPG en ligne de commande sur GNU/Linux. C'est volontaire : l'interface en terminal reste la plus lisible, la plus portable et souvent la plus explicite quand quelque chose se passe mal.

Au 16 mai 2026, l'amont GnuPG a publié GnuPG 2.5.20. Vos dépôts système peuvent toutefois embarquer une version plus ancienne, ce qui reste normal selon la distribution.

Avant de commencer

Dans la suite, nous utiliserons gpg. C'est la commande canonique sur les systèmes actuels. Sur certaines distributions, gpg2 existe encore comme alias ou paquet de transition, mais il ne faut plus en faire un prérequis.

Sur certaines distributions, GnuPG est déjà installé. Sinon, voici les commandes à privilégier :

# Debian, Ubuntu récentes
apt install gnupg

# Arch Linux
pacman -S gnupg

# Fedora, Red Hat
dnf install gnupg2

# openSUSE
zypper install gpg2
⚠️
Vérification au 16 mai 2026 :
- Debian 13 "trixie" fournit gpg 2.4.7,
- Arch Linux gnupg 2.4.9,
- Fedora 42 gnupg2 2.4.9,
- openSUSE Tumbleweed gpg2 2.5.17.
Les noms de paquets varient, mais la commande utilisateur reste en général gpg.

Configurer GPG proprement

Avant de créer des clés, nous vous recommandons de définir un fichier gpg.conf cohérent sur toutes les machines qui devront signer ou chiffrer.

S'il n'existe pas encore :

touch ~/.gnupg/gpg.conf
chmod 600 ~/.gnupg/gpg.conf

Ajoutez ensuite, au minimum, les paramètres suivants :

# Limite les informations diffusées pour les clés
no-emit-version
no-comments
export-options export-minimal

# Affiche l'ID long et l'empreinte
keyid-format 0xlong
with-fingerprint

# Affiche la validité des clés
list-options show-uid-validity
verify-options show-uid-validity

# Préférences publiées dans vos nouvelles clés
personal-cipher-preferences AES256
personal-digest-preferences SHA512
default-preference-list SHA512 SHA384 SHA256 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

# S2K (String-to-Key)
s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-mode 3

# Le paramètre s2k-count peut être réduit sur une machine peu puissante
# Valeur attendue entre 1024 et 65011712
s2k-count 65011712
⚠️
Nous avons volontairement retiré ici les options trop prescriptives comme cipher-algo, digest-algo, disable-cipher-algo ou weak-digest SHA1. Elles peuvent durcir localement GnuPG, mais aussi casser des usages légitimes ou des échanges avec des clés plus anciennes. Gardez-les pour une politique interne stricte, pas comme base universelle.

En 2026, il faut surtout distinguer compatibilité et bon défaut moderne :

  • ECC moderne pour un nouvel usage personnel : Ed25519 pour la certification et la signature, Curve25519 / cv25519 pour le chiffrement
  • RSA 4096 si vous devez rester compatible avec des outils ou procédures plus anciennes

L'ancien tutoriel du wiki insistait sur RSA 4096 et sur des courbes de 384 bits ou plus. Ce n'est plus tout à fait d'actualité ; GnuPG sait créer des paires ECC par défaut depuis la branche 2.3 et sa documentation expose aussi ed25519/cert,sign+cv25519/encr comme future default.

💡
Pour le volet théorique, nous vous renvoyons vers l'article dédié au chiffrement :
Le Chiffrement
Article traitant des notions de chiffrement dans son ensemble et les outils recommandés.

Créer votre clé maître

La clé maître est la base de votre chaîne de confiance. C'est elle qui certifie l'ensemble. Elle doit donc être générée dans de bonnes conditions.

Nous vous recommandons, autant que possible :

  • une machine hors ligne
  • une machine secondaire ou un système fraîchement démarré
  • si possible, un support déjà chiffré

L'idée est simple : la clé maître sert peu, mais elle sert pour les opérations les plus sensibles. Elle ne doit donc pas vivre sur votre machine principale au quotidien.

Méthode recommandée

Pour un usage personnel classique, nous vous recommandons aujourd'hui une clé maître de certification uniquement, avec des sous-clés dédiées et une durée de vie explicite plutôt que "jamais".

gpg --quick-gen-key "Jean Dupont <jean.dudu@pont.fr>" ed25519 cert 1y

Récupérez ensuite l'empreinte complète de la clé :

gpg --fingerprint "Jean Dupont <jean.dudu@pont.fr>"

Puis ajoutez vos sous-clés :

gpg --quick-add-key VOTRE_EMPREINTE ed25519 sign 1y
gpg --quick-add-key VOTRE_EMPREINTE cv25519 encr 1y

Cette séquence est plus simple à relire, plus conforme aux usages GnuPG récents, et évite de présenter le "jamais d'expiration" comme un bon réflexe par défaut.

Variante RSA, pour compatibilité

Si vous devez absolument rester sur un schéma RSA proche de l'ancien wiki, utilisez alors la génération avancée :

gpg --full-gen-key --expert

Dans l'exemple fourni par l'ancien wiki, la clé maître est créée comme une clé RSA de certification uniquement :

Quel est votre choix ? 8
...
Quel est votre choix ? s
...
Quel est votre choix ? c
...
Quel est votre choix ? q
Quelle taille de clef désirez-vous ? (3072) 4096
Pendant combien de temps la clef est-elle valable ? (0) 0

Concrètement, cela revient à :

  • partir d'une clé RSA paramétrable
  • retirer la capacité de signature
  • retirer la capacité de chiffrement
  • conserver uniquement la capacité de certification
  • choisir une taille de 4096 bits
  • ne pas définir d'expiration dans cet exemple

Ensuite, GPG vous demandera :

  • votre nom
  • votre adresse de courriel
  • éventuellement un commentaire
  • puis une phrase de passe solide

Lorsque la génération se termine, vous obtenez un résultat de ce type :

pub   rsa4096/0xA6F76D3B09BC268A 2022-11-14 [C]
      Empreinte de la clef = 5445 E89C 355F 4FB4 E653  3D47 A6F7 6D3B 09BC 268A
uid                              Jean Dupont <jean.dudu@pont.fr>

Retenez bien deux choses :

  • l'ID long de la clé, ici 0xA6F76D3B09BC268A
  • l'empreinte complète
Voilà, votre première bi-clé PGP est créée.

Petit rappel important : les métadonnées associées à votre clé publique, comme votre nom et votre courriel, seront visibles. PGP n'est pas un outil d'anonymat. Vous pouvez jouer sur le pseudonymat, mais cela change la logique de confiance attachée à la clé.

Créer vos sous-clés

L'approche proposée ici consiste à séparer les usages :

  • une sous-clé pour la signature
  • une sous-clé pour le chiffrement

Dans l'exemple RSA, on repart de l'ID de la clé maître :

gpg --edit-key 0xA6F76D3B09BC268A

Puis, depuis l'invite gpg>, on ajoute les sous-clés.

Sous-clé de signature

gpg> addkey
Quel est votre choix ? 4
Quelle taille de clef désirez-vous ? (3072) 4096
Pendant combien de temps la clef est-elle valable ? (0) 0
Faut-il vraiment la créer ? (o/N) o

Vous obtenez alors une sous-clé marquée [S].

Sous-clé de chiffrement

gpg> addkey
Quel est votre choix ? 6
Quelle taille de clef désirez-vous ? (3072) 4096
Pendant combien de temps la clef est-elle valable ? (0) 0
Faut-il vraiment la créer ? (o/N) o

Vous obtenez alors une sous-clé marquée [E].

Enregistrez enfin le tout :

gpg> save

Vous devriez retrouver une structure de ce type :

gpg -K
sec   rsa4096/0xA6F76D3B09BC268A 2022-11-14 [C]
      Empreinte de la clef = 5445 E89C 355F 4FB4 E653  3D47 A6F7 6D3B 09BC 268A
uid                  [  ultime ] Jean Dupont <jean.dudu@pont.fr>
ssb   rsa4096/0x2C7E486743774AEA 2022-11-14 [S]
ssb   rsa4096/0xD403F40075C53CA0 2022-11-14 [E]

L'article d'origine choisit de ne pas faire expirer les clés. En 2026, nous préférons un message plus prudent : une expiration d'un an ou de deux ans est souvent plus saine, quitte à la prolonger si votre clé reste d'actualité.

💡
Vous avez maintenant une clé maître de certification et deux sous-clés dédiées à l'usage quotidien.

Générer un certificat de révocation

Le certificat de révocation sert à déclarer qu'une clé ne doit plus être considérée comme fiable, par exemple si :

  • elle a été compromise,
  • vous avez perdu le contrôle de la clé,
  • vous avez perdu la phrase de passe.

Depuis GnuPG 2.1, un certificat de révocation est déjà créé automatiquement à la génération de la clé, dans ~/.gnupg/openpgp-revocs.d/. C'est un point important : l'ancien réflexe consistant à chercher un .rev à la racine de ~/.gnupg n'est plus le bon cas général.

Vous pouvez malgré tout en générer un explicitement si vous voulez un fichier nommé à part :

gpg --output ~/.gnupg/A6F76D3B09BC268A.rev --gen-revoke 0xA6F76D3B09BC268A

GPG vous demandera de confirmer la création, puis de choisir une raison. Dans l'exemple, la raison 1 est retenue : la clé a été compromise.

Le résultat sera un fichier .rev, par exemple :

~/.gnupg/A6F76D3B09BC268A.rev
⚠️
Toute personne ayant accès à ce certificat peut rendre votre clé inutilisable. Stockez-le hors ligne, proprement, et si possible sur plusieurs supports.

Stocker la clé maître et exporter les sous-clés

Nous recommandons d'utiliser 3 clés USB :

  • 2 pour sauvegarder la clé maître
  • 1 pour transporter les sous-clés

La clé maître reste au coffre, les sous-clés circulent.

Pour exporter la clé maître :

umask 077

# Clé privée maître
gpg -a --output /media/user/CLESECRETE/secret_key.asc --export-secret-key 0xA6F76D3B09BC268A
gpg --output /media/user/CLESECRETE/secret_key.gpg --export-secret-key 0xA6F76D3B09BC268A

# Clé publique maître
gpg -a --output /media/user/CLESECRETE/public_key.asc --export 0xA6F76D3B09BC268A
gpg --output /media/user/CLESECRETE/public_key.gpg --export 0xA6F76D3B09BC268A

# Certificat de révocation auto-généré
cp ~/.gnupg/openpgp-revocs.d/*.rev /media/user/CLESECRETE/

Pour exporter les sous-clés :

gpg -a --output /media/user/MACLEUSB/secret_subkeys.asc --export-secret-subkeys 0xA6F76D3B09BC268A
gpg --output /media/user/MACLEUSB/secret_subkeys.gpg --export-secret-subkeys 0xA6F76D3B09BC268A
La commande --export-secret-subkeys exporte les sous-clés privées sans embarquer la clé privée maître qui doit rester un secret absolu.

Nous recommandons aussi de chiffrer les supports :

  • LUKS sur GNU/Linux
  • VeraCrypt sur d'autres systèmes

Une clé USB contenant des éléments cryptographiques en clair n'est généralement pas une bonne idée.

Nettoyer la machine qui a servi à la génération

Si vous avez travaillé depuis une session éphémère, comme un système live ou Tails, le nettoyage est plus simple.

Si vous avez utilisé une machine persistante, l'article propose de supprimer les clés locales :

gpg --delete-secret-keys 0xA6F76D3B09BC268A
gpg --delete-key 0xA6F76D3B09BC268A

Puis de vérifier :

gpg -K
gpg -k

L'objectif est clair : ne pas laisser traîner la clé maître sur une machine qui n'a plus besoin de la conserver.

Importer les sous-clés sur une machine de travail

Quand la génération est terminée, vous pouvez importer les sous-clés sur la ou les machines qui serviront au quotidien :

gpg --import /media/user/MACLEUSB/secret_subkeys.gpg

Après import, la sortie peut ressembler à ceci :

gpg: clef A6F76D3B09BC268A : clef publique « Jean Dupont <jean.dudu@pont.fr> » importée
gpg: clef A6F76D3B09BC268A : clef secrète importée

Vérifiez ensuite :

gpg -K
sec#  rsa4096/0xA6F76D3B09BC268A 2022-11-14 [C]
      Empreinte de la clef = 5445 E89C 355F 4FB4 E653  3D47 A6F7 6D3B 09BC 268A
uid                  [  ultime ] Jean Dupont <jean.dudu@pont.fr>
ssb   rsa4096/0x2C7E486743774AEA 2022-11-14 [S]
ssb   rsa4096/0xD403F40075C53CA0 2022-11-14 [E]

Le sec# est important : il indique que la clé maître privée n'est pas réellement présente sur cette machine. C'est précisément ce que nous cherchons.

Vous pouvez maintenant utiliser vos sous-clés au quotidien, sans exposer en permanence votre clé maître.

Distribuer votre clé publique

Vos correspondants doivent récupérer votre clé publique. Deux approches ici :

  • la publication sur un serveur de clés
  • la distribution manuelle

Publication sur un serveur de clés ou via WKD

Via :

  • keys.gnupg.net
  • pgp.mit.edu
  • keyserver.ubuntu.com

Par exemple :

gpg --keyserver keyserver.ubuntu.com --send-keys 0xA6F76D3B09BC268A
⚠️
En 2026, plusieurs serveurs de clés historiques comme keys.gnupg.net ou pgp.mit.edu ne doivent plus servir de référence pédagogique. Pour la découverte de clés, GnuPG utilise par défaut local,wkd, et WKD reste le meilleur premier choix quand vous contrôlez votre domaine de courriel.

Si vous gérez votre propre domaine de courriel, publier votre clé via Web Key Directory est souvent une meilleure option qu'un keyserver public. Côté utilisateur, GnuPG sait interroger ces sources automatiquement :

gpg --locate-external-keys utilisateur@exemple.org

Distribution manuelle

Pour beaucoup d'usages, c'est souvent le choix le plus sobre :

  • par clé USB
  • ou par courriel
  • ou via un autre canal de confiance

Dans tous les cas, il faut vérifier l'empreinte de la clé, idéalement sur un canal séparé :

gpg --fingerprint 0xA6F76D3B09BC268A

Vous obtiendrez l'empreinte complète de la clé maître, ainsi que celles des sous-clés.

Sauvegarder votre répertoire GnuPG

Sauvegarder les sous-clés, ou même tout le répertoire ~/.gnupg, reste une bonne idée si vous voulez pouvoir restaurer rapidement :

umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg

L'archive créée devrait avoir des permissions restrictives :

-rw-------  1 user  user  20480 nov. 15 14:41 gnupg-backup.tar

Pour restaurer ensuite au bon endroit :

tar -xf $HOME/gnupg-backup.tar -C $HOME
⚠️
Le vrai piège ici n'est pas le z éventuel, GNU tar sait souvent autodétecter. Le vrai risque, c'est de restaurer dans le mauvais répertoire. Gardez bien le -C $HOME.

Réutiliser temporairement la clé maître

Vous aurez parfois besoin de réimporter la clé maître, par exemple pour signer une autre clé ou révoquer une sous-clé.

Exemple :

gpg --import /media/user/CLESECRETE/secret_key.gpg

Puis, une fois l'opération terminée :

gpg --delete-secret-keys 0xA6F76D3B09BC268A

Le principe reste toujours le même :

  • importer la clé maître uniquement quand c'est nécessaire
  • effectuer l'opération sensible
  • supprimer de nouveau la clé privée locale

Comprendre la toile de confiance

Le cœur de PGP, ce n'est pas seulement le chiffrement. C'est aussi la toile de confiance.

Vous pouvez signer la clé publique d'un contact après avoir vérifié son identité et son empreinte. C'est ce qui permet de construire des liens de confiance entre clés.

Nous prenons l'exemple d'une clé publique d'Edward Snowden :

gpg --keyserver keyserver.ubuntu.com --recv-keys 347ff6babdee5137d2d06299da20a6cb20cabb31

Puis l'on vérifie les signatures déjà présentes :

gpg --check-sigs 347FF6BABDEE5137D2D06299DA20A6CB20CABB31

Ensuite, si vous avez réellement vérifié l'identité du titulaire, vous pouvez signer la clé :

gpg --sign-key 347FF6BABDEE5137D2D06299DA20A6CB20CABB31

Et ajuster le niveau de confiance :

gpg --edit-key 347FF6BABDEE5137D2D06299DA20A6CB20CABB31

Depuis l'invite :

gpg> trust

Ici plusieurs niveaux :

  • ultime : uniquement pour vos propres clés
  • entière ou légère : selon la confiance que vous accordez à la personne pour vérifier d'autres clés
  • pas confiance
  • pas d'avis
💡
Ne donnez pas une confiance "ultime" à la légère. Cette valeur ne sert pas à dire "j'aime bien cette personne", elle sert à structurer votre modèle de confiance.

Révoquer une sous-clé ou une clé complète

Révoquer une sous-clé

Si une sous-clé a été compromise, perdue ou n'est plus utilisée, voici la séquence à suivre :

gpg --edit-key 0xA6F76D3B09BC268A

Puis :

gpg> key 1
gpg> revkey
gpg> save

Il faudra ensuite republier ou retransmettre votre clé mise à jour pour que vos interlocuteurs prennent en compte cette révocation.

Révoquer intégralement une clé

Dans ce cas, on réimporte le certificat de révocation généré plus tôt :

gpg --import /media/user/CLESECRETE/A6F76D3B09BC268A.rev

Puis on vérifie avec :

gpg -K
gpg -k

Vous devriez voir l'état [révoquée] apparaître sur la clé concernée.

🚨
Une révocation intégrale est une action lourde. Assurez-vous de bien comprendre sa portée avant de l'appliquer.

Et l'interface graphique ?

Oui, c'est possible.

Voici quelques outils qui offrent une interface visuelle :

  • seahorse et, selon les distributions GNOME, seahorse-nautilus pour ajouter des actions dans le gestionnaire de fichiers
  • gpa pour administrer des clés avec une interface graphique

Exemples :

apt install seahorse seahorse-nautilus
apt install gpa

Ces noms de paquets restent toutefois très dépendants de la distribution. Là encore, retenez surtout l'idée générale : l'interface graphique peut aider, mais la ligne de commande reste le meilleur point d'entrée pour apprendre, diagnostiquer et éviter les malentendus.

Pour conclure

Vous avez maintenant une vue complète du cycle de vie d'une clé GPG :

  • création de la clé maître
  • génération des sous-clés
  • stockage hors ligne
  • import sur les machines d'usage
  • sauvegarde
  • distribution
  • révocation si nécessaire

Ce n'est pas un sujet "plug and play", mais une fois la logique comprise, l'ensemble devient beaucoup plus clair (et beaucoup moins intimidant).

Voilà, vous avez une base solide pour utiliser GPG de façon plus rigoureuse au quotidien.