正在使用消息摘要来验证消息是否是预期消息。
将哈希摘要与内容捆绑在一起以形成消息会增加对消息的冲突和前映像攻击的难度？
例如，要编码：
message = data . hash1(data)
message_hash = hash2(message)
使用message_hash验证邮件：
check(hash2(message) == message_hash)
data = message[:-digest_size]
check(hash1(data) == message[-digest_size:])
hash1和hash2可能是完全不同类型的哈希函数。
我的理由是，任何攻击都必须打破两个哈希函数 - 伪造外部摘要需要构造一个带有有效内部哈希的消息。
答案 0 :(得分：2)
如果外部哈希算法被破坏，内部哈希可能会有所帮助，但你必须考虑这种情况对于一个备受尊重的算法的可能性。
如果外部哈希是如此之小以至于蛮力攻击是可行的，那么内部哈希就不会有太多帮助。攻击者不必查找具有相同哈希值的消息，而是必须使用相同的外部哈希来查找带有内部哈希的消息，这几乎相同。
因此，尽可能使哈希值尽可能大，并集中精力确保系统其余部分没有后门。除非你期望政府或大公司有兴趣打破你的哈希值，否则64位可能就差不多了。
答案 1 :(得分：1)
您的提案让我想起了HMAC。如果您愿意，这种结构允许用户创建消息验证码，键控哈希值。
但是，我没有看到使用2个哈希函数的意义。选择一个迄今为止抵抗攻击的标准攻击并继续使用它。如果你认为其中一个会破碎，为什么一开始就使用它？ SHA-2或SHA3竞赛的任何最终候选人都应该没问题，如果你想要强大的安全性，可以在这里获得更多信息：http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo。
答案 2 :(得分：1)
在某些情况下，内部哈希可能使攻击者的任务更加困难，但不一定如此。例如，如果您对两个哈希函数都使用MD5，那么在给定MD5的迭代结构的情况下，内部哈希的冲突也意味着外部哈希的冲突。
因此，添加内部哈希函数不一定增加对碰撞和预图像的抵抗力。从纯理论的角度来看，它实际上可能减少阻力，虽然这是不太可能的，特别是如果哈希函数是安全的（但如果函数是安全的，那么构造是没有意义的）。在一个更实用的平面上，这种双重散列会增加计算工作量（更多的CPU，可能更大的代码 - 因此更多的L1缓存使用 - 如果两个函数不相同）。所以我的建议是不要这样做。相反，使用单个“相信安全”哈希函数，如SHA-256。哈希函数不会是你的应用程序中最大的弱点（或者更确切地说，如果哈希函数 是你应用程序中最大的弱点，那么你就是编程之神和/或{{3} }）。
作为示例，Donald Knuth同时使用MD5 和 SHA-1作为抵制两个函数中的任何一个的弱点的尝试。但较新的SSL/TLS版本仅切换到SHA-256。