Journal Et paf, le SHA-1 !

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
67
23
fév.
2017

Un journal bookmark pour annoncer la première collision SHA-1.

Concrètement, des chercheurs du Centrum Wiskunde & Informatica (institut néerlandais de recherche en mathématiques et informatique) et de Google sont parvenus à fabriquer deux fichiers PDF dont le contenu diffère mais dont le condensat SHA-1 est identique.

Si les auteurs expliquent brièvement en quoi Git (qui repose sur SHA-1 pour l’identification des blobs et des commits contenus dans un dépôt) est impacté, ils ne s’attardent pas en revanche sur OpenPGP, ce que je vais donc faire ici.

SHA-1 est actuellement utilisé au « cœur » d’OpenPGP, pour le calcul des empreintes des clefs en version v4. Ce dont on a besoin pour ce type d’utilisation est la résistance aux attaques sur la seconde pré‐image (étant donné le condensat d’une clef, trouver une autre clef donnant un condensat identique). La résistance aux collisions n’est pas critique ici et vos clefs OpenPGP ne sont donc pas menacées par le résultat rapporté ci‐dessus.

Notez qu’une mise à jour du standard OpenPGP est nécessaire pour changer l’algorithme utilisé pour les empreintes de clefs, ce n’est pas une décision qu’une implémentation peut prendre unilatéralement. Et le groupe de travail OpenPGP à l’IETF travaille précisément en ce moment sur une nouvelle version de la RFC 4880, qui devrait probablement déboucher sur un nouveau format de clef v5 utilisant un autre algorithme de condensation (de la même façon que le format v4, utilisant SHA-1, avait remplacé le format v3, utilisant MD-5).

L’autre utilisation possible de SHA-1 dans le monde OpenPGP est bien entendu les signatures (de clefs, de messages, de documents). Là, la résistance aux collisions est nécessaire, faute de quoi un attaquant pourrait vous faire signer un document A et faire valoir la signature sur un autre document B (comme les deux fichiers PDF générés par l’équipe de recherche).

À ce sujet, je tiens à rappeler que toutes les versions de GnuPG publiées depuis 2010 utilisent par défaut, pour les signatures, SHA-256 et non plus SHA-1. Vous n’avez donc pas besoin, contrairement à ce qu’on peut lire sur des tutos obsolètes, d’ajouter d’options du style cert-digest-algo ou personal-digest-preferences à votre fichier ~/.gnupg/gpg.conf.

Ce que vous pouvez avoir à faire en revanche, c’est mettre à jour la liste des algorithmes de condensation préférés associée à votre clef : si vous l’avez générée avec une version de GnuPG d’avant 2010, SHA-1 figure probablement toujours en tête de cette liste.

Éditez votre clef OpenPGP et utilisez la commande showpref pour afficher les listes d’algorithmes préférés :

$ gpg2 --edit-key alice@example.org
[...]
gpg> showpref
[ultimate] (1). Alice <alice@example.org>
     Cipher: Cipher: AES, AES192, AES256, TWOFISH, CAST5, 3DES
     Digest: SHA256, SHA512, SHA224, SHA384, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify

Ici, SHA-1 (dans la liste Digest) est en queue de liste, tout va bien.

Si jamais SHA-1 apparaît en tête de liste, utilisez simplement la commande setpref (sans arguments) pour mettre à jour les préférences en utilisant les algorithmes par défaut recommandés par les versions récentes de GnuPG.

  • # Oupa

    Posté par  (site web personnel) . Évalué à 0.

    SHA-1 est actuellement utilisé au « cœur » de OpenPGP, pour le calcul des empreintes des clefs en version v4. Ce dont on a besoin pour ce type d’utilisation est la résistance aux attaques sur la seconde pré-image (étant donné le condensat d’une clef, trouver une autre clef donnant un condensat identique). La résistance aux collisions n’est pas critique ici et vos clefs OpenPGP ne sont donc pas menacées par le résultat rapporté ci-dessus.

    Gaffe, tu es dans la 3ème colonne là :P
    http://valerieaurora.org/hash.html

    • [^] # Un 2nd Oupa

      Posté par  (site web personnel) . Évalué à 3.

      À ce sujet, je tiens à rappeler que toutes les versions de GnuPG publiées depuis 2010 utilisent par défaut, pour les signatures, SHA-256 et non plus SHA-1. Vous n’avez donc pas besoin, contrairement à ce qu’on peut lire sur des tutos obsolètes, d’ajouter d’options du style cert-digest-algo ou personal-digest-preferences à votre fichier ~/.gnupg/gpg.conf.

      Il y a une différence entre « GnuPG a fixé le problème depuis 2010 » et « les distributions et OS ont propagé la modification ».
      Actuellement, sous Debian stable, on a toujours le problème :

      $ cat /etc/debian_version 
      8.7
      $ apt-get dist-upgrade                                   
      Lecture des listes de paquets... Fait
      Construction de l'arbre des dépendances       
      Lecture des informations d'état... Fait
      Calcul de la mise à jour... Fait
      0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
      $ apt-cache policy gnupg{,2}
      gnupg:
        Installé : 1.4.18-7+deb8u3
        Candidat : 1.4.18-7+deb8u3
       Table de version :
       *** 1.4.18-7+deb8u3 0
              500 http://http.debian.net/debian/ jessie/main amd64 Packages
              100 /var/lib/dpkg/status
           1.4.18-7+deb8u2 0
              500 http://security.debian.org/ jessie/updates/main amd64 Packages
      gnupg2:
        Installé : 2.0.26-6+deb8u1
        Candidat : 2.0.26-6+deb8u1
       Table de version :
       *** 2.0.26-6+deb8u1 0
              500 http://http.debian.net/debian/ jessie/main amd64 Packages
              100 /var/lib/dpkg/status
      
      $ gpg --gen-key
      pub   2048R/22152665 2017-02-23
       Empreinte de la clef = 2696 3ECE B2DD BD1D B015  0C27 A26E 442A 2215 2665
      uid                  test-key <test@example.org>
      sub   2048R/58A0BAC2 2017-02-23
      $ gpg --edit-key 22152665
      gpg> showpref
      [  ultime ] (1). test-key <test@example.org>
           Hachage : SHA256, SHA1, SHA384, SHA512, SHA224
      
      $ gpg2 --gen-key                                                              
      pub   2048R/E71DC86E 2017-02-23
       Empreinte de la clef = 61F5 082A 93D9 491B CAAD  C6A5 E055 E54D E71D C86E
      uid      [  ultime ] test-key <test@example.org>
      sub   2048R/360B7F49 2017-02-23
      $ gpg2 --edit-key E71DC86E
      gpg> showpref
      [  ultime ] (1). test-key <test@example.org>
           Hachage : SHA256, SHA1, SHA384, SHA512, SHA224
      

      Et donc actuellement, sur une Debian stable, SHA1 est encore devant les SHA-2 à l’exception de SHA256…

      Il faut attendre la version 2.1 de GnuPG pour réellement avoir ce changement. Version actuellement disponible nul part ou presque (Debian testing uniquement, ni Debian stable, ni Ubuntu, ni Windows, ni Mac).

      Donc si, on a toujours besoin de faire ces modifications de fichiers !

      • [^] # Re: Un 2nd Oupa

        Posté par  . Évalué à 4.

        ni Ubuntu

        Ça quand même l'air d'être là depuis xenial http://packages.ubuntu.com/xenial/gnupg2

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Un 2nd Oupa

          Posté par  (site web personnel) . Évalué à 0.

          Si je ne dis pas de connerie (donc à vérifier), ça nécessite la version 2.1.14 minimum.

          • [^] # Re: Un 2nd Oupa

            Posté par  . Évalué à 2.

            Quoi, avoir SHA-1 en dernière position par défaut (et non pas en deuxième position) ? Pas du tout, ça date d’août 2014 et ça nécessite donc la version 2.1.0 publiée trois mois plus tard.

      • [^] # Re: Un 2nd Oupa

        Posté par  . Évalué à 9.

        Il y a une différence entre « GnuPG a fixé le problème depuis 2010 » et « les distributions et OS ont propagé la modification ».

        Et bien il est grand temps que « les distributions et OS » se bougent le cul.

        GnuPG 2.1.0 est sorti en novembre 2014. On est en février 2017. Sérieusement il n’y a plus d’excuse, là.

        Les développeurs de GnuPG ont annoncé la fin de vie de la branche 2.0 pour la fin de l’année, et quand à la branche 1.x, ça fait longtemps qu’elle n’est plus maintenue que par souci de compatibilité (principalement pour ceux qui pourraient avoir besoin de déchiffrer de vieux messages datant de l’époque de PGP 5).

        (Pro-tip: Quand je veux savoir si un tuto ou un quelconque document parlant de GnuPG vaut la peine d’être lu, je regarde la version de GnuPG utilisée. Si c’est GnuPG 1.x, je passe mon chemin.)

        Et donc actuellement, sur une Debian stable, SHA1 est encore devant les SHA-2 à l’exception de SHA256

        Et donc SHA-1 n’est pas l’algorithme de condensation par défaut, dans aucune des versions de GnuPG disponibles. Merci.

        • [^] # Re: Un 2nd Oupa

          Posté par  (site web personnel) . Évalué à -1.

          novembre 2014. On est en février 2017. Sérieusement il n’y a plus d’excuse, là.

          Ben si : 2.5 ans, c'est pas si énorme, faut arrêter de dire que 3 ans c'est obsolète et "pas d'excuse pour avoir changé".
          Pour référence WinXP a 15 ans est est toujours sur 10% des machines persos dans le monde.
          Alors certes 15 ans en sécurité c'est peut-être pas facile, mais entre 3 et 15 il y a de quoi faire.

          Perso, je dirai : quoi, on était en 2014 et c'est que la que SHA-1 n'a plus été mis en premier? Ca faisait des années qu'on sait que ça allait casser. Ce qui craint, c'est qu'on proposait encore SHA-1 en 2014 sans de gros avertissement "attention connerie, sachez ce que vous faites" (et pareil pour Git, ça craint qu'on n'ai pas migré depuis le temps).

          • [^] # Re: Un 2nd Oupa

            Posté par  . Évalué à 5.

            Perso, je dirai : quoi, on était en 2014 et c'est que la que SHA-1 n'a plus été mis en premier?

            Qu’est-ce qui n’est pas clair dans « toutes les versions de GnuPG publiées depuis 2010 utilisent par défaut SHA-256 et non plus SHA-1 » ?

            SHA-1 n’est plus l’algorithme par défaut depuis 2010, date à laquelle il a été placé en deuxième position derrière SHA-256.

            Et en 2014, pour faire bonne mesure, il a carrément été relégué en queue de liste (ce qui concrètement n’apporte pas grand’chose, mais ça permet de satisfaire ceux qui viennent se plaindre sur les listes du projet que « oh mon Dieu c’est une catastrophe SHA-1 est toujours là » — les mêmes que ceux qui depuis hier viennent se plaindre que « oh mon Dieu c’est une catastrophe SHA-1 est complètement cassé faites quelque chose bon sang »).

            • [^] # Re: Un 2nd Oupa

              Posté par  (site web personnel) . Évalué à 2.

              Qu’est-ce qui n’est pas clair dans « toutes les versions de GnuPG publiées depuis 2010 utilisent par défaut SHA-256 et non plus SHA-1 » ?

              Rien, c'est moi qui suis allé un peu trop loin, me focalisant sur 2014 qui dit "plus d'excuse", ok compris.

      • [^] # Re: Un 2nd Oupa

        Posté par  (site web personnel) . Évalué à 1.

        Le problème est donc bien fixé dans Debian :)

  • # Every single 64 bits possible value…

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 23 février 2017 à 23:19.

    http://shattered.io/

    The SHAttered attack is 100,000 faster than the brute force attack that relies on the birthday paradox.

    Je n'ai d'abord pas compris comment il était possible de réussir en n'étant que 100000 fois plus rapide.

    Un SHA1 a une longueur de 160 bits. Avec le paradoxe des anniversaires, on peut espérer en force brute trouver une collision en à peu près 280 hashes (une bonne approximation est de prendre la racine carrée du nombre de possibilités). Donc ça revient à tester toutes les combinaisons d'une variable de 80 bits. Infaisable.

    Mais même 100000 fois plus rapide, ça ne fait gagner que ~17 bits (ln(100000)/ln(2)) :

    $ echo 'l(100000)/l(2)' | bc -l
    16.60964047443681173951

    Donc ça fait quand même plus de 263. C'est toujours infaisable.

    Mais ils précisent :

    This attack required over 9,223,372,036,854,775,808 SHA1 computations.

    Ce nombre est exactement 263.

    Donc ils ont calculé presque 264 hashes. C'est dingue, je pensais qu'il était matériellement impossible de calculer n'importe quelle fonction pour toutes les valeurs possibles d'une variable de 64 bits.

    Je vais donc revoir mes règles de pouce approximant la frontière entre le possible et l'impossible à la hausse.


    PS : comment écrire 264 en markdown sur linuxfr sans manger l'espace ou mettre en exposant le caractère qui suit ?
    Voici ce que j'ai essayé :

    • 2^64. donne 264.
    • 2^64^. donne 264.
    • 2^{64}^. donne 2{64}.
    • 2^64 hashes. donne 264 hashes.
    • 2^64 h. donne 264 h. ← ça fonctionne, mais ce n'est pas ce que je veux écrire.

    EDIT : Pour 2^64 hashes., le problème ne se produit que lors de la prévisualisation, une fois posté, ça fonctionne ;-)
    Il y a d'autres différences entre la prévisualisation et la version postée, par exemple 2^{64}^..

    blog.rom1v.com

    • [^] # Re: Every single 64 bits possible value…

      Posté par  (site web personnel) . Évalué à 5.

      Donc ils ont calculé presque 264 hashes. C'est dingue, je pensais qu'il était matériellement impossible de calculer n'importe quelle fonction pour toutes les valeurs possibles d'une variable de 64 bits.

      C’est pour ça que l’état de l’art de la crypto est plutôt de tabler sur 128 bits minimum pour être à l’abri des attaques modernes.
      64 bits, ça puait déjà un peu depuis quelques temps, sweet32 avait fini de semer le doute partout, mais là c’est carrément une preuve que Google nous a sortie !

      • [^] # Re: Every single 64 bits possible value…

        Posté par  . Évalué à 7.

        C'est pour ça aussi que la NSA enregistre et stocke même les mails chiffrés:
        Ils pourront toujours les déchiffrer en force brute quelques années plus tard.

        • [^] # Re: Every single 64 bits possible value…

          Posté par  . Évalué à 5.

          C'est pour ça aussi que la NSA enregistre et stocke même les mails chiffrés:

          Fort probable, mais ça va leur coûter très chaud en stockage, à terme : ça se compresse pas bien du tout, les données chiffrées :)

          • [^] # Re: Every single 64 bits possible value…

            Posté par  . Évalué à 5.

            Peut-être que la NSA a mis la main sur les technologies ultra-secrètes d'i2bp.

          • [^] # Re: Every single 64 bits possible value…

            Posté par  . Évalué à 3.

            Pas forcément au regard du faible volume de mails chiffrés.

            Pour que ça les titille, il faudrait que tout le monde s'y mette y compris pour les mails anodins.
            Mais pour ça, il faudrait également que ça se fasse "tout seul", en particulier dans les clients mails grand public. Pourquoi GMail aiderait à chiffrer les mails que Google lit?

    • [^] # Re: Every single 64 bits possible value…

      Posté par  (site web personnel) . Évalué à 3.

      Effectivement, la description de la puissance de calcul utilisée est un peu affolante ; cependant (et l'analyse sur OpenGPG le montre) il faut aussi essayer d'identifier le cas d'usage : MD5 est "cassé" mais on peut continuer à l'utiliser pour la distribution de binaire en complément d'un SHA256 par exemple. Cela permet d'avoir une confiance raisonnable dans le binaire très rapidement !

      • [^] # Re: Every single 64 bits possible value…

        Posté par  (site web personnel) . Évalué à 8.

        mais on peut continuer à l'utiliser pour la distribution de binaire en complément d'un SHA256 par exemple

        Autant ne laisser que le SHA256 du coup…

      • [^] # Re: Every single 64 bits possible value…

        Posté par  . Évalué à 7.

        MD5 est "cassé" mais on peut continuer à l'utiliser pour la distribution de binaire en complément d'un SHA256 par exemple.
        C'est inutile. Des attaques génériques dites "en multicollision" montrent que ce n'est pas plus sûr que la plus sûre des deux. (c'est-à-dire qu'il est possible de trouver une collision sur les deux simultanément avec un temps de calcul de l'ordre de la collision sur la plus sûre des deux fonctions).

        • [^] # Re: Every single 64 bits possible value…

          Posté par  . Évalué à 2.

          Lorsqu'on recherche une solution pour de nombreuses années, il faut augmenter considérablement la taille des clefs/empreintes/etc. Mais si une découverte vient vraiment casser l'algo, c'est fichu.

          En combinant plusieurs algo, on peut raisonnablement penser être à l'abri du cassage de l'un d'entre-eux. Mais comment faire ?

          Si on « additionne » (exemple donné ci-dessus : on donne un résultat pour chaque algo) ça fonctionne pour les empreintes (hashes) à condition de toutes les vérifier. Si on constate qu'une empreinte n'est pas bonne, alors il y a eu un bricolage.

          Par contre ça ne fonctionne pas pour le chiffrement : on chiffre un message avec chaque algo, et cela donne un message résultant pour chaque. Il suffit de casser un algo pour lire le message original.
          Il faut donc faire une « multiplication » : chiffrer avec le premier algo, puis prendre ce résultat et le chiffrer avec le second, etc. C'est d'ailleurs ce qui vient à l'esprit intuitivement.
          Il y a d'autres solutions ?

          • [^] # Re: Every single 64 bits possible value…

            Posté par  . Évalué à 2.

            Ce que tu propose est tout à fait raisonnable en effet. Pour MD5 et SHAxxx, les fonctions étant basées sur sensiblement les mêmes principes (Add-Rotate-Xor avec insertion d'un morceau de message à chaque tour), cela ne semble pas très pertinent (la NSA le NIST a lancé le concours SHA-3 suite aux premières ébauches d'attaques sur SHA-1 par manque de confiance dans SHA-256 à SHA-512 puisque basées sur le même principe).

            Ce que tu suggères au fond est de prendre plusieurs algorithmes aux principes vraiment différents et de surchiffrer (ou hacher plusieurs fois). Par exemple, on pourrait prendre AES - Serpent - Twofish comme fait Veracrypt, ou différentes fonctions de hachage.

            C'est une possibilité. Le point de vue généralement adopté dans la communauté académique est plus binaire : soit tu as confiance dans un algorithme, soit pas, auquel cas tu en changes :-)
            De plus il semble possible de régler la marge de sécurité : finalement, un AES avec 4 tours suppplémentaires serait bien plus résistant tout en coûtant seulement 40% de plus en performances.

            Ensuite il y a la logique industrielle : utiliser plusieurs algorithmes est beaucoup plus coûteux qu'un seul (et pour des raisons techniques il vaut mieux en utiliser 3 que 2, pour la même raison qu'on fait du Triple-DES et non pas du Double-DES). Et d'un autre coûté, en changer quand il commence à y avoir une faiblesse est très coûteux.

            Du coup le débat n'est pas tranché, nul doute que l'approche d'utiliser plusieurs algorithmes est la plus sûre, c'est le côté 'meilleure sécurité' des compromis 'performances versus sécurité'.

            • [^] # Re: Every single 64 bits possible value…

              Posté par  . Évalué à 4.

              C'est une possibilité. Le point de vue généralement adopté dans la communauté académique est plus binaire : soit tu as confiance dans un algorithme, soit pas, auquel cas tu en changes :-)

              C'est tout de même la raison qui a était retenu pour choisir l'algo de sha3 : https://linuxfr.org/news/keccak-remporte-la-mise-et-devient-sha-3

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Est-ce réellement un problème ?

    Posté par  . Évalué à 5.

    Question naïve :

    Réaliser un fichier dont le contenu ne veut rien dire (ou présentant des différences mineures, comme dans l'exemple produit) mais dont la somme SHA-1 est identique à celle d'un autre fichier, c'est une chose.

    En revanche, réaliser, disons, une fausse iso Ubuntu contenant des logiciels malveillants fonctionnels et faire en sorte qu'elle ait le même SHA-1 que l'original, ça me paraît nettement plus compliqué.

    Donc est-ce réellement un problème ?

    • [^] # Re: Est-ce réellement un problème ?

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Sur le plan pratique, ce n'est peut-être pas encore un problème (par exemple avec Git). Mais le temps de SHA1 est davantage compté que ce qu'on pensait jusqu'alors. Autant anticiper les changements nécessaires pour éviter de se retrouver plus tard (et peut-être pas si tard que ça, justement) la tête dans le mur.

      La cybersécurité, c'est aussi de la gestion de risque, toussa…

    • [^] # Re: Est-ce réellement un problème ?

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Pourquoi ça serait plus compliqué?

      Normalement, une fonction de hachage, elle doit donner un résultat très différent même pour des changements mineurs du fichier original. La "distance" entre les clés n'est donc pas corrélée avec la distance entre les contenus source.

      Pour une image ISO par exemple, on commence par ajouter les fichiers malveillants, puis on lance le machin pour trouver une collision, en lui disant tous les endroits où il peut faire des changements. Typiquement, les secteurs d'une image ISO font 2048 octets, et la fin du dernier secteur alloué à chaque fichier n'est pas utilisée (car le fichier n'a pas une taille multiple de 2048 octets, il y a donc un peu de place perdue). L'outil n'a plus qu'à trouver comment remplir ces espaces de façon à générer une collision.

      Maintenant, je n'ai pas été vérifier: est-ce que cet outil génère à volonté des collisions avec un hash donné, ou bien est-ce qu'il peut "seulement" générer deux fichiers avec la même signature? (en ayant le contrôle des deux, et pas d'un seul)? Même dans ce deuxième cas, il y a plein d'endroits où ça pourrait être utilisé (comme indiqué dans le journal: on pourrait te faire signer numériquement un fichier PDF avec un contrat, mais avoir fabriqué un autre fichier PDF avec un texte différent, et "prouver" que c'est celui-là que tu as signé, puisqu'il a le même hash).

      • [^] # Re: Est-ce réellement un problème ?

        Posté par  . Évalué à 9.

        Pourquoi ça serait plus compliqué?

        Parce que ce n’est pas du tout la même chose.

        Pouvoir fabriquer deux fichiers ayant le même condensat (i.e. « générer une collision ») n’est pas la même chose que de pouvoir créer un fichier ayant le même condensat qu’un fichier donné (« trouver une seconde pré-image »).

        Même MD-5, dont la résistance aux collisions est en miette depuis très longtemps (on peut générer des collisions MD-5 à volonté avec une puissance de calcul bien moindre que celle mise en œuvre ici), est toujours résistant en pratique aux attaques sur la seconde pré-image.

        Maintenant, je n'ai pas été vérifier: est-ce que cet outil génère à volonté des collisions avec un hash donné, ou bien est-ce qu'il peut "seulement" générer deux fichiers avec la même signature?

        La réponse B.

        • [^] # Re: Est-ce réellement un problème ?

          Posté par  . Évalué à 9.

          Parce que ce n’est pas du tout la même chose.

          Pour être un peu plus parlant, la différence entre « générer une collision » et « trouver une seconde pré-image », c’est en gros la différence qu’il y a entre « trouver dans une foule deux personnes ayant leur anniversaire le même jour » (ce qui est plus probable qu’on a tendance à le croire — le fameux paradoxe des anniversaires, justement) et « trouver dans une foule une personne ayant son anniversaire le même jour que le tien ».

    • [^] # Re: Est-ce réellement un problème ?

      Posté par  (site web personnel) . Évalué à 6.

      Réaliser un fichier dont le contenu ne veut rien dire (ou présentant des différences mineures, comme dans l'exemple produit)

      Très différent entre "rien dire" et "diff mineures", souvent l'objectif est une diff mineure.

      Donc est-ce réellement un problème ?

      Disons qu'il y a 10 barrières mises en place, 8 on lâchées, à un moment il faut se poser la question de ce qu'on va faire quand les 2 dernières lâcheront, et comme ça met du temps à propager le tout chez tout le monde (des années), c'est déjà même un peu tard, alors oui c'est un problème (un gros même).

      Espérons que ça fera prendre conscience à du monde.
      (perso j'ai participé il y a peu à un vote avec le choix SHA-1 vs SHA-256, SHA-1 a été choisi car "c'est juste pour du contrôle que la transmission a pas merdé", et certes c'est vrai mais je trouve que c'est dommage de ne pas avoir les "best practices" partout pour dire d'éliminer SHA-1 de la tête des gens pour qu'ils ne votent pas pour SHA-1 à un autre moment plus sensible en ayant oublié son défaut juste ne votant machinalement).

      • [^] # Re: Est-ce réellement un problème ?

        Posté par  . Évalué à 4.

        Question naïve : quels sont les avantages du sha1 par rapport à un sha256 ? La vitesse de calcul ?

        • [^] # Re: Est-ce réellement un problème ?

          Posté par  (site web personnel) . Évalué à -2.

          La vitesse de calcul ?

          oui et non, ça rentre en ligne de compte mais pas plus que ça.
          Plutôt l'habitude "c'était dans la spec qu'on fait évoluer, pas la peine de changer sinon ça fera du code en plus donc ça coûte pour rien".

        • [^] # Re: Est-ce réellement un problème ?

          Posté par  . Évalué à 0.

          160bit vs 256 aussi. Pour certains usages ou les données sont petites cela a son importance.

          • [^] # Re: Est-ce réellement un problème ?

            Posté par  . Évalué à 2.

            Ça pourrait s'arranger avec un SHA-256 dont on tronque la sortie à 160 bits, sans avoir de collisions (pour le moment :)

            • [^] # Re: Est-ce réellement un problème ?

              Posté par  . Évalué à 4.

              La crypto n'est pas mon domaine mais il n'y a pas de risque d'affaiblir l'algo de manière non linéaire (relatif aux bits enlevés) en faisant cela ?

              • [^] # Re: Est-ce réellement un problème ?

                Posté par  . Évalué à 6.

                A priori non, du moins avec les algorithmes de la famille SHA-2. En tout cas tronquer un condensat SHA-2 est considéré comme complètement acceptable par le NIST (FIPS 180-4, section 7).

                L’algorithme SHA2-224 est d’ailleurs défini comme un condensat SHA2-256 (avec une constante d’initialisation différente toutefois) tronqué aux premiers 224 bits.

                • [^] # Re: Est-ce réellement un problème ?

                  Posté par  . Évalué à 3.

                  Pour ceux qui ne sont pas aller voir, il est surtout expliqué que ça réduit la résistance de nb/2 soit 80. Donc si 80bits de résistance à la collision suffit, c'est ok.

                  C'est ce que je comprends de ce papier : http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf (section 5.2.2)

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Est-ce réellement un problème ?

                    Posté par  . Évalué à 2.

                    Je vois rien qui parle de troncature dans ton lien, à part une référence à http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=911479, qui dit :

                    If collision resistance is required, λ shall be at least twice the required collision resistance strength s (in bits) for the truncated message digest (i.e., λ ≥ 2s).

                    Ce qui n’a rien à voir avec une éventuelle perte de sécurité relative à l’algorithme originel, mais fait référence au paradoxe des anniversaires (cad que SHA-512 non tronqué a 256 bits de sécurité contre une collision, et SHA-512 tronqué à 256 a 128 de bits de sécurité contre une collision).

                    • [^] # Re: Est-ce réellement un problème ?

                      Posté par  . Évalué à 3.

                      Page 11, section 5.2.2 première phrase du paragraphe :

                      As noted in Section 5.1, when the outputs of an approved L-bit hash function are truncated to λ bits (where λ < L), the collision resistance strength supported by the truncated message digests is reduced to λ/2 bits.

                      Ça n'est apparemment pas lié à SHA-256, mais il est bien dit que la "collision resistance strength" est réduite.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: Est-ce réellement un problème ?

                        Posté par  . Évalué à 5. Dernière modification le 01 mars 2017 à 17:24.

                        Je pense qu’on est d’accord, mais histoire d’être bien clair : si tu tronques une fonction de hash sécurisée à λ bits, tu perds potentiellement en sécurité pour deux raisons :

                        • Trivialement, parce que tu as moins de bits : c’est ce que confirme le passage que tu cites : avec λ bits tu as au plus une sécurité de λ/2 bits de résistance contre une collision (birthday paradox), quel que soit ton algorithme (un algo qui te sort direct λ bits, ou un algo qui te sort L bits tronqué à λ bits)

                        • Des effets non triviaux qui réduisent la résistance à la collision à une valeur inférieure au maximum théorique de λ/2, qui est je suppose ce que pBpG demandait par « La crypto n'est pas mon domaine mais il n'y a pas de risque d'affaiblir l'algo de manière non linéaire (relatif aux bits enlevés) en faisant cela ? ». La réponse (au vu de tes liens) est clairement non pour SHA-*, d’après tes liens : si SHA-512 est optimal (fournit 256 bits de sécurité) alors SHA-512/λ l’est (fournit λ/2 bits de sécurité).

      • [^] # Re: Est-ce réellement un problème ?

        Posté par  . Évalué à 4.

        SHA-1 a été choisi car "c'est juste pour du contrôle que la transmission a pas merdé"

        Si c'est juste pour ça ils auraient carrément pu utiliser un CRC…

        • [^] # Re: Est-ce réellement un problème ?

          Posté par  (site web personnel) . Évalué à -4.

          Plutôt MD5 pour un fichier entier, jamais vu de fichier "crcsum".
          Pour la spec à laquelle je pense, c'est surtout que SHA-1 était le "standard" à l'époque de la première version, donc coût nul de prendre SHA-1 par rapport à MD5, tandis que faire une deuxième version vers SHA-2 a un coût en plus sans en voir de gain financier en retour (du moins dans un premier temps, et les fonctions CPU d'Intel ne m'aident pas vu qu'elles ont les deux). Ca se défend, mais pour ma part j'estime que c'est une problème potentiel plus tard qu'on ne maitrise pas et préfère faire évoluer trop tôt que trop tard.

          • [^] # Re: Est-ce réellement un problème ?

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Le CRC est utilisé pour vérifier l'intégrité de chaque fichier dans un zip, par exemple. Mais en effet il est rarement utilisé en dehors. Peut-être juste parce qu'il manque les outils pour le faire, mais aussi parce que finalement, ça coûte pas tellement plus cher de mettre un SHA256 qui donne quelques garanties supplémentaires. à moins de traiter vraiment beaucoup de gros fichiers?

            • [^] # Re: Est-ce réellement un problème ?

              Posté par  (site web personnel) . Évalué à 1. Dernière modification le 24 février 2017 à 16:26.

              Le CRC est utilisé pour vérifier l'intégrité de chaque fichier dans un zip,

              Le ZIP a une contrôle en plus (le fait que la décompression s'est bien passée, ni trop court ni trop long), il triche :).

              ça coûte pas tellement plus cher de mettre un SHA256

              Ce qui coûte, c'est le changement. Le poids de l'histoire. Git ou autre, on mettrai SHA-256 si on créé un nouveau produit. Mais changer c'est complètement différent, nouveau code + gestion du contenu existant.

              gros fichiers?

              Dans mon exemple, ça parle de fichiers d'1 TB ou plus.
              A toi de dire si c'est petit ou gros pour toi ;-).

              • [^] # Re: Est-ce réellement un problème ?

                Posté par  . Évalué à -4. Dernière modification le 28 février 2017 à 14:34.

                on mettrai SHA-256 si on créé un nouveau produit

                Si c'est pour de la sécurité alors SHA-512 stp, le 256 est potentiellement facile à casser pour un pays qui possède des usines capable de fabriquer en masse des ASIC comme la Chine (ce n'est pas pour rien que le bitcoin et ses frangins utilisent un double sha-256).
                Si c'est pour du P2P, alors ok SHA-256 ou double SHA-256 (pour profiter des asic) :P

                PS: à titre d'exemple le pool de Antminer (société chinoise qui fabrique des ASIC) tourne a 546.25 PH/s (PetaHash par seconde)

                Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Est-ce réellement un problème ?

      Posté par  . Évalué à 6.

      J'ai comparé le contenu des 2 fichiers PDFs et les différences se trouvent dans une zone de 128 octets au tout début (de 0x0c0 à 0x140) Je ne sais pas comment interpréter les PDF mais je suppose que cette zone contient une palette de couleur.

      La partie vraiment intéressante est qu'il est possible de créer de nouvelles collisions en utilisant ces 0x140 octets comme début de fichier.

      echo "Ceci est un fichier quelconque " > ZZZ
      head -c $((0x140)) shattered-1.pdf > X1
      head -c $((0x140)) shattered-2.pdf > X2
      cat X1 ZZZ > Y1 
      cat X2 ZZZ > Y2 
      sha1sum Y1 Y2

      Le résultat est
      96e77b1431ca36560609853b8f2df56c439cf104 Y1
      96e77b1431ca36560609853b8f2df56c439cf104 Y2

      Maintenant, il suffit juste de remplacer ZZZ par du code PDF valide affichant 2 contenus différents en fonction des valeurs entre 0xc0 et 0x140. C'est probablement assez facile pour n'importe quel expert en PDF.

      Le seul point positif est que les entêtes X1 et X2 ne peuvent pas être modifiés et il contiennent le texte "SHA-1 is dead!!!!!". Une arnaque basée sur ce principe est donc possible mais assez facile à prouver.

      Quoi qu'il en soit je suis certain que d'ici quelques heures ou quelques jours, des outils permettant de créer des collisions de PDF vont apparaître sur le darknet.

  • # Et paf le Subversion

    Posté par  . Évalué à 10.

    Quelqu’un a voulu tester si Webkit pouvait être susceptible à ce type de collision dans le cadre d’un empoisonnement de cache, et il a donc tout à fait logiquement eu l’idée d’envoyer deux fichiers ayant le même SHA-1 dans le dépôt Subversion du projet. Résultat : leur SVN est tout cassé

    • [^] # Re: Et paf le Subversion

      Posté par  . Évalué à 3.

      • [^] # Re: Et paf le Subversion

        Posté par  (site web personnel) . Évalué à 7.

        J'aime bien la partie où il rassure en disant que l'on sera prévenu a posteriori de l'empoisonnement du puits. Aaargh…

      • [^] # Re: Et paf le Subversion

        Posté par  . Évalué à 2.

        Mouaif.
        il a écrit qq chose de tres long, pour dire en gros "git est pas vraiment affecté, mais en fait si, on a un patch, mais il est pas encore release".
        Ce que j'en retient c'est qu'il est tout à fait possible de modifier un commit dans un repo sans casser aucun sha dans l'arbre, ce qui est quand même assez vilain: prend un commit suffisament vieux pour que personne n'y fasse attention, modifies le code pour introduire une faille subtile (du genre de heartbleed), ajoutes y un pdf, potentiellement cache (dot file), génère ta collision et paf le repo.

        Sur un repo suffisament gros, c'est tres probable que personne ne remarque le fichier supplémentaire, et si la faille est un débordement de tampon subtile, ca se remarque pas non plus.

        Ca fait un peu bizarre de voir Linus dire ca, après l'avoir entendu répéter pendant des années "git est chanmé parce que sha-1 garantit l'intégrité de l'historique".

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Et paf le Subversion

          Posté par  . Évalué à 7.

          On n’a pas dû lire le même texte.

          D’abord, d’après Linus, l’attaquant a besoin de contrôler les deux objets, il ne peut pas partir de n’importe quoi. Ensuite, du code a déjà été écrit pour ajouter à git la détection automatique des collisions, donc pas besoin de surveillance par un humain. Et enfin, il y a déjà (depuis longtemps) un projet en cours pour migrer vers quelque chose de plus sûr que SHA-1.

          • [^] # Re: Et paf le Subversion

            Posté par  . Évalué à 5.

            La détection des collisions, c'est pour les nouveaux commits, ça ne concerne pas une modification de l'historique (vu que tu n'utiliserait pas git pour faire ça mais tes outils dédiés).

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Et paf le Subversion

              Posté par  (site web personnel) . Évalué à 1.

              Un outil dédié pour modifier un historique git ? Du genre… git ?

              • [^] # Re: Et paf le Subversion

                Posté par  . Évalué à 7.

                Non, tu utilise git pour modifier l'historique git quand tu veux le faire comme c'est prévu. Pas pour remplacer un commit sain par un commit malicieux en gardant le même sha1.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Et paf le Subversion

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Sachant que bricoler le hash d'un commit git n'est pas forcément difficile (même sans cacher des fichiers dedans), car on peut aussi bricoler les métadonnées: message de commit, date et heure, etc.

          Cela est déjà mis en pratique par exemple ici (bien regarder les commit hashs affichés dans l'historique - juste en changeant la date des commits de +/- 30 minutes):

          https://github.com/vog/beautify_git_hash/commits/master

    • [^] # Re: Et paf le Subversion

      Posté par  . Évalué à 2.

      On parle de quel type de bug là ?

      XKCD 1700

      Parce qu'on est d'accord, c'est pas sha-1 le problème là hein ? Mais le fait que SVN semble considérer qu'une fonction de hash est injective.

      • [^] # Re: Et paf le Subversion

        Posté par  . Évalué à 5.

        Mais le fait que SVN semble considérer qu'une fonction de hash est injective.

        C’est pas les seuls à considérer que c’est le cas en pratique, et c’est tout à fait raisonnable : c’est le principe d’une fonction de hash cryptographique que la probabilité d’une collision ne soit certes pas nulle (comme ce serait la cas d’une fonction de hash injective) mais complètement négligeable. De fait, si tu trouves un exemple de non-injectivité d’une fonction de hash, même par accident, c’est que tu as réussi à casser le hash, et à toi la célébrité.

        • [^] # Re: Et paf le Subversion

          Posté par  . Évalué à 1.

          C’est pas les seuls à considérer que c’est le cas en pratique, et c’est tout à fait raisonnable

          C'est pas raisonnable du tout, c'est faux. Et c'est pas du tout le cas « en pratique », ou nous ne serions pas en train d'avoir cet échange…

        • [^] # Re: Et paf le Subversion

          Posté par  (site web personnel) . Évalué à 4.

          comme ce serait la cas d’une fonction de hash injective

          Une fonction de hash purement injective n'a pas vraiment de sens, du moins si tu considères tes entrées comme indéfinies et donc infini.
          Car dans ce cas tu amènes un espace infini d'entrées (des fichiers) dans un espace fini (sur quelques octets), les collisions existeront forcément.

          Donc on sait que quelque soit la fonction de hachage, pour comparer des fichiers, des collisions surviendront. Donc tomber par hasard dessus n'a rien de si extraordinaire pour te rendre célèbre.

          Ce qui est intéressant de savoir est :

          • Est-ce qu'on sait concevoir des collisions rapidement ?
          • Est-ce qu'on peut concevoir des collisions facilement de sorte que deux fichiers d'un but similaire puissent être indiscernables ainsi ? Car on s'en fout un peu que l'ISO de ta Debian ait une collision avec ta facture de téléphone, ils ne partagent pas les mêmes buts, n'auront pas la même taille (donc tu pourras voir le soucis rapidement) et sont très facilement distinguables l'un de l'autre visuellement. Par contre entre deux factures du même prestataire, la même date mais le montant qui change, c'est un soucis sérieux…
      • [^] # Re: Et paf le Subversion

        Posté par  (site web personnel, Mastodon) . Évalué à 7.

        git repose exactement sur la même "supposition". Selon leurs propres mots: il y a plus de chance que les développeurs du projet soient tués par des loups une nuit, dans des évènements indépendants, que de tomber par hasard sur une collision SHA-1.

        La supposition que les collisions sont suffisament rares pour ignorer le problème permet à git (et je suppose aussi à SVN) d'être rapide. Dans le cas de git, il me semble qu'ils vérifient qu'il n'y a pas de collision, et donc lors d'un commit, tu auras un message d'erreur avant de casser ton dépôt. C'est déjà ça…

  • # Et paf le commitstrip !

    Posté par  . Évalué à 3.

Suivre le flux des commentaires

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