|
|
6 回复 | 直到 7 年前
|
1
28
2 26.5 操作(其中一个“操作”是通过短消息计算MD5)。看到了吗 this page 关于攻击的一些细节和实现(我写的代码;它在2.4 GHz Core2 x86(64位模式)上平均14秒内发现冲突。 同样,最著名的对沙一号的攻击发生在 61 操作,而不是 . 它仍然是理论上的(还没有产生实际的碰撞),但它是在可行的范围内。 至于对安全性的影响:散列函数通常有三个属性:
n 2 n 前两个属性的操作,以及 2 然而,并非所有哈希函数的用法都依赖于这三个属性。例如,数字签名首先对要签名的数据进行散列,然后在算法的其余部分使用散列值。这依赖于对前映像和第二前映像的抵抗,但数字签名本身不受冲突的影响。在某些特定的签名方案中,冲突可能是一个问题,攻击者可以选择要由受害者签名的数据(基本上,攻击者计算冲突,一条消息由受害者签名,签名也对另一条消息有效)。这可以通过在计算签名(攻击和解决方案,在X.509证书的上下文中演示)之前为签名消息预先添加一些随机字节来抵消。 HMAC安全依赖于 (PRF)。关于什么是PRF的细节是相当技术性的,但是,粗略地说,PRF应该和PRF没有区别 . 一个随机的先知被模拟成一个黑盒子,里面有一个侏儒,一些骰子和一本大书。在一些输入数据上,gnome选择一个随机输出(用骰子),并在书中写下输入消息和随机选择的输出。gnome使用这本书来检查他是否已经看到了相同的输入消息:如果看到了,那么gnome将返回与以前相同的输出。通过构造,在尝试之前,您对给定消息上随机预言的输出一无所知。 随机预言模型允许在调用PRF时量化HMAC安全性证明。基本上,证明表明HMAC不能在没有大量调用PRF的情况下被破坏,我所说的“巨大”是指在计算上不可行。 不幸的是,我们没有随机预言,所以在实践中我们必须使用哈希函数。没有证据证明散列函数真的存在,具有PRF属性;现在,我们只有候选函数,也就是我们还不能证明它们的压缩函数不是PRF的函数。 如果 压缩函数是一个PRF 然后 哈希函数自动抵抗冲突。这就是PRF的魔力之一。 ,如果我们能找到散列函数的冲突,那么我们就知道内部压缩函数不是PRF。这不会将碰撞转化为对HMAC的攻击。能够随意产生碰撞无助于破坏HMAC。但是,这些冲突表明与HMAC相关的安全证明不适用。担保无效。这和笔记本电脑是一样的:打开箱子不一定会把机器弄坏,但之后你就得靠自己了。 Kim-Biryukov-Preneel-Hong 文章介绍了针对HMAC的一些攻击,特别是针对HMAC-MD4的伪造攻击。攻击利用了MD4的缺点(它的“弱点”),使它成为非PRF。相同弱点的变体被用来在MD4上产生碰撞(MD4被彻底破坏;有些攻击产生的冲突比哈希函数本身的计算速度还要快!)。因此,碰撞并不意味着HMAC攻击,但两种攻击都来自同一个来源。不过,请注意,伪造攻击已经付出了代价 2 58 ,这是相当高的(没有产生实际的伪造,结果仍然是理论上的),但大大低于预期的抵抗水平从HMAC(与一个强大的哈希函数与一个 -位输出,HMAC应抵抗高达 2 n n=128个 对于MD4)。 本身 暗示HMAC的弱点,这是坏消息。实际上,碰撞对于很少的设置是一个问题。但是知道冲突是否会影响哈希函数的给定用法已经足够棘手了,继续使用已经演示了冲突的哈希函数是非常不明智的。
关于这个主题的更多信息,从阅读本书的第9章开始 Handbook of Applied Cryptography |
|
|
2
4
只有在冲突的后果是无害的或微不足道的情况下(例如,将文件分配给文件系统上的bucket时),才可以安全地使用损坏的哈希函数。 |
|
3
2
当你不在乎它是否安全的时候。 说真的,在几乎每种语言中使用安全哈希函数都不需要任何额外的努力,而且对性能的影响可以忽略不计,所以我不明白为什么不这样做。 [实际阅读问题后编辑] 实际上,这基本上是因为能够为哈希生成冲突并不一定能帮助您为哈希生成冲突 hash-of-a-hash (与HMACs使用的XORing结合使用)。
不,如果散列有
preimage attack
它允许您将数据预先添加到输入中。例如,如果哈希是
|
|
|
4
2
对于一个坏的散列,1更容易一些。但是确保冲突同时满足文件的其他已知属性在计算上过于昂贵。
|
|
|
5
0
答案完全取决于你用它做什么。如果你需要在几毫秒内阻止某人产生碰撞,我会比你需要在几十年内阻止某人产生碰撞更担心。
|
|
|
6
0
对于使用MD4之类的东西作为密码,大多数担心与当前已知的攻击无关,而与这样一个事实有关:一旦分析到很容易产生冲突,一般认为,有人能够利用这些知识来创建前映像攻击的可能性要大得多,而且当/如果发生这种情况,基本上所有可能使用该哈希函数的方法都会变得脆弱。 |
推荐文章