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

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?

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.

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.

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).

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 .

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.

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.

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

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

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 .