Hash 计算文件散列的最快方法？

很多文件将存储在数据库中，我需要文件哈希来唯一标识文件没有更改。

---

（通常，将用作Windows个人防火墙部件）

当然，这在一般情况下是不可能的。许多人仍在为此目的使用哈希算法，这是一种流行的算法，它为文件提供128位的“签名”，当文件内容发生变化时，很有可能发生变化

在一般情况下，您需要查看文件的每一位以将其包含在哈希中，并且性能可能会受到I/O限制。它是对文件中所有数据的顺序扫描，更新每个新字节使用的任何哈希算法的状态。在现代CPU上，后者将比前者更快。在奔腾90 MHz CPU上显示约45 MB/s。

如果我正确理解“用作Windows个人防火墙”部分，MD5不是一个好的算法选择

MD5算法上存在一个成功的攻击，它允许您找到一个不同的消息，该消息以相对较少的工作量（与暴力相比）生成相同的哈希。这种攻击过去没有实际意义，例如，当MD5被用来散列密码等。与此同时，新的攻击已经被发现，因此MD5和SHA-1都可以以可怕的速度被散列/碰撞，用这些“老”散列破解整个数据库中的“适当加密”和单散列用户密码不仅完全可行，而且已经被证明。
然而，在“确保此文件未被篡改”的特定应用程序中，这种攻击一直是一个问题，而不仅仅是最近。MD5将非常安全地检测到一个位错误或意外修改，但试图绕过您的个人文件墙的恶意软件可能会发现受感染二进制文件的冲突，从而使哈希与原始文件匹配，从而绕过您的整个安全性

在这种情况下，您应该使用SHA-256[更新：同时，SHA-3已经出局，虽然我个人不同意NIST对获胜者的选择（或排除一些非常好的第二轮候选人的模糊标准），但使用SHA-3（Keccak）是一个更安全的选择或者选择SHA-3决赛选手之一。所有决赛选手都由经验丰富的团队精心设计，经过非常彻底的分析，到目前为止，还没有一支球队有一个现实的攻击或一个可以想象会导致现实攻击的已知问题，而且他们都有“更多比特”（这本身并不意味着什么，但更多的比特不会带来伤害）

此外，请记住，除了保存散列外，还要始终保存文件的长度，这样即使是较差的散列，也会以可忽略的代价大大硬化。如果可以，请计算两个不同的散列。对于攻击者来说，在一个散列上查找产生冲突的消息要比查找产生冲突且具有完全相同大小的消息容易得多ame长度，甚至是在两个不同哈希上冲突且长度相同的消息。
由于带宽（磁盘和内存）是计算散列的一个不可忽略的因素，因此计算单个散列或两个散列甚至可能同时以相当的速度运行。
我在计算CRC并随后用分组密码加密相同的块时观察到了这种效果。是否计算CRC在整个运行时的差异小于1%，因此基本上是一种免费操作

如果您认为有充分的理由不使用众所周知的标准散列（性能限制？），您可以构建自己的安全散列，您可以将任何安全块密码转换为安全哈希函数。例如，使用固定密钥使用AES加密每个输入块，并在加密下一个块之前将输出异或到下一个块。最后一个块之后的输出是您的哈希值

虽然“构建您自己的”通常不是一个好主意，但在这种情况下可能确实有合理的理由，因为AES速度快，并且在最新处理器的硬件中受支持。在我的机器上，AES的运行速度大约为130MB/s。在i7（具有硬件支持）上，据报告，互联网上的速度大约为570MB/s

至于I/O受限，unwind是正确的，磁盘可以很好地成为限制因素，尽管它不需要。内存映射是您的朋友，特别是在您的特殊情况下

---

如果您检查在防火墙上申请权限的文件，那么这些文件将是加载到RAM中的可执行文件（怎么可能有什么不同，它们毕竟是在执行！）。因此，映射RAM中已经存在的页面将只是添加一个页面表项，或多或少是一个禁止操作。即使数据不在RAM中，性能也会下降（轻松）记忆映射的效果非常惊人，我现在很少使用其他任何东西来提高速度。

哦，天哪，这个问题已经问了2年了！为什么没有人告诉我，现在我觉得自己很愚蠢……但你的答案仍然很好，所以它没有任何附加值。一年过去了，你的答案仍然有附加值。a+1:）你把比特和字节弄混了。那个网站显示的是~45MB/s而不是45MB/s。每个字节2.0个时钟是不现实的。现代CPU为MD5管理大约5个时钟。