MD5散列文件是否仍然被认为是一种足够好的方法来唯一地识别它,因为 MD5算法的所有破坏和安全问题等等?在这里,安全性不是我主要关心的问题,但惟一地标识每个文件才是。
有什么想法吗?
是的。从安全的角度来看,MD5已经完全被破坏了,但是意外碰撞的可能性仍然微乎其微。只要确保这些文件不是由你不信任的人或者可能有恶意的人创建的。
MD5已经被破坏,您可以改用 SHA1(在大多数语言中实现)
我个人认为人们使用原始校验和(选择你的方法)的其他对象作为唯一的标识符太多时,他们真正想做的是有唯一的标识符。为这种使用指纹一个对象不是目的,可能需要比使用 uuid 或类似的完整性机制更多的思考。
出于实际目的,创建的散列可能是适当的随机的,但是由于 鸽巢原理,理论上是的总是存在碰撞的可能性。使用不同的散列当然意味着文件是不同的,但获得相同的散列并不一定意味着文件是相同的。
因此,为此目的使用哈希函数——无论安全性是否是一个问题——应该始终只是检查的第一步,特别是如果已知哈希算法容易产生冲突的话。要可靠地查明两个具有相同散列的文件是否不同,您必须逐字节地比较这些文件。
如果没有对手,MD5就足够好了。但是,有人可以(有目的地)创建两个不同的文件,这两个文件的散列值相同(这被称为冲突) ,这可能是一个问题,也可能不是一个问题,这取决于您的确切情况。
因为知道已知的 MD5弱点是否适用于给定的上下文是一个微妙的问题,所以建议不要使用 MD5。使用抗碰撞散列函数(SHA-256或 SHA-512)是安全的答案。此外,使用 MD5是不好的公共关系(如果您使用 MD5,请准备好证明自己的合理性; 而没有人会质疑您使用 SHA-256)。
Md5可以产生碰撞。从理论上讲,尽管不太可能,但一行中的一百万个文件可以产生相同的哈希值。在存储值之前,不要测试您的运气并检查 md5冲突。
我个人喜欢创建随机字符串的 md5,这减少了散列大文件的开销。当发现冲突时,我使用附加的循环计数器迭代和重新散列。
你可以在 鸽巢原理上阅读。
我不建议这么做。如果应用程序可以在多用户系统上运行,可能会有用户,这将有两个具有相同 md5散列的文件(他可能是工程师,玩这样的文件,或只是好奇-他们很容易从 http://www2.mat.dtu.dk/people/S.Thomsen/wangmd5/samples.html下载,我自己在写这个答案下载了两个样本)。另一个问题是,有些应用程序可能出于某种原因存储这样的副本(我不确定是否存在这样的应用程序,但存在这种可能性)。
如果您是唯一标识由您的程序生成的文件,我会说可以使用 MD5。否则,我将推荐任何其他尚未知道冲突的散列函数。
当散列短时(< 几个 K?)字符串(或文件)一个可以创建两个 md5散列键,一个用于实际的字符串,另一个用于与短的非对称字符串连接的字符串的反面。示例: md5(return (string | |’1010’))。添加额外的字符串可以确保即使是由一系列相同位组成的文件也会生成两个不同的键。请理解,即使在这种方案下,有一个理论上的机会,两个哈希键是相同的非相同的字符串,但概率似乎非常小-在单一的 md5碰撞概率的平方的顺序,节省的时间可以是相当可观的,当文件的数量增长。也可以考虑创建第二个字符串的更详细的方案,但我不确定这些方案是否会大大提高成功的几率。
为了检查冲突,可以运行这个测试来检查 db 中所有 bit _ Vector 的 md5哈希键的唯一性:
选择 md5(bit _ Vector)、 count (*)、 bit _ and (bit _ Vector) 带位向量的数据库 按 md5(bit _ Vector) ,bit _ Vector 分组 具有 bit _ and (bit _ Vector) < > bit _ Vector
我喜欢将 MD5视为存储大量文件数据时的一个概率指标。
如果哈希值相等,那么我就知道我必须一个字节一个字节地比较文件,但这种情况可能只会出现几次,否则(哈希值是不相等的)我可以肯定我们谈论的是两个不同的文件。