对于一个散列来说，32个字节足够了吗?还有什么是“过度工程”吗？

Question

为了实现数据完整性，特别是针对小块数据，而不是使用SHA-256散列，或者只是截断SHA-512哈希，我使用以下方法：

function saferHash(data) {
    let hash1Entropy = 42;  // sha512:42
    let hash2Entropy = 4; // 4B extra possible protected outcomes in case of highly unlikely collision in hash 1
    const hash1  = sha512(data).slice(0,hash1Entropy); // for 42 byte entropy, truncated to save space + prevent length extension vulnerabilities 
    const hash2 = blake3(data).slice(0,hash2Entropy); // cheapest extra forgery prevention in case of sha512:42 hash collision, truncated to save space + prevent length extension vulnerabilities 
    return new Uint8Array([...hash1,...hash2]); // 46 byte total hash  
}

这是否完全超出了整个系统的设计，或者将熵增加到+32字节，并使用额外的廉价哈希函数(blake3)来增加创建冲突的难度，这是不是太糟糕了？

Answer 1

1. 是的，32字节/256位被认为是足够的 (认真阅读这篇博客文章)。这个长度提供了2^{128}、碰撞阻力和2^{256}、预像和二次预像电阻，用于SHA256等等。
2. 48字节/384位或64字节/512位提供了更大的安全性，在某些情况下使用更明智，但在其他情况下则没有必要。例如，如果要抓捕一条用于Ed25519的消息，则需要使用512位哈希来最大限度地提高冲突抵抗能力。
3. 这是过度设计。您所做的工作比使用常规的SHA512要弱，因为碰撞电阻取决于输出的长度。输出的4字节太小，不应该使用。BLAKE3的默认输出长度为32字节/256位，一般不应低于任何未键散列函数。42字节也是一个奇怪的选择。没有必要使用多个散列函数或重新发明方向盘。如果一个散列对于建立良好的现实世界协议来说是足够好的，那么它对你来说就足够了。
4. 为了防止长度扩展攻击，可以使用SHA3 512/256，或者理想情况下使用更现代的散列函数，如BLAKE2、SHA3或BLAKE3 (按我的看法)。您不需要截断BLAKE3以避免长度扩展攻击。

Answer 2

通过截断散列，您实际上增加了每个哈希的碰撞率。

最终，对于一定数量的字节，并且考虑到算法是静态的，并且是相对安全的(通过具有接近均匀的输出)，碰撞率将大致保持不变。

你唯一能阻止的可能是彩虹--如果一个特定的散列存在的话，那么大多数都不会因为你的组合而存在。

我相信这是完全的工程，它是更安全，更方便和绝对更快充分使用沙-512比截断每一个和重新发明车轮。

简单地说，你是在截断一个更慢更好的算法，减少你从它得到的“好的”熵，用一个“更便宜”的算法代替它。

Answer 3

散列的大小取决于您预期的加密需求。我们预计128位安全足以应付未来的无限期.因此，32字节(256位)散列对于经典密码来说应该是很好的.但是，如果您需要在后量子密码系统中生存下来的抗碰撞能力，则建议使用更长的哈希(384位或更多)。

我的建议是避免混合和匹配散列，因为并不总是增加额外的安全性就像您认为的那样。与混合和匹配散列相比，更好地使用单个强散列的输出。这也使密码分析结果更容易跟踪，因为它的结构简单和标准。类似地，如果您的代码出于任何原因需要进行审核，那么简单地说“我正在使用这个标准哈希算法”就更容易了，然后向审计师解释您为什么选择自定义构造。

一般来说，任何一种具有足够大小的SHA-2或SHA-3算法或BLAKE2都是很好的选择。BLAKE3也可能是一种选择，但它所看到的密码分析较少，并且与随机预言不同。如果您想要一个非常快的选项，BLAKE2b比MD5和SHA-1更快，并且是加密安全的，并且它可以配置为提供最多512位的任何输出大小(尽管有些实现只提供这个大小)。您可以截断一个算法，但我建议您选择一个满足适当输出大小的算法。

如果您真的担心密码学的发展，您可以使用像多散列这样的格式来存储您的数据，然后，如果将来有必要，只需转换到一个新的函数。