很多文件将存储在数据库中，我需要文件哈希来唯一标识文件未更改。（一般情况下，会用作 Windows 个人防火墙的一部分）
Omega
问问题
6013 次
2 回答
19
如果我理解“用作 Windows 个人防火墙”部分正确，MD5 作为算法不是一个好的选择。
存在对 MD5 算法的成功攻击，它可以让您找到产生相同哈希的不同消息，而工作量相对较少（与蛮力相比）。这种攻击过去没有真正的影响，例如，当使用 MD5 对密码等进行哈希处理时。与此同时，新的攻击已经被发现，因此 MD5 和 SHA-1 都可以以可怕的速度进行散列/碰撞，并且用这些“老”散列破解整个“正确加盐”和单散列用户密码数据库是不可能的仅完全可行，但已被证明。
但是，在“确保这个文件没有被篡改”的特定应用中，这种攻击一直存在是一个问题，不仅仅是最近。MD5 可以非常安全地检测到位错误或意外修改，但是试图绕过您的个人文件墙的恶意软件可能会通过查找受感染二进制文件的冲突以使哈希与原始文件匹配，从而轻松绕过您的整个安全性。
对于这种情况，您应该使用 SHA-256 [更新：与此同时，SHA-3 已经出局，虽然我个人不同意 NIST 选择获胜者（或排除某些非常好的第 2 轮的模糊标准）候选人），使用 SHA-3 (Keccak) 或 SHA-3 决赛选手之一是更安全的选择。所有入围者都由经验丰富的团队精心设计，经过非常彻底的分析，到目前为止，还没有一个真实的攻击或可能导致真实攻击的已知问题，而且它们也都有“更多位”（这本身并没有多大意义，但更多的比特不会受到伤害）]。
此外，请记住除了散列之外始终保存文件的长度，这会以可忽略不计的成本大大加强即使是糟糕的散列。如果可以，计算两个不同的哈希值。对于攻击者来说，找到在一个哈希上产生冲突的消息比找到产生冲突且长度完全相同的消息，甚至是在两个不同的哈希上发生冲突并具有相同长度的消息要容易得多.
由于带宽（磁盘和内存）在计算散列时是不可忽略的因素，因此计算单个散列或两个散列甚至可能以相当的速度同时运行。
在计算 CRC 并随后使用分组密码加密相同的块时，我观察到了这种效果。是否计算 CRC 对整体运行时间的影响小于 1%，因此基本上是自由操作。
如果您认为您有充分的理由不使用众所周知的标准哈希（性能限制？），您可以构建自己的安全哈希。使用 Merkle–Damgård 构造（或最近的 HAIFA），您可以将任何安全块密码转换为安全散列函数。例如，使用固定密钥使用 AES 加密每个输入块，并将输出异或到下一个块，然后再加密该块。最后一个块之后的输出是你的哈希值。
虽然“自己构建”通常不是一个好主意，但在这种情况下确实有正当理由，因为 AES 速度很快，并且在最新处理器的硬件中得到了支持。在我的机器上，AES 以大约 130MB/s 的速度运行。在 i7（具有硬件支持）上，据报道它在 Internet 上的速度约为 570MB/s。
至于受 I/O 限制，unwind 是正确的，磁盘很可能是限制因素，尽管不必如此。内存映射是您的朋友，尤其是在您的特定情况下。
如果您检查在防火墙上申请权限的文件，那么这些文件将是已加载到 RAM 中的可执行文件（怎么可能有什么不同，毕竟它们正在被执行！）。因此，映射已经在 RAM 中的页面将只是添加一个页表条目，或多或少是一个空操作。即使数据不在 RAM 中，内存映射的性能（和易用性）也非常惊人，这些天我很少使用其他任何东西，因为速度是任何问题。
于 2011-03-11T01:05:16.450 回答