您可能有兴趣阅读ssdeep，这是一种“上下文触发的分段散列”（CTPH），用作与内容无关的模糊散列形式。Ssdeep 构建文件片段的哈希值，以便确定相似性；假设一个字符在两个相同的文件之间发生变化。更改的文件部分的校验和会有所不同，但所有其他部分的校验和不会，因此文件被认为是高度相似的。

您实际上是在尝试这样做，但不打算使用它来测量文件相似性。

我的印象是，只要您保留整个哈希（不要截断它们）并且您哈希的段足够大以使冲突很少发生（可能是 512 字节？），那么您将拥有足够的数据完整性水平。从理论上讲，由于哈希长度更长，因此您可能具有更高的完整性，但是在实现中必须特别注意很多方面，我根本不推荐这样做。

也就是说，您指定了三个sha256 哈希值，其中一个用于整个文件。只要您匹配所有三个，这应该是最弱的，与单独的 sha256 一样好。它可能更强大，但是当涉及到理论上的 SHA-2 漏洞时，您（可能）会像单个 sha256 一样容易受到攻击，因此您不妨选择另一种算法，例如SHA-3甚至（因为您仍然拥有完整文件的 sha256）更快的东西，比如 MD5。您还可以考虑存储字节大小。

除非您担心遥远的未来，否则 256 位 SHA-2 应该足以应付任何事情。如果是这种情况，你不能认为任何事情都是理所当然的，但我会选择 SHA2-512和SHA3​​-512以及确切的文件大小。

如果您只是想要更快的速度并且不担心受到攻击（即您只是担心故障硬件和/或糟糕网络的数据完整性），您可以从文件大小开始，然后同时计算 MD5 和 SHA1（两个单独的进程，一个文件读取）。除非您想使用 ssdeep （默认情况下似乎使用 MD5 作为其片段），否则我仍然不会混淆文件。

也许速度和完整性的一个有吸引力的平衡可能是检查文件大小，然后是前 5MB 的 MD5（或整个文件，如果低于 5MB），然后是真正的完整性检查，例如 sha256 或 sha3-512。它应该*更难创建碰撞并且更快地检测故障（在第一次故障时停止），而仅比最后一次检查慢得可以忽略不计（我花了 0.003 秒来计算随机 5MB 测试文件的 MD5 哈希）。 _{^{（* 我既不是密码分析专家，也不是密码校验和专家：这不是权威的。）}}

我想说的是，如果不怀疑攻击，那么文件大小和 MD5 都可以（您可能只使用 MD5 就可以了，尽管文件大小可以让您更快地失败并提供更好的数据的完整性）。

也许但还不足以打扰。SHA256 非常安全。目前没有已知的冲突（或 SHA1 的冲突）。您应该认为 SHA256 实际上是完美的。如果您有幸因碰撞而受到攻击，请将其发布并成名（至少在那些关心这些事情的人中）。

您的逻辑基于这样的假设，即如果确实发生了冲突，那么根据散列函数的本质，它不应该再次发生。但我觉得这个逻辑是错误的。您必须考虑碰撞是如何发生的。如果能够为整个文件生成冲突，那么他们应该能够为部分和整个文件执行此操作。您的想法可行的唯一方法是攻击者不知道您划分文件的方式。但由于这不是事情的工作方式（因为应该知道 3 个哈希值），所以这应该无法提高您的安全性。然后如您所知，sha256 仍然足够安全，并且会持续足够长的时间，所以如果您拥有它，那么您最不必担心碰撞。