【发布时间】:2011-06-08 06:57:11
【问题描述】:
我听说在创建哈希时,如果使用小文件或大量数据,则生成的哈希更有可能发生冲突。如果这是真的,是否应该使用最低“安全”数据量来确保不会发生这种情况?
我猜这个问题也可以表述为:
可以安全可靠地散列的最小数据量是多少?
【问题讨论】:
我听说在创建哈希时,如果使用小文件或大量数据,则生成的哈希更有可能发生冲突。如果这是真的,是否应该使用最低“安全”数据量来确保不会发生这种情况?
我猜这个问题也可以表述为:
可以安全可靠地散列的最小数据量是多少?
【问题讨论】:
他的哈希是 256 位长,任何超过 256 位的都存在冲突。
你不能在没有碰撞的情况下将某些东西压缩成更小的东西,这违背了数学原理。
是的,因为算法和 2 的 256 次方有很多不同的哈希值,但它们不是无冲突的,这是不可能的。
【讨论】:
没有最小输入大小。 SHA-256 算法实际上是一种随机映射,碰撞概率不依赖于输入长度。即使是 1 位输入也是“安全的”。
请注意,对于 SHA-256,输入被填充为 512 位(64 字节)的倍数(对于 SHA-512,是 1024 的倍数)。采用 12 字节输入(Thomas 在他的示例中使用),当使用 SHA-256 时,有 2^96 个可能的长度为 64 字节的序列。
例如,一个 12 字节的输入 Hello There! (0x48656c6c6f20546865726521) 将被填充一个位,然后是 351 个零位,然后是 64 位表示的输入长度位为 0x0000000000000060 以形成 512 位的填充消息。此 512 位消息用作计算哈希的输入。
更多细节可以在 RFC: 4634 "US Secure Hash Algorithms (SHA and HMAC-SHA)", http://www.ietf.org/rfc/rfc4634.txt
【讨论】:
哈希函数接受任意长度(或至少非常长)的输入,并产生固定长度的输出。可能的输入多于可能的输出,因此必然存在冲突。安全哈希函数的全部意义在于它是“抗冲突的”,这意味着虽然冲突必须在数学上存在,但实际计算一个非常非常困难。因此,没有已知的 SHA-256 和 SHA-512 冲突,并且最知名的计算方法(通过故意进行)非常昂贵,以至于它们不会很快应用(一个世纪的整个美国联邦预算只会购买到可笑的一小部分。
因此,如果不能故意现实地做到这一点,您可以期望不会因为(坏)运气而发生碰撞。
此外,如果您将自己限制为非常短的输入,则有可能根本不会发生冲突。例如,如果您考虑 12 字节输入:有 296 个可能的 12 字节序列。这是巨大的(超过今天的技术可以列举的)。然而,SHA-256 会将每个输入映射到一个 256 位的值,即更大空间中的值(大小为 2256)。我们无法正式证明它,但很可能所有这 296 个哈希值彼此不同。请注意,这没有实际后果:因为没有碰撞而没有发现碰撞与因为极不可能撞到碰撞而没有发现碰撞之间没有可测量的区别。
只是为了说明与 SHA-256 发生碰撞的风险有多低:考虑一下您被从当地动物园或私人所有者逃脱的大猩猩伤害的风险。不太可能?是的,但它仍然可能发生:似乎有一只大猩猩从Dallas zoo in 2004 中逃脱并打伤了四人;另一只大猩猩从same zoo in 2010 中逃脱。假设整个地球上每 6 年只有一只狂暴的大猩猩(不仅在达拉斯地区),而您恰好是 65 亿人口中走在他的道路上的不幸小伙子,那么您将面临严重的风险大猩猩对身体的伤害估计约为每天 243.7 中的 1 个。现在,使用 10 千 台 PC 并让它们为 SHA-256 寻找冲突。每天发生碰撞的可能性接近 275 分之一 - 比愤怒的猿类小十亿多。结论是,如果您担心 SHA-256 碰撞但没有始终随身携带上膛的霰弹枪,那么您的优先级就错了。另外,不要惹得克萨斯州。
【讨论】:
很大程度上取决于您的应用程序:如果您只是简单地散列“YES”和“NO”字符串以通过网络发送以指示您是否应该给我 100,000 美元的贷款,那将是一个很大的失败 - 域答案的数量不能那么大,因此有人可以很容易地根据“小输入”哈希输出的数据库检查网络上观察到的哈希值。
如果您要包括日期、时间、我的姓名、我的税号、请求的数量、被散列的数据量可能不会太多,但这些数据在预先计算的散列表中的可能性是很苗条。
但我知道没有任何研究可以指出你超出我的直觉。对不起。
【讨论】:
不,消息长度不会影响发生冲突的可能性。
如果是这样的话,算法就坏了。
您可以自己尝试对所有单字节输入运行 SHA,然后对所有双字节输入等等,看看是否会发生冲突。可能不会,因为没有人发现 SHA-256 或 SHA-512 的冲突(或者至少他们kept it a secret from Wikipedia)
【讨论】: