与更现代的哈希函数（例如MD5或SHA1）相比，何时使用CRC进行错误检测更合适？前者在嵌入式硬件上更容易实现吗？

CRC可以很好地检测可能发生的数据中的随机错误，例如网络干扰，线路噪声，失真等。

CRC在计算上比MD5或SHA1复杂得多。使用MD5之类的哈希函数可能对于随机错误检测来说是多余的。但是，将CRC用于任何类型的安全检查将比更复杂的哈希功能（例如MD5）安全性低得多。

是的，CRC在嵌入式硬件上更容易实现，您甚至可以在IC上获得不同的打包解决方案。

CRC旨在防止数据意外更改。也就是说，它对于检测意外错误很有用，但是作为确保未恶意处理数据的一种方式将毫无用处。

另请参阅此。

我发现了一项研究，该研究表明哈希表的CRC哈希有多么不合适。它还说明了该算法的实际特征。该研究还包括对其他哈希算法的评估，并且可以作为很好的参考。

有关CRC哈希的相关结论：

CRC32从未打算用于哈希表。确实没有充分的理由为此目的使用它，我建议您避免这样做。如果决定使用CRC32，则必须从与密钥八比特组馈入相反的那一端使用哈希位，这一点至关重要。这取决于特定的CRC32实现。不要将CRC32视为“黑匣子”哈希函数，也不要将其用作通用哈希。确保测试其每个应用程序的适用性。

更新

看来该网站已关闭。在互联网档案馆有一个副本，但。

我在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”，因为它们具有：

  1. 您关心安全性时的一些安全性问题
  2. 当您只需要CRC时，散列字串会更长，且比“ crc32b”慢

有关实现，速度和可靠性的CRC信息，请参阅CRC错误检测算法的无痛指南。它具有CRC上的所有内容。

除非有人打算恶意修改您的数据并隐藏更改，否则CRC就足够了。只需使用“良好”（标准）政策即可。

这完全取决于您的要求和期望。

以下是这些哈希函数算法之间的简要区别：

CRC（CRC-8 / 16/32/64）

• 是不加密的哈希算法（它使用基于循环冗余校验的线性函数）
• 可以产生9、17、33或65位
• 不能用于加密目的，因为不做任何加密保证，
• 不适合用于数字签名，因为它很容易反转²⁰⁰⁶，
• 不应用于加密目的，
• 不同的字符串会产生碰撞，
• 于1961年发明，并用于以太网和许多其他标准，

MD5

• 是一种密码哈希算法，
• 产生一个128位（16字节）的哈希值（32位十六进制数字）
• 它是一个加密哈希，但是如果您担心安全性，则认为它已弃用，
• 已知的字符串具有相同的MD5哈希值
• 可以用于加密目的，

SHA-1

• 是一种密码哈希算法，

• 产生一个160位（20字节）的哈希值，称为消息摘要

• 它是一个加密哈希，自2005年以来，它不再被认为是安全的，

• 可以用于加密目的，

• 发现sha1碰撞的一个例子

• 最早于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

有关：

• PHP上的md5（），crc32（）和sha1（）加密之间有什么区别？

您没有说您要保护的是什么。

CRC通常在嵌入式系统中用作检查意外数据损坏的方法，而不是防止恶意系统修改。CRC有用的地方的例子是在系统初始化期间验证EPROM映像，以防止固件损坏。系统引导加载程序将计算应用程序代码的CRC，并在允许代码运行之前将其与存储的值进行比较。这样可以防止程序意外损坏或下载失败的可能性。

CRC也可以类似的方式用于保护存储在闪存或EEPROM中的配置数据。如果CRC错误，则可以将数据标记为无效，并使用默认或备份数据集。由于设备故障或用户在更新配置数据存储期间断电，CRC可能无效。

有评论认为，与具有多个比特错误的CRC相比，散列提供更大的检测损坏的可能性。的确如此，是否使用16或32位CRC的决定将取决于使用损坏的数据块的安全后果，以及您是否可以证明2 ^ 16或2 ^ 32的机会是1。数据块被错误地声明为有效。

许多设备具有用于标准算法的内置CRC生成器。德州（TI）的MSP430F5X系列具有CRC-CCITT标准的硬件实现。

CRC32更快，散列长度只有32位。

仅在需要快速轻松的校验和时使用它。CRC用于以太网。

如果需要更高的可靠性，最好使用现代的哈希函数。

仅在计算资源非常紧张（例如某些嵌入式环境）或您需要存储/传输许多输出值且空间/带宽很紧凑的情况下才使用CRC（因为CRC通常为32位，而MD5输出为128位，SHA1 160位以及其他SHA变体（最高512位）。

切勿使用CRC进行安全检查，因为CRC非常容易“伪造”。

即使对于意外错误检测（而不是恶意更改检测），哈希也比简单的CRC更好。一方面是因为计算CRC的简单方法（另一方面，由于CRC值通常比普通哈希输出短，因此可能值的范围要小得多），在出现两个或多个错误的情况下，可能性更大，一个错误将掩盖另一个错误，因此尽管有两个错误，您仍然会得到相同的CRC。

简而言之：除非您有理由不使用体面的哈希算法，否则请避免使用简单的CRC。

我最近发现使用CRC很聪明。的作者jdupe文件重复识别和删除工具（流行的EXIF工具的jhead的同一作者）第一次通过文件中使用它。在每个文件的前32K上计算CRC，以标记看起来相同的文件，而且文件的大小也必须相同。这些文件将添加到要进行完整二进制比较的文件列表中。它加快了检查大型媒体文件的速度。

CRC32速度更快，并且有时具有硬件支持（即在Nehalem处理器上）。确实，只有在与硬件接口或性能非常紧张时才使用它

让我们从基础开始。

在密码术中，哈希算法通过摘要操作将许多位转换为更少的位。哈希用于确认消息和文件的完整性。

所有哈希算法都会产生冲突。一个冲突是当几个多位组合产生相同的更少位输出时。散列算法的密码强度由个人无法确定给定输入的输出内容来定义，因为如果他们能够构建具有与合法文件匹配的散列并损害假定完整性的文件系统的。CRC32和MD5之间的区别在于MD5会生成一个较大的哈希，很难预测。

当您想要实现消息完整性时-意味着消息在传输过程中未被篡改-无法预测冲突是重要的属性。一个32位的哈希可以使用40亿个不同的唯一散列来描述40亿个不同的消息或文件。如果您有40亿个文件和1个文件，则可以确保发生1次冲突。1 TB的位空间有可能发生数十亿次碰撞。如果我是攻击者，并且可以预测32位哈希将是什么，则可以构造一个与目标文件冲突的受感染文件。具有相同的哈希值。

此外，如果我正在执行10mbps传输，则数据包被破坏的可能性恰好是绕过crc32并继续沿目的地到达并执行的可能性很小。假设以10mbps的速度出现10错误/秒。如果我将其提高到1gbps，现在每秒将收到1,000个错误。如果我每秒提高1 EB，那么我的错误率就是每秒1,000,000,000个错误。假设我们的碰撞率为1 \ 1,000,000传输错误，意味着百万个传输错误中的1导致损坏的数据无法通过检测。以10mbps的速度发送的错误数据每100,000秒或大约每天发送一次。以1gbps的速度每5分钟发生一次。以每秒1埃比特的速度，我们每秒谈论几次。

如果弹出Wireshark，您将看到典型的以太网头具有CRC32，IP头具有CRC32，TCP头具有CRC32，这是高层协议可能要做的工作；例如，除上述以外，IPSEC可能还使用MD5或SHA进行完整性检查。在典型的网络通信中，错误检查存在几层，并且仍然以低于10mbps的速度反复失误。

循环冗余校验（CRC）有几种常见的版本，有几种不常见的版本，但通常旨在仅告诉消息或文件在传输过程中已损坏（多位翻转）。在大型标量企业环境中，由于冲突率，CRC32本身并不是一种很好的错误检查协议。平均每个用户的硬盘驱动器可以拥有超过10万个文件，而公司的文件共享可以有数千万个文件。哈希空间与文件数的比率太低。CRC32在计算上实现起来很便宜，而MD5则不是。

MD5旨在阻止故意使用冲突以使恶意文件看起来良好。之所以认为这是不安全的，是因为哈希空间已被充分映射以允许发生某些攻击，并且某些冲突是可预测的。SHA1和SHA2是新手。

对于文件验证，Md5开始被许多供应商使用，因为您可以使用它快速处理多千兆字节文件或多兆字节文件，并将其堆叠在通用操作系统的使用和对CRC32的支持之上。如果在未来十年内文件系统开始使用MD5进行错误检查，请不要感到惊讶。

CRC代码更加简单快捷。

您需要什么？