CRC何时比MD5 / SHA1更适合使用?

时间:2009-06-15 15:43:51

标签: hash embedded crc

什么时候使用CRC进行错误检测而不是更现代的哈希函数(如MD5或SHA1)?前者在嵌入式硬件上更容易实现吗?

13 个答案:

答案 0 :(得分:102)

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

CRC在计算上远不如MD5或SHA1复杂。使用像MD5这样的散列函数可能会对随机错误检测造成过大的影响。但是,使用CRC进行任何类型的安全检查都不如MD5等更复杂的散列函数安全。

是的,CRC在嵌入式硬件上更容易实现,你甚至可以在IC上获得不同的封装解决方案。

答案 1 :(得分:29)

CRC旨在防止数据中的无意更改。 也就是说,它有助于检测无意的错误,但作为确保数据未被恶意处理的一种方法将毫无用处。

另见this

答案 2 :(得分:19)

我发现了一项显示how inappropriate CRC hashes are for hash tables的研究。它还解释了算法的实际特征。 The study还包括对其他哈希算法的评估,并且是保持良好的参考。

关于哈希的CRC的相关结论:

  

CRC32从未打算用于哈希表。没有充分的理由将其用于此目的,我建议您不要这样做。   如果您决定使用CRC32,那么使用与密钥八位字节输入相反的末端的散列位是至关重要的。这取决于具体的CRC32实现。不要将CRC32视为“黑盒子”哈希函数,也不要将其用作通用哈希。请务必测试每个应用程序的适用性。

<强>更新

网站似乎已关闭。但是internet archive has a copy

答案 3 :(得分:16)

我在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
    3. 时,它比“crc32b”慢

答案 4 :(得分:10)

有关实施,速度和可靠性的CRC信息,请参阅A painless guide to CRC error detection algorithms。它拥有CRC上的所有内容。

除非有人试图恶意修改您的数据并隐藏更改CRC就足够了。只需使用“好”(标准)polinoomial。

答案 5 :(得分:8)

你没有说你试图保护的是什么。

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

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

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

许多设备都有内置的CRC生成器,用于标准算法。德克萨斯州的MSP430F5X系列具有CRC-CCITT标准的硬件实现。

答案 6 :(得分:6)

CRC32更快,哈希只有32位长。

只需要快速轻便的校验和即可使用它。 CRC用于以太网。

如果您需要更高的可靠性,最好使用现代的散列函数。

答案 7 :(得分:6)

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

以下是这些hash function算法之间的快速简短差异:

CRC(CRC-8/16/32/64)

  • 加密哈希算法(它使用基于循环冗余检查的线性函数)
  • 可以生成9,17,33或65位
  • 不打算用于加密目的,因为没有加密保证,
  • 不适合用于数字签名,因为它很容易可逆 2006
  • 不应用于加密目的,
  • 不同的字符串可以产生碰撞,
  • 发明于1961年,用于以太网和许多其他标准,

MD5

SHA-1

  • 是加密哈希算法,
  • 生成160位(20字节)哈希值,称为消息摘要
  • 这是一个加密哈希,自2005年以来它不再被认为是安全的,
  • 可用于加密目的,
  • an example of a sha1 collision has been found
  • 首次发表于1993年(作为SHA-0),然后1995年发表为SHA-1,
  • 系列:SHA-0,SHA-1,SHA-2,SHA-3,

    总之,使用SHA-1不再被认为对资金充足的对手是安全的,因为在2005年,密码分析师发现对SHA-1的攻击,这表明它可能不够安全,不能持续使用 {{3} } 。美国NIST建议联邦机构应停止使用SHA1-1进行需要抗冲击的应用,并且必须在2010年之后使用SHA-2 schneier

因此,如果您正在寻找简单快速的解决方案来检查文件的完整性(防止损坏),或者出于性能方面的一些简单缓存目的,您可以考虑使用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

相关:

答案 8 :(得分:5)

如果计算资源非常紧张(即某些嵌入环境),或者您需要存储/传输许多输出值并且空间/带宽紧张(因为CRC通常是32位,其中MD5输出为128位),则仅使用CRC ,SHA1 160位,以及最多512位的其他SHA变体。

永远不要使用CRC进行安全检查,因为CRC非常容易“伪造”。

即使是意外错误检测(而不是恶意更改检测),哈希也比简单的CRC更好。部分原因是计算CRC的简单方法(部分原因是CRC值通常比常见的哈希输出短,因此可能的值范围要小得多),在有两个或更多错误的情况下更有可能,一个错误将掩盖另一个错误,所以尽管有两个错误,你最终会得到相同的CRC。

简而言之:除非您有理由使用合适的哈希算法,否则请避免使用简单的CRC。

答案 9 :(得分:5)

我最近使用了CRC,这很聪明。 jdupe文件复制识别和删除工具(流行的exif工具jhead的同一作者)的作者在第一次传递文件时使用它。在每个文件的前32K上计算CRC以标记看起来相同的文件,并且文件必须具有相同的大小。这些文件将添加到要进行完整二进制比较的文件列表中。它加快了检查大型媒体文件的速度。

答案 10 :(得分:4)

CRC32更快,有时也有硬件支持(即在Nehalem处理器上)。真的,你唯一一次使用它是因为你正在与硬件接口,或者如果你真的性能紧张

答案 11 :(得分:4)

让我们从基础开始。

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

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

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

此外,如果我正在进行10mbps的传输,那么数据包被破坏的可能性正好绕过crc32并继续沿着目标执行并且执行非常低。让我们说在10mbps时我得到 10个错误\第二个。如果我将其提升到1gbps,那么现在我每秒 1,000个错误。如果我每秒达到1个exabit,那么我的错误率每秒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本身并不是一个非常好的错误检查协议。普通用户的硬盘驱动器可以拥有超过100k的文件,而公司的文件共享可以有数千万。哈希空间与文件数量的比率太低了。 CRC32实现起来计算成本低,而MD5则不然。

MD5旨在阻止故意使用冲突,使恶意文件看起来是良性的。它被认为是不安全的,因为哈希空间已被充分映射以使某些攻击发生,并且一些冲突是可预测的。 SHA1和SHA2是街区的新孩子。

对于文件验证,Md5开始被很多供应商使用,因为你可以快速地使用多GB文件或多TB文件,并将其叠加在一般操作系统的使用和CRC32的支持之上。如果在接下来的十年内文件系统开始使用MD5进行错误检查,请不要感到惊讶。

答案 12 :(得分:1)

CRC代码更简单,更快。

你需要什么?