J'ai commandé des blocs de données, chacun haché individuellement avec sha256. Je veux combiner ces hachages en un seul hachage sha256. Dois-je simplement nourrir les hachages dans sha256 en tant que données, ou y a-t-il un autre moyen qui est meilleur d'un point de vue mathématique / crypto? Cela peut sembler une question triviale, mais les intuitions sont souvent fausses en matière de cryptographie.
edit : Le but de ceci est de former une sorte de blockchain bien que ce terme soit assez surchargé de nos jours. C'est à des fins d'intégrité, pas de preuve de travail. L'idée est de hacher les blocs au niveau des nœuds suiveurs, de combiner les hachages en un sur le chef de cluster pour avoir un hachage représentant la chaîne dans son ensemble, puis de l'ajouter aux nouveaux blocs à hacher.
C'est un peu étrange dans la mesure où il s'agit d'un système distribué, donc le "hachage de la chaîne entière" est généralement un peu périmé, donc je sais ce que le hachage représentant la chaîne, comme le sait ce nœud, lorsque le bloc a été créé à ce nœud, il peut y avoir plusieurs blocs qui «s'accrochent à la chaîne» à ce hachage particulier, puis ceux-ci sont ordonnés et combinés dans le hachage système qui est ajouté au début aux nouveaux blocs.
J'utilise Go, si cela compte.
3 Réponses :
Essayez de prendre vos hachages SHA256 que vous avez déjà et mettez-les dans une chaîne. Ensuite, hachez cette chaîne en utilisant SHA256 ou l'algorithme de votre choix. Vous pouvez également enchaîner vos mandrins de données d'origine, puis les hacher. Mais je pense que c'est plus rapide et plus propre de simplement "hacher les hachages".
Si vous essayez de recréer le hachage d'une charge utile volumineuse (par exemple, un fichier de 1 Go) qui a été divisé en morceaux (par exemple 10 Mo de taille), le hachage (MD5, SHA-256 etc.) doit être calculé sur le toute la collection. Donc, en utilisant cet exemple, vous ne pouvez pas ajouter les 100 hachages fragmentés pour recréer le hachage du fichier d'origine. Cependant ...
Vous pouvez envoyer 2 valeurs avec chaque bloc:
Au fur et à mesure que les morceaux sont diffusés, on peut vérifier que les coutures de l'état de hachage à la fin du morceau N correspondent à celles de l'état de hachage au début du morceau N + 1 .
L'état de hachage final du bloc final sera le hachage de l'ensemble de la charge utile.
Pourquoi faire comme ça? Parce que le hachage peut être calculé en temps réel au fur et à mesure que les morceaux de fichier sont reçus - plutôt comme un processus long et séparé - après que tous les morceaux de fichier ont été reçus.
Edit: strong> basé sur les commentaires:
Voici une solution d'état de hachage d'état brut:
Créez un gros fichier aléatoire (100 Mo):
$ ./hash -o 102760448 -s "736861032a24f8927fc4aa17527e1919aba8ea40c0407d5452c752a82a99c06149fd8d35000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006200000" offset: 103809024 hash: fbbfd2794cd944b276a04a89b49a5e2c8006ced9ff710cc044bed949fee5899f state: 73686103bdde167db6a5b09ebc69a5abce51176e635add81e190aa64edceb280f82d6c08000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006300000 offset: 104857600 hash: 4cc76e41bbd82a05f97fc03c7eb3d1f5d98f4e7e24248d7944f8caaf8dc55c5c state: 73686103c29dbc4aaaa7aa1ce65b9dfccbf0e3a18a89c95fd50c1e02ac1c73271cfdc3e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006400000
Utilisation d'un outil externe pour vérifier le hachage:
... ... ... offset: 102760448 hash: 8ae7928735716a60ae0c4e923b8f0db8f33a5b89f6b697093ea97f003c85bb56 state: 736861032a24f8927fc4aa17527e1919aba8ea40c0407d5452c752a82a99c06149fd8d35000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006200000 offset: 103809024 hash: fbbfd2794cd944b276a04a89b49a5e2c8006ced9ff710cc044bed949fee5899f state: 73686103bdde167db6a5b09ebc69a5abce51176e635add81e190aa64edceb280f82d6c08000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006300000 offset: 104857600 hash: 4cc76e41bbd82a05f97fc03c7eb3d1f5d98f4e7e24248d7944f8caaf8dc55c5c state: 73686103c29dbc4aaaa7aa1ce65b9dfccbf0e3a18a89c95fd50c1e02ac1c73271cfdc3e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006400000
Exécuter ceci code du terrain de jeu sur le fichier ci-dessus.
$ shasum -a 256 large.bin 4cc76e41bbd82a05f97fc03c7eb3d1f5d98f4e7e24248d7944f8caaf8dc55c5c large.bin
le hachage final correspond.
Essai avec un décalage et un état de hachage intermédiaire . Le fichier sera recherché vers ce décalage, reprenant le calcul de hachage à partir de ce point:
dd if=/dev/urandom of=large.bin bs=1048576 count=100
nous obtenons le même hachage final que précédemment. p>
Remarque: cela expose l'état interne du hachage, alors soyez conscient des implications pour la sécurité cela peut entraîner. Avec une grande taille de morceau, cela ne devrait pas être un problème.
Gardez à l'esprit que de nombreuses bibliothèques de hachage ne prennent pas en charge la capture ou la restauration d'un état intermédiaire, vous devrez donc probablement modifier un morceau de code existant ou implémenter l'algorithme de hachage à la main. (Excellente réponse, les lecteurs peuvent simplement supposer que c'est facile.)
Je pense que c'est peut-être ce que je recherche. Savez-vous quelle est la taille de l'état de hachage pour sha256?
32 octets (pour SHA-256, cela se trouve être de la même taille que le hachage final, mais ce n'est pas universel)
Je vais mettre à jour la réponse avec comment reprendre la sommation de hachage, après le déjeuner ...
On dirait que cela peut être fait dans Go car il implémente encoding.BinaryMarshaler et encoding.BinaryUnmarshaler pour marshaler et démarshal l'état interne du hachage: golang.org/src/crypto/sha256/sha256.go#L161
@Eloff oui ... mais il y a un hic. Malheureusement, la structure digest n'est pas publique ( d minuscule). Et sha256.New () renvoie l ' interface hash.Hash - et pas le digest valeur directement. Il faudrait donc copier la source du condensé dans son propre projet pour pouvoir invoquer les marshalers binaires. Faisable, mais plus impliqué que je ne l'avais prévu.
En fait, cela semble plus facile que cela, j'ai jeté un second coup d'œil, ce que vous auriez à faire est de convertir l'interface hash.Hash retournée en encoding.BinaryMarshaler et encoding.BinaryUnmarshaler , ceci est autorisé pour les hachages stdlib selon: golang.org/pkg/hash/#Hash
@Eloff intéressant! J'ai mis à jour la réponse avec un exemple de travail incluant cette découverte.
cette construction semble inutilement faible (à partir d'un crypto PoV), je recommanderais d'utiliser quelque chose comme un arbre de merkle. exposer un état interne comme celui-ci "cassera" divers schémas de hachage. la fonction de finalisation / sortie de SHA2 concatène simplement les variables d'état internes donc est probablement sûre, mais cela briserait SHA3. Je recommanderais également de regarder les HMAC et leurs attaques si vous vous souciez de l'intégrité / l'authenticité
edit: Le but de ceci est de former une sorte de blockchain bien que ce terme est assez surchargé ces jours-ci. C'est pour l'intégrité fins, pas une preuve de travail. L'idée est de hacher les blocs au nœuds suiveurs, combinez les hachages en un sur le leader du cluster pour avoir un hachage représentant la chaîne dans son ensemble, puis ajoutez-le aux nouveaux blocs à hacher.
cela ressemble à un arbre de merkle
https://brilliant.org/wiki/merkle-tree/
Un arbre Merkle est une structure de données basée sur le hachage qui est une généralisation de la liste de hachage. C'est une structure arborescente dans laquelle chaque nœud feuille est un hachage d'un bloc de données, et chaque nœud non-feuille est un hachage de son enfants. En règle générale, les arbres Merkle ont un facteur de ramification de 2, ce qui signifie que chaque nœud a jusqu'à 2 enfants.
Les arbres Merkle sont utilisés dans les systèmes distribués pour des données efficaces vérification. Ils sont efficaces car ils utilisent des hachages au lieu de fichiers complets. Les hachages sont des moyens d'encoder des fichiers beaucoup plus petits que le fichier lui-même. Actuellement, leurs principales utilisations sont des réseaux peer-to-peer tels que Tor, Bitcoin et Git.
Jetez un œil à cette implémentation https://github.com/cbergoon/merkletree
la question est: faire quoi?
En d'autres termes: voulez-vous combiner les hachages simplement parce que vous voulez les combiner ou y a-t-il un cas d'utilisation spécifique où vous avez besoin de cette combinaison. Ce que vous devez faire dépend de votre cas d'utilisation spécifique (et inconnu). Et surtout si vous demandez comment le gérer de manière cryptographique, les détails sur le cas d'utilisation sont essentiels.