C中的64位散列/摘要

Question

我试图找出C中是否有用于计算64位哈希的API。 我发现有些人使用前64位的MD5 / SHA1等。这是一个好方法吗？

Answer 1

您可以在其形式中尝试SipHash作为MAC（但需要密钥管理）。它特别适用于短输入消息，并以加密强度为目标。还可以使用C implementation。

但是，如果你真的关心某人积极搞乱你的文件，你不应该把自己限制在64位的安全性。如果有足够的时间和资源，今天甚至可以通过暴力破解64位。您应该使用SHA-256或更强。或者让我反过来说明，将破碎的选项列入黑名单：不要使用MD5（或MD-anything）。仅在由于某种原因不能使用SHA-256时才使用SHA-1。

使用散列还有一个优点，即您不需要管理任何密钥（与使用MAC相反）。您应该将计算的哈希值保存在与要监视的文件不同的位置 - 否则有人篡改您的文件也会轻易篡改校验和。

关于截断哈希是好还是坏

理论上，我不明白为什么将一个160位的哈希值截断到64位是错误的，无论你是采用最高有效位还是最低有效位或者使用任意方式选择它们图案。我没想到这个问题的唯一原因就是效率 - 如果有更有效的算法来处理较小的问题，为什么要带上大枪。

在下文中，我假设为此目的使用加密安全哈希，通用哈希是一个完全不同的主题 - 它们可能会在我知道的所有内容被截断时暴露攻击面。

但是，对于加密安全散列，除非算法被破坏，否则我们可以假设其输出与均匀分布的随机变量的输出无法区分。

如果我们现在截断这个值，我们不会进一步深入了解算法的内部工作原理。尽管如此，我们做通过一个简单的事实来削弱安全性，即暴力强制（无论是冲突还是寻找前映像）现在通过概率法则花费的时间更少。

例如，找到64位哈希的冲突平均需要大约2 ^ 32次尝试 - 生日悖论说。如果将输出截断为原始64位散列的最低32位，那么您将发现大约2 ^ 16的时间冲突，因为您只是忽略了最重要的32位，其余的事实均匀分布 - 就像你开始首先搜索具有32位值的冲突一样。

Answer 2

这是一个坏主意。 哈希函数值总是意味着整体。

对于“如何计算64位哈希”的隐含问题：您的预期用途是什么？请记住，对于加密强度哈希函数，64位太少了。

Answer 3

使用CRC来防止随机变化。

使用HMAC防止攻击者更改您的文件。 HMAC使用生成和验证标签所必需的密钥。 HMAC的结果与底层散列函数一样长（例如HMAC-SHA1的20个字节），但它经常被截断。即根据NIST SP 800-107第14页，64-96位应该足以满足大多数应用。

Answer 4

对于散列来说，64位是小的，通常，散列应该作为一个整体。

现在，你需要这些64位用于什么？答案取决于预期用途。

请记住，md5现在非常破碎，64位的安全性非常低。

Answer 5

如果您只需要针对随机更改进行完整性检查，那么其他答案中给出的简单校验和可能就足够了。

如果您需要加密强度来确保原始内容，那么64位太弱了。更好地使用不间断算法的全部值，即不是MD5。 SHA1仍然可以，但为了更长期的安全性，最好使用SHA256。或者甚至更进一步与HMAC，如另一个答案所述。

使用加密哈希的截断值没有任何问题。实际上，SHA224 / 384是通过计算具有不同初始化向量的SHA256 / 512散列然后截断结果来计算的。但是，这仅适用于加密哈希。对于正常的校验和和表哈希来说，这可能是一个坏主意。

Answer 6

使用OpenSSL的API进行计算。（www.openssl.org）。