> ## Content Index > Fetch the complete content index at: https://www.wikilibriste.fr/llms.txt > Use this file to discover other available public pages before exploring further. # Utiliser GPG au quotidien - URL: https://www.wikilibriste.fr/utiliser-gpg/ - Published: 2025-05-24T13:17:00.000Z - Updated: 2026-05-24T13:21:12.000Z - Description: Un tutoriel complet pour créer, stocker et utiliser des clés GPG de façon plus sûre. - Author: ayo - Tags: #tutoriels, #rating-3 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 : ```bash # 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 : ```bash touch ~/.gnupg/gpg.conf chmod 600 ~/.gnupg/gpg.conf ``` Ajoutez ensuite, au minimum, les paramètres suivants : ```ini # 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 ChiffrementArticle traitant des notions de chiffrement dans son ensemble et les outils recommandés.![](https://www.wikilibriste.fr/content/images/icon/Logo---exp-1-185.svg)Wikilibristeayo![](https://www.wikilibriste.fr/content/images/thumbnail/photo-1724304406928-c43b01912fa1-11)](https://www.wikilibriste.fr/chiffrement/) ## 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". ```bash gpg --quick-gen-key "Jean Dupont " ed25519 cert 1y ``` Récupérez ensuite l'empreinte complète de la clé : ```bash gpg --fingerprint "Jean Dupont " ``` Puis ajoutez vos sous-clés : ```bash 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 : ```bash 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** : ```text 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 : ```text pub rsa4096/0xA6F76D3B09BC268A 2022-11-14 [C] Empreinte de la clef = 5445 E89C 355F 4FB4 E653 3D47 A6F7 6D3B 09BC 268A uid Jean Dupont ``` 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 : ```bash gpg --edit-key 0xA6F76D3B09BC268A ``` Puis, depuis l'invite `gpg>`, on ajoute les sous-clés. ### Sous-clé de signature ```text 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 ```text 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 : ```text gpg> save ``` Vous devriez retrouver une structure de ce type : ```bash gpg -K ``` ```text 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 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 : ```bash 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 : ```text ~/.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 : ```bash 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 : ```bash 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 : ```bash gpg --delete-secret-keys 0xA6F76D3B09BC268A gpg --delete-key 0xA6F76D3B09BC268A ``` Puis de vérifier : ```bash 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 : ```bash gpg --import /media/user/MACLEUSB/secret_subkeys.gpg ``` Après import, la sortie peut ressembler à ceci : ```text gpg: clef A6F76D3B09BC268A : clef publique « Jean Dupont » importée gpg: clef A6F76D3B09BC268A : clef secrète importée ``` Vérifiez ensuite : ```bash gpg -K ``` ```text 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 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 : ```bash 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 : ```bash 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é : ```bash 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 : ```bash umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg ``` L'archive créée devrait avoir des permissions restrictives : ```text -rw------- 1 user user 20480 nov. 15 14:41 gnupg-backup.tar ``` Pour restaurer ensuite au bon endroit : ```bash 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 : ```bash gpg --import /media/user/CLESECRETE/secret_key.gpg ``` Puis, une fois l'opération terminée : ```bash 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 : ```bash gpg --keyserver keyserver.ubuntu.com --recv-keys 347ff6babdee5137d2d06299da20a6cb20cabb31 ``` Puis l'on vérifie les signatures déjà présentes : ```bash gpg --check-sigs 347FF6BABDEE5137D2D06299DA20A6CB20CABB31 ``` Ensuite, si vous avez réellement vérifié l'identité du titulaire, vous pouvez signer la clé : ```bash gpg --sign-key 347FF6BABDEE5137D2D06299DA20A6CB20CABB31 ``` Et ajuster le niveau de confiance : ```bash gpg --edit-key 347FF6BABDEE5137D2D06299DA20A6CB20CABB31 ``` Depuis l'invite : ```text 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 : ```bash gpg --edit-key 0xA6F76D3B09BC268A ``` Puis : ```text 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 : ```bash gpg --import /media/user/CLESECRETE/A6F76D3B09BC268A.rev ``` Puis on vérifie avec : ```bash 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 : ```bash 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.