160 位 SHA1 哈希值的前 32 位是否可以替代 CRC32 哈希值？

Question

我正在开发一个 .NET 3.5 项目，我需要一个 32 位哈希值。 .NET Cryptography 类中似乎没有任何方法返回 32 位哈希（MD5 是 128 位，SHA1 是 160 位等）。 我实现了一个 CRC32 类，但我发现现有的 SHA1 和 MD5 哈希函数要快得多。

如果我使用 SHA1 散列函数并只截断前 32 位来存储为我的散列值，是否会出现任何问题（即增加冲突的可能性）？

Answer 1

除非您想要 CRC32 的额外功能（作为线性代码），否则您应该可以将输出削减为 32 位。

切割某些加密哈希函数的输出是否会损害其抗碰撞安全性是一个开放的研究问题（如果我没记错的话，存在“不自然”构造的示例）。 但 NIST（可能得到了 NSA 的批准）无论如何都使用了切割技术从 SHA-256 中获取 SHA-224（请参阅 维基百科中有关 SHA 的文章）。

编辑：CRC32 允许检测（并且可能纠正）单个位错误，而加密哈希函数应该具有这样的属性：您无法找到具有相同哈希值的两个输入。

你知道“生日悖论”吗（再次参见维基百科）？ 使用 32 位校验和，当您有大约 2^16 个输入并且您想要对更多输入进行哈希处理时，您预计会发生冲突（即，两个输入具有相同的哈希值）。 （重读您的评论，这对您来说可能不是问题。）

Answer 2

假设哈希函数将其输入均匀地分布在其共域上，那么假设它也将均匀地分布在其任何子集上似乎是合乎逻辑的。
然而，使用“原生”32 位哈希函数可能仍然是更好的选择。 也许更深入地了解此事的人可以为我们提供比我的直觉更好的理由:)

Answer 3

为什么不直接使用 string.GetHashCode() 呢？ 它旨在计算 32 位哈希值，并在给定真实数据的情况下产生很少的冲突。 当然，它不安全，但您的问题不包括这一要求。

Answer 4

如果您不打算将 32 位用于加密目的，那么应该没问题。 否则，我不会依赖与整个散列具有相同分布的前 32 位。

为什么不能使用可用的更广泛的哈希值？

Answer 5

CRC32 可能适合您的需求。 此问题对此进行了讨论。

就截断哈希原语而言，唯一频繁使用的应用程序是 SSL /TLS 伪随机函数 (PRF) 用于生成密钥。 它使用 HMAC、种子和标签，通过多次散列然后截断到您需要的字节数来生成您需要的任意数量的字节。

至于你的具体问题，如果你偏执的话，你可以将散列的输出读入 Int32，然后将它们异或在一起：

static void Main()
{
    int xorCrc = GetHashedCrc(new SHA1Cng(), new byte[] {0xDE, 0xAD, 0xBE, 0xEF});
}

private static int GetHashedCrc(HashAlgorithm algorithm, byte[] bytesToHash)
{
    byte[] hash = algorithm.ComputeHash(bytesToHash);
    int totalInt32s = hash.Length/sizeof(int);
    int result = 0;
    for(int i = 0; i < totalInt32s; i++)
    {
        int currentInt = BitConverter.ToInt32(hash, sizeof(int)*i);
        result = result ^ currentInt;
    }

    return result;
}