MD5仍然足以唯一地识别文件吗?


139

考虑到MD5算法的所有突破和安全性问题等,MD5散列文件仍然被认为是一种足以唯一标识该文件的好方法吗?安全不是我主要关注的问题,而是唯一标识每个文件。

有什么想法吗?


2
实际上,我目前正在自己​​的一个应用程序中使用它,据我所知,它足以唯一地标识文件。
不可用

2
您可能会发现以下问题:stackoverflow.com/questions/862346/…有用。
sharptooth 2010年

您需要识别多少个文件?它输出128位,因此,如果您要尝试识别数千个文件,就可以了。但是,如果您要尝试做更多的事情,您可能会碰到碰撞/生日悖论。
Marcin 2010年

它们将是图像文件,jpg,png和gif。是的,我认为限制为几千...但是您大概认为有多少文件会给我带来麻烦?
Ranhiru Jude Cooray 2010年

Answers:


89

是。从安全角度来看,MD5已被完全破坏,但是意外碰撞的可能性仍然很小。只要确保文件不是由您不信任的人创建的,并且可能有恶意。


2
@none:关于第一个问题,请参见此处。恐怕我不明白其他问题。
Marcelo Cantos 2010年

9
@ 0xA3:您和我都不知道OP指的是什么文件,或者折衷会造成多大的损害。据我们所知,这可能是他们孩子的婴儿照片集。我的目标是提供事实;别人与他们做的是他们的生意。还应考虑Bruce Schneier 建议写下您的密码。并非所有东西都需要存放在诺克斯堡。有些东西在花盆下面会很好的。
Marcelo Cantos

3
@Marcelo Cantos,我认为这里缺少的是对“安全”一词的区分或分解。显然,人们对任何使用校验和的工作都承担着“安全性”,但是Marcelo的命名法可能意味着“在实验室中”。
hpavc

5
我非常不同意。不同的哈希值表明文件不同。但是对于相等的散列值:如果散列相同,则不能说“很有可能两者都相同”:您只能逐字节比较。哈希值比整个文件中不同值的数量小几个数量,因此每个哈希值有很多很多可能的冲突。只有在复制已知文件(带有已知哈希)的情况下,相同的哈希值才“可能意味着”第二个副本已正确复制(即使这样,也不能百分百确定,但很有可能)。
奥利维尔·杜拉克

3
好吧,我的数学糟透了。GUID的熵约为122位,因此十亿个文件中任何位置发生冲突的可能性约为2 ^(2 * 30-122)= 2 ^ -62。尽管这比我最初的计算要高得多,但仍然只有四分之一万亿分之一。
马塞洛·坎托斯

32

出于实践目的,创建的哈希可能适当地是随机的,但是由于Pigeonhole原理理论上总是存在发生冲突的可能性。拥有不同的哈希当然意味着文件是不同的,但是获得相同的哈希并不一定意味着文件是相同的。

为此,无论是否考虑安全性,使用哈希函数始终应始终只是检查的第一步,尤其是如果已知哈希算法很容易造成冲突的话。为了可靠地找出具有相同散列的两个文件是否不同,您必须逐字节比较这些文件。


16
@Ranhiru。否。哈希为您提供了一个“摘要”值(对于MD5)仅为16个字节长。为了确保文件相同,您需要逐字节检查。无论您选择哪种哈希算法,都是如此,总是有可能发生冲突。
PaulG 2010年

6
@Ranhiru。重读此答案,它是我这里最全面的答案。哈希可以用作第一步,这使您获得99.99 ^ e%的文件相同性的确定性,但是如果您要绝对地100%确定,则需要逐字节检查。无论您使用MD5,SHA还是任何其他算法,都是如此。
PaulG 2010年

7
这个答案是错误的。防止篡改和验证唯一性是同一回事。同样,虽然哈希不能保证唯一性,但实际比较也不能保证唯一性。实际上,由于正常的太阳伽马射线发射而导致的CPU故障,导致哈希偶然碰撞的可能性实际上比比较失败的可能性要低。并且不要忘记,文件的唯一来源通常位于Web服务器内部的另一端,而您具有比较目的的唯一独立信息就是哈希。
马塞洛·坎托斯

8
@马塞洛 它不站在逻辑推理意外碰撞是不太可能比偶然位翻转(同时进行逐字节比较字节)。构建散列时,位翻转的机会仍然相同(并且可以说是更多的,因为涉及更多的处理时间)。@Thomas最初提出的观点是,尽管位翻转的影响值得商de,但没有确定唯一性的保证方法。最悲观的估计是每GB /小时1次翻转,而ECC RAM甚至可以消除这种情况。
PaulG 2010年

2
“哈希偶然碰撞的可能性实际上比由于正常的太阳伽马射线发射引起的CPU故障而导致比较失败的可能性更低”(引证需要)
endolith

20

如果您没有对手,那么MD5就足够了。但是,某人可以(有目的地)创建两个不同的文件,这些文件散列为相同的值(称为冲突),根据您的具体情况,这可能是问题也可能不是问题。

由于知道已知的MD5弱点是否适用于给定的上下文是一个微妙的问题,因此建议不要使用MD5。使用抗碰撞的哈希函数(SHA-256或SHA-512)是安全的答案。同样,使用MD5不利于公共关系(如果您使用MD5,请准备好为自己辩护;而没有人会质疑您使用SHA-256)。


2
如果读者对哈希不太熟悉,那么这个答案可能会产生误导。SHA不能阻止哈希冲突,它具有更强大的抵抗哈希冲突攻击的能力。如果要确保文件相同,则要超过99.999 ^ e%,则仍然需要逐字节检查。
PaulG 2010年

7
实际上,由于宇宙射线将位翻转(例如,将a return 0;转换为a return 1;),因此字节之间的比较可能会失败。这是极不可能的,但与SHA-256发生碰撞的风险甚至更低。从数学上讲,您不能确保两个哈希值相同的文件是相同的,但是只要您使用计算机进行比较,就无法通过比较文件本身来确定这一点。我的意思是,超过99.999 .... 9%的确定性毫无意义,而SHA-256已经提供了更多的确定性。
Thomas Pornin 2010年

2
什么,您不使用ECC内存?;)。好评论,非常有趣的想法。
PaulG 2010年

1
不要忘记锡纸帽子!更严重的是,您如何知道这些有关碰撞的事实,并以某种方式进行了验证?
James P.

@ThomasPornin宇宙射线的位翻转也会影响MD5方法,因此情况更糟。
endolith

9

md5可能产生冲突。从理论上讲,尽管极不可能,但连续一百万个文件可以产生相同的哈希值。在存储值之前,请勿测试您的运气并检查md5冲突。

我个人喜欢创建随机字符串的md5,这样可以减少散列大文件的开销。当发现冲突时,我使用附加的循环计数器进行迭代并重新哈希。

您可以阅读信鸽原理


6

我不推荐它。如果该应用程序可以在多用户系统上运行,则可能会有用户使用两个具有相同md5哈希值的文件(他可能是工程师,并且正在使用此类文件,或者只是好奇-可以从http:/轻松下载它们/www2.mat.dtu.dk/people/S.Thomsen/wangmd5/samples.html,我自己在编写此答案时下载了两个样本。另一件事是,某些应用程序可能出于任何原因存储此类重复项(我不确定是否存在任何此类应用程序,但可能存在)。

如果您唯一地标识由程序生成的文件,则可以使用MD5。否则,我会建议任何其他尚无冲突的哈希函数。


2

我个人认为人们在真正想要拥有唯一标识符时,会过多地使用其他对象的原始校验和(选择您的方法)来充当唯一标识符。为此目的使用指纹并不是目的,并且与使用uuid或类似的完整性机制相比,可能需要更多的思考。


0

MD5已损坏,您可以改用SHA1(在大多数语言中实现)


这是一个很好的答案。从2018年5月开始,MD5对于欧洲法律和会计用例不可接受。
Bert Sinnema

@BertSinnema能否请我指出定义哪些哈希函数可接受的源代码等?
berezovskyi

@GregSchmit可能是因为OP本身并不关心加密强度。我将问题理解为“我已经在非安全环境中使用MD5,我是否需要花费时间来更新代码?” 之类的事情。在这种情况下,答案很可能是错误的,SHA1也从此被破坏了。
berezovskyi

0

当对短(小于K个)字符串(或文件)进行散列时,一个可以创建两个md5散列键,一个用于实际字符串,第二个用于与短非对称字符串连接的字符串的反向。示例:md5(反向(字符串||'1010'))。添加额外的字符串可确保即使由一系列相同的位组成的文件也会生成两个不同的密钥。请理解,即使在这种方案下,对于不相同的字符串,两个哈希键在理论上也是相同的,但是概率似乎非常小-大约是单个md5碰撞概率的平方,并且节省了时间文件数量不断增长时可能会非常可观。也可以考虑使用更复杂的方案来创建第二个字符串,

要检查冲突,可以针对db中所有bit_vector的md5哈希键的唯一性运行此测试:

从db中选择md5(bit_vector),count(*),bit_and(bit_vector)与bit_vector
按md5(bit_vector)组,具有bit_and(bit_vector)<> bit_vector的bit_vector


聪明的主意。如果“攻击者”使用相同的md5哈希值创建了一个伪文件,除非他知道您的“盐腌”,否则它将无济于事,并且反转内容将创建不同的哈希值。像这样使用2个md5键会大大降低赔率。如果只是为了防止在使用本地计算之前使用盐进行“攻击”就足够了。
Wolf5

0

我喜欢将MD5视为存储大量文件数据时可能性的指标。

如果哈希值相等,那么我就知道我必须逐字节比较文件,但是由于错误的原因,这种情况可能只会发生几次,否则(哈希值不相等)我可以确定我们正在谈论两个不同的文件。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.