如何结合 sha 哈希？

Question

我已经订购了大块数据，每个数据块都用 sha256 单独散列。我想将这些散列组合成一个 sha256 散列。我应该将散列作为数据输入 sha256，还是从数学/加密的角度来看有另一种更好的方法？这似乎是一个微不足道的问题，但在涉及加密时，直觉往往是错误的。

编辑：这样做的目的是形成一种区块链，尽管这个术语现在已经超载了。这是出于完整性目的，而不是工作证明。这个想法是在跟随者节点对块进行散列，在集群领导者上将散列组合成一个散列，以具有代表整个链的散列，然后将其添加到要散列的新块之前。

有点奇怪，因为它是一个分布式系统，所以“整个链散列”通常有点陈旧，所以我知道代表链的散列是什么，正如该节点所知，当在该节点创建块时，但可能有几个区块在那​​个特定的哈希上“挂在链上”，然后这些区块被排序并组合到系统哈希中，最终被添加到新的区块中。

如果这很重要，我正在使用 Go。

Answer 1

如果您尝试重新创建已拆分为多个块（例如 10MB 大小）的大型负载（例如 1GB 文件）的哈希，则需要在整个集合上计算哈希（MD5、SHA-256 等）。因此，使用此示例，您无法添加100 个分块散列来重新创建原始文件的散列。然而...

您可以为每个块发送 2 个值：

• 单个块的哈希（就像你现在正在做的那样）
• 中间哈希状态，当您的服务扫描文件以创建每个块有效负载时：在块的开头和结尾

随着块的流入，可以验证块末尾的哈希状态的接缝是否与块N开头的哈希状态的接缝相匹配N+1。

最终块的最终散列状态将是整个有效负载的散列。

为什么会这样？因为可以在接收文件块时实时计算散列——而不是作为一个单独的耗时过程——在接收到所有文件块之后。

编辑：基于评论：

这是一个粗略的状态哈希状态解决方案：

创建一个大的随机文件（100MB）：

dd if=/dev/urandom of=large.bin bs=1048576 count=100

使用外部工具验证哈希：

$ shasum -a 256 large.bin 
4cc76e41bbd82a05f97fc03c7eb3d1f5d98f4e7e24248d7944f8caaf8dc55c5c  large.bin

在上述文件上运行此Playground 代码。

...
...
...
offset: 102760448   hash: 8ae7928735716a60ae0c4e923b8f0db8f33a5b89f6b697093ea97f003c85bb56  state: 736861032a24f8927fc4aa17527e1919aba8ea40c0407d5452c752a82a99c06149fd8d35000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006200000
offset: 103809024   hash: fbbfd2794cd944b276a04a89b49a5e2c8006ced9ff710cc044bed949fee5899f  state: 73686103bdde167db6a5b09ebc69a5abce51176e635add81e190aa64edceb280f82d6c08000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006300000
offset: 104857600   hash: 4cc76e41bbd82a05f97fc03c7eb3d1f5d98f4e7e24248d7944f8caaf8dc55c5c  state: 73686103c29dbc4aaaa7aa1ce65b9dfccbf0e3a18a89c95fd50c1e02ac1c73271cfdc3e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006400000

最后的哈希匹配。

尝试使用偏移量和中间哈希状态。该文件将在seeked此偏移量处，从该点恢复哈希计算：

$ ./hash -o 102760448 -s "736861032a24f8927fc4aa17527e1919aba8ea40c0407d5452c752a82a99c06149fd8d35000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006200000"
offset:  103809024  hash: fbbfd2794cd944b276a04a89b49a5e2c8006ced9ff710cc044bed949fee5899f  state: 73686103bdde167db6a5b09ebc69a5abce51176e635add81e190aa64edceb280f82d6c08000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006300000
offset:  104857600  hash: 4cc76e41bbd82a05f97fc03c7eb3d1f5d98f4e7e24248d7944f8caaf8dc55c5c  state: 73686103c29dbc4aaaa7aa1ce65b9dfccbf0e3a18a89c95fd50c1e02ac1c73271cfdc3e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006400000

我们得到与以前相同的最终哈希值。

注意：这确实会暴露哈希内部状态，因此请注意这可能带来的安全隐患。对于大块大小，这应该不是问题。