SHA256用于计算散列的文件的哪些部分

Question

我正在通过网络传输文件。传输过程中数据丢失容忍度为零。我被要求计算原始文件和复制文件的SHA256值，以验证内容是否相同。到目前为止，我已经基于复制和粘贴文件进行了比较，并让Windows使用附加到文件名的-copy重命名文件。我也尝试在重命名之后重命名文件，以及删除文件扩展名。到目前为止，它们都产生相同的哈希值。我还编写了更改文件属性的代码（刚刚更改了lastWrittenTime和fileCreationTime），这似乎对哈希没有影响。

Checksum result of copying and pasting a file(explorer appends "-copy to name):

E7273D248F191A0F914837A21BE39D229D790CA242D38651BAA06DAC9EBB63F7
E7273D248F191A0F914837A21BE39D229D790CA242D38651BAA06DAC9EBB63F7

Checksum result of renaming the -copy in explorer:

E7273D248F191A0F914837A21BE39D229D790CA242D38651BAA06DAC9EBB63F7
E7273D248F191A0F914837A21BE39D229D790CA242D38651BAA06DAC9EBB63F7

Checksum result of changing file extension:

E7273D248F191A0F914837A21BE39D229D790CA242D38651BAA06DAC9EBB63F7
E7273D248F191A0F914837A21BE39D229D790CA242D38651BAA06DAC9EBB63F7

创建哈希时，文件的哪个部分使用？

好的，零容忍度有点多，如果散列不匹配，则必须重新发送文件。

Answer 1

整个二进制文件内容通过散列算法进行流式传输。文件元数据（例如姓名，日期等）不起作用。

Answer 2

首先，一般建议：不要这样做。使用rsync或类似的东西来进行批量文件传输。 Rsync背后有多年的优化和调试，有无数的选项来控制复制的方式（以及是否），并且在Windows上可用。不要浪费时间建造已经建成的东西。

但如果你必须......

哈希算法通常关心字节，而不是文件。将SHA256应用于文件时，您只需读取字节并将其传递给算法。

如果要散列路径，权限等，则应在目录级别执行此操作，因为这些构成了目录的“内容”。目录没有标准的字节级表示，因此您可以自己制作一个。看起来像排序顺序的目录列表的东西通常就足够了。并确保每个条目包含相应事物的哈希值，无论是文件还是其他目录。这样，目录的散列不仅唯一地指定每个子节点的名称和属性，而且递归地指定子目录的整个内容。

注意：一旦系统意识到目标中已存在具有相同散列的文件，相同文件具有相同散列的事实实际上对您有利，通过避免传输第二个文件。当然，您必须明确地为此编码。但是请注意，这样做可以在文件被移动或复制时允许超级便宜的同步，因为它们将具有与以前相同的散列。只有受影响的目录（从直接父节点到根节点）将具有不同的散列值。

最后，一个小小的狡辩：没有零容忍这样的事情。忘记SHA256碰撞是否会在宇宙的生命周期中发生。伽马射线可以翻转说“这两个文件不匹配！”这种错误很少发生，但比你想象的更频繁。在嘈杂的量子宇宙中，我们应该避免以绝对的方式说话。