Après avoir fait le constat que peu / pas de gens dans mon entourage savent ce qu’est GnuPG, j’ai considéré pertinent de faire mon propre tutoriel « concis » sur ce sujet. Pour en savoir davantage sur ce merveilleux outil, quelques références supplémentaires sur le sujet sont disponibles à la fin :3.
NOTE : Ce tutoriel ne nécessite pas de fortes compétences avec les ordinateurs, mais nécessite de ne pas être technophobe. Dans la partie pratique du tutoriel, je n’explore que l’interface non-graphique de GnuPG, puisque c’est celle-ci que j’utilise et elle me semble plus versatile. Vous n’avez cependant pas vraiment besoin de connaître des commandes Bash sophistiquées pour me suivre, bien que cela vous aiderait au long terme d’en apprendre la base. Une référence supplémentaire vous montre comment intégrer GPG dans Thunderbird / Icedove si vous n’êtes pas confortable, et vous n’auriez alors qu’à comprendre un minimum ce qu’est GPG et vous créer une paire de clés. Dans tous les cas, si vous rencontrez des difficultés, faites moi signe !
GPG est un logiciel libre permettant d’encrypter et / ou de signer des documents à partir du standard OpenPGP. En encryptant un document, le but est que seul le destinataire souhaité puisse le consulter (ou en tout cas, le premier à le consulter). En signant un document, nous souhaitons habituellement permettre au destinataire de confirmer (ou infirmer) que c’est vraiment nous qui avons envoyé le dit document, et qu’il n’a entre autre pas été modifié en cours de route. Cet outil est extrêmement malléable, et peut servir pour tout type de contenu, médium, etc.
Si vous souhaitez utiliser GPG sans rien comprendre de son fonctionnement, cette section est facultative. Cependant, elle est loin d’être inutile si vous souhaitez en faire une utilisation intelligente. Bien sûre, je ferai de mon mieux pour ne pas apporter de vocabulaire trop technique, juste le nécessaire. Si vous n’êtes pas intéressé, faites juste accepter comme fait établi que votre clé privé doit être protégée à tout prix, et que votre clé publique peut (et doit) être partagée à autruis sans soucis, sans besoin de le faire secrètement, tant et aussi longtemps qu’on a de bonnes raisons de penser qu’elle ne sera pas altérée en cours de route, puis passez à la section.
Pour l’encryption,GPG utilise un chiffrement hybride, qui est en fait une combinaison synergétique des forces du chiffrage symmétrique et du chiffrage avec clés publiques. Pour comprendre le sens de cette phrase, prenons un exemple concrèt. Admettons que A veuille envoyer un document à B et seulement à B, anonymement ou non.
Si A et B utilisait une encryption symmétrique, alors ils s’entendrait d’abord sur un algorithme de chiffrement symmétrique, ce qui peut se faire publiquement s’il n’est pas trop médiocre. B créerait alors une grande « clé » avec beaucoup d’entropie. Par là, on entend qu’il y a un grand nombre de clés que B a considéré, et que nous n’avons pas de bonnes raisons de penser qu’une clé était préférrée sur une autre. B doit alors partager SECRÈTEMENT sa clé à A et à personne d’autre, car c’est la clé qui permettra à la fois l’encryption et la décryption lorsqu’on connaît l’algorithme de chiffrement. A utilise alors la clé pour encrypter le document en se fiant à l’algorithme, le transmet à B à la vue de tous, puis B, réutilise la même clé pour décrypter le document. Ce processus a beau être TRÈS sécuritaire, il est évidemment particulièrement inconvénient, pour de nombreuses raisons… Par exemple, comment s’assurer que la clé symmétrique est transmise sécuritairement alors que nous créons justement cette clé pour communiquer sécuritairement ?
Si A et B utilisaient plutôt une encryption avec clés publiques, ils s’entendraient d’abord sur un algorithme avec clés publiques. B créerait alors un couple de deux clés. D’abord, une clé privée ne servant qu’à décrypter des documents. Puis une clés publiques correspondantes, n’étant en fait que le complémentaire de la clé privée d’un point de vue pratique, c’est-à-dire qu’avec la clé publique seule, on ne peut qu’encrypter des documents. Ne concluons pas que ces deux clés sont mutuellement exclusives; Certaines composantes de la clé publique sont [en pratique] essentielles pour permettre la décryption des documents, mais en aucun cas suffisantes. Ainsi, pour permettre à A de communiquer sécuritairement son document, B transmet sa clé publique à A, ce qui peut se faire à la vue de tous, à la seule condition qu’il y a de bonnes raisons de penser que la clé ne sera pas altérée en chemin (cela laisserait sinon la porte ouverte à un tier pour décrypter tous les messages de A, puis de les réencrypter à destination de B, en raison de l’essence de l’algorithme). En se fiant à l’algorithme, A utilise la clé publique de B pour encrypter son document (une fois encrypté, remarquons que l’algorithme ne permet pas même à A de déchiffrer). A transmet alors son document à B à la vue de tous. Finalement, B utilise sa clé privée [et quelques composantes de sa clé publique] pour déchiffrer le dit document. Cette façon de faire est beaucoup plus convéniente que le chiffrement symmétrique (remarquons que A et B n’ont nullement eu besoin de communiquer secrètement entre eux), mais un problème qui reste est que cette procédure est très coûteuse d’un point de vue computationnel, surtout avec de longues clés (longueur qui est nécessaire pour atteindre un niveau de sécurité satisfaisant).
En utilisant un chiffrement hybride, ce problème de ressources computationnelles que rencontreraient A et B disparaît pratiquement. L’idée est d’utiliser un chiffrement symmétrique pour chiffrer le document à envoyer, puis de chiffrer cette même clé symmétrique (mais SEULEMENT la clé) à l’aide d’un chiffrement avec clé publique. Pour résumer, la procédure serait la suivante : A et B conviennent publiquement sur un chiffrement symmétrique, et un chiffrement avec clés publiques. B crée sa clé publique et sa clé privé, puis envoye publiquement sa clé publique à destination de A. A, de son bord, crée sa clé symmétrique, et chiffre son document avec pour ensuite chiffrer la clé symmétrique à partir de la clé publique de B. A envoye le tout publiquement à B, qui décrypte la clé symmétrique à l’aide de sa clé privée, puis utilise cette même clé pour déchiffrer le document souhaité. Heureusement, le tout est fait de façon semi-automatisée par GnuPG :).
Pour l’instant, à partir du protocole mentionner, n’importe qui pourrait chiffrer un document à destination de B tout en prétendant être A. De plus, il est souvent pratique de ne rien encrypter, mais de tout de même assurer aux destinataire(s) que le document provient vraiment de nous.
GnuPG règle le problème en prenant soin de choisir, dans son chiffrement hybride, un chiffrement avec clés publiques tel qu’une propriété supplémentaire est satisfaite : la clé privée et la clé publique sont reliée de façon telle qu’une procédure, bien définie à l’avance dans la spécification de l’algorithme avec chiffrement publique, permette à la clé PRIVÉE et SEULEMENT à la clé privée d’encrypter des documents à destination de la clé publique à partir de cette procédure (dans le cas de RSA, seulement des nombres qui ne sont pas riduculement ridiculement grands peuvent être encryptés de cette façon, mais le principe demeure et cela ne posera aucun problème pour l’utilisation qui suit). Dit de façon équivalente, la clé publique est en mesure d’encrypter avec destination unique la clé privée, mais vice-versa. Étant donné que [a priori] seul A connaît sa clé privée, un message encrypté à destination de la clé publique de A provient nécessairement de A. Cela correspondrait donc à une façon valide de signer un document, mais tel qu’il a été éclipsé lorsqu’on parlait de chiffrement avec clés publiques, il est computationnellement inconvénient d’encrypter des gros documents à l’aide d’un chiffrement avec clés publiques seules. De plus, il est souvent souhaitable de ne pas encrypter le document, tout en garantissant l’authenticité…
Heureusement, nous connaissons plusieurs fonctions mathématiques f aux propriétés spéciales pouvant nous sortir de cette situation. Ces fonctions f (qui forment en fait un sous-ensemble des fonctions de hashage) possèdent les trois propriétés suivantes (SHA2 et MD5 en sont des exemples bien connus) :
À l’aide de cet outil mathématique, une procédure plus simple, mais qui reste tout aussi sécuritaire, est d’appliquer la fonction possédant ces trois propriétés à notre document, puis d’uniquement encrypter le nombre que la fonction attribue à notre document (toujours à l’aide de notre clé privée). Si on voulait également de l’encryption, on encrypterait ensuite le tout par la procédure habituelle, utilisant un chiffrement hybride se servant uniquement de la clé publique du destinataire. Lorsqu’un destinataire reçoit le document signé, iel n’a qu’à déchiffrer la signature à l’aide de la clé PUBLIQUE de l’auteur, puis comparer le nombre déchiffré au nombre qu’elle obtient en appliquant la même fonction de hashage aux propriétés spéciales au document.
Si vous êtes sur un distro Linux qui n’est pas trop ridiculement minimal, GnuPG est très probablement déjà installé sur votre système. Si ce n’est pas le cas, il est assurément dans vos répertoires de logiciels. Il peut alors être installé comme n’importe quel autre logiciel (sudo apt-get install gnupg sur Debian, sudo dnf install gnupg sur Fedora, sudo pacman -S gnupg sur Archlinux, etc.).
Si vous êtes sur Windows, considérez d’abord le fait que votre système d’opérations est un gros blob propriétaire (aka malware), que vous n’avez aucun contrôle / liberté sur votre système d’opérations, que le tout appartient à une grosse mégacorporation qui a accès à TOUT ce qui se trouve sur votre système. Cela inclut notamment vos clés privés permettant de décrypter et de signer vos documents. Dépendamment de comment Copilot™ se sent aujourd’hui, vous pourriez admettre que les tiers affiliés à Microsoft™ ont également accès à vos données. Si, malgré tout, vous souhaitez avoir au moins l’illusion d’un sentiment de vie privée sur le système à Microsoft, voici les instructions :
Si vous êtes sur MacOS, ChromeOS, ou tout autre système d’opérations propriétaire, le même principe que pour Windows s’applique. Si vous souhaitez malgré tout avoir l’illusion d’un croisement entre la liberté et votre vie privée, voici les instructions fournies par votre manufacturier :
Si vous n’avez qu’un téléphone et ne possédez pas d’ordinateur personnel en raison du prix de la liberté de nos jours (tor) (i2p), il serait selon moi futile de fournir un tutoriel pour tenter d’installer la liberté sur votre appareil de surveillance de masse. Or, le Grand Gargamel est un personnage pathétique, et vous fournie donc les instructions pour votre système d’opérations :
Comme à peu près toutes les commandes bash, toutes les fonctionnalités de base de GPG peuvent être imprimées avec l’argument « –help », ou simplement « -h » :
gpg -h
Vous devriez commencer par générer votre paire de clés OpenPGP. Ce n’est techniquement pas nécessaire si votre utilisation est strictement anonyme et aucunement pseudonyme. Ouvrez donc votre console préférrée, et entrez la commande suivante pour donner l’instruction à GPG :
gpg --full-generate-key
Le dialogue suivant (ou similaire) sera alors imprimé :
gpg (GnuPG) 2.2.40; Copyright (C) 2022 g10 Code GmbH This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (14) Existing key from card Your selection?
L’option par défaut est parfaite, Entrez donc « 1 ». GPG nous demande ensuite la longueur en bits de nos clées :
RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (3072)
Pour contrer une attaque plausible par l’ordinateur classique pour encore quelques décennies, entrez le maximum, « 4096 ». On vous demande par la suite la date de péremption de vos clés :
Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0)
À moins de prévoir une utilisation sophistiquée (ce qui n’est probablement pas le cas si vous lisez mon tutoriel), entrez « 0 » pour qu’elle n’expire jamais. Vous devez confirmer votre choix :
Key does not expire at all Is this correct? (y/N)
Tel qu’indiqué, entrez donc « y ». Vous vous faites ensuite intercepté par les services secrets qui trouvent vos activités louches, et vous exigent de vous authentifier avec de VRAIES informations. Vous n’avez d’autres choix que de vous dévoiler :
GnuPG needs to construct a user ID to identify your key. Real name: Schtroumpfette su l'speed Email address: schtroumpfette-ben-buzzée@amazon.qc.ca Comment: Le schtroumpf est l'évolution canonique de la licorne. You are using the 'utf-8' character set. You selected this USER-ID: "Schtroumpfette su l'speed (Le schtroumpf est l'évolution canonique de la licorne.) <schtroumpfette-ben-buzzée@amazon.qc.ca>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
Comme vous voyez, on peut introduire des informations insensées; GPG ne tentera en aucun cas de vérifier ces informations sur les internets, elles restent toutes locales (pour l’instant). Cela vous permet de mener plusieurs vies; Une paire de clées GPG pour papa #1, une autre pour papa #2. Dans mon cas, j’ai juste l’intention d’infiltrer les schtroumpfs.
Une fois que vous êtes satisfait de vos renseignements, N’APPUYEZ PAS TOUT DE SUITE SUR « O ». À la prochaine question, GPG vous demandera un mot de passe… Ce mot de passe ne fait qu’encrypter votre clé privée. Il ne contribue donc en rien à la sécurité [et / ou l’authenticité] de vos documents en admettant les trois prémisses suivantes :
Seulement si l’une de ces trois conditions n’est pas satisfaites devriez-vous considérer un bon mot de passe (À MON AVIS). Mais peut importe la force du mot de passe, si l’un des trois points n’est pas respecté et que, par ce fait même, votre ordinateur est éventuellement victime d’un spyware, le responsable a plus que les moyens d’obtenir votre clé privée non encryptée si vous continuez d’utiliser votre ordinateur normalement. Autrement dit, ce mot de passe joue essentiellement le même rôle que celui de votre base de données KeepassXC.
À présent que vous êtes satisfait de votre mot de passe, entrez « O » pour confirmer la validité de vos renseignements, puis fournissez votre mot de passe.
Pour finaliser la génération de votre paire de clés, vous devez fournir de l’entropie :
We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.
Tel que suggéré par GPG, mettez vous â frapper sur votre clavier tout en faisant danser votre souris. Cela devrait être suffisant.
Vous êtes maintenant propriétaire d’un trousseau de clés GPG non-vide ! Pour le consulter, lancez la commande suivante :
gpg --list-keys
Ou, sa version moins verbose mais équivalente :
gpg -k
Ce qui devrait vous l’imprimer :
[...] ----------------------------- [...] pub rsa4096 2025-08-07 [SC] D16B68CAB94C9CDDB0E5E8005A1D450EB6323CFF uid [ultimate] Le Grand Gargamel (je déteste les schtroumpfs) <gargamel@envs.net> sub rsa4096 2025-08-07 [E] pub rsa4096 2025-08-07 [SC] 45BE8A5892CC0098CF1BD85C8B5003A98F5003A7 uid [ultimate] Schtroumpfette su l'speed (Le schtroumpf est l'évolution canonique de la licorne.) <schtroumpfette-ben-buzzée@amazon.qc.ca> sub rsa4096 2025-08-07 [E]
La deuxième ligne d’une clé (« 45BE8A5892CC0098CF1BD85C8B5003A98F5003A7 » dans le cas de ma nouvelle clé) correspond à son empreinte digitale. C’est une façon simple et efficace pour comparer deux clés publiques lorsqu’on souhaite déterminer si elles sont associées à la même clé privée.
Maintenant, pour permettre à autruis d’utiliser notre clé publique, nous n’avons qu’à l’exporter. L’option « –armor » fait en sorte que la clé publique sera sous format non-binaire (comme tout bon individu) :
gpg --output schtroumpfette.asc --armor --export schtroumpfette-ben-buzzée@amazon.qc.ca
Ou, sous format plus compact mais équivalent :
gpg -o schtroumpfette.asc -a -e schtroumpfette-ben-buzzée@amazon.qc.ca
Nous pouvons alors partager notre clé publique. Pour l’utiliser, un récipient de la clé publique n’aurait qu’à l’importer à son trousseau de clés :
gpg --import schtroumpfette.asc
Le récipient peut à présent encrypter des documents dont seul votre clé privé peut décrypter, et vérifier la signature de documents que vous lui envoyer.
Il est admis que vous avez importé la clé publique de votre destinataire :
gpg --import destinataire.asc
Posons d’abord les variables suivantes :
A : Votre nom / adresse courielle / empreinte digitale associé à votre clé publique (dont vous avez la clé privée). B : Le nom / adresse courielle / empreinte digitale associé à la clé du destinataire. D : Le nom / emplacement du document à encrypter (par exemple, document.txt).. D.asc : Le nom / emplacement du document encrypté (par exemple, document.txt.asc).
Pour encrypter votre document sans n’y associer aucune de vos paires de clés, c’est la commande suivante :
gpg -o D.asc -ea -r B D
ou, une commande équivalente mais plus verbose :
gpg --output D.asc --encrypt --armor --recipient B D
l’option -a (ou –armor) met le document encrypté sous format non-binaire (i.e. ne le compresse pas), ce qui prend plus de place, mais fait en sorte que vous pourriez facilement copier / coller le contenu du document ailleurs. Vous pouvez l’omettre si vous ne pensez pas en avoir besoin.
Remarquez que vous n’avez nullement eu besoin de votre paire de clés GPG générée lors de la section précédente, et donc que n’importe qui aurait pu encrypter ce document à votre place. Pour assurer au destinataire que c’est bien vous qui avez envoyé ce document, vous voulez plutôt encrypter votre document de façon pseudonyme :
Pour signer votre document à l’aide de votre clé privée générée lors de la section précédente et ainsi donner une bonne certitude au destinataire que le document vient vraiment de vous, on ajoute simplement le paramètre ‘-s’ à la commande :
gpg -o D.asc -sea -r B D
ou, une commande équivalente mais plus verbose :
gpg --output D.asc --sign --encrypt --armor --recipient B D
l’option -a (ou –armor) met le document encrypté sous format non-binaire (i.e. ne le compresse pas), ce qui prend plus de place, mais fait en sorte que vous pourriez facilement copier / coller le contenu du document ailleurs. Vous pouvez l’omettre si vous ne pensez pas en avoir besoin.
Dans le cas où vous menez plusieurs vies et que vous avez donc plusieurs clés privées, vous pouvez spécifier l’identité que vous souhaitez associer à votre document :
gpg -o D.asc -sea -u A -r B D
ou, une commande équivalente mais plus verbose :
gpg --output D.asc --sign --encrypt --armor --local-user A --recipient B D
L’ordre des arguments fournis à GPG n’a aucune importance, SAUF que le document à encrypter (D) doit être le dernier paramètre, et que son output (-o D.asc) doit être le premier.
Il est admis que vous avez généré votre paire de clés GPG. Si ce n’est pas le cas, référez vous à la section concernée.
Posons d’abord les variables suivantes :
D : Le nom / emplacement du document décrypté (par exemple, document.txt). D.asc : Le nom / emplacement du document encrypté (par exemple, document.txt.asc ou document.txt.gpg)..
La commande est alors la suivante :
gpg -o D -d D.asc
ou, une commande équivalente mais plus verbose :
gpg --output D --decrypt D.asc
Dans le cas où le document est volontairement anonyme, vous pouvez ignorer ce que GPG imprime.
Sinon, si vous vous attendiez à ce que le document vienne d’un certain utilisateur, assurez vous d’avoir importé sa clé publique (gpg –import utilisateur.asc), puis assurez vous que GPG vous dise ‘Good signature from “Le Grand Gargamel (je déteste les schtroumpfs) <gargamel@envs.net>”’, où les renseignements sont substitués par ceux de l’utilisateur. GPG ne vérifiera que parmis vos clés importées. Si, malgré tout, vous avez importé (ET conservé sans changer leur niveau de confiance via gpg –edit-key) les clés publiques de plusieurs utilisateurs nommés ‘Le Grand Gargamel’ avec la même adresse courriel ET la même description, la ligne supérieure à « Good signature from […] » vous indique l’empreinte digitale de la clé publique, qui, dans ce cas, devrait être ‘D16B68CAB94C9CDDB0E5E8005A1D450EB6323CFF’ pour le vrai GRAND Gargamel.
Le message devrait ressembler au suivant :
gpg: encrypted with 4096-bit RSA key, ID 17A873EAA7D64463, created 2025-08-07 "Schtroumpfette su l'speed (Le schtroumpf est l'évolution canonique de la licorne.) <schtroumpfette-ben-buzzée@amazon.qc.ca>" gpg: Signature made Sat 09 Aug 2025 10:54:56 PM EDT gpg: using RSA key D16B68CAB94C9CDDB0E5E8005A1D450EB6323CFF gpg: issuer "gargamel@envs.net" gpg: Good signature from "Le Grand Gargamel (je déteste les schtroumpfs) <gargamel@envs.net>" [ultimate]
Il est admis que vous avez généré votre paire de clés GPG. Si ce n’est pas le cas, référez vous à la section concernée.
Il existe deux façons de signer un document sans l’encrypter, mais je recommenderais celle qui suit pour la majorité des applications (l’autre consisterait à combiner la signature et le document en un seul et même fichier (options –clear-sign ou –sign (cette dernière compresse également le document))) : Posons d’abord les variables suivantes :
A : Votre nom / adresse courielle / empreinte digitale associé à votre clé publique (dont vous avez la clé privée). D : Le nom / emplacement du document à signer (par exemple, document.txt). D.asc : Le nom / emplacement de sa signature détachée (par exemple, document.txt.asc).
La commande pour signer le document est alors la suivante :
gpg -o D -b D.asc
ou, une commande équivalente mais plus verbose :
gpg --output D --detach-sign D.asc
Comme dans le cas de l’encryption, on peut utiliser l’option -u (–local-user) pour spécifier une paire de clés à utiliser en particulier :
gpg -o D -b -u A D.asc
ou, une commande équivalente mais plus verbose :
gpg --output D --detach-sign --local-user A D.asc
Il est admis que vous avez importé la clé publique de l’auteur du document à vérifier (gpg –import auteur.asc)
Pour vérifier une signature détachée telle que celle créée à la section précédente, posons d’abord les variables suivantes :
D : Le nom / emplacement du document à signer (par exemple, document.txt). D.asc : Le nom / emplacement de sa signature détachée (par exemple, document.txt.asc).
La commande est alors la suivante :
gpg --verify D.asc D
Ce qui devrait un message semblable :
gpg: Signature made Mon 04 Aug 2025 05:44:56 PM EDT gpg: using RSA key D16B68CAB94C9CDDB0E5E8005A1D450EB6323CFF gpg: Good signature from "Le Grand Gargamel (je déteste les schtroumpfs) <gargamel@envs.net>" [ultimate]
Dans ce cas-ci, l’ordre des arguments est important (la signature précède le document, sans quoi GPG vous retournera une erreur). Pour que ce qui est imprimer par GPG confirme que la signature vient effectivement de l’auteur souhaité, je cite la partie pertinente de la section sur l’encryption d’un document :
« [...] assurez vous que GPG vous dise 'Good signature from "Le Grand Gargamel (je déteste les schtroumpfs) <gargamel@envs.net>"', où les renseignements sont substitués par ceux de l'utilisateur. GPG ne vérifiera que parmis vos clés importées. Si, malgré tout, vous avez importé (ET conservé sans changer leur niveau de confiance via gpg --edit-key) les clés publiques de plusieurs utilisateurs nommés 'Le Grand Gargamel' avec la même adresse courriel ET la même description, la ligne supérieure à « Good signature from [...] » vous indique l'empreinte digitale de la clé publique, qui, dans ce cas, devrait être 'D16B68CAB94C9CDDB0E5E8005A1D450EB6323CFF' pour le vrai GRAND Gargamel. »
Pour plutôt vérifier une signature attachée, la procédure est exactement la même que pour décrypter un document pseudonyme. Si vous en avez donc besoin, et que vous ne savez pas / ne vous rappelez pas comment faire, je vous réfère à la section concernée.
Soit les variables suivantes :
A : Votre nom / adresse courielle / empreinte digitale associé à votre clé publique (dont vous avez la clé privée). B : Le nom / adresse courielle / empreinte digitale associé à la clé du destinataire. D : Le nom / emplacement du document à encrypter (par exemple, document.txt).. D.asc : Le nom / emplacement du document encrypté (par exemple, document.txt.asc).
# Générer une paire de clés. gpg --full-generate-key # Imprimer la liste des clés. gpg -k # Exporter une clé publique sous format non binaire. gpg -o gargamel.asc -a --export gargamel@envs.net # Importer une clé publique à son trousseau de clés. gpg --import gargamel.asc # Encrypter un document anonymement. gpg -o D.asc -ea -r B D # Encrypter un document pseudonymement. gpg -o D.asc -sea -r B D # Encrypter un document pseudonymement selon une paire de clés spécifique. gpg -o D.asc -sea -u A -r B D # Décrypter un document. gpg -o D -d D.asc # Signer un document sans l'encrypter. gpg -o D -b D.asc # Signer un document sans l'encrypter selon une paire de clés spécifique. gpg -o D -b -u A D.asc # Vérifier la signature détachée d'un document. gpg --verify D.asc D
# Générer une paire de clés. gpg --full-generate-key # Imprimer la liste des clés. gpg --list-keys # Exporter une clé publique sous format non binaire. gpg --output gargamel.asc --armor --export gargamel@envs.net # Importer une clé publique à son trousseau de clés. gpg --import gargamel.asc # Encrypter un document anonymement. gpg --output D.asc --encrypt --armor --recipient B D # Encrypter un document pseudonymement. gpg --output D.asc --sign --encrypt --armor --recipient B D # Encrypter un document pseudonymement selon une paire de clés spécifique. gpg --output D.asc --sign --encrypt --armor --local-user A --recipient B D # Décrypter un document. gpg --output D --decrypt D.asc # Signer un document sans l'encrypter. gpg --output D --detach-sign D.asc # Signer un document sans l'encrypter selon une paire de clés spécifique. gpg --output D --detach-sign --local-user A D.asc # Vérifier la signature détachée d'un document. gpg --verify D.asc D