Quel algorithme de hachage dois-je utiliser pour une somme de contrôle de fichier sûre?
Pour mon travail, je devrai fournir à mon client un fichier spécifique qui sera le résultat du travail que j'ai fait pour lui.
Afin de protéger l'intégrité du travail que j'ai effectué et de garantir qu'il n'a jamais été modifié, j'ai l'intention d'ajouter une somme de contrôle à ma documentation qui sera fournie avec le fichier.
Étant donné que MD5 et SHA-1 ne sont plus sécurisés depuis longtemps, je me demandais si nous les utilisions toujours à cette fin ou s'il existe un meilleur algorithme qui pourrait faire le même travail mais plus sûr.
Je recherche la meilleure solution fiable. Je suis conscient qu'une preuve à 100% ne sera jamais possible, mais je me demandais si MD5 était toujours classé "bon" à cet effet ou s'il existe des outils vraiment nouveaux et plus sûrs.
Choix de l'algorithme de hachage
Utilisez SHA-256 ou SHA-512: l'un des deux membres "principaux" de la famille SHA-2 . SHA-2 est le successeur de SHA-1 et est considéré comme sécurisé. C'est le hachage à choisir, sauf si vous avez une bonne raison de choisir le contraire. Dans votre cas, le choix entre SHA-256 et SHA-512 est indifférent. Il existe un SHA-3, mais il n'est pas encore très largement pris en charge et il n'est pas plus sécurisé (ou moins sécurisé) que SHA-2, c'est juste une conception différente.
N'utilisez pas MD5 ou SHA-1. Ils ne sont évidemment pas inappropriés dans votre scénario, mais ils pourraient être exploités avec un peu de travail supplémentaire. De plus, le fait que ces algorithmes soient déjà partiellement cassés les rend plus à risque de se casser davantage au fil du temps.
Plus précisément, pour ces deux hachages, il est possible de trouver des collisions: il est possible de trouver deux documents D1 et D2 tels que MD5 (D1) = MD5 (D2) (ou SHA-1 (D1) = SHA-1 ( D2)), et tels que D1 et D2 se terminent chacun par un petit bit qui doit être calculé et éventuellement un suffixe commun choisi. Le bit qui doit être calculé ressemblera à des ordures, mais il peut être caché dans un commentaire, dans une image décalée hors page, etc. Produire de telles collisions est trivial sur un PC pour MD5 et est faisable mais cher pour SHA- 1 (sauf si vous le souhaitez pour deux PDF, auquel cas les chercheurs ont déjà dépensé l'argent pour le calcul pour en trouver un et l'ont publié ).
Dans votre scénario, vous ne vous souciez généralement pas des collisions, car vous produirez D1. Vous n'allez pas fabriquer ce morceau au milieu. Cependant, il y a un risque que quelqu'un vous incite à injecter ce bit, par exemple en fournissant une image à inclure dans le document. Il serait assez difficile de réaliser une collision de cette façon, mais c'est faisable en principe.
Étant donné que l'utilisation de MD5 présente un risque et aucun avantage par rapport à l'utilisation de SHA-256, utilisez SHA-256.
Que faire avec un hachage
Avec un hachage cryptographique non rompu comme SHA-256, ce que vous savez, c'est que si deux fichiers ont le même hachage, ils sont identiques. Inversement, cela signifie que si deux fichiers ont des hachages différents, ils sont différents. Cela signifie que si vous conservez une copie de confiance du hachage (par exemple, vous l'imprimez et la stockez ou la notarisez), vous pourrez dire plus tard "oui, ce fichier que vous me montrez est le même fichier" ou " non, ce fichier que vous me montrez est différent ".
Connaître le hachage du fichier ne prouve pas que vous l'avez écrit. Il n'y a aucun moyen cryptographique de prouver la paternité. Le mieux que vous puissiez faire est de prouver que vous aviez le fichier plus tôt que quiconque peut le prouver. Vous pouvez le faire sans révéler le fichier en communiquant le hachage à un tiers auquel tout le monde fait confiance pour se souvenir correctement de la date à laquelle vous lui avez montré le hachage; ce tiers peut être un notaire public ou la Wayback Machine si vous mettez le hachage sur une page Web qu'il indexe. (Si vous publiez le hachage, alors en théorie, quelqu'un pourrait comprendre le fichier, mais il n'y a pas de meilleure façon de le faire que d'essayer tous les fichiers plausibles jusqu'à ce qu'ils trouvent le bon. Si cela vous inquiète, utilisez une signature du fichier au lieu d'un hachage, et notarisez la signature et la clé publique mais gardez la clé privée pour vous.)
Exemple de chose pour laquelle un hachage est bon: votre client veut du support, mais vous êtes seulement prêt à prendre en charge votre produit d'origine et non un produit modifié. Vous leur demandez donc de calculer le hachage de ce qu'ils veulent que vous preniez en charge. Si la valeur de hachage n'est pas celle que vous avez fournie, vous refusez de fournir une assistance. Notez que vous devez faire confiance au client pour calculer le hachage du produit, et non pas calculer le hachage d'une copie de l'original ou le lire sur le bon de livraison.
Exemple de quelque chose pour lequel un hachage n'est pas bon: quelqu'un d'autre prétend qu'il est l'auteur du document. Vous dites "non, regardez, je connais son hachage, c'est 1234…". Cela n'aide pas: n'importe qui peut calculer le hachage.
Exemple de quelque chose qu'un hachage est bon s'il est utilisé correctement: quelqu'un d'autre prétend qu'il vient d'écrire le document. Vous dites "non, regardez, j'ai notarié le hash 6 l'année dernière, donc vous ne pouvez pas l'avoir écrit la semaine dernière".
Exemple de quelque chose pour lequel un hachage n'est pas bon: quelqu'un fait une légère modification du document. Il aura alors un hachage différent. Tout ce que vous pouvez dire, c'est que le document est maintenant différent, mais cela ne donne aucune information sur leur différence. Le hachage d'un document complètement différent est tout aussi différent que le hachage d'une version avec une correction de faute de frappe ou une version codée différemment.
Pour garantir que le produit de travail est inchangé, même MD5 est raisonnable.
La capacité d'un attaquant à concevoir une collision est dangereuse lorsqu'il peut, par exemple, générer un exécutable. Cet exécutable peut prendre 500 Kb pour faire quelque chose de mal et dépenser 50 000 Kb rotation des bits inutilisés juste pour obtenir la collision. C'est correct si ces bits sont inutilisé; vous voyez simplement un exécutable avec le bon hachage, et vous êtes dupe.
Il n'est pas possible de concevoir une collision qui correspond à la fois au hachage MD5 et représente une documentation incorrecte. Vous êtes plus susceptible de vous retrouver avec une documentation qui se lit " Prenez le plug et insérez-le dans le $ # WG% ga 940 [2aj2'rj09 [3j59g; qa1j; socke t "- quiconque regarde cela se rendra compte que la documentation a été falsifiée. Même un ensemble progressif de singes shakespeariens ne peut pas faire tourner une collision MD5 qui ressemble toujours à de la documentation.
En y regardant de plus près, je vois que ce n'est pas la documentation que vous protégez; vous incluriez le hachage du "fichier spécifique qui sera le résultat du travail que je fais pour eux". Encore une fois, ne sachant pas que ce fichier est - exécutable? code source? - il est irréalisable sur le plan informatique qu'ils puissent le modifier de manière à affirmer de manière crédible que c'est ce que vous leur avez donné, et à créer une collision de hachage en même temps.
Voir aussi cette réponse sur Crypto.SE qui résume:
MD5 est actuellement considéré comme trop faible pour fonctionner comme un hachage cryptographique. Cependant, pour toutes les utilisations de hachage traditionnelles (c'est-à-dire non cryptographiques), MD5 est souvent parfaitement bien.
Vous ne regardez pas l'utilisation cryptographique d'un hachage, donc MD5 vous convient. Cela empêchera le remplacement des remplacements modifiés ou falsifiés du produit de travail que vous leur avez fourni.