使用哈希跟踪文件的唯一版本答案

【问题标题】：Tracking unique versions of files with hashes使用哈希跟踪文件的唯一版本
【发布时间】：2011-01-27 02:21:07
【问题描述】：

我将跟踪可能有数百万个不同文件的不同版本，我的目的是对它们进行哈希处理以确定我已经看到了该文件的特定版本。目前，我只使用 MD5（该产品仍在开发中，因此它从未处理过数百万个文件），这显然不足以避免冲突。

但是，这是我的问题 - 如果我使用两种不同的方法对文件进行哈希处理并存储两个哈希值（例如，SHA1 和 MD5），或者如果我选择一个更长的哈希值（像 SHA256）并仅依靠它？我知道选项 1 有 288 个哈希位，而选项 2 只有 256 个，但假设我的两个选择的总哈希长度相同。

由于我可能要处理数百万个文件（以及随着时间的推移这些文件的多个版本），我想尽我所能避免冲突。但是，CPU 时间不是（完全）免费的，所以我对社区对这种权衡的看法很感兴趣——在我的哈希中添加更多位，计算成本会相应增加，并且多个不同的哈希是否有任何优势？在两个解决方案中给定相同数量的位的单个更长的哈希？

【问题讨论】：

标签： hash collision-detection

【解决方案1】：

我对这个问题进行了很多思考和处理，我建议使用 SHA256 以保持安全（它速度较慢，但 CPU 仍应设法跟上）。我不知道这是否会显着削弱散列强度，但您可能希望将散列打包在 16MB 块中（例如），然后在最后散列散列以便您可以并行化。

我从玩弄大量文件和散列中学到的一个教训是：一次性将数百万条记录添加到 PostgreSQL 数据库中并不是很快。当我编写一个程序来散列一百万个文件并将它们存储在 PostgreSQL 数据库中时，数据库通常是瓶颈。我没有尝试 MySQL，但我推测它大致相同。 SQLite 可能要快得多，因为没有客户端/服务器开销。我建议先尝试 SQLite。也可能太慢了。

另外，如果您通过哈希将一百万个文件存储到一个目录中并丢失了索引文件，那么很难找到东西:)

【讨论】：

在索引上足够公平 - 我必须保持它的安全，因为重建它会很痛苦。但是，我将文件作为密钥进行散列，并存储文件大小，因此碰撞将不得不碰撞这两个项目，这似乎比单独的散列更不可能。也许有了这两条信息，我就安全了。
优化以避免碰撞并没有给你任何我能看到的东西。

【解决方案2】：

对于文件版本跟踪，我认为不同文件之间的冲突不是问题。对于每个文件，您都使用哈希来确定该文件是否更改并且只有该文件更改。该文件的哈希是否与其他文件冲突无关紧要，不是吗？

编辑：您正在应用哈希作为优化，以避免将每个新文件与数百万个现有文件进行比较。冲突不是避免使用快速散列的理由。通过存储文件的新版本来简单地处理冲突情况（如果它曾经发生）。两种散列方案都将提供优化。为什么要对可能不会发生的事情进行过度优化。如果你有一个超快的哈希值，它会在 1000000 中碰撞 1 个。这对密码学来说不是很好，但对版本控制来说很好。

即使在使用 GUID 时，系统也会检测到冲突并进行处理。系统不需要针对统计上永远不会发生的事情进行优化。

【讨论】：

如果两个文件具有相同的哈希值但不同，文件跟踪器不会知道它们不同，最终可能会删除其中一个，从而导致数据丢失（无论分钟）。
如果这是一个问题，那么哈希函数是不合适的。
我也担心不同文件之间的冲突——不管它的名字是什么，我想确定一个文件是否已经被网络上的其他人备份。我想我的问题是尽量减少碰撞风险的最佳方法。
@mrjoltcola：如果世界上任何两个 SHA256 哈希冲突的可能性是 ${astronomical number} 中的 1，那么实际上你不妨说它永远不会发生。没有已知的 SHA256 冲突。如果将来找到一个，将有更好的加密哈希算法来替代它。
@Joey Adams：我同意，但我的观点是，哈希可用于实现对先前文件的“足够好”检测。在“${astronomical number} 中的 1”的情况下，您发现了一个碰撞，您可以通过比较文件内容和/或存储一个唯一的化身来处理它。散列并不是解决系统中所有挑战所必需的，它只是一种优化，以避免将每个新文件与版本控制系统中的数百万个现有文件进行比较。