Créez vos propres collisions MD5
Je fais une présentation sur les collisions MD5 et j'aimerais donner aux gens une idée de la probabilité d'une collision.
Ce serait bien d'avoir deux blocs de texte qui hachent la même chose, et d'expliquer combien de combinaisons de [a-zA-Z] étaient nécessaires avant de heurter une collision.
La réponse évidente est de hacher toutes les combinaisons possibles jusqu'à ce que deux hachages soient identiques. Alors, comment feriez-vous pour coder cela. Comme expérience rapide, j'ai essayé de hacher toutes les combinaisons de 5 colonnes de [A-Z], de les stocker dans une table de hachage .net et d'attraper l'exception de collision. Deux problèmes avec cela - la table de hachage finit par expirer, et je suis presque sûr que je vais avoir besoin de BEAUCOUP plus de caractères.
De toute évidence, cette structure de données est trop volumineuse pour être gérée en mémoire, alors je vais maintenant devoir impliquer une base de données. Cela ressemble aussi à un bon projet pour tester Azure - un peu comme ces gars-là .
Quelqu'un peut-il m'orienter vers une manière efficace de procéder?
Ces deux séquences de 128 octets différentes sont hachées de la même manière:
Hash MD5: 79054025255fb1a26e4bc422aef54eb4
Les différences ci-dessous sont surlignées (en gras). Désolé, c'est un peu difficile à voir.
D131dd02c5e6eec4693d9a0698aff95c 2fcab5 8 712467eab4004583eb8fb7f89 55ad340609f4b30283e4888325 7 1415a 085125e8f7cdc99fd91dbd f 280373c5b D8823e3156348f5bae6dacd436c919c6 dd53e2-- b 487da03fd02396306d248cda0 e99f33420f577ee8ce54b67080 a 80d1e c69821bcb6a8839396f965 2 b6ff72a70
et
D131dd02c5e6eec4693d9a0698aff95c 2fcab5 712467eab4004583eb8fb7f89 55ad340609f4b30283e4888325 f 1415a 085125e8f7cdc99fd91dbd 7 280373c5b D8823e3156348f5bae6dacd436c919c6 dd53e2-- 487da03fd02396306d248cda0 E99f33420f577ee8ce54b67080 2 80d1e c69821bcb6a8839396f965 a b6ff72a70
La visualisation de la collision/bloc1 (Source: Links.Org )
La visualisation de la collision/block2 (Source: Links.Org )
C'est difficile de le faire avec juste des fichiers texte, AFAIK. Vous pouvez obtenir quelques collisions, mais les faire provenir également de [a-zA-Z] n'est pas (encore) facile.
D'un autre côté, si vous voulez juste deux fichiers d'apparence "significative" avec le même hachage, vous pouvez le faire avec quelque chose comme, disons, PostScript: avoir différents blobs binaires provoquant la collision, et utiliser une expression conditionnelle pour afficher une sortie différente en conséquence.
Voir par ex. ce problème (la partie H2) et solution . Par exemple, ce fichier PS et celui-ci ont la même somme MD5 mais ce sont tous les deux des fichiers PostScript bien formés qui contiennent du texte entièrement différent lorsque vous les ouvrez.
Si vous parlez de la probabilité d'une collision simple - celle où il n'y a pas de tentative délibérée d'en provoquer une - alors vous allez être déçu: vous devez générer en moyenne 2 ^ 64 textes en clair avant de vous attendre à voir une collision, et c'est beaucoup plus que ce que vous allez pouvoir faire dans un délai raisonnable (ou vraiment, même non raisonnable).
Si vous cherchez à démontrer la difficulté de créer délibérément une collision, d'autres réponses l'ont déjà démontré. Cependant, la contrainte supplémentaire d'exiger que les chaînes soient entièrement textuelles rend même ces approches largement impraticables.
Je voudrais jeter un œil à Hashcash . Avec un algorithme de hachage efficace, comme md5, le temps de calculer une collision à exponentielle avec le nombre de bits. Ce que fait Hashcash, c'est calculer les collisions partielles. C'est-à-dire, une correspondance de disons les 16 bits inférieurs du hachage. Pour que les 16 bits inférieurs correspondent, il faudrait essayer de hacher en moyenne 2 ^ 15 combinaisons différentes. Si vous savez combien de temps il faut pour arriver à une collision de 16, 24 ou 32 bits, vous pouvez facilement calculer le temps pour un plus grand nombre de bits.