两个文件的相同加密哈希或校验和是否表示它们相同?


57

我有2个excel文档,除了文件名之外,我想检查它们是否完全相同。

例如,文件称为fileone.xlsfiletwo.xls。除了文件名,它们的内容被假定为相同,但这是我要检查的内容。

我一直在寻找方法来审查此问题,而无需安装大量插件。似乎没有直接的方法。

我试过为两个文件生成MD5哈希值。如果哈希值相同,是否意味着文件内容是1:1相同?


8
对于比较不同系统上的文件或在大量文件中进行搜索,加密散列(有时甚至是普通散列)可能非常有用,但是如果两个文件位于同一系统上,则可以轻松地将它们与cmpUnix上的fc文件比较或Windows上的(文件比较)进行比较。
dave_thompson_085 '18

10
shattered.io -SHA1是比md5更为“强大”的哈希算法,并且仍然被shattered.io/static/shattered-1.pdfshattered.io/static/shattered-2.pdf具有相同的哈希值,但完全不同。
发泡胶飞

30
旁注:请先检查其尺寸。如果它们的大小不同,请不要打扰打开文件,因为它们是不同的。
Emilio M Bumachar

42
简化版本:MD5哈希足以防止意外,它不足以防止再次恶意。这是否对您足够好,您必须根据自己的情况决定。
欧洲米切利'18

9
diff -s file1 file2如果它说它们是相同的,则它们是相同的(实际上是逐字节比较文件,因此甚至排除了哈希冲突)。当您只有一个散列并且被认为与该散列的创建者相同时,将使用校验和。
巴库里

Answers:


93

如果哈希值相同,是否意味着文件内容是1:1相同?

所有文件都是字节的集合(值0-255)。如果两个文件的MD5哈希值匹配,则这两个字节集合极有可能完全相同(相同顺序,相同值)。

两个文件可以生成相同的MD5(128位哈希)的可能性很小。概率为:

只有两个散列意外碰撞的概率为1/2 128为1在340 undecillion 282 decillion 366 nonillion 920千的十六次方938 septillion 463 sextillion 463三次方374万亿6070000亿431十亿7.68亿211000 456(从上一个答案的StackOverflow。)

散列只能在“一个方向”上工作-即,您获取了一个字节的集合并获得了一个哈希,但是您无法获得一个哈希值并取回了一个字节的集合。

密码学依赖于此(这是可以在不知道这些东西是什么的情况下比较两件事的一种方法。)

在2005年左右,人们发现了采用MD5哈希并创建与该哈希匹配的数据的方法,从而创建了两个具有相同MD5哈希的文档(碰撞攻击)。 请参阅下面的@ user2357112的注释。这意味着攻击者可以创建两个具有相同MD5的可执行文件,例如,如果您依靠MD5来确定信任哪个可执行文件,那么您将被愚弄。

因此,不应将MD​​5用于加密或安全性。例如,在下载站点上发布MD5以确保下载完整性是很不好的。根据MD5哈希,您不会生成自己来验证文件或数据内容是否要避免。

如果您生成自己的,那您就知道自己并没有恶意(希望如此)。因此,您可以使用它,但是如果您希望其他人能够复制它,并且您想公开发布MD5哈希,则应该使用更好的哈希。


请注意,两个Excel文件可能在相同的行和列中包含相同的值,但是由于格式,样式,设置等不同,文件的字节流也可能完全不同。

如果要比较文件中的数据,请先将其导出到具有相同行和列的CSV格式,以去除所有格式,然后哈希或比较CSV格式。


107
Excel文件和其他Office文档也可以具有不同的哈希值,因为它们已被打开并重新保存而不进行任何更改,这是由于文件中的元数据在上次保存的日期时间存储有新值。
BeowulfNode42 '18年

29
奖励:如果您已导出到CSV,则可以使用古老的diff工具或类似的实用工具来实际确认文件的字节对字节相同,而不仅仅是具有相同的哈希。
蒙蒂·哈德

18
获取哈希并创建与哈希匹配的数据是前映像攻击。我相信MD5当前容易受到碰撞攻击,但是我认为当前无法使用原像或第二原像攻击。
user2357112 '18年

2
@蒂姆,你在说什么?他说:将它们导出到CSV并用于diff -s检查CSV是否相同。实际上,您diff -s甚至可以使用excel文件:如果diff说它们是相同的,则无需进行CSV比较。
巴库里

2
@Bakuriu显然,我的评论措词很差-我的意思是,导出为CSV会丢失很多信息-特别是公式,图表,条件和标准格式。
蒂姆(Tim)

37

是的,实际上,只要不是由攻击者或其他恶意实体制作的文件,相同的加密哈希就意味着文件相同。任何精心设计的密码散列函数发生随机碰撞的几率很小,因此在实践中和在没有主动攻击者的情况下,可以忽略不计。

但是,总的来说,不能,我们不能说两个具有相同哈希值的任意文件绝对意味着它们是相同的。

密码哈希函数的工作方式是采用任意长度的输入,并输出根据输入计算出的固定长度的值。一些哈希函数具有多个输出长度可供选择,但是输出在某种程度上仍是固定长度的值。该值的长度最多为几十个字节。如今,通常使用的具有最大输出值的哈希算法具有512位输出,而512位输出为64字节。

如果哈希函数的输入长于哈希函数的输出,则必须删除某些保真度以使输入适合输出。因此,必须存在多个长度大于输出长度的输入,它们会生成相同的输出。

让我们以当前的主力机SHA-256为例。它输出256位或32个字节的哈希。如果您有两个文件,每个文件的长度正好为32个字节,但不同,则无论文件内容如何,​​这些文件都应(假定算法无缺陷)散列为不同的值。用数学术语来说,散列是将2 256个输入空间映射到2 256个输出空间的函数,应该可以做到无冲突。但是,如果有两个文件,每个文件的长度为33个字节,则必须存在某种输入组合,两个文件的输入散列值必须相同,因为我们现在将2 264个输入空间映射到2 256个输出空间;在这里,我们可以很容易地看到,每个平均输出应该平均存在2 8个输入。更进一步,对于64字节文件,每个单个输出应该存在2 256个输入!

密码散列函数的设计使得在计算上很难组合提供特定输出的输入,或组合两个提供相同输出的输入。这就是所谓的原根攻击碰撞攻击。找到这些碰撞并非不可能;它只是打算变得非常,非常,非常,非常困难。(碰撞攻击的一种特殊情况是生日攻击。)

有些算法在抵抗攻击者方面比其他算法更好。这些天一般认为MD5完全坏掉了,但是我最后看,它仍然具有相当不错的初像抵抗力。SHA-1同样有效地被破坏;尽管没有理由相信无限期地会发生这种情况,但已经证明了原像攻击,但是需要特定的条件。俗话说,攻击总会变得更好,却永远不会变得更糟。目前仍认为SHA-256 / 384/512对于大多数目的是安全的。但是,如果您只是想看看两个非恶意制作的,有效的文件是相同的,那么这些文件中的任何一个都应该足够了,因为输入空间已经受到足够的限制,您将对随机碰撞最感兴趣。如果您有任何理由认为文件是恶意制作的,则至少需要使用当前被认为是安全的加密哈希函数,这会将下限设置为SHA-256。

第一个原像是找到产生特定输出哈希值的输入;第二个原像是找到一个输入,该输入与另一个指定的输入具有相同的输出;冲突是找到两个产生相同输出的输入,而不考虑输出是什么,有时不考虑输入是什么。

综上所述,重要的是要记住,文件可能具有完全不同的数据表示形式并且仍然显示完全相同的数据。因此,他们可能看起来是一样,即使他们的密码散列不匹配,但是如果哈希匹配,那么他们极有可能出现相同的。


2
如果哈希值匹配,则文件要么是有意冲突的结果,要么不是,则可以保证它们是相同的。偶然碰撞的可能性纯粹是理论上的。说“如果哈希匹配,那么它们很有可能看起来一样”是一种误导:如果有恶意,并且是碰撞情况,则它们不可能相同,否则概率实际上为零,这是不可能的。不需要防御的一些低概率事件。
吉尔斯

9
@吉尔斯:相反。迈克尔的措辞是完全正确的,“保证”是误导性的(或者,事实上是错误的)。具有相同散列的两个文件不匹配(尽管进行了恶意修改)的可能性极低,在实践中可以忽略。但是,它不为零。通常有一种机会,无论出于何种原因,不同的输入都将产生相同的哈希,甚至可能比2 ^ -128高得多(加密算法是一种黑手艺,算法可能会以一种微妙的,未知的方式存在缺陷,并且我们无法百分百确定)。
达蒙(Damon)'18年

5
@Gilles“ 有效零 ”仍然不为零,这意味着两组不同的数据将导致相同的哈希值仍然存在(一定很小的)概率。你不能反对。
阿蒂

5
@Attie:两个不相关的文件散列为相同值的概率远远低于许多其他可能出错的概率(例如,随机位错误破坏了磁盘上的文件),因此不值得防止巧合。防范精心设计的比赛可能是值得的,但意外比赛是如此不可能,以至于为防范比赛而付出的任何努力都可能会花在其他地方。
超级猫

3
@吉尔斯错了。您不能一口气告诉我,有机会(无论您的评分多么小)可能会发生意外碰撞,然后在下一个受让人中不会发生碰撞。这种说法极具误导性,因为它暗示着哈希算法的一种特性,该特性已经众所周知是完全错误的。
iheanyi

10

这是一个概率游戏……散列能够表示有限数量的值。

如果我们考虑一种假设的(且非常弱)的8位哈希算法,那么它可以表示256个不同的值。当您开始通过算法运行文件时,您将开始散列出来……但是不久之后,您将开始看到“ 哈希冲突 ”。这意味着将两个不同的文件输入到算法中,并且产生的哈希值与其输出相同。显然,这里的哈希值不够强,我们不能断言“ 具有匹配哈希值的文件具有相同的内容 ”。

扩展散列的大小并使用更强大的加密散列算法可以显着帮助减少冲突,并提高我们对具有相同散列的两个文件具有相同内容的信心。

这就是说,我们永远不可能达到100%的确定性-我们永远不能确定具有相同哈希值的两个文件确实具有相同的内容。

在大多数/许多情况下,这很好,并且比较散列值“ 足够好 ”,但这取决于您的威胁模型。

最终,如果您需要提高确定性级别,那么我建议您执行以下操作:

  1. 使用强大的哈希算法(如果您需要防范潜在的恶意用户,则不再认为MD5足够了)
  2. 使用多种哈希算法
  3. 比较文件的大小-一个额外的数据点可以帮助识别潜在的冲突,但是请注意,演示的MD5冲突不需要更改数据的长度。

如果您需要100%确定,则一定要从哈希开始,但如果哈希匹配,请对两个文件进行逐字节比较。


此外,正如其他人指出的那样,由Word和Excel等应用程序生成的文档的复杂性意味着文本,数字和可见布局可以相同,但是文件中存储的数据可以不同。

Excel在这方面尤其不利-只需打开一个电子表格进行保存(不做任何操作)就可以生成具有不同内容的新文件。


6
不再认为MD5在加密上是非常正确的,但对于唯一性检查(在没有恶意的情况下,例如,如果您控制输入),它又好又快(128位应该足够)
Chris H

4
接下来是两个文件的逐字节比较。 ”如果要进行文件比较,则最好先进行操作...读取所有文件以计算它们的所有内容毫无意义哈希只能重新读取两个文件以进行比较!
TripeHound

3
@TripeHound这取决于文件是否都是本地文件...您是否已经有一个哈希值并正在向系统引入一个新文件,如果新文件仍然需要存储在数据库中的哈希值,等等...拨打适合您情况的电话。
阿提

5
不,这不是概率游戏。您误估计了意外碰撞的可能性。只是不会发生。比较期间略微翻转的可能性更大。另一方面,在某些情况下,可能会发生故意的碰撞,而这根本不是概率游戏。
吉尔斯

3
@mbrig:32位哈希将有很大的意外失配风险。但是,转到128或256位会产生很大的差异。有了128位,十亿只猴子每只键入十亿个大小合适的真正随机文档,就有大约0.3%的机会创建两个具有相同哈希值的文档。如果使用256位,即使数十亿只猴子可以在十亿年中每秒键入十亿个体面大小的随机文档,那么这些非十亿个文档中任何一个具有哈希值一致匹配的可能性都将很小。
超级猫

6

如果两个文件具有相同的MD5哈希,并且它们不是都经过特殊设计,则它们是相同的。制作具有相同MD5哈希值的文件有多难,取决于文件格式,我不知道使用Excel文件有多么容易。

因此,如果您自己的文件随处可见并且想要查找重复文件,则MD5是安全的。如果您编写了其中一个文件,而另一个文件是可疑的,则MD5仍然是安全的(使用相同的MD5校验和获取不同文件的唯一方法是同时制作两个文件)。如果您不信任的人向您发送了预算提案,然后又发送了他们声称相同的另一个文件,则MD5可能不够。

为避免任何风险,请使用SHA-256或SHA-512代替MD5。如果两个文件具有相同的SHA-256哈希,则它们是相同的。SHA-512也是如此。(从理论上讲,它们可能会有所不同,但这种偶然发生的可能性远小于您的计算机在验证过程中发生一点翻转的可能性,而这与其无关紧要。至于有人故意制作带有两个文件的文件,相同的哈希,没人知道如何对SHA-256或SHA-512执行此操作。)

如果两个Excel文件具有不同的哈希值,则它们是不同的,但是无法知道它们之间有多少不同。它们可能具有相同的数据,但格式不同,或者它们的属性可能不同,或者它们可能已由不同的版本保存。实际上,如果Excel类似于Word,则仅保存文件即可更新其元数据。如果只想比较数字和文本数据,而忽略格式和属性,则可以将电子表格导出为CSV进行比较。

如果您有可用的Unix / Linux工具,则可以cmp用来比较两个文件。要在同一台计算机上比较两个文件,校验和只会使事情变得更复杂。


如果两个文件具有相同的MD5哈希值,并且都没有经过特殊设计,则它们是相同的。那是不对的。可能的消息是无限的,但是只有2 ^ 64个可能的64位哈希。这就是所谓的“鸽子洞原理”:“鸽子洞原理规定,如果使用将n物品放入m容器中n > m,则至少一个容器必须包含一个以上的物品。” 如果创建的消息多于2 ^ 64条,则将发生冲突,而无需进行任何“特殊设计”。而你可能只用2
安德鲁汉勒

@ AndrewHenle,MD5不是64位,而是128。如果发生意外碰撞使我们陷入了宇宙热死的时标,那么它仅对于极其学术性的定义(因此无用)是“可能的”。
查尔斯·达菲

@CharlesDuffy您假设哈希是随机分布的。不是。
安德鲁·亨利

有效等同于随机分布是构成良好加密哈希的定义的一部分-由于某种原因,您需要进行很多轮混合。当然,散列算法很弱,但是关注这些弱点会使我们陷入先前针对故意攻击的警告。(或者您是说MD5仅显示了有效随机的64位?我承认我一直没有跟上,所以这很合理-请链接吗?)
Charles Duffy

@AndrewHenle我没有声明碰撞在数学上是不可能的,这是错误的,但在这里不相关。我说这没有发生,这是事实。您的评论不正确,从而完全改变了交易。有2 ^ 128个可能的MD5哈希,而不是2 ^ 64。这意味着您将需要生成2 ^ 128个哈希值才能确定会产生冲突。实际上,根据生日悖论,2 ^ 64会给您宏观的机会,使您生成的哈希值发生冲突(而不是先前生成的哈希值)。但这是没有意义的,因为我们知道如何进行碰撞。
吉尔斯

6

简短的回答:一个加密散列是应该帮助你有理由相信,随着配套文件的哈希值是相同的。除非经过精心设计,否则两个略有不同的文件具有相似的哈希值的可能性非常小。但是,在比较和验证可能被人为篡改的文件时,MD5并不是一个好选择。(使用另一个哈希函数,例如SHA3或BLAKE2。)

长答案:理想的哈希函数是为每个唯一数据创建几乎唯一的加密哈希的函数。换句话说,我们绝对知道,在这个Universe中有两个文件的哈希值发生冲突,这两个文件自然地在一起的机会非常小。

十年前,我决定我必须与MD5保持距离。(当然,直到昨天,我还记得这样做的错误原因;您知道十年是很长的时间。我回顾了过去的备忘录以记住原因,并编辑了这个答案。)您看到,1996年,发现MD5容易受到碰撞攻击。9年后,研究人员能够创建具有相同哈希值的成对PostScript文档和X.509证书!MD5明显损坏。(Megaupload.com也在使用MD5,并且在哈希冲突周围出现了很多麻烦,这在当时给了我麻烦。)

因此,我得出结论,尽管MD5在比较良性文件上是(而且仍然是)可靠的,但是必须完全停止使用它。我认为,依赖它会带来放纵和错误信心的风险:一旦开始使用其MD5哈希值比较文件,则有一天您会忘记安全性规定,然后比较两个经过精心设计以具有相同哈希值的文件。另外,CPU和加密处理器不太可能添加对此的支持。

但是,原始海报使用MD5的理由更少,原因是:

  1. 只要一个人仅比较两个文件,逐字节比较实际上比生成自己的MD5散列要快。为了比较三个或更多文件...好吧,现在您有一个合理的原因。
  2. OP指定“无需重新安装插件即可进行审查的方式”。Windows PowerShell的Get-FileHash命令可以生成SHA1,SHA256,SHA384,SHA512和MD5哈希。在具有对SHA哈希功能的硬件支持的现代计算机上,生成它们的速度更快。

6
您可以创建自己的任意长度的加密哈希函数,即true;但随后它具有固定的长度,无论如何也采用信鸽原理。普遍的答案是:“仅比较它们的哈希,就不能确定两个文件是否相同”。
卡米尔Maciorowski

2
@KamilMaciorowski从理论上讲,是的,我可以。我的定制哈希函数可以简单地生成最大文件的副本。但是我没有兴趣进一步讨论这个问题。事实是,您之所以拒绝投票,是出于挑剔的目的,只是为了证明您更聪明,并且事与愿违。现在,您无法重新投票。

我同意@KamilMaciorowski ...这是一个概率游戏...使用单个哈希,您可以“ 相当有信心 ”确保具有匹配哈希值的文件相同,但是并不能保证100%。使用更好的算法或使用多种算法可以提高您的信心-即使比较文件大小也可以帮助您...但是,如果不逐字节检查,您永远不会100%充满信心。
阿蒂

1
@Attie Huh!那就是我的原意。谢谢。🙏只有我不熟悉别致的短语,例如“您可以相当自信”。抱歉。😜尽管如此,这就是我们拥有编辑按钮的原因。我个人绝不会因为一个单词是错误的而浪费一个好的答案。我编辑它。

1
关于“破坏一个好的答案”:请注意,我首先确保这不是一个错字,而你确实是真的。然后投票,同时我给了您反馈,透露了我的理由,希望您的回答会更好。做到了,所以我不再投票了。基本上,我告诉过您我认为您的答案有什么问题,阿蒂帮助您弄清楚了,您改进了答案。从我的角度来看,我们所有人都妥善处理了这种情况,整个故事进展得非常顺利。谢谢。
卡米尔Maciorowski

5

我有2个excel文档,除了文件名之外,我想检查它们是否完全相同。

从实际的角度来看,直接比较文件以找出它们是否不同将比为每个文件计算一个哈希然后比较该哈希更快。

要计算散列,您必须阅读两个文件的全部内容。

要通过直接比较确定它们是否相同,您只需要读取两个文件的内容,直到它们不匹配为止。一旦发现差异,就知道文件不相同,也不必从任何一个文件读取更多数据。

在执行任何一项操作之前,您可以简单地比较两个文件的大小。如果大小不同,则内容不能相同。


在一个物理驱动器上使用两个文件时,使用散列函数可以分别保持每个文件的I / O速度可能比比较文件稍快一些,因为无需在读取两个文件之间进行切换。但是,在尝试进行涉及许多太大而无法容纳内存的文件的比较时,散列的真正亮点是。即使您只是想找出它们是否都匹配,将文件1与文件2进行比较,然后将文件1与文件3进行比较,然后将文件1与文件4进行比较,等等,其速度几乎是计算所有哈希值的两倍。
超级猫

@supercat如果读取文件的大小大于MB左右,则文件之间的切换不会引起注意。而且,如果工作流程涉及比较一堆文件以查找重复项,那么散列也可以在写入每个文件时进行计算-因为这样做实际上可以免费完成。
安德鲁·亨利

如果一个人有足够的空间来缓冲大块文件,则切换时间不必成问题,否则就可以了。至于在写入文件时计算哈希值,如果可以保证在不更改或至少使存储的哈希值无效的情况下不能修改文件,那可能会很好。如果试图避免冗余备份文件,则仅查看存储的哈希值可能会导致备份意外损坏的文件,而不会备份那些损坏的文件匹配但匹配的损坏的文件。
超级猫

“一旦发现差异,就知道文件不相同”-不一定。XLSX文件是ZIP文件,可以潜在地以相同的内容存储不同的内容。但是,即使您解压缩它们并比较每个单独的文件,XLSX文件也包含XML文档,这些XML文档可能具有例如不同的行尾而不影响内容。
托马斯·韦勒

5

诸如MD5或SHA之类的哈希具有固定长度,可以说是300个字母数字字符(实际上,它们较短,并且不使用整个字母数字字符集)。

可以说文件由字母数字字符组成,最大大小为2GB。

您可以轻松地看到,存在比可能的哈希值更多的文件(最大2GB)。信鸽原理说,某些(不同)文件必须具有相同的哈希值。

另外,如shattered.io 1所示,您可以拥有两个不同的文件:shattered.io/static/shattered-1.pdf和shattered.io/static/shattered-2.pdf,它们具有相同的SHA-1哈希值完全不同。

1 SHA1比md5是“更强”的哈希算法


意外碰撞的可能性太低,无法考虑。MD5也存在故意碰撞的风险,并且比SHA-1更为严重,而SHA-1此处并不十分相关。
吉尔斯

4

没有。不同的值可确保文件不同。相同的值不能保证文件相同。使用CRC16查找示例相对容易。

在概率与现代哈希方案的平衡上,它们是相同的。


1
问题是关于MD5,它没有意外碰撞的风险。确实有发生故意碰撞的风险,但这不是概率问题。
吉尔斯

1
这也与具有不同名称的excel电子表格有关,不能选择用于字节比较的字节有多大?两种哈希方案一起将提供确定性。
mckenzm

2
@Gilles 根据定义,所有哈希码都有发生意外冲突的风险。唯一的解决方法是将整个文件用作哈希码。您的评论没有任何意义。
user207421

3

不过,您的问题是倒退的-假设哈希意味着它们具有相同的数据(虽然不能100%保证,但足以在一生中每秒比较文件而不会发生冲突)。不一定具有相同的数据意味着它们将具有相同的哈希值。因此,没有-你不能将数据通过,因为有一个散列的文件进行比较的Excel与另一个文件中的数据excel文件很多的这两个文件可以在没有基础数据是不同的不同的方式。一种明显的方式-数据存储为XML,每个单元都有自己的XML节点。如果这些节点以不同顺序存储,则数据相同,但文件不同。



2

已经给出了此操作的答案,但可能会从摘要中受益。

如果要检查两个文件是否相同,则很大程度上取决于文件和哈希是否在您的控制之下。

如果您从文件中自己生成哈希,并且可以肯定没有其他人有机会/技能/动机故意尝试使您得出错误的结论,那么几乎任何哈希-甚至是像“ MD5”和“ SHA1”这样的“已知破损”哈希都是几乎可以肯定就足够了。但这就是说,您可以高速生成数百万年的文件,但最终还是不可能获得实际上不同但具有相同哈希值的任何两个文件。几乎可以肯定是安全的。

这是您遇到的情况,当您想快速检查PC或文件服务器上的两个目录是否具有相同的内容,目录中的任何文件是否完全相同,等等,并且您确定这些文件没有经过工程设计/非法修改,并且您相信自己的哈希应用/实用程序可以提供正确的结果。

如果您处于其中一个文件(或预先计算的哈希)可能已经被操纵或设计为使您误入错误结论的情况,那么您需要更强(不间断)的哈希和/或其他安全性。例如,如果您下载文件并通过检查散列来检查其是否有效,则攻击者可能能够使用正确的散列来设计错误的文件,或者在您寻找“正确的”名称时攻击网站放置不正确的散列“ (期望值。这归结为更广泛的安全问题。


2

在Windows命令行上,您可以使用该comp实用程序来确定两个文件是否完全相同。例如:

comp fileone.xls filetwo.xls

1

如果哈希值相同,是否意味着文件内容是1:1相同?

否。如果哈希值是不同的,并不意味着内容是不同的。相等的哈希码并不意味着相等的内容。顾名思义,哈希码是将大域缩小为较小范围的方法:含义是不相等内容上的哈希码可以相等。否则,计算它们将毫无意义。


否则,计算它们将毫无意义。 如果您违反了数学定律并且发明了可以压缩随机数据的无损压缩函数,这违反了信鸽准则,那么使用它将非常有价值!如果128位哈希确实代表了文件的全部内容,那将非常方便。即使没有解压缩功能,也无法将哈希表转换回文件,但数学上不可能的无冲突哈希表也将是不错的选择,例如,加快对VM映像中不可信数据的重复查找。
彼得·科德斯

“如果哈希值不同,则表示内容不同。” 不必要。XLSX文件是ZIP文件,并且可能以不同的文件顺序存储相同的内容。
托马斯·韦勒

1

该答案旨在为可能发生或无法发生的情况以及您可以应用的推理提供方便的地图。请参阅其他答案以了解为什么散列函数以这种方式工作。


选择哈希函数并坚持使用之后,可以考虑以下所有组合:

          |    identical   |   different    |
          |   hash values  |  hash values   |
----------+----------------+----------------+
identical |   can happen,  | cannot happen, |
  files   |     common     |   impossible   |
----------+----------------+----------------+
different |   can happen,  |   can happen,  |
  files   |      rare*     |     common     |
----------+----------------+----------------+

* rare, unless whoever generates (at least one of) the files
  purposely aims at this scenario

完全相同的文件生成不同的哈希值的情况是唯一绝对不可能的情况。


始终适用的两个理由:

  • 如果文件相同,则哈希值肯定相同。
  • 如果哈希值不同,则文件肯定不同。

不严格的两个理由:

  • 如果文件不同,则哈希值可能不同。
  • 如果哈希值相同,则文件可能相同。

0

就您的目的而言,是的,相同的哈希表示相同的文件。

正如其他答案所表明的那样,可以构造2个导致相同哈希值的不同文件,并且MD5在这方面不是特别可靠。

因此,如果您打算比较大量的excel文档,或者您认为有人可能想要操纵比较,请使用更强大的哈希算法。SHA1比MD5更好。SHA256再一次变得更好,应该使您完全确信自己的特定用法。


-1

如果文件的哈希值相同,则它们可能相同。通过以相同的方式修改两个文件(例如,将相同的值放在相同的未使用的单元格中),然后比较修改后的文件的哈希值,可以提高置信度。很难为文件创建故意的冲突,而这种冲突是以事先未知的方式更改的。


由于Office文件中存储了其他数据,因此无法使用。您需要例如在保存之前将光标放在相同的单元格中,以及在准确的时间保存等。但是即使如此,XLSX文件在内部还是zip文件,因此,如果该算法以不同的顺序(出于任何目的)存储各个文件,该文件是相同的,但哈希值不是
Thomas Weller '18

-2

让我们以实际的方式来看一下。我不会说“哈希是相同的”,而是说“我写了一个计算机程序来计算两个文件的哈希并打印出它们是否相同”,然后运行带有两个文件的程序,并说“相同”。这样做有几个原因:

这些文件可能是相同的。我的代码可能存在错误(实际上在实践中发生过一个错误,即不是将两个长(256字节)的哈希与memcmp进行比较,而是与strcmp进行了比较:如果每个哈希的第一个字节为零,则比较将返回“相同”,并且在65536中为1。这可能是硬件故障(宇宙射线撞击存储单元并进行切换),或者您可能遇到两种情况,即两个不同的文件具有相同的哈希(哈希冲突)。

我要说的是,对于不相同的文件,到目前为止,最可能的原因是程序员错误,然后是宇宙射线,它改变了布尔变量,并将散列值从“ false”更改为“ true”,结果出现了很多哈希冲突的巧合。

有些企业备份系统通过对每个文件进行哈希处理并检查服务器上已存储的哈希相同的文件来避免从10,000个用户备份相同的文件。因此,如果发生冲突,将不会备份文件,可能会导致数据丢失。有人计算过,与丢失文件相比,陨石更有可能击中您的服务器并破坏所有备份,因为丢失的校验和与另一个文件匹配。

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.