与 MD5 或 SHA1 等更现代的散列函数相比，何时使用 CRC 进行错误检测更合适？前者更容易在嵌入式硬件上实现吗？
问问题
102535 次
13 回答
124
CRC 可以很好地检测数据中可能出现的随机错误，例如来自网络干扰、线路噪声、失真等。
CRC 在计算上比 MD5 或 SHA1 简单得多。使用像 MD5 这样的散列函数对于随机错误检测来说可能是多余的。但是，使用 CRC 进行任何类型的安全检查都远不如 MD5 等更复杂的散列函数安全。
是的，CRC 更容易在嵌入式硬件上实现，您甚至可以在 IC 上获得不同的封装解决方案。
于 2009-06-15T15:51:21.447 回答
36
CRC 旨在防止数据中的意外更改。也就是说，它有助于检测意外错误，但无法确保数据未被恶意处理。
也看到这个。
于 2009-06-15T15:58:00.480 回答
23
我发现一项研究表明CRC 哈希对于哈希表来说是多么不合适。它还解释了算法的实际特征。该研究还包括对其他哈希算法的评估，是一个很好的参考。
更新
网站好像挂了。互联网档案虽然有一个副本。
更新 2
哦亲爱的。事实证明，这项研究可能围绕 CRC 用作哈希的结论存在缺陷。感谢@minexew 提供链接。
于 2011-09-22T05:35:08.120 回答
19
我在 1.000.000 循环中运行了这个 PHP 代码的每一行。结果在评论 (#) 中。
hash('crc32', 'The quick brown fox jumped over the lazy dog.');# 750ms 8 chars
hash('crc32b','The quick brown fox jumped over the lazy dog.');# 700ms 8 chars
hash('md5', 'The quick brown fox jumped over the lazy dog.');# 770ms 32 chars
hash('sha1', 'The quick brown fox jumped over the lazy dog.');# 880ms 40 chars
hash('sha256','The quick brown fox jumped over the lazy dog.');# 1490ms 64 chars
hash('sha384','The quick brown fox jumped over the lazy dog.');# 1830ms 96 chars
hash('sha512','The quick brown fox jumped over the lazy dog.');# 1870ms 128 chars
我的结论：
- 当您需要http://en.wikipedia.org/wiki/Cyclic_redundancy_check并且您不关心安全性时，请使用“crc32b” 。
当您需要添加安全层时，请使用“sha256”（或更高版本）。
不要使用“md5”或“sha1”，因为它们有：
- 当你关心安全时的一些安全问题
- 当您只需要 CRC 时，哈希字符串更长，并且比“crc32b”慢
于 2012-04-16T10:14:15.910 回答
11
有关实施、速度和可靠性的 CRC 信息，请参阅CRC 错误检测算法的无痛指南。它拥有 CRC 上的所有内容。
除非有人试图恶意修改您的数据并隐藏更改 CRC 就足够了。只需使用“好”（标准）多项式即可。
于 2009-06-17T09:01:47.953 回答
10
这一切都取决于您的要求和期望。
以下是这些哈希函数算法之间的简要区别：
CRC (CRC-8/16/32/64)
- 不是加密散列算法（它使用基于循环冗余检查的线性函数）
- 可以产生 9、17、33 或 65 位
- 不打算用于加密目的，因为没有加密保证，
- 不适合在数字签名中使用，因为它很容易可逆2006 ,
- 不应用于加密目的，
- 不同的字符串可以产生碰撞，
- 于 1961 年发明并用于以太网和许多其他标准，
MD5
- 是一种加密哈希算法，
- 生成 128 位（16 字节）哈希值（32 位十六进制数）
- 它是一个加密哈希，但如果您担心安全性，它会被视为已弃用，
- 存在具有相同 MD5 哈希值的已知字符串
- 可用于加密目的，
SHA-1
是一种加密哈希算法，
生成称为消息摘要的 160 位（20 字节）散列值
它是一个加密哈希，自 2005 年以来它不再被认为是安全的，
可用于加密目的，
首次发布于 1993 年（作为 SHA-0），然后在 1995 年作为 SHA-1，
系列：SHA-0、SHA-1、SHA-2、SHA-3、
总之，使用 SHA-1 不再被认为是针对资金充足的对手的安全性，因为在 2005 年，密码分析家发现了对 SHA-1 的攻击，这表明它对于持续使用schneier可能不够安全。美国 NIST 建议联邦机构应停止将 SHA1-1 用于需要抗碰撞的应用，并且必须在 2010 NIST之后使用 SHA-2 。
因此，如果您正在寻找简单快速的解决方案来检查文件的完整性（防止损坏），或者出于性能方面的一些简单缓存目的，您可以考虑使用 CRC-32，您可以考虑使用MD5，但是，如果您正在开发专业应用程序（应该是安全且一致的），为了避免任何冲突概率 - 使用 SHA-2 及更高版本（例如 SHA-3）。
表现
PHP中的一些简单基准测试：
# Testing static text.
$ time php -r 'for ($i=0;$i<1000000;$i++) crc32("foo");'
real 0m0.845s
user 0m0.830s
sys 0m0.008s
$ time php -r 'for ($i=0;$i<1000000;$i++) md5("foo");'
real 0m1.103s
user 0m1.089s
sys 0m0.009s
$ time php -r 'for ($i=0;$i<1000000;$i++) sha1("foo");'
real 0m1.132s
user 0m1.116s
sys 0m0.010s
# Testing random number.
$ time php -r 'for ($i=0;$i<1000000;$i++) crc32(rand(0,$i));'
real 0m1.754s
user 0m1.735s
sys 0m0.012s\
$ time php -r 'for ($i=0;$i<1000000;$i++) md5(rand(0,$i));'
real 0m2.065s
user 0m2.042s
sys 0m0.015s
$ time php -r 'for ($i=0;$i<1000000;$i++) sha1(rand(0,$i));'
real 0m2.050s
user 0m2.021s
sys 0m0.015s
有关的：
于 2016-02-05T12:37:30.087 回答
9
你没有说你想要保护的是什么。
CRC 通常在嵌入式系统中用作防止意外数据损坏的检查，而不是防止恶意系统修改。CRC 可能有用的地方的示例是在系统初始化期间验证 EPROM 映像以防止固件损坏。系统引导加载程序将计算应用程序代码的 CRC，并在允许代码运行之前与存储的值进行比较。这可以防止意外程序损坏或下载失败的可能性。
CRC 也可以以类似的方式用于保护存储在 FLASH 或 EEPROM 中的配置数据。如果 CRC 不正确，则可以将数据标记为无效并使用默认或备份数据集。由于设备故障或用户在更新配置数据存储期间断电，CRC 可能无效。
有人评论说，哈希比具有多位错误的 CRC 提供更大的检测损坏的可能性。这是真的，是否使用 16 位或 32 位 CRC 的决定将取决于正在使用的损坏数据块的安全后果，以及您是否可以证明 2^16 或 2^32 中的 1 的机会是合理的数据块被错误地声明为有效。
许多设备具有用于标准算法的内置 CRC 生成器。Texas 的 MSP430F5X 系列具有 CRC-CCITT 标准的硬件实现。
于 2009-06-16T12:16:39.297 回答
6
CRC32 更快，散列只有 32 位长。
当您只想要一个快速和轻便的校验和时使用它。CRC用于以太网。
如果您需要更高的可靠性，最好使用现代散列函数。
于 2009-06-15T15:51:23.193 回答
6
我最近遇到了一个聪明的 CRC 用法。jdupe文件重复识别和删除工具的作者（流行的exif工具jhead的同一作者）在第一次通过文件时使用它。对每个文件的前 32K 计算 CRC 以标记看起来相同的文件，而且文件必须具有相同的大小。这些文件被添加到要对其进行完整二进制比较的文件列表中。它加快了检查大型媒体文件的速度。
于 2010-12-09T02:43:16.950 回答
5
CRC32 速度更快，有时有硬件支持（即在 Nehalem 处理器上）。真的，你唯一会使用它的时候是你正在与硬件接口，或者你对性能非常严格
于 2009-06-15T15:47:07.227 回答
5
仅当计算资源非常紧张（即某些嵌入环境）或您需要存储/传输许多输出值并且空间/带宽紧张时才使用 CRC（因为 CRC 通常是 32 位，而 MD5 输出是 128 位，SHA1 160位，以及其他高达 512 位的 SHA 变体）。
切勿使用 CRC 进行安全检查，因为 CRC 很容易“伪造”。
即使对于意外错误检测（而不是恶意更改检测），哈希也比简单的 CRC 更好。部分是因为计算 CRC 的方法很简单（部分是因为 CRC 值通常比常见的散列输出短，因此可能值的范围要小得多），在有两个或多个错误的情况下，更有可能发生这种情况，一个错误将掩盖另一个错误，因此尽管有两个错误，但您最终会得到相同的 CRC。
简而言之：除非您有理由不使用像样的哈希算法，否则请避免使用简单的 CRC。
于 2009-06-15T16:48:22.970 回答
5
让我们从基础开始。
在密码学中，散列算法通过摘要操作将许多位转换为更少的位。哈希用于确认消息和文件的完整性。
所有散列算法都会产生冲突。当几个多位组合产生相同的较少位输出时，就会发生冲突。散列算法的加密强度是由个人无法确定给定输入的输出将是什么来定义的，因为如果他们可以构造一个具有与合法文件匹配的散列的文件并损害假定的完整性系统的。CRC32 和 MD5 之间的区别在于 MD5 生成的散列更大，更难预测。
当你想实现消息完整性时——意味着消息在传输过程中没有被篡改——无法预测冲突是一个重要的属性。一个32 位散列可以使用 40 亿个不同的唯一散列来描述40 亿个不同的消息或文件。如果你有 40 亿个和 1 个文件，你肯定会发生 1 次冲突。1 TB 位空间有数十亿次碰撞的可能性。如果我是攻击者并且我可以预测 32 位散列将是什么，我可以构造一个与目标文件冲突的受感染文件；具有相同的哈希值。
此外，如果我正在执行 10mbps 传输，那么数据包被破坏以绕过 crc32 并继续沿着目的地执行的可能性非常低。假设在 10mbps 时我得到10 个错误\秒。如果我将其提高到 1gbps，现在我每秒会收到 1,000 个错误。如果我以每秒 1 exabit 的速度运行，那么我的错误率为每秒 1,000,000,000 个错误。假设我们的碰撞率为1\1,000,000传输错误，意味着百万分之一的传输错误导致损坏的数据未被检测到。在 10mbps 时，我会每 100,000 秒或大约每天一次发送错误数据。在 1gbps 时，它每 5 分钟发生一次。在每秒 1 exabit 的情况下，我们每秒会说几次。
如果你打开 Wireshark，你会看到典型的以太网报头有 CRC32，你的 IP 报头有 CRC32，你的 TCP 报头有 CRC32，这是对高层协议的补充；例如，IPSEC 可能会使用 MD5 或 SHA 除上述之外的完整性检查。在典型的网络通信中有几层错误检查，它们仍然会时不时地以低于 10mbps 的速度进行检查。
循环冗余校验 (CRC) 有几个常见的版本和几个不常见的版本，但通常仅用于判断消息或文件在传输过程中何时损坏（多位翻转）。由于冲突率，CRC32 本身在大型标量企业环境中并不是一个很好的错误检查协议。普通用户的硬盘驱动器可以有超过 100k 的文件，而公司的文件共享可以有数千万。哈希空间与文件数量的比率太低了。CRC32 在计算上实现起来很便宜，而 MD5 则不然。
MD5 旨在阻止故意使用冲突来使恶意文件看起来是良性的。它被认为是不安全的，因为哈希空间已被充分映射以使某些攻击能够发生，并且某些冲突是可预测的。SHA1 和 SHA2 是新来的。
对于文件验证，Md5 开始被许多供应商使用，因为您可以使用它快速处理数千兆字节的文件或多兆字节的文件，并将其叠加在通用操作系统对 CRC32 的使用和支持之上。如果在未来十年内文件系统开始使用 MD5 进行错误检查，请不要感到惊讶。
于 2013-11-09T09:31:12.960 回答
1
CRC 码更简单、更快。
你需要什么？
于 2009-06-15T15:47:51.640 回答