Connexion
Abonnez-vous

SHA-1 à nouveau victime d’une attaque par collision, plus forte que la première

SHA-1 à nouveau victime d’une attaque par collision, plus forte que la première

Le 08 janvier 2020 à 09h33

Il y a trois ans, des chercheurs avaient prouvé que l’algorithme d'empreinte SHA-1 n’était définitivement plus fiable : des collisions étaient possibles.

Il y a collision quand deux fichiers chiffrés par le même algorithme donnent le même hash (empreinte cryptographique). En conséquence, un fichier peut sembler être ce qu’il promet et pourtant renfermer des données différentes.

À l’époque, l’attaque était cependant difficile à mettre en œuvre, nécessitant selon les chercheurs entre 110 000 et 560 000 dollars d’investissement sur Amazon Web Services pour les calculs, comme le rappelle Ars Technica. La nouvelle n’en nécessite que 45 000.

La méthode, tout juste présentée par des chercheurs au Real World Crypto Symposium de New York, permet également plus de souplesse pour les attaquants.

L’utilisation de SHA-1 a largement diminué ces dernières années, mais il est souvent l’algorithme par défaut vers lequel se replier quand un service, quel qu’il soit, se retrouve face à un appareil ne gérant pas de technologies plus récentes.

Nos confrères rappellent en outre que SHA-1 reste l’algorithme par défaut de l’ancienne branche 1.4 de GnuPG pour certifier les clés PGP. Les signatures SHA-1 étaient même acceptées jusqu’à récemment par la branche actuelle. Elles ne le sont plus, les développeurs ayant été prévenus par les chercheurs. Git l’utilise par contre toujours pour l’intégrité du code.

Le 08 janvier 2020 à 09h33

Commentaires (18)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Le roi de la contre-pétrie est parmi nous !

votre avatar

En fait la question n’est pas savoir s’il est possible deproduire un hash SHA-1 sur demande. C’est toujours possible. La point dur est de savoir en combien de temps, c’est-à-dire l’effort nécessaire.

Ici les chercheurs démontrent qu’une nouvelle technique permet de réduire encore plus cet effort pour forger un message produisant un même SHA-1.

En crypto il n’est pas question de “est-ce possible” mais “en combien de temps”. C’est pour cela que dans des protocoles de sécurité il y a souvant un timestamp protégeant un peu plus des usurpations durant la fenêtre de validité du message signé.

votre avatar

Vu que le chercheur parle en dollars, il est tout à fait logique de parler de chiffrage :-)

votre avatar



On parle d’un hash.

Tu peux mettre une limite de temps de validité, mais tu génèreras le même hash avec le même protocole pour une même source donné 10ans après.

Du coup je ne comprends pas ta remarque…

<img data-src=" />

votre avatar

Je ne comprends pas bien le débat, d’un côté selon wikipedia ce n’est plus considéré comme un chiffrement sûr depuis 2005.

En tant que algorithme de hashage c’est normal que deux entrées puissent produire la même empreinte. Et c’est comme ça que l’on doit l’utiliser, par exemple en exagérant disons qu’un hashage de votre numéro de carte bleue est de dire s’il est pair ou impair, forcément il est impossible de savoir lequel des numéros possibles (tous es pairs, ou tous les impairs) est le bon. Avec du texte par contre ce n’est pas tout à fait pareil car parmi les possibilité on va déjà éliminer ce qui ne veut rien dire, donc là oui ce n’est pas une très bonne idée.

votre avatar







barlav a écrit :



On parle d’un hash.

Tu peux mettre une limite de temps de validité, mais tu génèreras le même hash avec le même protocole pour une même source donné 10ans après.

Du coup je ne comprends pas ta remarque…

<img data-src=" />





En gros, en 1995, on a créé le SHA-1 en disant que c’était viable car un calcul de collision serait trop compliqué (mettons que jusqu’en 2005, ça prendrait au moins 10 ans d’en faire une) et on a pu signer (avec des certificats et tout le toutim) en utilisant SHA-1 dans le processus, en mettant 2005 comme date de péremption.

&nbsp;Mais comme il y a des dates de péremption, un signature utilisant SHA-1 n’est plus valable 10 ans après sa création. Donc soit cette signature a été refaite depuis, soit elle n’a plus de valeur. Dans tous les cas, on n’a pas une signature utilisant SHA-1 qui soit encore valide (même si tu peux refaire le même calcul).



&nbsp;



tontonCD a écrit :



Je ne comprends pas bien le débat, d’un côté selon wikipedia ce n’est plus considéré comme un chiffrement sûr depuis 2005.

En tant que algorithme de hashage c’est normal que deux entrées puissent produire la même empreinte. Et c’est comme ça que l’on doit l’utiliser, par exemple en exagérant disons qu’un hashage de votre numéro de carte bleue est de dire s’il est pair ou impair, forcément il est impossible de savoir lequel des numéros possibles (tous es pairs, ou tous les impairs) est le bon. Avec du texte par contre ce n’est pas tout à fait pareil car parmi les possibilité on va déjà éliminer ce qui ne veut rien dire, donc là oui ce n’est pas une très bonne idée.





Par définition, il y aura toujours des risques de collision. Tout le problème est d’avoir des méthodes qui ne permettent pas de les créer sur mesure.


votre avatar

Ce n’est pas un algorithme de chiffrement, mais de hachage. Ce qui permet par exemple de créer une signature à partir d’un message. Mais on ne peut aucunement retrouver le message avec la signature ainsi générée.

votre avatar

“Il y a collision quand deux fichiers chiffrés par le même algorithme donnent le même hash (empreinte cryptographique).”



La définition a changé ? Il ne suffit plus de deux fichiers différents générant le même hash pour parler de collision ?



“En conséquence, un fichier peut sembler être ce qu’il promet et pourtant renfermer des données différentes.”



Encore faut-il que ce soit la même clé, autrement, peu de chances que le déchiffré donne une donnée exploitable (que ce soit un texte pour un humain, une image, un XML, etc. pour une machine).

votre avatar

Il n’y a pas de clé pour les algorithmes de hachage.

Ici le risque est qu’un fichier forgé pour avoir le même hash qu’un autre (même s’il est de taille différente) ne soit pas rejeté par un système qui se base sur cette méthode de vérification.



Même dans le cas ou se fichier ne contient rien de particulier, cette collision peut par exemple invalider une non-répudiation, et sûrement d’autres problèmes qui ne me viennent pas en tête pour l’instant.

D’où le fait de l’éviter dans une PKI pour des opérations sensibles.

votre avatar

Je sais bien, je rejette complètement la définition de ce qu’est une collision telle que décrite ici dans la news mais dans le doute, du coup j’ai essayé de mettre en évidence son caractère absurde.



Je pense que John a une meilleure lecture que moi de la news en comprenant que l’auteur s’était trompé en employant le terme chiffré plutôt que “hashé” dans la première phrase que je cite.

votre avatar

Ah oui pardon, bien vu !

Du coup on est d’accord tous les trois, la phrase est mal formulée.

votre avatar



… nécessitant selon les chercheurs entre 110 000 et 560 000 dollars d’investissement sur Amazon Web Services pour les calculs…



2 remarques :




  • Personne n’est jamais assez fort pour ce calcul.

  • Le dollar est véritablement une unité de mesure universelle.

votre avatar

Des collisions il y en a forcément pour tous les algos de hashage, par définition, puisqu’on réduit une taille X à une taille Y avec Y &lt; X, et qu’on peut hasher n’importe quel message en entrée, il y a forcément plusieurs messages qui produisent le même hash.



La question est de savoir si on peut produire une collision exprès.



Effectivement l’article est mal formulé, surtout en utilisation le terme “chiffrage” qui induit en erreur.

votre avatar

Ca donne une idée de l’accessibilité de la faille. A l’heure actuelle à 45000 dollars la collision, tu ne peux pas attaquer massivement une base de donnée de mots de passes mal hashés, et ça ne reste qu’à la portée de grosses organisations et états.

Quand il faudra louer 100$ de machines pour le faire, ça deviendra plus problématique.

votre avatar

Les collisions ont toujours été possible. Le hash faisant un nombre finit de caractère. La nouveauté c’est de savoir créer un fichier corrompu avec un hash prédéfini.

votre avatar

Sans aucun doute, mais ce n’était pas du tout le sens de ma remarque.

votre avatar

Ce n’est pas un problème pour Git. Voir la réponse de Linus à l’attaque d’il y a 3 ans:&nbsp;https://news.slashdot.org/story/17/02/25/2229253/linus-torvalds-on-gits-use-of-sha-1-the-sky-isnt-falling

votre avatar

ça dépend de ce qui est en jeux, si c’est une verification d’une update d’un logiciel qui vérifie juste l’intégrité de l’update par un hash ( qu’il récupère de façon sécurisé sur le server d’update ) , et que tu as un exe malicieux passé par le réseaux qui s’execute auto … )



à une époque les iso microsofts en torrent était bien plus rapide à dl et on vérifiait le md5 sur le site de ms pour être sur de pas avoir d’iso trifouillé. ( ou des paks d’updates ) si il y s des sous à se faire ou que c’est des budget type organisation gouvernemental, c’est pas 50k$ qui les arrêtent…

SHA-1 à nouveau victime d’une attaque par collision, plus forte que la première

Fermer