System-Linux

Aller au contenu | Aller au menu | Aller à la recherche

Chiffrement et Identification via GnuPG

Un petit article sur GnuPG : Il vient en complément de l'article de GanGan sur mcrypt paru il y a quelques jours. Ce dernier traitait d'un moyen simple et clair de chiffrement avec une clé symétrique et le nouveau d'une technique de chiffrement à base de clés asymétriques.



GanGan va surement être content, cela fait 2 mois que je lui promet des articles et je traîne je traîne !
Vous êtes comme moi je suppose : Plein de chose en tête, des soucis, des bidules à faire et quand on arrive du boulot, on mange/glande/joue et pis on regarde celui - ou celle - que l'on aime et ni une ni deux on part dans des parties de scrabble endiablées ...
Et paf ! GanGan le lendemain vous tombe dessus entre deux cafés et vous rappel deux-trois vérités :
  1. vous êtes son esclave
  2. vous lui avez promis des articles
  3. il est tenace

Donc c'est contre mon gré, à reculons et avec du kawa que je mets à mon labeur pour un petit article sur GnuPG. Il vient en complément de l'article de GanGan sur mcrypt paru il y a quelques jours. Ce dernier traitait d'un moyen simple et clair de chiffrement avec une clé symétrique - je reviendrais sur cet aspect - pour protéger ses données.
GnuPG permet cela aussi mais ajoute d'autres possibilités, rapide tour d'horizon :
  • Chiffrer ses propres données.
  • Transmettre des données de toutes natures de façon sécurisé pour que seul le destinataire puisse l'ouvrir - vous même ne pourriez pas les déchiffrer mais encore une fois il va falloir attendre pour ce point.
  • Signer des documents et donc s'identifier comme le véritable auteur d'un texte ou mail.
  • Stocker les clés de vos amis et créer une toile de confiance
  • Créer un réseau social ... euh non pardon ça c'est mon twitter

Historiquement GnuPG est un équivalent libre à la solution de chiffrement PGP (Pretty Good Privacy) développée en 1991par Phillip Zimmermann. En effet, cela ne date pas d'hier et à l'époque les solutions de chiffrement étaient considérées comme des armes de guerres par la plupart des gouvernements et son utilisation était à la limite de légalité.
Aujourd'hui cela nous parait saugrenu mais je rappel que la guerre froide s'est terminée dans la fin des années 1980 ;)
Et si l'on y regarde bien, la loi en france interdisait l'utilisation de PGP, jusqu'en 1996 et encore ce n'est que depuis 2004 que l'on a le droit d'utiliser de vrai moyens de chiffrement (ce n'est pas une blague !).
Bref le sujet n'étant pas l'histoire du chiffrement, je m'arrêterais ici, wikipédia est heureusement là pour ceux qui cherchent d'autres infos.
Pendant tout ce temps, PGP existait, son petit frère libre GnuPG est né et l'IETF a normalisé le format OpenPGP. GnuPG est maintenant intégré dans toutes les bonnes distributions et dans un tas de logiciels.

OK OK ! Je me soumets et j'arrête le blabla pour passer au côté technique. Pour info, je suis sous debian mais votre système de paquet doit aussi contenir GnuPG.


L'installation via apt comme d'hab :


# apt-get install gnupg
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
gnupg est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

Quoi déjà installé ??? ... Ben oui il est tellement bien intégré qu'en fait apt en est dépendant pour la signature des paquets !


Configuration :

Aucune ! En fait, seules d'autres applications utilisant gnupg seront à configurer. On peut penser par exemple à Kmail, Mutt, Enigmail pour thunderbird, FireGPG pour firefox ...


Création d'une identité :

GnuPG va nous permettre de créer deux clés dans un premier temps. On les nomme des clés asymétriques et celles-ci auront la particularité de vous identifier et d'autoriser un chiffrement très efficace.
Les clés asymétriques pour les non-initiés sont un duo de clés générées en même temps, la clé publique et la clé privée intrinsèquement liées l'une à l'autre par trois aspects importants :
  • un contenu chiffré par une clé ne peut pas être déchiffré par cette même clé.
  • un contenu chiffré par la clé privée pourra être déchiffré par la clé publique.
  • un contenu chiffré par la clé publique pourra être déchiffré par la clé privée.

Pourquoi faire ceci ? Quand l'on utilise un mot de passe simple, on utilise en réalité une clé symétrique, c-a-d que n'importe qui connaissant votre mot de passe saura déverrouiller vos données et/ou se faire passer pour vous. Y compris la personne à laquelle vous transmettez vos données !

En utilisant des clés asymétriques on décide d'en garder une secrètement (la clé privée) dans un coin de son pc - ou sur une clé usb ou un coffre fort - et de diffuser l'autre très largement (la clé publique), Normal elle est "publique".
Il est alors possible de chiffrer ses données avec sa clé privée et un destinataire pourra les lire avec votre clé publique.

J'entends déjà la conversation :
--- Mais alors tout ceux qui ont votre clé publique peuvent lire les données que vous avez chiffrées ??
Et moi de répondre :
--- C'est en effet le gros problème mais en réalité on fait plus intelligent et on ne chiffre jamais - ou presque, cf plus bas - ses propres données avec ses propres clés ...
--- O_o
--- Dans un monde parfait, on considère en réalité que moi et mon destinataire avons tous les deux un duo de clé asymétriques et que nos clés publiques respectives sont tellement diffusée que chacun d'entre nous à celle de l'autre...
--- ô_ô
--- Et donc je peux chiffrer mes données avec la clé publique de mon destinataire et l'envoyer sans risque, il sera le seul à pouvoir les décoder puisqu'il couve jalousement sa clé privée. Et inversement, il pourra m'envoyer un contenu chiffré avec ma clé publique et je serais le seul à pour l'ouvrir avec ma clé privée.  Lui même en serait bien incapable !
--- :O
--- soyez gentil arrêtez les grimaces ...



J'espère que vous avez compris le concept, c'est assez essentiel. Maintenant générons nos clés. Pour cela rien de plus simple, la commande suivante vous générera le duo de clé en protégeant la clé privée par une pass-phrase (un genre de clé symétrique ^^) et les enregistrera dans sa base de données de clés.

Les réponses par défaut suffisent pour bien faire :
$ gpg --gen-key
gpg (GnuPG) 1.4.6; Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.                   
This is free software, and you are welcome to redistribute it     
under certain conditions. See the file COPYING for details.       

Please select what kind of key you want:
   (1) DSA and Elgamal (default)      
   (2) DSA (sign only)                
   (5) RSA (sign only)                
Your selection? 1                     
DSA keypair will have 1024 bits.      
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 2048              
Requested keysize is 2048 bits                  
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) 0                         
Key does not expire at all                      
Is this correct? (y/N) y                        

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:               
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"             

Real name: Kévin Hinault
Email address: hinault@gmail.com
Comment: <ici vous aurez la possibilité de mettre un surnom ou un commentaire> 
You are using the `utf-8' character set.
You selected this USER-ID:
    "Kévin Hinault <hinault@gmail.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
<ici vous aurez la possibilité de mettre la pass-phrase>

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.
+++++++++++++++++++++++++++++++++++++++++++++...+++++.+
++++++++++++++++++++++++..++++++++++++++++++++++++++++
++++++++++++..+++++++++++++++>++++++++++.................>.+++++..
.........<.+++++......>+++++...........+++++
Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 97 more bytes)
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.

<Ce message ne devrait pas apparaître mais si c'est le cas,
il vous suffit d'ouvrir un nouveau shell et de faire une recherche avec find /
ou dd if=/dev/urandom of=file count=100000 et la génération de la clé repartira
>

+++++++++++++++..+++++..++++++++++++++++++++.++++++++++..+
++++..++++++++++.++++++++++...+++++++++++++++.++++++++++++
+++++++++++++++++++++++++++++++++....++++++++++>....+++++.+
++++>+++++>+++++...........................................
......................+++++^^^
gpg: key 1C903836 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
pub   1024D/1C903836 2009-04-13
      Key fingerprint = 8A38 8CE6 E52C A002 1E41  AA41 99E1 61B1 1C90 3836
uid                  Kévin Hinault <hinault@gmail.com>
sub   2048g/90D77878 2009-04-13

Maintenant mon duo de clé est prêt mais les puristes conseillent de préparer une révocation au cas où votre clé privée se perde :
$ gpg --output revoke.asc --gen-revoke "Kévin Hinault"
sec  1024D/1C903836 2009-04-13 Kévin Hinault <hinault@gmail.com>
Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:      
  0 = No reason specified                         
  1 = Key has been compromised                    
  2 = Key is superseded                           
  3 = Key is no longer used                       
  Q = Cancel                                      
(Probably you want to select 1 here)              
Your decision? 0                                  

Enter an optional description; end it with an empty line:
> Clé perdue
>                                                     
Reason for revocation: No reason specified
Clé perdu
Is this okay? (y/N)                                

You need a passphrase to unlock the secret key for
user: "Kévin Hinault <hinault@gmail.com>"      
1024-bit DSA key, ID 1C903836, created 2009-04-13
<ici vous aurez la possibilité de mettre la pass-phrase>
ASCII armored output forced.
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!

J'aurais aussi pu utiliser l'ID de la clé, d'ailleurs en pratique on préfère l'utiliser plutôt que le nom, soit ici "gpg --output revoke.asc --gen-revoke 1C903836" aurait donné le même résultat.

Regardons un peu ce que l'on a dans notre base de données de clés.

Coté clés publiques :
$ gpg --list-keys
/home/kevin/.gnupg/pubring.gpg
--------------------------------------
pub   1024D/1C903836 2009-04-13
uid                  Kévin Hinault <hinault@gmail.com>
sub   2048g/90D77878 2009-04-13

Coté clés privées :
$ gpg --list-secret-keys
/home/kevin/.gnupg/secring.gpg
--------------------------------------
sec   1024D/1C903836 2009-04-13
uid                  Kévin Hinault <hinault@gmail.com>
ssb   2048g/90D77878 2009-04-13

ça se ressemble et pourtant ce sont bien des clés différentes :p

J'ai mes deux clés mais elle ne me permettent à l'heure actuelle que deux choses : signer des mails ou des fichiers et chiffrer mes propres données :

1 / Concernant les mails, je ne donnerais peut être des explications dans un sujet ultérieur mais sachez que des solutions simples existent pour thunderbird et firefox : enigmail et firepgp, si le deuxième est récent et bug un peu, le premier fonctionne lui parfaitement.

En ce qui concerne les signatures, c'est simple, prenons un fichier test.txt :

$ gpg --default-key 1C903836 --sign test.txt
You need a passphrase to unlock the secret key for
user: "Kévin Hinault <hinault@gmail.com>"
1024-bit DSA key, ID 1C903836, created 2009-04-13
<ici vous aurez la possibilité de mettre la pass-phrase>

$ file test.txt.gpg
t
est.txt.gpg: data

Pas terrible et inutilisable en l'état et pour peu que l'on édites le fichier, on se retrouve avec un joli binaire mais il est aussi possible d'utiliser --clearsign à la place de --sign pour intégrer la signature dans le texte et l'on aura alors quelque chose comme ceci dans le fichier généré :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

test
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJ+BO+meFhsRyQODYRAnzvAKCRko8KRwan13H/lMHPXWwzuRBJowCgkTy3
HMXWa24oQtpu5Vc0brdjX9s=
=WURt
-----END PGP SIGNATURE-----

Maintenant vérifions notre signature :
$ gpg --verify test.txt.gpg
gpg: Signature made mer 29 avr 2009 02:23:46 CEST using DSA key ID 1C903836
gpg: Good signature from "Kévin Hinault <hinault@gmail.com>"

J'ai donc bien la preuve que le fichier est de moi et toute personne ayant ma clé publique pourra en faire de même.

Supprimons la signature :
$ gpg --decrypt test.txt.gpg > test2.txt
gpg: Signature made mer 29 avr 2009 02:23:46 CEST using DSA key ID 1C903836
gpg: Good signature from "Kévin Hinault <hinault@gmail.com>"

test2.txt contiendra exactement la même chose que test.txt

Attention : Il n'est pas nécessaire de connaitre la clé publique pour enlever une signature et une signature n'a pas fonction de protection juste d'identification auprès d'un destinataire car celle-ci n'est pas falsifiable. Dans un monde parfait, on l'utiliserait même pour signer ses chèques :p

2 / On va maintenant voir le chiffrement de ses propres données à la manière de mcrypt et pendant 2 minutes vous allez oublier ce que j'ai raconté sur le fait de ne pas les chiffrer avec ses propres clés :)

On observe toujours le même concept : "le clé privée sert à décoder les données chiffrées avec la clé publique" et l'on utilise pour chiffrer ses propres donnes.
En cas d'incompréhension : dédoublez-vous et dites-vous que vous vous transmettez une information à vous même donc vous la chiffrez avec la clé publique du destinataire - seulement ici c'est la votre ! - et seul votre destinataire pourra la lire, c-a-d vous.

C'est ok ? Continuons. Pour chiffrer un fichier voici comment faire :

$ gpg --recipient hinault@gmail.com --encrypt test1.txt

C'est simple mais vérifions deux-trois choses tout de même :

$ file test1.txt
test1.txt: ASCII text

$ file test1.txt.gpg
test1.txt.gpg: GPG encrypted data

Le fichier est bien chiffré et si vous l'éditez, vous serez incapable de le lire puisqu'il sera devenu binaire.

Maintenant déchiffrons le :
$ gpg --decrypt test1.txt.gpg > test2.txt
You need a passphrase to unlock the secret key for
user: "Kévin Hinault <hinault@gmail.com>"
2048-bit ELG-E key, ID 90D77878, created 2009-04-13 (main key ID 1C903836)
<ici vous aurez la possibilité de mettre la pass-phrase>
gpg: encrypted with 2048-bit ELG-E key, ID 90D77878, created 2009-04-13
      "Kévin Hinault <hinault@gmail.com>"

Ici gpg a automatiquement compris que vous vouliez déchiffrer le texte avec votre clé privée et vous demande votre pass-phrase. Si votre clé privée est compromise ainsi que votre pass-phrase alors vos fichiers ne seront plus protégés.
En attendant celui qui arriverait lire vos données devrait déposer un brevet : il deviendrait très très riche :)

Le fichier est donc redevenu normal :
$ file test2.txt
test2.txt: ASCII text

Testons sur la même chose mais sur un autre compte n'ayant pas ma clé privée :
% gpg --list-keys
% gpg --list-secret-keys
Pas de clé publique ni de clé privée.

Tentative de décodage :
% cp ~kevin/test1.txt.gpg ~truc/
% gpg --decrypt test1.txt.gpg
gpg: encrypted with ELG-E key, ID 90D77878
gpg: decryption failed: secret key not available

On le voit, le déchiffrement échoue parce que truc n'a pas ma clé privée.
Et si je lui donne ma clé publique ? Profitons en pour voir comment exporter et importer une clé.

Exporter sa clé :
$ gpg --export --armor hinault@gmail.com
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)

mQGiBEnjhWQRBACXlfq8Hb5ZtrQfZJ+XL4o+lO0GDNaUffia2bJKnduW9F78Ns4O
yjFSDLKu0mNcNey1g6hbfMKoMSAXm8/p3iexKzRVrRLA+Awk7GAqfueade65IsmT
U3CymqdnyGmMTyyxCZVRkX9xRWILZSfCVzSm929M4zuRlAVGod7C6fjciwCgl3KG
kOwQUx9KsLvTEbyaLnaQC08D/iPGTfdSAUfDDewBypN3rPqwX3LR29ZJrA6HBcmF
Z5JsxMPts39V7fk84tZPAPluj27WfPLGHdvH2INducQq15TtcOsZKxwRgWMmNFg/
IeXgVbwW3S/oiaxVgK8VAx9JU2/KLuEGyrYLSf5cMQAUcd4cWrwmQVMwWRr8atOb
6kUCA/9eVBiQrdhggXlB/OwowPuZWkTbdHELdI4KZR4g4yeiv1gJNTAxRebWiyLE
1Ja3zprHxjJiO+Kaqdq4k/Z+9/2bra1FuB+2aPIguYAGXc4ie9KeJVpaiRmHAkqL
me7mLXKf9lfa1OglNVO7yqQokUpkGp9/pfWKR3hk1LFUmRKryLQiS8OpdmluIEhp
bmF1bHQgPGhpbmF1bHRAZ21haWwuY29tPoh3BBMRAgA4AhsDBgsJCAcDAgQVAggD
BBYCAwECHgECF4AFAknk1c0XGGh0dHA6Ly9zdWJrZXlzLnBncC5uZXQACgkQmeFh
sRyQODYvugCfShvtC5Nl8HCTC4dBuNAMk9h6jXwAmPpku3vgEKPSfx6YxVllGgPy
PBe5Ag0ESeOFaRAIAL6Z0y99mVuArcAZJX58LBiydspWisjHddCl8XCvdctzdKhP
Y44GQBnqG1/fYm188gVs5ivF8wMjg1MpN1xvaNggCzUxdyoD/W4j2pwttHYPhbWT
Wd06KZB5c7kWjZUxDk1ZW6j9+WxZP1K4eYLf4t5Uj/xzQYTv3sGd9ZXbNvlv+LeU
nijrfgSJb16RHWtyWAKlngXTrli0QHGMpuqzXym1szyONRIad6RLokRuXD4yLUyz
gRh308iVyGf1qyYoXXoxwhkBpgjkEp50A/2iIxUBU2nf4jd6MsTBxQKwqXfkuk+X
F+xwxJv68sf+4LAuIZP1U62TyjGifOm+2GiW0NMAAwUH/2TSkG9hGL3mqotA9UNX
Ov5jj1TcIdpfZ7n26SrYnOYVjOpc1flRvqoBvSXuRYLDDQyBXzUR27yb63ZNPyjX
XTPRSYFmp1IvR4llesAAhZOq7r72yZ6Sk8AQG7NCMC721n15Y1aJKsXyjILaxMeZ
ISh05cADRVtmnXxV8srBz9f8agpytkEs4VFIfg/brag0nEF2tXZMjqQy6ei+nAyc
BKespZE7jIfRdoxPoMAVpyAXxHJhMq5oiQBwO2pTnzA2XQLkW9zbBVbIghznFM0q
ZKE0aqcquPQhabSCFno8Xt5RAlwhndAurW/zhQzb0a9P2Fu6Ao1Ng4rqEe9g2Ybr
LwCISQQYEQIACQUCSeOFaQIbDAAKCRCZ4WGxHJA4NjBQAJ9AUaTgv3Ol99igaygH
1q6clpdeZQCfYJurv/eEwHhL0pWDD1e818e+e24=
=h6Ux
-----END PGP PUBLIC KEY BLOCK-----

La stocker (--armor l'affiche en base64 afin de pouvoir la transmettre facilement sinon elle serait affichée en binaire et c'est moins joli) :
$ gpg --export --armor hinault@gmail.com > hinault.gmail.com.pub.gpg
ou
$ gpg --export --armor --output hinault.gmail.com.pub.gpg hinault@gmail.com

$ file hinault.gmail.com.pub.gpg
hinault.gmail.com.pub.gpg: PGP armored data public key block

Je la transmet et l'importe :
% cp ~kevin/hinault.gmail.com.pub.gpg ~truc/
% gpg --import hinault.gmail.com.pub.gpg
gpg: key 1C903836: public key "Kévin Hinault <hinault@gmail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

La clé publique est bien importée mais pas la clé privée :

% gpg --list-keys
/home/truc/.gnupg/pubring.gpg
--------------------------------
pub   1024D/1C903836 2009-04-13
uid                  Kévin Hinault <hinault@gmail.com>
sub   2048g/90D77878 2009-04-13

% gpg --list-secret-keys
-Aucune-

Et si truc tente de déchiffrer ?

% gpg --decrypt test1.txt.gpg
gpg: encrypted with 2048-bit ELG-E key, ID 90D77878, created 2009-04-13
      "Kévin Hinault <hinault@gmail.com>"
gpg: decryption failed: secret key not available

gpg échoue encore avec une petite différence : il a reconnu qui a chiffrée la clé :)
Mon fichier est donc totalement protégé !

Pour les fous et les curieux :


Il est aussi possible de chiffrer et signer en même temps :
$ gpg --default-key 1C903836 --sign --recipient hinault@gmail.com --encrypt test1.txt

Il est possible d'exporter sa clé privée :
$ gpg --export-secret-key --armor hinault@gmail.com > hinault.gmail.com.secret.gpg

Et de la ré-importer ailleurs :
% gpg --import --allow-secret-key-import hinault.gmail.com.secret.gpg

Pour le reste, le man vous renseignera :)


Passons aux choses sérieuses (non ce n'était pas encore le cas) :

Cela consistera en une utilisation effective des clés pour transmettre le super-secret-de-la-mort  de truc à moi. Celui-ci aura donc besoin d'un duo de clé et on va commencer par lui créer ça :

Comme la première fois, un simple gen-key suffit
% gpg --gen-key
<blabla cf generation de la cle hinault@gmail.com>

% gpg --list-key
/home/truc/.gnupg/pubring.gpg
--------------------------------
pub   1024D/1C903836 2009-04-13
uid                  Kévin Hinault <hinault@gmail.com>
sub   2048g/90D77878 2009-04-13

pub   1024D/B6A1E3D0 2009-04-29
uid                  Truc Muche (truc) <truc.muche@gmail.com>
sub   2048g/E2583724 2009-04-29
% gpg --list-secret-key
/home/truc/.gnupg/secring.gpg
--------------------------------
sec   1024D/B6A1E3D0 2009-04-29
uid                  Truc Muche (truc) <truc.muche@gmail.com>
ssb   2048g/E2583724 2009-04-29

Truc contient toujours ma clé publique et cela tombe bien, il pourra m'envoyer son terrible secret sans que personne n'en sache rien.

Voici le secret ou plutôt le fichier contenant le secret : super-secret-de-la-mort.txt

% gpg --recipient hinault@gmail.com --encrypt super-secret-de-la-mort.txt
ou alors :
% gpg -r 1C903836 --encrypt super-secret-de-la-mort.txt
gpg: 90D77878: There is no assurance this key belongs to the named user

pub  2048g/90D77878 2009-04-13 Kévin Hinault <hinault@gmail.com>
  Primary key fingerprint: 8A38 8CE6 E52C A002 1E41  AA41 99E1 61B1 1C90 3836
      Subkey fingerprint: 557F 82FD 7BE2 3BDD 5498  F9CE 84CC 65C0 90D7 7878

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y
Vérifions que personne même pas truc ne peut lire le fichier :
% gpg --decrypt super-secret-de-la-mort.txt.gpg
gpg: encrypted with 2048-bit ELG-E key, ID 90D77878, created 2009-04-13
      "Kévin Hinault <hinault@gmail.com>"
gpg: decryption failed: secret key not available

Comme ça c'est clair :)

Par contre, personnellement je n'aime pas tellement que l'on connaisse le destinataire des fichiers chiffrés et pour ça on peut utiliser -R à la place de -r ce qui aura pour effet de laisser gpg dans le flou en cas de déchiffrement et il vous demandera la pass-phrase de sa propre clé privée et bien sûr cela échouera
% gpg --decrypt super-secret-de-la-mort2.txt.gpg
gpg: anonymous recipient; trying secret key E2583724 ...
Enter passphrase:
gpg: encrypted with ELG-E key, ID 00000000
gpg: decryption failed: secret key not available

Je récupère le fichier (le premier, celui qui n'est pas nominatif)
$ cp ~truc/super-secret-de-la-mort.txt.gpg ~kevin/

et je vais tenter de le déchiffrer :
$ gpg --decrypt super-secret-de-la-mort.txt.gpg > super-secret-de-la-mort.txt
gpg: anonymous recipient; trying secret key 934223AB ...
gpg: anonymous recipient; trying secret key 90D77878 ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with ELG-E key, ID 00000000

Maintenant voyons ce secret :
$ cat super-secret-de-la-mort.txt
AHHHH je suis un robot !

Quoi c'est tout ? ... je suis un peu déçu :|

Bon généralement on ne chiffre pas des trucs pareils et certainement pas pour les transmettre a quelqu'un avec cp. Cependant cette technique peut parfaitement être utilisée pour les fichiers à envoyer par mails et les mails directement. Dans la pratique, on se contente souvent de signer ces mails.


Diffusons la clé publique :

A quoi ça sert d'avoir une clé publique si personne ne la connait ? Pour cela gpg dispose de son propre protocole (utilisant le port 11371) pour envoyer la clé vers un serveur de clé et il en existe quelques un assez référent en la matière :
  • subkeys.pgp.net
  • pool.sks-keyservers.net
  • pgp.mit.edu
  • search.keyserver.net
  • ...

Je ne connais pas les détails mais ils semblent se partager les clés entre eux.

Commande pour émettre sa clé :
$ gpg --keyserver subkeys.pgp.net --send-key 1C903836
gpg: sending key 1C903836 to hkp server subkeys.pgp.net

Voilà n'importe qui peut maintenant vous transmettre des fichiers de manière sûre en récupérant votre clé auprès de ces serveurs.

$ gpg --keyserver subkeys.pgp.net --search-keys hinault@gmail.com
gpg: searching for "hinault@gmail.com" from hkp server subkeys.pgp.net
(1)     Kévin Hinault <hinault@gmail.com>
      1024 bit DSA key 1C903836, created: 2009-04-13
Keys 1-1 of 1 for "hinault@gmail.com".  Enter number(s), N)ext, or Q)uit > 1
gpg: requesting key 1C903836 from hkp server subkeys.pgp.net
gpg: key 1C903836: "Kévin Hinault <hinault@gmail.com>" 1 new signature
gpg: Total number processed: 1
gpg:         new signatures: 1

Il y aurait encore beaucoup de chose à dire notemment sur les configurations des clients mails et la création d'un réseau de confiance mais cela viendra en temps utiles, j'en ai déjà trop fait ... donc GanGan tu attendras encore deux ou trois mois !!!

:D



Article sous CC-by excepté les logos et les images.
Par Kevin Hinault | le jeudi, avril 30 2009 08:00