SHA1  a donc été "cassé", et si cela ne semble pas nouveau (que ce soit possible), Google en a apporté la preuve  
 
http://www.numerama.com/tech/23543 [...] sha-1.html
 
http://www.theverge.com/2017/2/23/ [...] -shattered
 
Ce que je ne comprends pas - je suis cryptodébutant -, c'est comment on peut arriver à ce résultat.
 
Pour moi le hash est le résultat d'un algorithme appliqué à un fichier ou une chaîne de caractères (sur quels aspects d'ailleurs pour le fichier ? Taille, structure, autre ?).
 
Dans le cas du SHA1 c'est censé être suffisamment bien foutu que pour que les empreintes soient uniques.
 
Je peux comprendre que comme le hash est de taille fixe, qu'il peut arriver que parmi les milliards de milliards de fichiers qui existent que, pas de bol, le résultat de l'algorithme soit identique (je présuppose que le nombre total de hashs possibles est < aux nombres de fichiers / chaînes de caractères qui peuvent exister, ce qui me semble logique).
 
Ce que je ne comprends pas, et c'est ce que Google est parvenu à faire, c'est comment on peut créer deux fichiers différents qui ont le même hash.
 
Pour moi cet algorithme est fixe, connu : on sait comment il calcule. Je peux comprendre qu'on puisse créer un fichier qui de par sa nature même donne le même hash qu'un autre fichier (il suffirait de tester tous les fichiers possibles et comparer les hashs).
 
Ce que je ne comprends pas, c'est qu'on puisse créer deux fichiers similaires (genre : deux textes de contrats très légèrement différents) qui ont le même hash.
 
Sur quoi se base le SHA1 pour pondre son résultat ? Est-ce que Google a "juste" réussi à modifier un fichier de telle sorte qu'il donne le même hash ? (sans que ce fichier ne ressemble à rien ?).
 
J'ai lu qq articles sur le sujet, mais aucun ne me permet de comprendre.
 
Si vous avez des éclaircissements, je suis preneur :-)
 
Merci

Je pense qu'il faut mieux aller voir du coté des mathématiciens.

Ce sujet a été déplacé de la catégorie Windows & Software vers la categorie Discussions par Wolfman

Pour ceux que ça intéresse, il y a qq éléments d'infos dans les commentaires de cet article : https://www.nextinpact.com/news/103 [...] tm#/page/3
 
Si j'ai bien tout compris, l'idée est d'ajouter des données inutiles (commentaires, autres...) au fichier doublon pour, à force d'essayer, finir par tomber sur le même hash que le fichier d'origine, non "altéré.
 
On pourrait donc créer deux PDF - puisque c'est le type de fichier que Google a utilisé - au contenu "visible / destiné à un humain" différents, mais avec un hash identique. Ce sont les données "annexes" qui permettraient de générer un autre PDF avec le même hash.
 
J'en conclus que Google a surtout été capable de faire suffisamment de versions altérées d'un fichier PDF pour en tester les hashs correspondants et tomber sur la même signature en un "temps raisonnable".
 
Rien de nouveau finalement, on pourrait faire la même chose quelque soit le hashage utilisé, non ? Sauf qu'actuellement on n'a pas la puissance machine nécessaire que pour le faire en un temps raisonnable avec des signatures plus longues que ce que permet SHA1.
 
Vous me dites si je n'ai rien compris hein

j'ai compris ce que tu as dit, mais je ne sais pas si c'est ce que l'article dit.
En tout cas ce serait une explication logique de ce problème.

SHA1 (ou tout autre hash crypto) est considéré cassé s'il existe une méthode autre que le brute force pour trouver deux "input" ayant le même hash.

Quand tu dis "Dans le cas du SHA1 c'est censé être suffisamment bien foutu que pour que les empreintes soient uniques.", c'est pas exact. Les fonctions de hashage font un condensé de taille fixe à partir d'une infinité de solution. De ce fait, par nature, il y a des collisions. C'est à dire que les résultats étant limité on doit forcément trouver dans la nature deux inputs ayant le même has. Le problème étant que SHA est conçu pour que la seule possibilité soit d'utiliser le brute force pour trouver une telle collision. La le truc plutot bien c'est qu'à partir d'un fichier, on peut lui trouver un complément qui ne change pas le hash dans un temps respectable. Après, ce n'est pas nouveau que l'on puisse calculer autrement que par brute force des collisions pour SHA1. Ca fait quelques temps que l'on recommande de basculer sur des hash puis robuste. Le NIST a d'ailleurs lancer un nouvel appel d'offre pour le remplaçant de mémoire.

 
On pourra donc appliquer la même méthode pour tous les algorithmes de hashage, si je comprends bien. Tant que l'algo donnera un résultat de taille fixe, on sera forcément limité par le nombre de possibilités résultant mécaniquement de la taille du résultats et du panel de caractères utilisés.
 
Ce n'est qu'une question de temps...