Comment les fichiers à zéro octet peuvent-ils générer une valeur de hachage?


20

Comment un fichier texte de zéro octet peut-il générer un hachage lorsqu'il est haché avec sha1sum, sha256sum, etc.? Quelles données les programmes hachent-ils pour générer une valeur de hachage?

Ta

QuickHash sous Linux

Commandes de terminal

Réponses:


21

Les algorithmes de hachage lisent l'entrée et la traitent, qu'il y ait ou non des données. Il s'agit d'un comportement valide et souhaité et est même utilisé pour vérifier si une certaine implémentation est correcte. Cela conduit à des "hachages nuls" pour tous les algorithmes majeurs.

Pour résumer: da39a3ee5e6b4b0d3255bfef95601890afd80709 est le hachage sha1 pour un fichier vide partout, la même chose est vraie avec les hachages nuls d'autres alrogrithmes.


1
Bien, tu apprends quelque chose de nouveau tous les jours! Je ne savais pas qu'il y avait une "valeur nulle" pour chaque algorithme. Merci beaucoup.
Gizmo_the_Great

3
Les algorithmes de hachage ont une condition initiale prédéterminée - un peu comme un nombre avec lequel ils commencent et mutent lorsqu'ils lisent des données. S'il n'y a pas de données à lire, le hachage est simplement le résultat de cette condition initiale prédéfinie.
Kevin

La raison est également due au fait que l'algorithme sha1 ajoute la longueur des données (dans ce cas: zéro) et qu'il y a également des indicateurs et un remplissage ajoutés dans le message. Ainsi, même «aucune donnée» entraînera toujours le traitement de certaines données.
user92979

14

Tous les algorithmes de hachage dans Quick Hash sont des constructions de Merkle – Damgård . En tant que tels, ils remplissent le message avec un multiple de la taille du bloc.

Les algorithmes de Quick Hash y parviennent en ajoutant un 1bit, autant de 0bits que nécessaire, et enfin la longueur du message.

Cela permet de hacher des messages de longueur arbitraire, y compris des messages de longueur nulle.


Si ma raison de modification prête à confusion, j'ai d'abord mal lu votre réponse et l'ai reformulée "pour plus de clarté", puis j'ai réalisé que ma modification était incorrecte et je suis retournée la corriger. Le système a consolidé les deux explications car il était dans la même fenêtre de temps.
fixer1234

1

(Complément à la réponse de Dennis et fixer1234?)

En résumé:

$ shasum -a 256 /dev/null e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /dev/null

Tous les fichiers de 0 octet auront la même somme de contrôle.

$ shasum -a 512 /dev/null cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e /dev/null

$ shasum /dev/null da39a3ee5e6b4b0d3255bfef95601890afd80709 /dev/null

$ md5 /dev/null MD5 (/dev/null) = d41d8cd98f00b204e9800998ecf8427e (Remarque: MD5 est cassé; ce n'est pas un «hachage sécurisé». Ceci est documenté dans l'entrée MD5 de Wikipedia.)

Ainsi, par exemple, si vous essayez de vérifier l'innocuité des fichiers sur virustotal.com avec l'une des valeurs de hachage sécurisées répertoriées ici, par exemple, da39a3ee5e6b4b0d3255bfef95601890afd80709vous pouvez être sûr que le fichier était bien 0 octet (ou était un dossier, ce qui virustotal, confusément, hache comme s'il s'agissait d'un fichier de 0 octet.)


Comment cela ajoute-t-il aux réponses actuelles?
Máté Juhász

En fournissant un moyen direct pour un sceptique de vérifier qu'il est vrai que tous les fichiers de 0 octet auront la même somme de contrôle Plusieurs personnes étaient sceptiques à ce sujet lors de l'examen de l'innocuité des fichiers de 0 octet sur virustotal.com. Je pense donc que cela ajoute à la solution un moyen pour quelqu'un qui arrive à cette question, pas sûr que ce soit vrai que si la somme de contrôle est cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f4329a8131a9
Matthew Elvey
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.