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.
Commentaires (18)
#1
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.
#2
“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).
#3
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.
#4
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.
#5
Ah oui pardon, bien vu !
Du coup on est d’accord tous les trois, la phrase est mal formulée.
#6
… nécessitant selon les chercheurs entre 110 000 et 560 000 dollars d’investissement sur Amazon Web Services pour les calculs…
2 remarques :
#7
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 < 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.
#8
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.
#9
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.
#10
Sans aucun doute, mais ce n’était pas du tout le sens de ma remarque.
#11
Ce n’est pas un problème pour Git. Voir la réponse de Linus à l’attaque d’il y a 3 ans: https://news.slashdot.org/story/17/02/25/2229253/linus-torvalds-on-gits-use-of-sha-1-the-sky-isnt-falling
#12
ç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…
#13
Le roi de la contre-pétrie est parmi nous !
#14
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é.
#15
Vu que le chercheur parle en dollars, il est tout à fait logique de parler de chiffrage :-)
#16
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…
#17
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.
#18