因此，从本质上讲，它们是加密哈希的非安全版本，可以说吗？因此，出于相同的原因，这些校验和比加密哈希更“便宜”吗？ （例如CRC32与SHA-256）
对不起，我的英语水平很差，可能还有一些琐碎的问题。我只需要弄清楚概念。
#1 楼
校验和基本上是加密散列的精简版本吗？例如：他们应该检测自然/随机发生的错误，而不是被设计为防止知识渊博的攻击者的精心设计的壮举？
这是一种查看错误的方法。但是，哈希函数有许多用途。它们也被认为是单向的（攻击者无法不猜测就不会知道原映像），为此，它与校验和没有平行之处。
因此，从本质上讲，它们是非安全版本可以说密码哈希吗？因此，出于相同的原因，这些校验和比加密哈希更“便宜”吗？ （例如CRC32与SHA-256）
由于它们的要求不同，校验和不仅“更糟，而且哈希值更快”。它们旨在防止特定类型的错误。循环冗余校验可以检测到短输入中的所有1-2位错误，以及典型应用中的其他一些常见错误类别（例如，突发错误）。这比具有类似长度的截断的密码散列要好得多。
被截断为32位的密码散列可以很容易地与两个输入只有一个或两个位不同而发生冲突，而CRC不会。 CRC旨在可靠地检测通常在传输过程中发生的错误模式，因此它将在此类错误上表现更好，而在其他类型上则更糟。短哈希在所有输入上表现最佳，因此比输入上的CRC更糟糕。CRC善于处理。
评论
$ \ begingroup $
@ArtjomB。截断为32位的加密散列可以很容易地与仅一个或两个位不同的两个输入发生冲突，而CRC不会。 CRC旨在可靠地检测通常在传输过程中发生的错误模式，因此它将在此类错误上表现更好，而在其他类型上则更糟。短哈希在所有输入上表现最佳，因此比CRC擅长处理的输入更糟糕。
$ \ endgroup $
–托马斯
16-2-21在19:21
$ \ begingroup $
@ArtjomB。 8位校验和将使您能够检测到字符串中任何位置的任何一位（甚至单字节）更改；加密的哈希被截断为8位将有1/256的机会没有检测到更改（或任何大小）。因此，虽然加密货币对恶意对手的抵抗力更强，但校验和对较小的随机变化（即数据传输错误）的抵抗力却更好。您应该使用哪一种取决于您要防范的内容。 BTW，校验和和CRC是截然不同的事物； CRC可以防止校验和表现不佳的几类（随机）错误。
$ \ endgroup $
–戈登·戴维森（Gordon Davisson）
16-2-21在19:22
$ \ begingroup $
我现在看到您想强调的是，CRC总是检测到1-2位错误（取决于所选的多项式）和哈希值。我刚刚阅读了《 CRC错误检测算法的无痛指南》，该指南明确了这一事实，而Wikipedia页面由于某种原因而没有。
$ \ endgroup $
– Artjom B.
16-2-21在20:24
$ \ begingroup $
@ OlegV.Volkov，存在某些类型的错误，您有100％的机会被检测到。要了解为什么您可以考虑使用奇偶校验检查，它可以检测所有一位翻转。
$ \ endgroup $
–otus
16年2月21日在21:32
$ \ begingroup $
@ OlegV.Volkov：CRC8适用于短数据包，但是如果使用128阶多项式，则不足以保护有效载荷超过15个字节的任何内容。您的小包有多大？
$ \ endgroup $
–超级猫
16-2-22在6:52
#2 楼
我认为将校验和视为消息身份验证代码的精简版本（而不是哈希）会更有用。消息身份验证代码（MAC）旨在检测对消息的任何修改，而在途中。它们即使在对抗性选择的修改下也很安全。
校验和旨在检测邮件在传输过程中的某些修改。它们旨在检测随机修改：可能偶然发生的修改类型（例如，由于突发的噪音，干扰或其他原因），而不是对抗性修改。
，校验和可能比MAC更快。但是MAC可以变得非常快。...
评论
$ \ begingroup $
MAC和哈希之间的关键区别在于，MAC是加密钥的，而哈希不是。 CRC也不加密，因此将CRC与散列进行比较似乎更合适。
$ \ endgroup $
–卡巴斯德
16-2-22在9:42
$ \ begingroup $
@kasperd，虽然有所不同，但与唯一相关的差异相去甚远。例如，散列必须是单向的； MAC不是，校验和也不是。您可以将CRC与散列进行比较，但是随后您会发现，散列具有额外的要求，这些要求不会出现在校验和中，并且看起来像是正交的，因此比较变得混乱。相比之下，MAC和校验和具有相似的目的，唯一的区别是对抗性与非对抗性，因此我个人认为将校验和与MAC近似地比较是更直观的。
$ \ endgroup $
– D.W.
16-2-22在18:43
#3 楼
从我的角度来看，他们将是遥远的亲戚。但我理解这一点：两者都生成固定长度的值，可以帮助指示完整性何时以某种方式受到损害。它们应该作为具有不同用途的遥远工具而存在，不应混淆，但是存在CRC32来使区别变得复杂。CRC32是一个校验和，可导出32位长的摘要，例如，用于检查压缩文件在传输过程中是否损坏。但是，它生成一个32位长的摘要的事实导致人们相信它可以用作完整性控制的加密哈希。特别是，它们在工业网络中用作哈希函数，在该网络中，硬件功能通常受严格限制，而实际的加密哈希可能是繁重的选择。这并不意味着它们实际上可以在任何程度上代替加密散列函数，而是表明这两个函数族的描述是如此相似，以至于细心的观察者可能会误认为。
#4 楼
MAC确保接收者使用共享密钥（密钥）由发送者真实地生成消息。 MAC是一对算法：生成和验证。通常，发件人会生成一个标签以附加到邮件中。通过混合消息，密钥和计数器，然后对结果进行哈希处理来生成此标记。然后，接收者可以使用相同的过程来验证消息是否真实。除了两个消息具有相同MAC（1/2 ^ n）的可能性低的事实外，MAC无法保证。根据Koopman等人的研究*，CAN中的15位CRC可确保所有消息冲突之间的汉明距离至少为6位。这意味着将始终在1-5个随机位翻转的消息帧（82位）中检测到错误。如果尝试将82位消息MAC转换为15位MAC，则错误检测的保证不成立。这就是为什么现在仍将CRC用于错误检测的原因。
* Koopman，Philip和Tridib Chakravarty。 “嵌入式网络的循环冗余码（CRC）多项式选择。”可靠的系统和网络，2004年国际会议。 IEEE，2004年。
评论
Crc不是“安全密码散列”。它具有非常不同的属性。哈希值不能轻易逆转。 Crc可让您知道添加哪些字节才能生成所需的crc。@JDługosz我从未宣称CRC是“安全的加密哈希”。我问是否可以将它们视为“非安全密码散列”-以及是否可以将相同的通用术语也应用于其他校验和。