我应该使用什么校验和算法？答案

【问题标题】：What checksum algorithm should I use?我应该使用什么校验和算法？
【发布时间】：2011-05-13 02:21:24
【问题描述】：

我正在构建一个系统，该系统需要能够查找字节块是否已更新。我认为我应该计算它的校验和，然后存储它并稍后计算相同的校验和，以查看 blob 是否已更新，而不是存储整个 blob（它们最多可达 5MB）。

目标是最小化以下（按此顺序）：

校验和的大小
计算时间
冲突的可能性（即使内容已被修改，也会发生 2 个相同的校验和）。

我们的系统可以接受不超过 1/1,000,000 的冲突。关心的不是安全性，而是简单的更新/错误检测，所以很少发生冲突是可以的。（这就是为什么我把它放在最后的原因）。

此外，我们不能自己修改文本块。

当然，我会想到 md5、crc 或 sha1，如果我想要一个快速的解决方案，我会去的。但是，除了快速解决方案之外，我还在寻找不同方法的比较以及优缺点。

【问题讨论】：

您有什么顾虑，在这里？您是在检查您的数据 blob 是否自较早前发生了变化，还是在尝试检测恶意更改？
只是想看看它们是否有任何更新。
如果您不担心恶意更改的可能性，而只想跟踪更改，并且（如您在其他地方所说）您可以忍受百万分之一的意外碰撞概率，那么使用 CRC - 它比 MD5 或 SHA 更快，并且冲突的可能性在您的规范内很好。
我会推荐 CRC-64。它比加密哈希要快得多，并且应该满足您对冲突概率的要求。

标签： md5 sha1 checksum crc

【解决方案1】：

我建议你看看this SO page，CRC vs MD5/SHA1。
速度和碰撞在this other thread 中讨论。
和往常一样，Wikipedia 是你的朋友。

如果我必须选择，有一个重要的问题需要回答：你是否希望在任何情况下都没有碰撞 - 或者，至少，概率如此之低以至于接近月球的可能性？在接下来的 5 分钟内与地球相撞？

如果是，请选择 SHA 系列。
在您的情况下，我会更改 更新检查 的完成方式。
例如，一个递增的数字可以与 blob 相关联，并被发送而不是 hash，如果另一个数字不同，则需要 更新请求边。在这种情况下，碰撞概率从 ~10^-18 变为 ~0（基本上是 0 + bug 概率）...

编辑跟随 cmets

找到了这个算法，Adler-32，它适用于 32 位 CRC 的长消息 (MB)，即大约 ~1/10^9（MD5 的长度为 128 位）。
计算速度很快。
Adler-32.底部有一些示例（链接）。

【讨论】：

我不介意非常罕见的碰撞。在我的脑海中，像 1/1,000,000 这样的东西似乎足够低（我们将平均每 15 分钟比较一次 blob，所以这是每 28k 年发生一次碰撞。另外，我不控制文本的 blob，所以我可以不要自己改变它们。
在这种情况下，您最好选择 MD5，它比 SHA 更快，但更容易发生冲突（概率接近您的要求）。
但是 MD5 是 32 位的，相当大，碰撞概率远低于 1/1,000,000...所以我认为它不是一个好的候选者！我们可以做得更好！
哈，是的，我的意思是字节 :( Adler-32 很有趣。
请注意，当人们说 Alder-32 对长消息有好处时，这意味着它对短消息有问题。请参阅有关文件系统损坏问题的讨论，其中将 alder-32 列为弱点blog.acolyer.org/2017/03/08/…

【解决方案2】：

Blake2 是你可以使用的最快的哈希函数，主要被采用：

BLAKE2 不仅比其他好的散列函数更快，而且甚至比 MD5 或 SHA-1 还要快 Source

SHA-3 竞赛的获胜者是 Keccak 算法，但还没有流行的实现，GNU/Linux 发行版默认不采用。相反，作为 SHA-3 竞赛候选者的 Blake2 比 Keccak 更快，并且是 GNU coreutils 的一部分。所以在你的 GNU/Linux 发行版上，你可以使用 b2sum 来使用 Blake2 哈希算法。

【讨论】：