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-modifyIci, 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 Aeris (site web personnel) . Évalué à 0.
Gaffe, tu es dans la 3ème colonne là :P
http://valerieaurora.org/hash.html
[^] # Un 2nd Oupa
Posté par Aeris (site web personnel) . Évalué à 3.
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 :
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 claudex . Évalué à 4.
Ç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 Aeris (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 gouttegd . É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 gouttegd . Évalué à 9.
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 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 Zenitram (site web personnel) . Évalué à -1.
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 gouttegd . Évalué à 5.
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 Zenitram (site web personnel) . Évalué à 2.
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 flan (site web personnel) . Évalué à 1.
Le problème est donc bien fixé dans Debian :)
[^] # Re: Un 2nd Oupa
Posté par Sufflope (site web personnel) . Évalué à 10.
Du coup s'il est fixé, ils ne le corrigeront jamais ? Faut changer de distrib ?
# Every single 64 bits possible value…
Posté par ®om (site web personnel) . Évalué à 10. Dernière modification le 23 février 2017 à 23:19.
http://shattered.io/
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)) :
Donc ça fait quand même plus de 263. C'est toujours infaisable.
Mais ils précisent :
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 Aeris (site web personnel) . Évalué à 5.
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 Maclag . É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 Larry Cow . Évalué à 5.
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 Antoine . É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 Maclag . É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 Clément David (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 Aeris (site web personnel) . Évalué à 8.
Autant ne laisser que le SHA256 du coup…
[^] # Re: Every single 64 bits possible value…
Posté par khivapia . É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 Kerro . É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 khivapia . É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 NSAle 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 barmic . Évalué à 4.
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 harlock974 . É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 aurel (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 Gof (site web personnel) . Évalué à 10.
Euh… Non.
On connait les faiblaisse du SHA-1 depuis plus de dix ans, et les experts comptaient déjà les jours depuis lors:
https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
http://valerieaurora.org/hash.html
[^] # Re: Est-ce réellement un problème ?
Posté par pulkomandy (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 gouttegd . Évalué à 9.
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.
La réponse B.
[^] # Re: Est-ce réellement un problème ?
Posté par gouttegd . Évalué à 9.
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 Zenitram (site web personnel) . Évalué à 6.
Très différent entre "rien dire" et "diff mineures", souvent l'objectif est une diff mineure.
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 Vlobulle . É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 Zenitram (site web personnel) . Évalué à -2.
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 pasBill pasGates . É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 khivapia . É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 pasBill pasGates . É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 gouttegd . É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 barmic . É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 Moonz . É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 :
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 barmic . Évalué à 3.
Page 11, section 5.2.2 première phrase du paragraphe :
Ç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 Moonz . É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 Antoine . Évalué à 4.
Si c'est juste pour ça ils auraient carrément pu utiliser un CRC…
[^] # Re: Est-ce réellement un problème ?
Posté par Zenitram (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 pulkomandy (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 Zenitram (site web personnel) . Évalué à 1. Dernière modification le 24 février 2017 à 16:26.
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 :).
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.
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 EauFroide . Évalué à -4. Dernière modification le 28 février 2017 à 14:34.
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 SChauveau . É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.
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.
[^] # Re: Est-ce réellement un problème ?
Posté par SChauveau . Évalué à 2.
Et bien entendu:
[^] # Re: Est-ce réellement un problème ?
Posté par Bernez . Évalué à 4.
Le site de shattered fournit une illustration pour l'expliquer :
[^] # Re: Est-ce réellement un problème ?
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
Voir SHA1 collider.
# Et paf le Subversion
Posté par ɹǝıʌıʃO . É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 ɹǝıʌıʃO . Évalué à 3.
En revanche, d’après Linus, git ne court pas le même genre de risque.
[^] # Re: Et paf le Subversion
Posté par Benoît Sibaud (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 groumly . É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 ɹǝıʌıʃO . É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 claudex . É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 Sufflope (site web personnel) . Évalué à 1.
Un outil dédié pour modifier un historique git ? Du genre… git ?
[^] # Re: Et paf le Subversion
Posté par claudex . É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 pulkomandy (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 foobarbazz . Évalué à 2.
On parle de quel type de bug là ?
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 Moonz . Évalué à 5.
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 foobarbazz . Évalué à 1.
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 Renault (site web personnel) . Évalué à 4.
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 :
[^] # Re: Et paf le Subversion
Posté par pulkomandy (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…
[^] # Re: Et paf le Subversion
Posté par ®om (site web personnel) . Évalué à 3.
Pour savoir exactement ce qu'il se passe quand git rencontre une collision dans différents cas:
http://stackoverflow.com/a/34599081/1987178
blog.rom1v.com
# Et paf le commitstrip !
Posté par windu.2b . Évalué à 3.
http://www.commitstrip.com/en/2017/02/27/17279/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.