我试图找出 C 中是否有任何用于计算 64 位哈希的 API。我发现有些人使用MD5/SHA1等的前64位。这是一个好方法吗？
你可以尝试SipHash作为MAC的形式（虽然需要密钥管理）。它特别适合短输入消息，旨在增强加密强度。C 实现也可用。
但是，如果您真的关心有人主动弄乱您的文件，则不应将自己限制在 64 位安全性。 如果有足够的时间和资源，今天也可以通过蛮力破解 64 位。为此，您应该使用 SHA-256 或更强。或者让我反过来说，将损坏的选项列入黑名单：不要使用 MD5（或 MD 任何东西）。仅当由于某种原因无法使用 SHA-256 时，才使用 SHA-1。
使用哈希还有一个优点，即您不需要管理任何密钥（与使用 MAC 相反）。您应该将计算的哈希保存在与要监视的文件不同的位置 - 否则篡改文件的人也很容易篡改校验和。
关于截断哈希是好是坏
从理论上讲，我不明白为什么将 160 位哈希值截断为 64 位应该是错误的，无论您是否采用最高有效位或最低有效位或使用任何任意模式选择它们。我能想到的不经常这样做的唯一原因是效率 - 如果有更有效的算法来处理较小的问题，为什么要带大枪。
在下文中，我假设为此目的使用加密安全哈希，通用哈希是一个完全不同的主题 - 它们可能会在截断时暴露攻击面。
但是，对于加密安全的哈希，除非算法被破坏，否则我们可以假设它的输出与均匀分布的随机变量的输出没有区别。
如果我们现在截断这个值，我们不会提供对算法内部工作的任何进一步见解。尽管如此，我们确实削弱了安全性，因为一个简单的事实，即暴力破解（无论是碰撞还是查找前像）现在根据概率定律花费的时间更少。
例如，找到 64 位哈希的碰撞平均需要大约 2^32 次尝试 - 生日悖论说。如果你将输出截断到原始 64 位哈希值中最低有效 32 位，那么你会在大约 2^16 的时间上发现冲突，因为你只是忽略了最重要的 32 位，而事实上的均匀分布完成了其余的工作 - 就像你首先开始搜索具有 32 位值的冲突一样。
这是一个坏主意。哈希函数值始终被视为一个整体。
对于"如何计算 64 位哈希"的隐含问题：您的预期用途是什么？请记住，64 位对于加密强度哈希函数来说太少了。
使用 CRC 防止随机更改。
使用 HMAC 防止攻击者更改您的文件。HMAC 使用生成和验证标记所需的密钥。HMAC 的结果与底层哈希函数一样长（例如，HMAC-SHA1 为 20 个字节），但它经常被截断。即根据NIST SP 800-107 p.14,64-96位应该足以满足大多数应用的需求。
64位对于哈希来说很小，通常，哈希值应该作为一个整体。
现在，您需要这64位做什么？答案将取决于预期的使用情况。
请记住，现在 md5 已经相当坏了，64 位的安全性非常低。
如果您只需要针对随机更改进行完整性检查，那么其他答案中给出的简单校验和可能就足够了。
如果需要加密强度来保证原始内容，那么64位就太弱了。最好使用不间断算法的全部值，即不是MD5。SHA1 仍然可以，但为了长期安全，最好使用 SHA256。甚至更进一步 HMAC，如另一个答案所述。
使用加密哈希的截断值没有错。实际上，SHA224/384 是通过使用不同的初始化向量计算 SHA256/512 哈希然后截断结果来计算的。但是，这仅对加密哈希有效。对于普通校验和和表哈希来说，这可能是一个坏主意。
使用 OpenSSL 的 API 进行计算。www.openssl.org）。