MD5 est-il encore suffisant pour identifier les fichiers de manière unique?
Le hachage MD5 d’un fichier est-il toujours considéré comme une méthode suffisante pour l’identifier de manière unique en raison de la rupture de l’algorithme MD5 et des problèmes 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. Le MD5 a été complètement brisé du point de vue de la sécurité, mais la probabilité d’une collision accidentelle est toujours aussi faible. Assurez-vous simplement que les fichiers ne sont pas créés par une personne en qui vous ne faites 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 existe toujours une probabilité de collision, due au principe principe de Pigeonhole . Avoir des hachages différents signifie certes 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 à cet effet - que la sécurité soit un problème ou non - ne devrait donc toujours être que la première étape d'un contrôle, surtout si l'algorithme de hachage est connu pour créer facilement des collisions. Pour déterminer de manière fiable si deux fichiers avec le même hachage sont différents, comparez ces fichiers octet par octet.
MD5 sera suffisant si vous n'avez pas d'adversaire. Cependant, quelqu'un peut créer (à dessein) deux fichiers distincts qui ont la même valeur (c'est ce que l'on appelle une collision), ce qui peut poser problème ou non, selon votre situation exacte.
Sachant que les faiblesses connues du MD5 s’appliquent à un contexte donné est une affaire 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) constitue la réponse sûre. De plus, utiliser MD5 est une mauvaise relation publique (si vous utilisez MD5, préparez-vous à devoir vous justifier; personne ne vous posera la question si vous utilisez SHA-256).
Un md5 peut provoquer des collisions. Théoriquement, bien que hautement improbable, un million de fichiers consécutifs peuvent produire le même hash. Ne tentez pas votre chance et vérifiez les collisions md5 avant de stocker la valeur.
Personnellement, j’aime bien créer md5 de chaînes aléatoires, ce qui réduit le temps système dû au hachage de gros fichiers. Lorsque des collisions sont trouvées, j'itère et 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 simplement être curieux - ils sont facilement téléchargeables depuis http://www2.mat.dtu.dk/people/S.Thomsen/wangmd5/samples.html , lors de l'écriture de cette réponse, j'ai 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 uniquement les fichiers générés par votre programme, je dirais que l’utilisation de MD5 est acceptable. Sinon, je recommanderais toute autre fonction de hachage pour laquelle 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 en tant qu’identificateurs uniques bien trop quand ils le souhaitent réellement, c’est qu’ils aient des identificateurs uniques. Empreinte digitale d'un objet pour cet usage n'était pas l'intention et nécessitera probablement plus de réflexion que l'utilisation d'un mécanisme d'intégrité uuid ou similaire.
MD5 a été cassé, vous pouvez utiliser SHA1 à la place (implémenté dans la plupart des langues)
J'aime penser à MD5 en tant qu'indicateur de probabilité lorsque vous stockez une grande quantité de données de fichier.
Si les hachages sont égaux, je sais alors que je dois comparer les fichiers octet par octet, mais cela peut ne se produire que quelques fois pour une raison fausse, sinon (les hachages ne sont pas égaux), je peux être certain que nous parlons de deux fichiers différents. .
Lors du hachage de chaînes courtes (ou de quelques K?), Il est possible de créer deux clés de hachage md5, une pour la chaîne réelle et une autre pour l’inverse de la chaîne concaténée avec une chaîne asymétrique courte. Exemple: md5 (reverse (string || '1010')). L'ajout de la chaîne supplémentaire garantit que même les fichiers constitués d'une série de bits identiques génèrent deux clés différentes. S'il vous plaît, comprenez 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 que la probabilité semble extrêmement petite - quelque chose dans l'ordre du carré de la probabilité de collision 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, mais je ne suis pas sûr que cela améliorerait considérablement les chances.
Pour vérifier les collisions, vous pouvez exécuter ce test pour vérifier le caractère unique des clés de hachage md5 pour tous les bit_vectors d'une base de données:
sélectionnez md5 (bit_vector), count (*), bit_and (bit_vector) à partir de la base de données avec bit_vector
groupe par md5 (bit_vector), bit_vector ayant bit_and (bit_vector) <> bit_vector