MD5 est-il encore assez bon pour identifier les fichiers de manière unique?

139

Le hachage MD5 est-il toujours considéré comme une méthode suffisamment bonne pour l'identifier de manière unique compte tenu de tous les problèmes d'algorithme MD5 et de sécurité, etc.? La sécurité n'est pas ma principale préoccupation ici, mais l'identification unique de chaque fichier l'est.

Des pensées?

hash md5 Ranhiru Jude Cooray
la source
2
Je l'utilise actuellement moi-même dans l'une de mes applications, et pour autant que je sache, il est assez bon pour identifier les fichiers de manière unique.
Indisponible
2
Vous trouverez probablement cette question: stackoverflow.com/questions/862346/… utile.
Dentranchante
Combien de fichiers devez-vous identifier? Il génère 128 bits, donc si vous essayez d'identifier quelques milliers de fichiers, c'est très bien. Mais si vous essayez d'identifier beaucoup plus que cela, vous risquez de vous heurter à des collisions / au paradoxe de l'anniversaire.
Marcin
Ce seront des fichiers image, jpg, png et gif. Et oui, je pense que la limite serait de quelques milliers ... Mais selon vous, combien de fichiers vont me causer des ennuis?
Ranhiru Jude Cooray
En relation: stackoverflow.com/questions/14973197/…
NeDark

Réponses:

89

Oui. MD5 a été complètement cassé du point de vue de la sécurité, mais la probabilité d'une collision accidentelle est encore extrêmement faible. Assurez-vous simplement que les fichiers ne sont pas créés par une personne en qui vous n'avez pas confiance et qui pourrait avoir une intention malveillante.

Marcelo Cantos
la source
2
@none: Pour votre première question, cliquez ici . J'ai peur de ne pas comprendre les autres questions.
Marcelo Cantos
9
@ 0xA3: Ni vous ni moi n'avons aucune idée des fichiers auxquels l'OP fait référence, ni des dommages qu'un compromis causerait. Cela pourrait être la collection de photos de bébé de leur enfant pour tout ce que nous savons. Mon objectif est de fournir les faits; ce que quelqu'un d'autre fait avec eux est leur affaire. Considérez également que Bruce Schneier recommande d' écrire votre mot de passe; tout n'a pas besoin d'être entreposé à Fort Knox. Certaines choses se conservent très bien sous le pot de fleurs.
Marcelo Cantos
3
@Marcelo Cantos, je pense que ce qui manque ici, c'est une différenciation ou un déballage du terme «sécurité». De toute évidence, les gens supposent la «sécurité» pour toute utilisation du travail de somme de contrôle, mais la nomenclature que Marcelo signifie probablement est «dans un laboratoire».
hpavc
5
Je suis fortement en désaccord. Une valeur de hachage différente indique que les fichiers sont différents. Mais pour une valeur de hachage égale: vous ne pouvez pas dire "il est fort probable que les deux soient identiques" si le hachage est le même: vous ne pouvez comparer que octet pour octet. Un hachage est de plusieurs ordres de grandeur inférieur au nombre de valeurs différentes pour l'ensemble du fichier, il existe donc de très nombreuses collisions possibles pour chaque valeur de hachage. Ce n'est que si vous copiez un fichier connu (avec un hachage connu) qu'une valeur de hachage identique "signifie probablement" que le 2ème a été copié correctement (même dans ce cas, ce n'est pas sûr à 100%, mais très probable).
Olivier Dulac
3
OK, mes maths sont nulles. Les GUID ont environ 122 bits d'entropie, et donc la probabilité d'une collision n'importe où dans un milliard de fichiers est d'environ 2 ^ (2 * 30 - 122) = 2 ^ -62. Bien que ce soit beaucoup plus élevé que mon calcul initial, il est toujours minuscule à environ un sur 4 quintillions.
Marcelo Cantos
32

Pour des raisons pratiques, le hachage créé peut être convenablement aléatoire, mais en théorie, il y a toujours une probabilité de collision, en raison du principe de Pigeonhole . Avoir des hachages différents signifie certainement que les fichiers sont différents, mais obtenir le même hachage ne signifie pas nécessairement que les fichiers sont identiques.

Utiliser une fonction de hachage à cette fin - que la sécurité soit un problème ou non - ne devrait donc toujours être que la première étape d'une vérification, surtout si l'algorithme de hachage est connu pour créer facilement des collisions. Pour savoir de manière fiable si deux fichiers avec le même hachage sont différents, vous devez comparer ces fichiers octet par octet.

stapeluberlauf
la source
16
@Ranhiru. Non. Le hachage vous donne une valeur «récapitulative» qui (pour MD5) ne fait que 16 octets. Pour garantir que les fichiers sont identiques, vous devez effectuer une vérification octet par octet. Cela est vrai quel que soit l'algorithme de hachage que vous choisissez, il y a toujours la possibilité d'une collision.
PaulG
6
@Ranhiru. Relisez cette réponse, c'est à mon humble avis la plus complète ici. Le hachage peut être utilisé comme première étape, ce qui vous permet d'obtenir une certitude à 99,99 ^ e% que les fichiers sont identiques, mais si vous voulez être absolument sûr à 100% , vous devrez alors effectuer une vérification octet par octet. Cela est vrai que vous utilisiez MD5, SHA ou tout autre algorithme.
PaulG
7
Cette réponse est fausse. La prévention de la falsification et la vérification de l'unicité sont la même chose. De plus, si le hachage ne garantit pas l'unicité, la comparaison réelle non plus. En fait, la probabilité de collision accidentelle d'un hachage est en réalité inférieure à la probabilité d'échec de la comparaison en raison de problèmes dans le processeur générés par les émissions de rayons gamma solaires normales. Et n'oubliez pas que souvent la seule source du fichier se trouve à l'autre bout du monde à l'intérieur d'un serveur Web, et que la seule information indépendante dont vous disposez à des fins de comparaison est le hachage.
Marcelo Cantos
8
@Marcelo. Cela ne résiste pas au raisonnement logique selon lequel une collision accidentelle est moins probable que des retournements de bits accidentels (tout en effectuant une comparaison octet par octet). Vous avez toujours la même chance de retournements de bits lors de la construction du hachage (et sans doute plus car plus de temps de traitement est impliqué). @Thomas a soulevé la question à l'origine pour suggérer qu'il n'y a pas de moyen garanti d'identifier l'unicité, bien que l'impact des retournements de bits soit très discutable. L'estimation la plus pessimiste est de 1 flip par Go / heure, et la RAM ECC supprimerait même cela.
PaulG
2
"la probabilité d'un hachage accidentellement en collision est en fait inférieure à la probabilité d'échec de la comparaison en raison de problèmes dans le processeur générés par les émissions de rayons gamma solaires normales" [la citation nécessaire]
endolith
20

MD5 sera assez bon si vous n'avez pas d'adversaire. Cependant, quelqu'un peut (exprès) créer deux fichiers distincts qui ont la même valeur (c'est ce qu'on appelle une collision), et cela peut ou non être un problème, en fonction de votre situation exacte.

Puisque savoir si des faiblesses connues de MD5 s'appliquent à un contexte donné est une question subtile, il est recommandé de ne pas utiliser MD5. L'utilisation d'une fonction de hachage résistante aux collisions (SHA-256 ou SHA-512) est la réponse sûre. De plus, l'utilisation de MD5 est mauvaise pour les relations publiques (si vous utilisez MD5, soyez prêt à devoir vous justifier, alors que personne ne remettra en question votre utilisation de SHA-256).

Thomas Pornin
la source
2
Cette réponse peut être un peu trompeuse si le lecteur n'est pas trop familiarisé avec le hachage. Il n'y a rien de magique à propos de SHA qui empêche les collisions de hachage, ils sont juste plus résistants aux attaques de collision de hachage . Si vous vouliez être sûr à plus de 99,999 ^ e% que les fichiers sont identiques, vous auriez toujours besoin d'une vérification octet par octet.
PaulG
7
En fait, une comparaison octet à octet peut échouer en raison d'un rayon cosmique basculant un peu (par exemple en transformant a return 0;en a return 1;). C'est hautement improbable, mais le risque de collision avec SHA-256 est encore plus petit que cela. Mathématiquement, vous ne pouvez pas être sûr que deux fichiers hachés à la même valeur sont identiques, mais vous ne pouvez pas non plus en être sûr en comparant les fichiers eux-mêmes, tant que vous utilisez un ordinateur pour la comparaison. Ce que je veux dire, c'est qu'il n'a pas de sens d'aller au-delà de quelque 99,999 ... 9% de certitude, et SHA-256 fournit déjà plus que cela.
Thomas Pornin
2
Quoi, vous n'utilisez pas la mémoire ECC? ;). Bon commentaire, pensées très intéressantes.
PaulG
1
N'oubliez pas le chapeau en aluminium! Plus sérieusement, comment connaissez-vous ces faits sur les collisions et avez-vous vérifié cela d'une manière ou d'une autre?
James P.
@ThomasPornin Les retournements de bits de rayons cosmiques affectent également la méthode MD5, donc c'est encore pire.
endolith
9

Un md5 peut produire des collisions. Théoriquement, bien que très improbable, un million de fichiers d'affilée peuvent produire le même hachage. Ne testez pas votre chance et vérifiez les collisions md5 avant de stocker la valeur.

Personnellement, j'aime créer md5 de chaînes aléatoires, ce qui réduit la surcharge de hachage de gros fichiers. Lorsque des collisions sont trouvées, j'itère et je re-hache avec le compteur de boucle ajouté.

Vous pouvez lire sur le principe du casier .

Afilina
la source
6

Je ne le recommanderais pas. Si l'application fonctionnait sur un système multi-utilisateur, il pourrait y avoir un utilisateur, qui aurait deux fichiers avec le même hachage md5 (il pourrait être ingénieur et jouer avec de tels fichiers, ou être simplement curieux - ils sont facilement téléchargeables à partir de http: / /www2.mat.dtu.dk/people/S.Thomsen/wangmd5/samples.html , j'ai moi-même pendant la rédaction de cette réponse téléchargé deux exemples). Une autre chose est que certaines applications peuvent stocker de tels doublons pour une raison quelconque (je ne suis pas sûr, s'il existe de telles applications mais la possibilité existe).

Si vous identifiez de manière unique les fichiers générés par votre programme, je dirais que vous pouvez utiliser MD5. Sinon, je recommanderais toute autre fonction de hachage où aucune collision n'est encore connue.

tach
la source
2

Personnellement, je pense que les gens utilisent des sommes de contrôle brutes (choisissez votre méthode) d'autres objets pour agir comme des identifiants uniques beaucoup trop quand ils veulent vraiment avoir des identifiants uniques. L'empreinte digitale d'un objet pour cette utilisation n'était pas l'intention et nécessitera probablement plus de réflexion que d'utiliser un uuid ou un mécanisme d'intégrité similaire.

hpavc
la source
0

MD5 a été cassé, vous pouvez utiliser SHA1 à la place (implémenté dans la plupart des langues)

Guillaume Lebourgeois
la source
C'est une réponse parfaitement bonne. MD5 est inacceptable pour les cas d'utilisation en droit et comptabilité en Europe à partir de mai 2018.
Bert Sinnema
@BertSinnema pourriez-vous m'indiquer la source qui définit quelles fonctions de hachage sont acceptables, etc., s'il vous plaît?
berezovskyi
@GregSchmit peut-être parce qu'OP ne se souciait pas de la force cryptographique en soi. J'ai compris la question comme suit: "J'utilise déjà MD5 dans un contexte non lié à la sécurité, dois-je passer du temps à mettre à jour le code?" sorte de chose. Et dans ce contexte, la réponse était probablement erronée et SHA1 a également été rompu depuis.
berezovskyi
0

Lors du hachage de chaînes (ou fichiers) courtes (<quelques K?), On peut créer deux clés de hachage md5, une pour la chaîne réelle et une seconde pour l'inverse de la chaîne concaténée avec une courte chaîne asymétrique. Exemple: md5 (reverse (string || '1010')). L'ajout de la chaîne supplémentaire garantit que même les fichiers composés d'une série de bits identiques génèrent deux clés différentes. Veuillez comprendre que même dans ce schéma, il y a une chance théorique que les deux clés de hachage soient identiques pour des chaînes non identiques, mais la probabilité semble extrêmement faible - quelque chose de l'ordre du carré de la probabilité de collision unique md5, et le gain de temps peut être considérable lorsque le nombre de fichiers augmente. Des schémas plus élaborés pour créer la deuxième chaîne pourraient également être envisagés,

Pour vérifier les collisions, on peut exécuter ce test pour l'unicité des clés de hachage md5 pour tous les bit_vectors dans une base de données:

sélectionner md5 (bit_vector), count (*), bit_and (bit_vector) de db avec bit_vector
group par md5 (bit_vector), bit_vector ayant bit_and (bit_vector) <> bit_vector

Marco Polo
la source
Idée intelligente. Si un "attaquant" crée un faux fichier avec le même hachage md5, cela n'aidera pas à moins qu'il connaisse votre "salage", et inverser le contenu créerait un hachage différent. Utiliser 2 touches md5 comme ça réduirait beaucoup les chances. Si c'est juste pour empêcher une "attaque" en utilisant un sel avant de calculer localement sera suffisant.
Wolf5
0

J'aime penser à MD5 comme un indicateur de probabilité lors du stockage d'une grande quantité de données de fichiers.

Si les hachages sont égaux, je sais que je dois comparer les fichiers octet par octet, mais cela ne peut se produire que quelques fois pour une fausse raison, sinon (les hachages ne sont pas égaux) je peux être certain que nous parlons de deux fichiers différents .

Shimmy Weitzhandler
la source