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 碰撞。伽马射线可以翻转“这两个文件不匹配！”的位。这种翻转发生得非常少，但比你想象的要频繁。在嘈杂的量子宇宙中，我们应该避免谈论绝对。