流行的加密哈希函数不应该编码输出中输入数据的长度吗？

Question

EDIT2:这个讨论被简化为“当您添加长度约束时，冲突实际上更难创建吗？”这与密码交换更相关。我将在那里创建一个问题，并在它存在时将其链接起来。感谢参加讨论的每一个人

编辑:维基百科中的“碰撞攻击”一词似乎只提到发现任何随机碰撞，我想说的是“图像前攻击”。

这在我看来是个好主意，因为它可以防止所有需要攻击者修改数据长度的碰撞攻击。攻击者必须找到完全相同长度的碰撞，这显然比找到一般碰撞要困难得多。

碰撞攻击通常要求攻击者修改数据的长度(通过向现有数据添加更多块或诸如此类的内容)，不是吗？

我看到的唯一缺点是，它将需要更长的哈希结果(我认为它只需要2-4字节，即“数据模2^16-2^32的长度”应该足够长)，所以没有太多。

当然，这不一定是散列函数本身的一部分，它可能只是一个一般的安全建议：“验证数据的预期长度，而不仅仅是它与计算的哈希匹配，以防止多种形式的碰撞攻击”。

虽然我以前从未听说过这个建议，尽管我认为它很有意义。

所以，总的来说，我在这里问:为什么这不是一个好主意？应该将其编码为散列函数，以便由使用这些函数的任何人自动应用，还是应该由哈希函数的用户独立于散列函数单独实现的一般安全建议？

或者是我完全错过了什么东西让这个想法变得荒谬？

Answer 1

您缺少了另一个缺点:它告诉攻击者明文的长度。

在某些情况下，这被认为是敏感信息。例如，如果我强行使用密码，您是在告诉我，除了指定长度的密码之外，我可以跳过所有密码的尝试。很好，谢谢。

碰撞攻击通常要求攻击者修改数据的长度(通过向现有数据添加更多块或诸如此类的内容)，不是吗？

我相信你在描述一个长度扩展攻击。真正的密码师可能会因为我这么说而责备我，但我天真地有一个在散列之前填充按摩的解决方案(此时您可以放弃整个长度的编码，只使用传统的散列函数)：_(真的，不要在此基础上构建软件，我不能保证它是安全的)。

hash( 0*(256 - (len(msg)%256) ) || msg)

然后，当攻击者试图通过将msg2连接到最后执行长度扩展攻击时：

hash( 0*(256 - (len(msg||msg2)%256) ) || msg||msg2)

他们将有不同数量的填充0's，这改变了按摩前缀，并完全打破了长度延伸攻击。

(我越想这件事，我就越不想支持这个想法。我应该花点时间搜索“长度扩展攻击缓解”，而不是坐在这里推测)。

Answer 2

加密散列函数的设计是为了对输出进行较大的更改，即使是对输出的小更改。通过添加一些描述输入长度的字节，您可以更改这个假设，因为这些长度位只会在对输入的小更改上对输出产生小的更改。

除此之外，正如奥恩斯沃思已经指出的那样，您实际上泄漏了有关输入的重要信息。实际上，您不仅要告诉攻击者输入的时间长短，而且还要告诉攻击者肯定有那么长的值，这就导致了这个哈希。这大大减少了攻击者为了获得相同的哈希结果而不得不使用的空间--在密码的情况下，这是唯一需要的，因为不需要串通。

但是，即使在您关心预图像的情况下，也不清楚您为编码长度而添加的比特在扩展散列本身的强度以避免预图像攻击方面是否更有用。虽然在输入必须比散列本身短，因此不太可能的情况下，它可能会有所帮助，但我认为这些比特更适合用于更长的真实哈希，以防输入比哈希输出更长，因为相同长度的预图像那时更有可能。

攻击者必须找到完全相同长度的碰撞，这显然比找到一般碰撞要困难得多。

有那么明显的困难吗？我同意，如果输入比散列更短，那就更困难了，因为这是一个寻找如此小大小的预图像的问题。但是，如果输入比哈希大得多(例如，与证书一样)，我怀疑要求特定长度确实会增加查找预图像的复杂性，除非哈希结构存在一些固有的弱点。