GPG - les concepts en clair et pédagogiquement

Posté par . Modéré par baud123. Licence CC by-sa
51
18
avr.
2011
Sécurité

Le printemps est propice à l'adoption de nouvelles pratiques. GPG est un outil libre de mise en œuvre la sécurisation de contenu numérique, stocké ou échangé. L'objet de cette dépêche est de proposer une synthèse, un parcours pédagogique, sur les principes de cet outil, pour en comprendre l'esprit et pouvoir l'utiliser en comprenant les enjeux techniques.

Concernant la sécurisation des communications numériques, on distingue :

  • le contrôle d'intégrité : il s'agit de vérifier qu'un contenu n'est pas altéré (on dit qu'il est conforme à l'original) ;
  • l'authentification : il s'agit de s'assurer de l'identité de l'auteur ;
  • le chiffrement : il s'agit de brouiller le message pour des yeux indiscrets.

GPG (« Gnu Privacy Guard ») permet de réaliser ces trois fonctions. GPG est la version libre (au sens de logiciel libre) du logiciel PGP (« Pretty Good Privacy »).

Un outil de base : le chiffrement asymétrique

GPG utilise un chiffrement asymétrique (on parle d'algorithme de chiffrement asymétrique). Cela lui permet de réaliser les fonctions d'authentification et de chiffrement : l'authentification nécessite d'utiliser le chiffrement, même si le but n'est pas de brouiller le contenu numérique lui-même.

Ce chiffrement utilisé est dit asymétrique car il n'y a pas une unique clé secrète (partagée lors d'une rencontre réelle entre l'émetteur et le destinataire) permettant de chiffrer et déchiffrer un contenu, mais une paire de clés -- une clé privée et une clé publique, les deux étant associées, -- créée par chaque utilisateur qui communique un contenu numérique. La clé privée a vocation a rester secrète (c'est un enjeu important) et la clé publique a vocation à être librement communiquée.

Le principe du chiffrement asymétrique en action : avec quelle clé chiffre-t-on un contenu ?

a) Un contenu peut être chiffré par une clé privée. Il peut alors être déchiffré par la clé publique associée. Ce déchiffrement peut être réalisé par quiconque : la clé publique a vocation a être accessible à tous. Cela donne l'assurance que c'est bien le détenteur de la clé privée qui a chiffré le contenu. C'est en exploitant ce principe que l'authentification peut être réalisée. Dans la pratique, du fait que l'algorithme de chiffrement asymétrique est plus gourmand en ressource machine qu'un algorithme de chiffrement symétrique, ce n'est généralement pas le contenu à transmettre qui est chiffré par la clé privée mais une "empreinte" de ce contenu (voir plus bas, les paragraphes sur le contrôle d'intégrité et l'authentification). Ici, « l'utilisateur » destinataire veut authentifier l'émetteur d'un contenu numérique.

b) Un contenu peut être chiffré par une clé publique. Il peut alors être déchiffré par la clé privée associée. N'importe qui peut chiffrer un contenu avec ma clé publique et seul moi, détenteur de la clé privée (restée secrète), pourrai le déchiffrer. C'est en exploitant ce principe que deux interlocuteurs peuvent échanger un contenu chiffré : A chiffre avec la clé publique de B, B déchiffre avec sa clé privée, et réciproquement. Dans la pratique, pour être précis dans le détail, comme exposé au cas a), GPG ne chiffre pas tout le contenu : ici, GPG chiffre le contenu avec un algorithme de chiffrement symétrique (comme 3DES, AES, ...) puis chiffre la clé de chiffrement symétrique utilisée grâce à l'algorithme de chiffrement asymétrique, avec la clé publique du destinataire. Ici, « l'utilisateur » émetteur veut chiffrer un contenu à destination d'une autre personne.

La question de la confiance... dans l'association entre une clé publique librement accessible et l'identité du détenteur de la clé privée correspondante

Dans les deux cas a) et b) précités, l'utilisateur doit obtenir l'assurance que la clé publique qu'il utilise -- pour déchiffrer dans le cas a) et pour chiffrer dans le cas b) -- est bien celle de son correspondant. Pour ce faire, soit les deux interlocuteurs se sont déjà rencontrés physiquement et ont échangé leurs clés publiques (ils ont scellé une relation de confiance), soit ils se font indirectement confiance (par le biais d'un intermédiaire ou de multiples intermédiaires qui constituent une chaine de confiance).

Je vous renvoie à la notion de « Key signing party » (notamment dans les rencontres d'adeptes de logiciels libres) où des personnes échangent ainsi leur clé publique GPG deux à deux (avec un contrôle minimal de l'identité, typiquement la carte d'identité).

Le principe de base du contrôle d'intégrité et ses limites

La fonction de contrôle d'intégrité est assurée notamment par un algorithme générant une « empreinte » d'un contenu numérique, ou encore, une « image » réduite en taille de ce contenu. À la réception d'un contenu et de son empreinte, un destinataire peut s'assurer que le contenu est conforme à l'original de la façon suivante : il génère lui-même l'empreinte de ce contenu avec le même algorithme que l'émetteur et compare cette empreinte avec l'empreinte qu'il a reçue.
Le processus décrit dans ce paragraphe est fiable si et seulement si :

  • l'algorithme de génération de l'empreinte est solide, c'est-à-dire si deux contenus distincts ont une très faible probabilité d'avoir une empreinte identique. C'est une vraie question car on découvre parfois des faiblesses dans les algorithmes utilisés. SHA512 est réputé solide, alors que MD5 ou SHA1 présentent des faiblesses. La NSA (National Security Agency, l'Agence de Sécurité américaine) est derrière la plupart de ces algorithmes et ils disposent de bon chercheurs. Cependant, le code source étant libre, il est largement audité par des experts indépendants ;
  • le destinataire a l'assurance que l'empreinte qu'il a reçue n'a pas été falsifiée pendant la communication.

Supposons que les deux interlocuteurs puissent échanger l'empreinte d'un contenu lors d'une rencontre réelle, ils ont alors l'assurance de partager une empreinte identique. À ce compte-là, autant échanger directement le contenu lui-même. Si la rencontre réelle n'est pas d'actualité et que l'échange a lieu par un réseau informatique, on peut imaginer que le contenu soit falsifié ainsi que l'empreinte (par un intermédiaire sur le réseau (on parle d'attaque du type « man in the middle » ou « l'homme au milieu » en français)). Si la falsification est bien faite, à la réception, la comparaison entre l'empreinte régénérée et l'empreinte reçue sera valide et le contenu à contrôler sera considéré abusivement comme intègre.

Ainsi, même si l'algorithme de génération de l'empreinte est solide, ce processus utilisé seul n'est pas suffisant. Pour avoir l'assurance que l'empreinte reçue n'a pas été falsifiée, un bon moyen est de chiffrer la communication. La falsification "correcte" de l'empreinte pendant la communication nécessitera alors de casser le chiffrement (on parle de décryptage) et de chiffrer correctement le contenu falsifié.

En accédant à un contenu chiffré par le protocole HTTPS ('S' pour Sécurisé), on obtient un premier niveau de garantie, mais l'algorithme de chiffrement utilisé par HTTPS est réputé théoriquement faible depuis peu.

L'authentification (par signature cryptographique)

Un autre moyen très favorable est d'utiliser le chiffrement asymétrique de GPG sur l'empreinte. C'est en réalité exactement ce que fait le logiciel GPG pour réaliser l'authentification : GPG produit une empreinte du contenu (par un algorithme au choix de l'utilisateur) et chiffre cette empreinte avec la clé privée de l'émetteur. Ainsi, l'authentification et le contrôle d'intégrité sont réalisés dans un même processus. On parle de signature cryptographique ou d'empreinte signée numériquement (chiffrée par une clé privée).

Pour maximiser la sécurité, il est possible pour un collectif d'auteurs de produire autant de signatures cryptographiques qu'il y a d'auteurs (chacun utilisant sa propre clé privée), ce seront autant de fichiers de signatures.

Ceci dit, pour finir, il est très intéressant de noter qu'un auteur (ou un collectif d'auteurs) peut produire et diffuser des contenus « authentifiés » en restant dans l'anonymat. Il conviendra alors de générer une signature cryptographique avec la même clé privée à chaque fois. Les destinataires auront une seule assurance : l'auteur (ou le collectif) est bien le même à chaque fois.

  • # une image vaut plein de mots

    Posté par (page perso) . Évalué à  9 .

    Je trouve qu'en général, l'utilisation de schémas aide à comprendre les concepts cryptographiques et comment ils sont assemblés pour former un cryptosystème. J'avais fait un truc sur le sujet il y a longtemps et c'est grandement améliorable mais si ça peut aider des gens :

    chiffrement asymétrique de bout en bout : end to end asymetric crypto

    toile de confiance : web of trust

    La présentation complète est à http://docu.fsugar.be/openpgp/openpgp.html

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

    • [^] # Re: une image vaut plein de mots

      Posté par (page perso) . Évalué à  10 .

      Heu … personnellement je ne comprends rien à ton image mais la dépêche m'a parue assez claire.

      Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

      • [^] # Re: une image vaut plein de mots

        Posté par (page perso) . Évalué à  3 .

        Bon ben faut croire que ça marche pas pour tout le monde :) Enfin sinon lors d'une présentation interactive ça aide pas mal je trouve.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

        • [^] # Re: une image vaut plein de mots

          Posté par (page perso) . Évalué à  3 .

          ça marche plutôt pas mal pour moi, mais je suis déjà bien familier avec la crypto (a)symétrique, le chiffrement et la signature donc ...

        • [^] # Re: une image vaut plein de mots

          Posté par (page perso) . Évalué à  5 .

          L'idée est effectivement de faire une présentation interactive pour que les choses soient plus claires. Découvrir et lire le schéma en un seul bloc peut être assez difficile pour beaucoup de personnes, alors qu'en ayant des blocs qui apparaissent au fil de l'explication est généralement plus apprécié.

          En tout cas, c'est le genre de retour que j'ai eu lors de mes présentation d'introduction à la cryptographie.

          publicité subliminale : http://www.ellendhel.net/article.php?ref=2009+12+30-0

      • [^] # Re: une image vaut plein de mots

        Posté par . Évalué à  1 .

        bah je le trouve plutôt clair moi son schéma ...

        il montre bien les utilisations des clés privées et des clés publiques ainsi
        que le processus de contrôle d'intégrité des personnes et du message.

    • [^] # Re: une image vaut plein de mots

      Posté par . Évalué à  5 .

      Pardon mais si en général, une image aide à comprendre les concepts, alors j'suis désolé mais là ça doit être l'exception qui confirme la règle, parce que ton schéma il est quand même atrocement compliqué.

      • [^] # Re: une image vaut plein de mots

        Posté par (page perso) . Évalué à  3 .

        ton schéma il est quand même atrocement compliqué.

        Ah ben pourtant c'est déjà pas mal simplifié :)

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

    • [^] # Re: une image vaut plein de mots

      Posté par . Évalué à  10 .

      Votre image est un message chiffré, c'est bien ça ?

    • [^] # Re: une image vaut plein de mots

      Posté par (page perso) . Évalué à  1 .

      Malheureusement je crains que ton schéma ne fasse pas la différence entre signature et chiffrement.

      • [^] # Re: une image vaut plein de mots

        Posté par (page perso) . Évalué à  2 .

        Ben la signature étant une application particulière du chiffrement, si. Mais effectivement sans les explications en live c'est pas forcément évident.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

        • [^] # Re: une image vaut plein de mots

          Posté par (page perso) . Évalué à  1 .

          la signature étant une application particulière du chiffrement

          Dans le cas général, non. À la limite dans le cas particulier de RSA et encore avec beaucoup de réserves. RSA est d'abord est une primitive cryptographique. Il existe des fonctions "signature RSA" et "chiffrement RSA" qui utilisent la même primitive mais :

          • La primitive est utilisée de façons différentes dans les deux fonctions : on produit une signature en utilisant sa clé privée, alors qu'on chiffre avec la clé publique du destinataire du message, le padding est différent...
          • Les services rendus sont différents : confidentialité dans le cas du chiffrement, authenticité et intégrité dans le cas de la signature.

          Le standard PCSK#1 décrit comment on peut utiliser RSA pour chiffrer ou signer.

          • [^] # Re: une image vaut plein de mots

            Posté par (page perso) . Évalué à  2 .

            la signature étant une application particulière du chiffrement

            Dans le cas général, non.

            Si.

            Ce que je veux dire c'est qu'un algo de chiffrement asymétrique est un algo de signature potentiel et vice-versa (et c'est pas juste pour RSA). Évidemment il faut déjà avoir compris en quoi les concepts de confidentialité et d'authentification sont différents avant de regarder le schéma (qui, à la base, fait partie d'une présentation disponible dans le même répertoire).

            Cela dit, il est vrai que les détails d'implémentation de l'algorithme de signature sont généralement différents de l'algo de chiffrement sur lequel il est basé et qu'on utilise même souvent des algos complétements différents pour l'un et l'autre mais l'idée était d'introduire les primitives cryptographiques et comment elles sont combinées, pas de discuter des algos spécifiques (et puis le schéma est déjà assez compliqué comme ça mais le .dia est dans le même répertoire donc tu peux toujours modifier si tu veux).

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

  • # Très intéressant, merci.

    Posté par (page perso) . Évalué à  4 .

    Merci pour cet exposé très intéressant sur GPG. Je souhaitais depuis quelques m'y pencher d'un peu plus près pour en comprendre le fonctionnement étant donné que mine de rien, je l'utilise tout les jours via les dépôts Debian.

    Merci encore ;).

    There is no spoon...

  • # Autre site

    Posté par . Évalué à  3 .

    Il y aussi ce site http://www.securite-informatique.gouv.fr/autoformations/signature_elec/co/mod01_chap01.html qui est pas mal je trouve, avec des animations bien faites et claires pour expliquer aux débutants les principes de base.

    • [^] # Re: Autre site

      Posté par (page perso) . Évalué à  4 .

      Dommage qu'on n'y parle pas de GPG, et qu'il y soit dit que les clefs ne sont fournies que par des organismes de confiance. Sinon, très bien fait, en effet :)

  • # La question de la limite des algorithmes

    Posté par . Évalué à  1 .

    Extrait de "Paroles de Hacker" par Eric Filiol (texte publié le 11 avril 2011) [ http://blogs.lesechos.fr/intelligence-economique/paroles-de-hacker-a5543.html ] (merci la revue de presse de l'April) :

    Un chiffrement de 256 bits est sans utilité face à un hacker capable de piloter un virus qui va modifier l’environnement informatique pour contrôler d’une manière ou une autre le chiffrement. Il est prévisible même que certaines « croyances de sécurité » (rappelons que beaucoup de mécanismes de sécurité reposent sur des suppositions mathématiques qui n’ont jamais été démontrées) tombent en pratique dans les prochaines années, telles la signature électronique. Même le sacro-saint chiffrement quantique a été mis en défaut en pratique par une approche de type hacker.

    Si vous voulez donner votre avis, bienvenue.

  • # HTTPS réputé théoriquement fiable depuis peu?

    Posté par . Évalué à  2 .

    En accédant à un contenu chiffré par le protocole HTTPS ('S' pour Sécurisé), on obtient un premier niveau de garantie, mais l'algorithme de chiffrement utilisé par HTTPS est réputé théoriquement faible depuis peu.

    Je suis surpris par cette phrase. D’où tiens tu cela?

    Je pensais qu'en cryptographie, tout est fiable jusqu’à ce que l'on prouve le contraire. Il me semble avoir vu qu'on arrive a avoir des idées sur la fiabilité d'un algorithme, mais qu'on ne peut pas prouver sa fiabilité.

    • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

      Posté par . Évalué à  2 .

      Nan, tu as lu ce que tu voulais lire. J'ai écrit "faible".

      Je l'ai lu récemment sur Linuxfr. Je n'ai le souvenir d'avoir contrôlé l'information.
      Une petite recherche rapide avec les mots "RSA weakness" je trouve cette source : http://members.tripod.com/irish_ronan/rsa/attacks.html

      Pour ma part, par ailleurs, j'ai observé que l'algorithme de hashage (qui produit la fameuse "empreinte") SHA-1 n'est pas en très bonne forme, or je vois que c'est utilisé dans les certificats auto-signés de Linuxfr.org et autres sites qui exploitent le HTTPS (avec chiffrement RSA). Je n'ai pas fait une étude exhaustive, mais j'ai toujours vu SHA-1.

      Concernant SHA-1, voici quelques billes :

      http://linuxfr.org/users/samwang/journaux/fichiers-de-signature-des-distributions#comment-1179544

      voici ce j'écris au point E) :

      Concernant SHA-1, il est révélé finalement qu'il est trop faible d'une part ("l'ANSSI recommande (et impose, dans certains cas), l'utilisation de fonctions de hachage ayant une sortie de 256 bits") [1] et a une faille de sécurité (dixit "Vlobulle") d'autre part !

      [1] "cowboy" dans un autre commentaire nous donne ce lien : http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf

      Dans le même journal, Etienne Bagnoud indique :

      Le NIST demande de ne plus utiliser SHA-1 après la fin de l'année 2010 : http://csrc.nist.gov/groups/ST/hash/statement.html

      • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

        Posté par . Évalué à  1 .

        Le ssl ne se base pas que sur un seul algo de chiffrement. Libre à l'administrateur d'un serveur web (quand il en a la possibilité) de limiter les algos de calcul de condensat et de chiffrement à ceux qui sont réputés fiables. Par exemple, avec apache httpd et mod_ssl, ça se fait avec la directive SSLCipherSuite (http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite ).
        Après, il faut aussi bien choisir son autorité de certification, et éviter celles qui utilisent encore md5, par exemple...

        • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

          Posté par . Évalué à  4 .

          Concernant les certificats pour SSH, je notais ceci en début 2011 qui traite de mon expérience de confrontation à un certificat auto-signé (comme ici sur Linuxfr accédé en HTTPS) :

          En consultant la vidéo "Copyright Enforcement Vs. Freedoms" (un extrait de 10 minutes) par Jérémie Zimmermann (président fondateur de la "Quadrature du net") : http://www.youtube.com/watch?v=qRiY9tkdkV8 ...Je découve dans le texte associé à la vidéo : << You can watch and download the full recording here: https://media.ccc.de/browse/congress/2010/27c3-4103-en-copyright_enforcement_versus_freedoms.html >>

          Je clique et je découvre que la connexion "n'est pas certifiée". Firefox m'en informe par un message titré : "Cette connexion n'est pas certifiée" lors d'un premier accès à cette page en HTTPS. C'est la notion de "certificat auto-signé" qui est en jeu. Il faut choisir entre accepter ou refuser cette exception.

          Note : au passage, je découvrirai plus tard que la même page est accessible en HTTP : 27C3 alias "27th Chaos Communication Congress" toutes les conférences avec de jolies vignettes et quelques infos : http://media.ccc.de/browse/congress/2010/index.html

          [compréhension des implications en matière de "sécurité"]

          ccc.de (le site qui héberge cette page) n'a pas payé un organisme délivrant des certificats (une "autorité de certification", selon l'expression consacrée, comme Verisign par ex.) pour obtenir la possibilité d'utiliser le chiffrement avec le protocole sécurisé HTTPS. Ils ont juste généré un certificat auto-signé (n'importe qui peut le faire) pour mettre en oeuvre cette technologie, qui donne la possibilité, ici non pas d'avoir l'assurance que le site est bien celui qu'il pourrait prétendre être auprès d'une autorité de certification (Yahoo paye pour avoir un certificat permettant l'usage transparent de HTTPS pour le mail consultable en ligne, pas ex), mais donne la possibilité de chiffrer le contenu des pages transmises et donc d'obtenir un bon niveau d'assurance sur l'intégrité du contenu transmis.

          Au passage : donc, concrètement, pour la page https://media.ccc.de/browse/congress/2010/27c3-4103-en-copyright_enforcement_versus_freedoms.html (pour voir l'ensemble de la vidéo) j'accepte d'ajouter une exception ("je comprends les risques" tel que le propose Firefox et j'ajoute une exception... Pour ma culture, je clique ensuite sur "Voir" (le certificat) avant de "confirmer l'exception de sécurité")

          [Complément d'information]

          En cliquant "Voir" je découvre que "l'algorithme de signature des certificats" est "PKCS #1 SHA-1 avec chiffrement RSA" (avant dernier champ dans la fenêtre détails du certificat" que me propose Firefox.

          Or SHA1 est aujourd'hui réputé faible (voir commentaire ici : http://linuxfr.org/comments/1179345.html#1179345 )

          Extrait :

          En ce qui concerne SHA1 il existe des attaques théoriques mais il est encore très utilisé ne serait-ce que parce qu'il existe encore beaucoup de matériels qui ne supporte que SHA1 (cartes à puces...). Les administrations ont d'ailleurs un temps d'adaptation pour appliquer le RGS. La bonne nouvelle c'est que la famille SHA2 résiste mieux que prévu. On pensait après la publication des attaques sur SHA1 que SHA2 suivrait assez vite. Toutefois on peut aussi penser que cette résistance est due au fait qu'aujourd'hui les spécialistes du domaines travaillent plutôt sur les algorithmes candidats au concours SHA3 que sur la cryptanalyse de SHA2. http://csrc.nist.gov/groups/ST/hash/sha-3/index.htm

          Et un commentaire plus haut sous le même journal : http://linuxfr.org/comments/1179307.html#1179307 extrait :

          Petite information supplémentaire, SHA-1 est considéré comme devant être abandonné. L'ANSSI recommande (et impose, dans certains cas), l'utilisation de fonctions de hachage ayant une sortie de 256 bits : http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf

          [Conclusion pratique]

          vous pouvez très bien cliquer dans le navigateur pour "ajouter une exception" en comprenant le risque que >>>> la page que vous accéder ne soit pas reconnue par un tiers de confiance comme venant bien du serveur que vous interrogez, d'une part, et d'autre part >>>> l'algorithme de chiffrement étant reconnu faible aujourd'hui (théoriquement), acceptez qu'un éventuel pirate modifie la page alors qu'elle est chiffrée (fort peu probable, surtout dans un contexte peu sensible comme ici, à mon avis). Donc vous ne gagnez rien en matière de sécurité, mais vous ne perdez rien non plus... Ou plutôt vous gagnez un peu l'assurance de l'intégrité de la page transmise (conformité par rapport au contenu envoyé par le serveur), si tant est qu'aucun pirate ne sache la modifier du fait de faiblesses théoriques sur SHA1.
          Note : avec SHA256 c'est plus costaud, c'est ce qui est recommandé notamment en France, par des instances techniques de l'État.

      • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

        Posté par . Évalué à  1 .

        En fait, j'ai simplement lu trop vite. Toutes mes confuses.

        Si je me rappelle bien, SHA-1 est déconseillé car il est possible de générer un hash SHA-1 identique a un autre hash avec une probabilité accessible a des grands moyens computationnels. En pratique est ce que cela rend le surf en HTTPs moins sur? Oui, mais est ce que cela me dérange que quelqu'un intercepte mes communications sur linuxfr.org at applique une grosse masse de calcul pour arriver a me leurrer? non.

        Comme d'habitude en sécurité, il y a un compromis entre ta sécurité et la convivialité d'utilisation. Tout dépend de ce que tu as a perdre si jamais on te vole ces informations.

        Par exemple, de nombreux projets utilisaient jusqu’à récemment des signatures md5 pour les tarballs, parce que ce l'on veut juste vérifier que le paquet est intègre. On ne cherche pas a assurer une sécurité absolue.

        • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

          Posté par (page perso) . Évalué à  8 .

          Par exemple, de nombreux projets utilisaient jusqu’à récemment des signatures md5 pour les tarballs, parce que ce l'on veut juste vérifier que le paquet est intègre. On ne cherche pas a assurer une sécurité absolue.

          Il y a aussi le principe qui dit qu'un système est aussi sécurisé que sa partie la plus faible. C'est-à-dire que si tu construit un coffre-fort, il y a beaucoup plus de chance qu'on te vole la clef qu'on perce la paroi du coffre. Et pour les tarball, la plupart du temps, le lien est à côté de la somme MD5 (ou dans le même répertoire quand il n'y a pas de page web), si quelqu'un arrive à changer le lien ou le fichier, il n'y a aucune raison qu'il n'arrive pas à changer la somme MD5 avec celle de son nouveau fichier.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

          Posté par . Évalué à  3 .

          Tout dépend de ce que tu as a perdre si jamais on te vole ces informations.

          On le voit souvent formulé de la façon suivante : une bonne protection est une protection qui tiendra pour la durée de vie de la donnée à protéger.

          Pour un numéro de carte bancaire par exemple, c'est quelques années.

        • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

          Posté par (page perso) . Évalué à  5 .

          Toutes les attaques ne se valent pas, toutes ne sont pas applicables à tous les "mode opératoires". Par exemple pour MD5 je peux te sortir une collision en une dizaine de seconde sur mon PC, par contre trouver un autre fichier qui a une empreinte données, c'est beaucoup plus difficile. Si en plus je veux pirater un repository debian et que ce fichier doit être un tarball valide, là c'est carrément mission impossible.

          Dans le même esprit, la spécification TLS utilise MD5 et SHA-1 ensemble, mais pour le moment il n'a pas été montré que les attaques sur ces deux algorithmes ont un impact sur la sécurité de TLS. Des attaques type Comodo (sur les PKI) sont à mon avis bien plus facile à monter et donc plus probables.

          • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

            Posté par . Évalué à  2 .

            Il a été démontré en 2008 (http://www.win.tue.nl/hashclash/rogue-ca/) qu'avec relativement peu de moyens (200 playstations, un quadcore), on pouvait générer deux certificats avec le même hash md5 en à peu près une journée.
            Dans la démo en question, ils ont fait signer par une AC reconnue un certificat anodin, puis associé cette signature à un autre certificat (ayant le même hash md5) pouvant être utilisé comme autorité intermédiaire. Ce qui signifie au final qu'ils ont pu émettre et signer des certificats reconnus par les navigateurs.
            Pour moi, il est clair que md5 et sha-1 ne sont plus fiables.

            • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

              Posté par . Évalué à  1 .

              Bonjour,

              Je suis utilisateur d'OpenPGP (standard de GPG) depuis quelques années, et j'ai effectivement entendu que des fonctions de hashage comme MD5 ou SHA-1 ne devaient plus être utilisées.
              Effectivement, tomber sur une page HTTPS utilisant SHA-1 comme algo de signature du certificat fait prendre le risque que le contenu ne soit pas authentifié, le chiffrement des données transitant n'étant pas mis en question.

              Je me pose dans ce cas une question à propos d'OpenPGP :
              Alors qu'il est possible avec GPG de signer des contenus avec SHA-2 (ex : SHA-256, SHA-512), lors des Signing Parties, chacun a la possibilité d'étendre le réseau de confiance en signant la clef publique de son voisin. En fait il ne signe pas la clef publique, mais son empreinte SHA-1 !
              Le réseau de confiance, et toute la fiabilité des clefs reçues sur serveur de clefs, n'en est-il donc pas altéré ?

              Cordialement

  • # symétrique(message)

    Posté par . Évalué à  1 .

    b) [...] GPG ne chiffre pas tout le contenu : ici, GPG chiffre le contenu avec un algorithme de chiffrement symétrique (comme 3DES, AES, ...) puis chiffre la clé de chiffrement symétrique utilisée grâce à l'algorithme de chiffrement asymétrique, avec la clé publique du destinataire. Ici, « l'utilisateur » émetteur veut chiffrer un contenu à destination d'une autre personne.

    Est-ce uniquement pour des questions de vitesse/légèreté, comme pour le point a) au dessus ?

    D'autre part, dans le manuel de GPG, on lit :

    --show-session-key

    Display the session key used for one message. See --override-session-key for the counterpart of this option.

    We think that Key Escrow is a Bad Thing; however the user should have the freedom to decide whether to go to prison or to reveal the content of one specific message without compromising all messages ever encrypted for one secret key. DON'T USE IT UNLESS YOU ARE REALLY FORCED TO DO SO.

    Je ne suis pas sûr de comprendre cette option. Est-ce que cela sert à voir la clef temporaire utilisée pour le chiffrement symétrique ?

    • [^] # Re: symétrique(message)

      Posté par . Évalué à  0 .

      Pour répondre à ta première question, je dirais que oui, c'est uniquement pour des questions de vitesse/légèreté, mais je n'ai pas assez d'information pour être catégorique.

      Pour ta deuxième question, je n'ai pas la réponse. Je serais ravi qu'un utilisateur expérimenté de GPG se manifeste.

      Pour être honnête, j'ai mis en oeuvre PGP pour le chiffrement et la signature il y a 10 ans sous Windows 2000. J'ai tenté d'utiliser GPG récemment sous Ubuntu 10.10 mais j'ai été un peu calmé par un plantage de GPA ("Gnu Privacy Assistant" - l'interface graphique pour habiller GPG qui est un outils utilisable en ligne de commande) pendant le processus de génération de la paire de clés, juste en commençant à l'utiliser... J'aurais pu persévérer avec GPG en ligne de commande uniquement, mais mon besoin n'étant pas urgent, j'ai laissé filer. Ça ne m'a pas empêché de réfléchir au fil des mois passés et de pondre cette dépêche. Je remettrai bientôt les mains dans le cambouis et je compte bien me servir prochainement de GPG et de GPA sous GNU/Linux !

    • [^] # Re: symétrique(message)

      Posté par . Évalué à  2 .

      Je ne suis pas sûr de comprendre cette option. Est-ce que cela sert à voir la clef temporaire utilisée pour le chiffrement symétrique ?

      Je ne suis pas utilisateur de GPG, mais oui, ça a l'air d'afficher la clef de session utilisée pour un message.

    • [^] # Re: symétrique(message)

      Posté par . Évalué à  4 .

      Pour répondre à la première question, j'avais lu que la fiabilité des chiffrements asymétriques était d'autant plus élevée que les contenus à chiffrer étaient petits. En gros, si on chiffre trop de données avec un algo asymétrique, on "risque" de pouvoir retrouver le message et/ou la clé privée (ou une histoire du même genre).

      Les méthodes symétriques n'ont pas ce défaut : elles fonctionnent très bien, très vite, très rapidement sur de grandes quantités de données. Leur seul inconvénient est que le secret doit être partagé. C'est un inconvénient de taille...

      L'idée est donc de prendre une clé de session arbitraire qui sera placée dans le message, mais chiffrée avec un algo asymétrique, puis de chiffrer le reste des données avec uniquement cette clé de session. On utilise les bonnes propriétés des deux techniques, et en plus, la clé change à chaque fois, ce qui neutralisera pas mal d'attaque basées sur la répétition d'un motif habituel (Ceci dit, il y a d'autres techniques pour éviter cette répétition).

  • # C'est clair !

    Posté par (page perso) . Évalué à  4 .

    Haha, un article sur le chiffrement qui s'appelle "les concepts en clair", elle est bonne. :)

    C'est vrai que GPG sans ça c'est un peu cryptique.

    Merci pour l'article en tout cas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.