Aller au contenu

GPG, comment ça marche


Messages recommandés

Quoi-t-est-ce ?

Il y a un certain temps, vous aviez probablement entendu parler de PGP, un outil pour chiffrer ses mails. C'était bien, mais ça avait l'inconvénient d'être un logiciel propriétaire. Comment être sûr que mes mails chiffrés ne pourront être relus que par le destinataire si j'utilise un logiciel propriétaire ? Comment être sûr qu'il n'y a pas de backdoor ?

Bref, il fallait un logiciel libre, et c'est dans cet objectif que GnuPG (GNU Privacy Guard) a été créé.

GnuPG est donc un outil de chiffrement/signature, qui est souvent utilisé pour les mails, mais qui peut chiffrer/signer n'importe quel fichier. Il est souvent utilisé pour des releases de logiciels opensource, et il est utilisé pour signer les packages RPM et les fichiers de métadata Debian (Release/Packages/.dsc).

Comment ça marche

GPG est basé sur le principe des clefs asymétriques. L'utilisateur génère deux clefs qui ont les propriétés mathématiques suivantes :

- Tout ce qui est chiffré avec une clef ne peut être déchiffré qu'avec l'autre clef

- La connaissance d'une clef ne permet pas d'en déduire l'autre.

Ensuite, à la génération, le logiciel détermine arbitrarement que l'une d'elle est "publique" et l'autre est "privée". C'est à dire qu'il y en a une que vous pouvez donner à tout le monde, mettre sur votre site web, sur des serveurs de clefs, etc... alors que vous devez garder l'autre très précieusement et vous assurer que personne n'y a accès.

D'ailleurs, à la création le logiciel va vérouiller la clef privée par un mot de passe, que vous devrez redonner quand vous voudrez l'utiliser. C'est la "passphrase", comme pour les clefs SSH ou les certificats SSL.

A une clef publique, on peut associer un nom, un commentaire et une adresse mail.

Le chiffrement

Comment chiffrer un fichier avec GnuPG ? Avant les clefs asymétriques, quand vous vouliez envoyer un fichier à Bob et que vous vouliez être sûr que seul Bob pourra le lire, il fallait convenir avec lui d'un mot de passe et chiffrer le fichier avec ce mot de passe. Seulement voilà, si quelqu'un écoute votre conversation et récupère le mot de passe, vous êtes mal. Et envoyer le mot de passe par correspondance papier ou electronique, c'est encore bien pire.

Avec un système de clefs asymétriques, pour envoyer un fichier à Bob il me suffit de :

- récupérer sa clef publique (c'est facile, elle est publique)

- chiffrer le fichier avec cette clef

- lui envoyer.

Et comme il est le seul détenteur de la clef privée correspondante, il n'y a que lui qui pourra déchiffrer le fichier.

Pas d'échange de mot de passe par un canal non sécurisé, donc pas de problème.

La signature

GnuPG ne sert pas qu'à chiffrer. En fait, son utilisation la plus courante est même la signature. Voilà comment ça marche :

- Je génère une somme MD5 (ou mieux, SHA1) de mon fichier.

- Je chiffre cette somme MD5 avec ma clef privée

- J'envoie le fichier avec la somme MD5 chiffrée, les deux à la fois.

Que font les gens pour vérifier la signature ?

- Ils déchiffrent la somme MD5 avec ma clef publique

- Ils génèrent eux-même une somme MD5 du fichier

- Ils comparent leur somme et celle qu'ils ont déchiffré

- Si c'est pareil, le message n'a pas été modifié.

Donc la signature permet de vérifier deux choses :

- que le message n'a pas été modifié entre l'envoi et la réception (même somme de contrôle MD5)

- que le message vient bien de moi : si ils ont pu décrypter la somme avec ma clef publique, c'est que c'est bien moi avec ma clef privée qui l'ai chiffrée.

Les "keysigning parties"

Alors tout ça ça marche nickel, sauf sur un point. Quand je récupère la clef publique de Bob, comment m'assurer que c'est bien sa clef publique à lui ? Un pirate aurait pu remplacer la clef sur son site, ou aurait pu modifier le serveur de clefs.

C'est là le seul point faible du système, et comme on sait : une chaîne n'est jamais aussi solide que son plus faible maillon. Pour remédier à ça, il y a ce qu'on appelle le "réseau de confiance".

GnuPG permet de signer la clef publique de quelqu'un d'autre. En faisant cette opération, vous attestez au monde entier (qui récupèrera sa clef publique) que vous avez bien vérifié que cette clef publique appartient bien à son propriétaire (le nom et l'adresse mail associé). A partir du moment où cette vérification a été faite, vous pouvez utiliser la clef pour chiffrer des messages à l'attention de Bob.

Comment faire cette vérification ? Le mieux est de rencontrer la personne physiquement, qu'elle vous donne sa clef publique, et un moyen de prouver son identité (une pièce d'identité quoi). Pour rendre ça plus convial, les utilsateurs de GPG organisent parfois des "Keysigning parties" lors desquelles ils échangent leurs clefs publique.

En fait pas leur clef publiques en entier, ce serait un peu long à vérifier (en général 1024 caractères, parfois 2048...), ils échangent les "fingerprints", qui sont en fait des sommes de contrôle MD5 de ces clefs.

Donc si on résume, il faut avoir rencontré la personne une fois et échangé ses clefs publiques pour pouvoir vraiment s'envoyer des messages cryptés. Où est le "réseau de confiance" dans tout ça ? Et bien GnuPG est configué pour avoir le comportement suivant : si vous voulez utiliser la clef de quelqu'un que vous ne connaissez pas, mais qui est signée par 3 personnes à qui vous faites confiance, alors la nouvelle clef devient aussitôt valide.

C'est cool, comment on fait ?

Il y a déjà des tas de tutos sur le net sur la façon de se créer une clef GPG. On peut utiliser gpg en ligne de commande, ou utiliser des interfaces. Il y a notamment KGPG pour KDE et Seahorse pour GNOME

L'intégration dans les clients de mail sous Linux est en général très bonne, Kmail et Evolution le gèrent en natif (ben oui, vous pensiez pas qu'il allait falloir sauvegarder le mail, et le décrypter à la main non ? :chinois: )

Pour Thunderbird et Mozilla, il y a l'extention Enigmail qui intègre GPG au client de mail.

Pour Outlook, il y a WinPT qui fait ça aussi (mais franchement conseillez plutôt de migrer vers Thunderbird...)

Voilà quelques bons tutos sur la création de clefs :

- http://gpglinux.free.fr/gpg.pdf

- http://fr.wikibooks.org/wiki/GPG

- http://www.lea-linux.org/cached/index/Rese...-gpg-intro.html

Lien vers le commentaire
Partager sur d’autres sites

Une question: est-ce qu'on peut gérer les clef d'authentification de connection SSH avec le même logiciel que celle pour les mails? par exemple avec KGPG ou Seashore ?

Et est-ce qu'il existe un moyen de synchroniser ses clefs entre deux ordinateurs, comme par exemple son agenda ou ses contacts (synchro PC/PDA).

Je comprend pas comment on peut chiffrer un fichier avec une clef sans pouvoir le déchiffrer avec la même clef (en l'occurrence la clef publique) ???

Mais en tout cas ça à l'air de marcher ce principe, donc je vais faire confiance aux cryptologues ( :cartonrouge: ), ils sont fort probablement meilleurs que moi en math (c'est pas dur :transpi: )

Lien vers le commentaire
Partager sur d’autres sites

Une question: est-ce qu'on peut gérer les clef d'authentification de connection SSH avec le même logiciel que celle pour les mails? par exemple avec KGPG ou Seashore ?

Nope, KGPG et Seahorse ce sont des front-ends à GnuPG, pas à SSH.

Avec GPG, il y a un programme appelé gpg-agent qui permet de garder en mémoire la passphrase de la clef pour éviter d'avoir à la retaper à chaque fois, un peu comme ssh-agent. Ensuite, il y a un jeu de scripts qui s'appelle keychain ( http://www.gentoo.org/proj/en/keychain/ ) qui permet de garder en mémoire la passphrase des clefs GPG et SSH, pour simplifier la config. Mais ça ne permet pas la création et la gestion des clefs elles-mêmes.

C'est le seul pont entre GPG et SSH que je conaisse.

Et est-ce qu'il existe un moyen de synchroniser ses clefs entre deux ordinateurs, comme par exemple son agenda ou ses contacts (synchro PC/PDA).

Les clefs sont conservées dans deux fichiers dans ~/.gnupg : pubring.gpg et secring.gpg. Si tu veux passer une clef d'un pc à un autre, il faut l'exporter et l'importer avec les options --export et --import de GPG.

Je comprend pas comment on peut chiffrer un fichier avec une clef sans pouvoir le déchiffrer avec la même clef (en l'occurrence la clef publique) ???

Ouais, fais confiance aux matheux, apparemment c'est béton.

En fait il faut voir ça de la façon suivante : la clef publique est un cadenas que tu donnes à tout le monde, et dont toi seul possède la clef. Ils peuvent chiffrer des messages à ton attention, mais seul toi peut les déchiffrer.

Lien vers le commentaire
Partager sur d’autres sites

GPG est basé sur le principe des clefs asymétriques.
Si je peux me permertre :

GPG est une implémentation d'un algorithme de chiffrement asymétrique, ce qui se traduit par l'utilisation de plusieurs clés (une pour le chiffrement et une pour le déchiffrement pour faire simple).

Dire que des cléfs sont asymétriques n'a pas tellement de sens. C'est l'algo qui l'est du fait que ce n'est pas symétrique justement ( f² ≠ Id ou encore (f(f(x)) ≠ x)

ben oui, vous pensiez pas qu'il allait falloir sauvegarder le mail, et le décrypter à la main non ? :craint:
Hum...

déchiffrer :chinois:

Décrypter ça risque de prendre pas mal de temps et de ressources :roll:

Pour rappel, en français :

On chiffre (avec sa clé) et le destinataire déchiffre (avec la même clé ou une autre dans le cas des algo non symétriques).

Quand un pirate attaque, il décrypte.

Contrairement en anglais où c'est plus simple : encrypt/decrypt.

Pour ce qui est du passage MD5/SHA1, c'est clair qu'il vaut mieux laisser tomber MD5 (quoi que on a encore pu trouver que quelques collisions et dans des cas bien précis). Mais SHA1 c'est pas la panacée non plus. Le mieux était d'utiliser quand c'est possible SHA512 (ou SHA256 ou SHA384).

Merci pour ce tuto en tout cas :zarb: mon gauret !

Lien vers le commentaire
Partager sur d’autres sites

Si je peux me permertre :

GPG est une implémentation d'un algorithme de chiffrement asymétrique, ce qui se traduit par l'utilisation de plusieurs clés (une pour le chiffrement et une pour le déchiffrement pour faire simple).

Dire que des cléfs sont asymétriques n'a pas tellement de sens. C'est l'algo qui l'est du fait que ce n'est pas symétrique justement ( f² ≠ Id ou encore (f(f(x)) ≠ x)

Toi, tu as décidé de m'embêter :) Je simplifie volontairement, pour clarifier.

déchiffrer

Rhaaa ! C'est le seul décrypter du texte ! Je me suis relu 4 fois pour tous les enlever, et même pendant l'écriture j'ai fait mal à ma touche backspace !

C'est trop injuste, il en restait un...

Pour ce qui est du passage MD5/SHA1, c'est clair qu'il vaut mieux laisser tomber MD5

On est bien d'accord, d'ailleurs GPG utilise SHA1, et peut en utiliser d'autres par le biais de l'option personal-digest-preferences. Mais comme MD5 est plus connu, j'ai parlé de somme MD5, pour que ce soit plus parlant.

Alors c'est vrai, "vulgariser c'est trahir", mais bon pour les détails il y a toujours http://www.ietf.org/rfc/rfc2440.txt :mad2:

Lien vers le commentaire
Partager sur d’autres sites

Toi, tu as décidé de m'embêter :)
Meuh non :)

:zarb: encore pour ton tuto :yes:

Rhaaa ! C'est le seul décrypter du texte ! Je me suis relu 4 fois pour tous les enlever, et même pendant l'écriture j'ai fait mal à ma touche backspace !
Oui, t'inquiète ça se voit, ceux qui ne savent pas mettent crypter/décrypter à chaque fois :-D
C'est trop injuste, il en restait un...
dur la vie :p
Lien vers le commentaire
Partager sur d’autres sites

Pour ce qui est du passage MD5/SHA1, c'est clair qu'il vaut mieux laisser tomber MD5

On est bien d'accord, d'ailleurs GPG utilise SHA1, et peut en utiliser d'autres par le biais de l'option personal-digest-preferences. Mais comme MD5 est plus connu, j'ai parlé de somme MD5, pour que ce soit plus parlant.

Pour être sûr, il suffit d'y aller à fond (comme sous gentoo, MD5 + RMD160 + SHA256, si avec ces 3 là à la fois ça passe encore c'est qu'il y a du balaise derrière :zarb: )

Lien vers le commentaire
Partager sur d’autres sites

Le problème c'est qu'il faut être sûr de ce qu'on fait.

Une chaine n'est pas plus solide que le plus faible de ses maillons. Il se peut qu'une faiblesse de l'un des algorithmes (dans n'importe quel ordre qu'on le fasse) nique toute la chaine.

Et utiliser 10 algos, c'est pas forcément plus sûr que d'en utiliser qu'un seul.

Lien vers le commentaire
Partager sur d’autres sites

'Lut tous,

J'avais eu l'explication en direct de Gauret lors du first Jeudi dernier, et ce tuto me rappelle un peu tout ce qu'il m'a expliqué (ben vi, y'avait de la bière avec tout ca ;))

Donc je dis Merci Gauret !!!!! :roule:

Faudra que je me penche dessus dès que je pourrais ...

Lien vers le commentaire
Partager sur d’autres sites

Pour être sûr, il suffit d'y aller à fond (comme sous gentoo, MD5 + RMD160 + SHA256, si avec ces 3 là à la fois ça passe encore c'est qu'il y a du balaise derrière :transpi: )

Dis, tu parles bien du hash pour les ebuilds ?

Comment on configure portage pour utiliser du SHA256 par exemple ? Parce que le mien, visiblement, il vérifie le MD5 lors d'un emerge...

Lien vers le commentaire
Partager sur d’autres sites

Dis, tu parles bien du hash pour les ebuilds ?

Comment on configure portage pour utiliser du SHA256 par exemple ? Parce que le mien, visiblement, il vérifie le MD5 lors d'un emerge...

Oui

Mais ça dépend des ebuilds (et peut-être de la version de portage)

Lien vers le commentaire
Partager sur d’autres sites

  • 4 semaines après...
pour info, theocrite, il faut écrire " autant pour moi", et non au temps pour moi :cartonrouge:

Erreur fatale...

C'est LE truc qu'il ne faut pas dire :roll:

Déjà le faire c'est limite, mais le dire c'est la correction assurée :mdr2:

parenthèse culture pour tout le monde sur le autant/au temps pour moi

autant/au temps pour moi

très intéressant :incline:;)

sunfun

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...