2

我正在使用具有本机硬件功能的微控制器从内存块中计算 CRC32 哈希，其中多项式可以自由定义。事实证明，系统有不同的数据链路，具有不同的 CRC 位长度，如 16 位和 8 位，我打算为此使用硬件引擎。

在使用在线工具进行的简单测试中，我得出结论，可以找到与 8 位 CRC 具有相同结果的 32 位多项式，例如：

  • 使用 8 位引擎和 poly 0xb7 对“样本字符串”进行散列运算得到结果 0x97
  • 使用 16 位引擎和 poly 0xb700 散列“示例字符串”会产生结果 0x9700
  • ...32 位引擎和 poly 0xb7000000 产生结果 0x97000000（初始值为零，最终异或为零，无反射）

因此，用零填充多边形并右移结果似乎有效。但是“总是”有可能找到一组参数使 32 位引擎像 16 位或 8 位引擎一样工作吗？（包括 poly、final xor、init val 和 inversions）

为了提供更多上下文并防止诸如“不要使用本机引擎”之类的“绕过答案”：我在安全关键系统中有一个场景，有必要防止常见的设计错误传播到冗余处理节点。一种解决方案是在一个节点中进行基于软件的 CRC 计算，并在其对中进行基于硬件的计算。

4

2 回答 2

2

是的，您所做的通常适用于未反映的 CRC。使用围绕硬件指令循环的代码可以非常简单地完成预处理和后处理。

假设硬件 CRC 没有这个选项，要进行反射 CRC，您需要反映每个输入字节，然后反映最终结果。这可能会破坏使用硬件 CRC 的目的。（虽然如果你的目的只是有一个不同的实现，那么也许它不会。）

于 2017-04-13T03:38:47.340 回答
0

你不必猜测。你可以计算一下。因为 CRC 是除以不可约多项式的余数，所以它是其域上的 1 对 1 函数。

因此，例如，如果您在 0 到 65536 上运行 CRC16，则必须产生 65536 (64k) 个唯一结果。

要查看通过获取部分 CRC32 是否获得相同的结果，请在 0 到 65535 上运行它，保留您想要保留的 2 个字节，然后查看是否有任何冲突。

如果您的数据中有 32 位，那么这应该不是问题。如果您的数字少于 32 位，并且您在 32 位空间中随机播放它们，就会出现问题。它们的第一个和最后一个字节不能保证均匀分布。

于 2021-10-10T16:32:49.110 回答