为什么LevelDB和RocksDB需要使用'masked CRC32'

Question

从leveldb或rocksdb的crc32.h中，我们可以找到一条注释：

static const uint32_t kMaskDelta = 0xa282ead8ul;

// Return a masked representation of crc.
//
// Motivation: it is problematic to compute the CRC of a string that
// contains embedded CRCs.  Therefore we recommend that CRCs stored
// somewhere (e.g., in files) should be masked before being stored.
inline uint32_t Mask(uint32_t crc) {
  // Rotate right by 15 bits and add a constant.
  return ((crc >> 15) | (crc << 17)) + kMaskDelta;
}

那么，这是什么意思？为什么我们需要口罩？

Answer 1

遮罩

“掩码”在注释和一行代码中进行了说明。它通过将其右移15位并添加一个常量来修改32位CRC。

为什么需要口罩？

不需要“掩码”，但是建议在存储CRC时使CRC比标准CRC复杂一些。我不知道为什么建议以这种方式“保护”存储的CRC。如果“屏蔽”过程是固定的并且已知，那么我看不出它如何对“保护”存储的CRC有帮助。我认为该面具是自定义的，其他人对于实际使用是未知的。

计算包含嵌入式CRC的字符串的CRC有问题。>

我不清楚评论的内容。生成可以在字符串中任意位置传输的数据并不难，这样计算出的CRC才有效。通常，将CRC附加到消息中，但是可以通过将CRC乘以（1 /（2 ^（n）））（在适当的Galois字段中）并进行无进位乘法来将其向后循环n位，该无进位乘法可以加速使用诸如X86的pclmulqdq之类的指令（它使用xmm寄存器）进行设置。例如，假设32位CRC将存储在具有m

位的字符串的位索引j上，包括数据和CRC。将索引j的32位清零，然后使用标准CRC来计算CRC，就好像要在位索引m处附加它一样。然后，CRC向后循环m-j位，并存储在位索引j。

在字符串中嵌入多个CRC将使逆向工程变得困难，但是我已经看到了用于游戏的保存文件具有两个嵌入的CRC的情况，黑客能够对双CRC方法进行逆向工程。