如何评价 2 月 23 日谷歌宣布实现了 SHA-1 碰撞? | 目的地Destination

如何评价 2 月 23 日谷歌宣布实现了 SHA-1 碰撞?

多图预警,长答案预警,请在WiFi环境下阅读此答案。

写在前面

感谢知乎密码学交流群的同学 @王希 对本答案的部分地方进行了精炼,@某位老师对本答案提出了宝贵的意见。感谢安全大事件(知乎专栏)团队成员 @Murasaki为本答案提出了改进的建议。

攻击成本问题

SHA-1攻击成果令人惊异,据说还导致了小范围比特币的抛售…然而,事情并没有想象的那么严重。原因如下:

首先,比特币系统中一共使用了2个哈希函数,分别为SHA-256、RIPEMD160。这是与SHA-1完全不同的哈希函数。另外,RIPEMD160只用于交易地址的压缩,确认交易和数字签名所用的哈希函数均为SHA-256。到现在为止学者们还没有发现SHA-256的漏洞,因此比特币的安全性仍然可以得到保证。

第二,正如后面答案中提到的,SHA-1早在2011年就已经被建议替换。只不过因为兼容性问题和成本问题,有些对安全不太重视的厂商还在使用SHA-1。这次的攻击结果能够促使这些厂商认真考虑替换SHA-1的问题,否则其产品会失去市场。对于那些对安全很重视的公司,如Google、苹果、IBM、微软等(感谢 @唐勇 的评论,微软也是最先推荐使用SHA-256的公司之一),SHA-1早已被抛弃使用了。

第三,虽然Google的算法是实际上可行的,但攻击成本有多少呢?论文中提到,算法的执行时间大约为6500CPU年和100GPU年。这是个什么概念呢?如果某个攻击者要使用这个算法实现攻击,它需要在Amazon EC2上租赁足够的CPU计算核与GPU计算核(当然了,租的越多花费时间越少)。正如论文中给出的,如果把时间成本也考虑其中,实施SHA-1攻击的成本虽然得到了降低,但也不少,大约需要花费7.5W-12W美金。这对一般攻击者来说,成本应该算比较高吧…

(注:7.5W-12W美金的花费实际对应的是Stevens等人提出的另一种攻击方法,此攻击方法效率更好,但是并行处理能力相对较差。猜测新攻击方法会花费更多的费用租赁GPU计算核,从而实现大规模并行处理。综合考虑,个人认为两种攻击的花销接近,可能新攻击方法的花销会更大)

前沿

今天(2017年02月24日)一大早,我微信的朋友圈就被刷屏了:Google发布了哈希函数SHA-1的 哈希碰撞实例。同时,我的知乎上也推送了上海交通大学LoCCS实验室理论密码研究组发布的专栏文章:《密码学大事件!研究人员公布第一例SHA-1哈希碰撞实例》(专栏文章链接:知乎专栏)。

起初,我还以为Google团队仅仅找到了两组没有意义的数据,但SHA-1结果相同而已。但在晚间深入阅读了Google团队的安全博客,并阅读了论文《The First Collision for Full SHA-1》后,我发现我低估了Google所发布工作的意义。实际上,Google发布的工作远超我之前的想象。Google的工作基本可以宣判了SHA-1的死刑!

专栏文章:《密码学大事件!研究人员公布第一例SHA-1哈希碰撞实例》也提到一个八卦:

这个轰动性结果甚至让今年某顶级学术会议的Deadline为之延期!!

而这个顶级学术会议就是密码学界最为著名的会议CRYPTO了。在CRYPTO 2017官方网站上我们可以看到一个大大的红色延期标记:

一般来说,会议截稿日期延期主要是因为投稿论文数量没有达到期望值,但任意领域最顶级的会议从来不会缺少稿件。而且注意到,这次延期感觉很奇怪,只延长了19个小时而已。因此,能使这种重量级会议的截稿日期延期,唯一的情况就是某个轰动的结果所总结的论文将会投稿到此会议上。实际上,CRYPTO组委会就是多给了19小时的时间,等待Google方面完成论文的撰写。由此可见,Google这一工作对密码学理论的重要程度。这篇重量级的论文即为前面提到的《The First Collision for Full SHA-1》(原始论文:shattered.io/static/sha)。相信这篇论文会被CRYPTO 2017录用。

本着可观科学的原则,我试图撰写一篇稍微深入的答案,为知友们深入介绍一下Google所做的工作,以及这个工作的意义。本答案将包括下述几个部分:

  1. 哈希函数简介(科普)
  2. SHA-1哈希函数简介(科普)
  3. 《The First Collision for Full SHA-1》工作简介(科普)
  4. 《The First Collision for Full SHA-1》工作验证(非科普)
  5. 《The First Collision for Full SHA-1》工作意义(科普)

哈希函数简介(科普)

我相信很多知友们都听说过,或者有意无意地使用过哈希函数。知乎已经实现了全站https,因此我们访问知乎的时候就会无意中使用哈希函数。https的标志是浏览器地址栏的左侧会出现一个带锁的标志。以Google的Chrome浏览器为例,锁的标志大概是这样的:

如果知友们了解如何浏览https证书信息的话,可以通过一系列操作,最后看到这样的界面:

其中,【签名哈希算法】部分写着SHA-256,这就是https所使用的哈希函数了。有趣的是,如果拖动滚动条,会发现知乎https证书的【指纹算法】仍然使用了SHA-1:

所以可能知乎所用的证书也需要更新了~

(注:实际上证书安全性的核心在于数字签名、密钥用法等,单纯的指纹算法和指纹本身对安全性没什么影响。由于数字签名使用的是SHA-256,知乎的证书暂时没什么问题,大家还是可以放心的~)

另一个知友们可能经常看到的哈希函数使用实例在软件下载界面。下载软件时,我们经常会看到文件上传者提供了几个看似毫无意义的字符串。这几个字符串就是使用不同的哈希函数计算得到的。不过,由于互联网安全技术的不断发展,这些字符串的验证过程已经变为了后台执行,用户下载时不需要再人工比对了。例如,如果知友们于2017年2月24日访问著名程序语言Java的开发环境下载界面,则会看到这样一个警告信息:

关键地方的翻译如下:

Important planned change for MD5-signed JARs
有关MD5-签名JARs的重要变化

Starting with the April Critical Patch Update releases, planned for April 18 2017, all JRE versions will treat JARs signed with MD5 as unsigned.
计划于2017年4月18日发布四月的重要补丁更新,此更新后,如果JRE版本JARs文件所用的签名使用了MD5,服务器将认为此签名无效。

正是由于著名哈希函数MD5已经不再安全,因此安全界才会发布这样一个计划,逐渐将MD5退出历史舞台。

那么,哈希函数是什么呢?简单地说,它是密码学中的一个重要的函数,一般以/textsf{Hash}(/cdot) 表示。这个函数可以将任意一段数据(一般称这段数据为“消息”)压缩成固定长度的字符串(一般称输出的字符串为“摘要”)。哈希函数需要满足下述条件:

  1. 确定性:哈希函数的算法是确定性算法,算法执行过程不引入任何随机量。这意味着相同消息的哈希结果一定相同。
  2. 高效性:给定任意一个消息m ,可以快速计算/textsf{Hash}(m)
  3. 目标抗碰撞性:给定任意一个消息m_0 ,很难找到另一个消息m_1 ,使得/textsf{Hash}(m_0)=/textsf{Hash}(m_1) .
  4. 广义抗碰撞性:很难找到两个消息m_0 /neq m_1 ,使得/textsf{Hash}(m_0)=/textsf{Hash}(m_1)

在密码学上,一般认为如果第4个条件不满足,那么此哈希函数就不再安全。在实际中,一般认为如果在某种程度上第3个条件不满足,那么此哈希函数就不再安全。当然了,如果第3个条件完全不满足,那么此哈希函数已经彻底不安全,应该被直接弃用。

哈希函数的(广义)抗碰撞性使得哈希函数可以用于数据的完整性验证。举例来说,某个用户上传一个文件供其他用户下载。用户在网络上公开了文件的哈希函数输出结果。下载用户完成下载后,计算下载结果的哈希函数输出结果。如果结果相等,则可以认为下载的软件就是官方发布的软件,没有遭到第三方的篡改。

哈希函数第二个常见的应用场景是密码存储。在用户进行网站登录时,如果服务器直接存储用户密码,则如果服务器被攻击者所攻击,用户的密码就会遭到泄露。最典型的事件就是CSDN的密码明文存储事件了。为了解决这个问题,服务器可以仅存储用户密码的哈希结果。当用户输入登录信息后,服务器端可以计算密码的哈希结果,并与存储的哈希结果进行对比,如果结果相同,则允许用户登录。由于服务器不直接存储用户密码,因此即使服务器被攻击者攻击,用户的密码也不会被泄露。这也是为什么我们在使用【找回密码】功能时,服务器直接请求输入新的密码,而不是把原始密码发送给我们。毕竟,它自己也不知道用户的密码是什么… 至于彩虹表攻击等,属于讨论范畴之外,在此不多做叙述。

(注:特别感谢 @大空格 的指正。原始答案中我写的是客户端计算哈希值后传给服务器,这是完全错误的。参考加盐密码哈希:如何正确使用 - 文章 - 伯乐在线文章中的描述:

即使浏览器端用JavaScript加密了,你仍然需要在服务端再次进行加密。试想有个网站在浏览器将密码经过哈希后传送到服务器,那么在认证用户的时候,网站收到哈希值和数据库中的值进行比对就可以了。这看起来比只在服务器端加密安全得多,因为至始至终没有将用户的密码明文传输,但实际上不是这样。

问题在于,从客户端来看,经过哈希的密码逻辑上成为用户真正的密码。为了通过服务器认证,用户只需要发送密码的哈希值即可。如果有坏小子获取了这个哈希值,他甚至可以在不知道用户密码的情况通过认证。更进一步,如果他用某种手段入侵了网站的数据库,那么不需要去猜解任何人的密码,就可以随意使用每个人的帐号登录。

这并不是说你不应该在浏览器端进行加密,但是如果你这么做了,一定要在服务端再次加密。

哈希函数第三个重要的应用是数字签名。实际上, 数字签名算法对消息的长度和格式是有要求的 ,要求数据满足一定的条件。为了解决这个问题,学者们指出可以对数据的哈希结果签名。由于哈希结果的长度是固定的,一般来说容易构造一种方法,让这个长度固定的结果进一步满足数字签名算法对数据输入的要求。而由于哈希函数的抗碰撞性,如果原始数据被篡改,那么哈希结果也会变化,同样会导致签名无法通过验证。更为重要的是,先哈希后签名的方法可以让签名变得更安全。实际上可以证明,如果先哈希,再执行RSA数字签名,则此算法是可证明安全的。详细信息可以参考Katz和Lindell的书籍《Introduction to Modern Cryptography》,第13.2.3节,OAEP。

SHA-1哈希函数简介(科普)

SHA-1是1995年国家标准技术局NIST(National Institute of Standards and Technology)于1995年标准化的哈希函数。与前身MD5相比,SHA-1的输出长度更长(MD5输出长度为128bit,而SHA-1的输出长度为160bit),这也意味着出现哈希碰撞的概率更低。同时,SHA-1的安全性似乎也比MD5更好。

这里要稍微介绍一下寻找哈希函数碰撞的难度和一般方法了。以SHA-1为例,其哈希结果长度为160bit。如果SHA-1本身没有漏洞,而攻击者想找到一组碰撞的话,最显然的方法是选取2^{160}组不同的数据,依次计算它们的哈希结果。根据著名的抽屉原理,必然会出现一组数据,使得其哈希结果相同。此攻击方法需要调用2^{160}次SHA-1,即计算量级大约为2^{160}

(注:在后面的论述中,我将直接用计算量级表示调用SHA-1的次数)

抽屉原理很容易理解:假设有4个抽屉,而有5个苹果。我们要把这5个苹果放在4个抽屉里,那么必然至少有2个苹果被放进了同一个抽屉。就算前4个苹果均放在了不同的抽屉中,由于所有抽屉都被占满了,而第5个苹果也要占一个抽屉,因此这个苹果一定和前面4个苹果中的某个苹果放在了同一个抽屉里面。

(图片来源:课件《抽屉原理》_永恒的心_新浪博客

虽然这么寻找碰撞一定是可行的,但计算代价太大了,2^{160}这个数量级有多夸张?对比一下,全地球沙子的数量大约为10^{21} /approx 2^{4 /times 21} = 2^{84}。(参考知乎问题:地球上共有多少粒沙子? - 科普 - 知乎,我这里直接用10 /approx 2^4 = 16完成的计算,感谢 @许铖 指出了一个更确切的估计:2^{160} /approx 10^{48},看来全球沙子也还是远远不够的)

然而,我们可以通过概率方法寻找。我们放宽条件:如果降低一定的计算量,能不能有比较高的概率找到一组碰撞呢?这就是著名的生日攻击(Birthday Attack)了。

根据抽屉原理,一个屋子里必须有366个人(一年有365天,不考虑闰年)才能保证一定有2个人生日相同。然而,如果一个屋子里有23个人,则有50%的概率2个人生日相同。根据概率论(感谢 @程恩琼 @韩劼群 指出原始答案中的笔误):

  • 第2个人和第1个人生日不相同的概率为1-/frac{1}{365}
  • 第3个人和第1个人生日不相同的概率为1-/frac{1}{365} ,和第2个人生日也不相同的概率为1-/frac{1}{364} (因为此时已经假定前2个人生日不同),因此和前2个人生日都不相同的概率为/left(1-/frac{1}{365}/right)/left(1-/frac{1}{364}/right)
  • 第4个人和前3个人生日都不相同的概率为/left(1-/frac{1}{365}/right)/left(1-/frac{1}{364}/right)/left(1-/frac{1}{363}/right)
  • ......
  • 第23个人和前22个人生日都不相同的概率为/[/prod/limits_{i = 1}^{23} {/left( {1 - /frac{1}{{365 - i + 1}}} /right)} /]
  • 上述事件同时发生时,23个人生日才会各不相同。因此,23个人中存在2个人生日相同的概率为:1-/frac{365!}{(365-23)! /cdot 365^{23}} /approx 50/%

寻找哈希碰撞时也可以用到这个方法。事实上可以证明,对于SHA-1来说,选择大约/sqrt{2^{160}}=2^{80}组不同的数据并计算哈希结果,则有50%的概率有2个数据的哈希结果相同。此方法的计算量级可达到2^{80},远优于2^{160}。引入的代价是成功率变为50%,因此计算量级的期望为2^{81}。这个量级和全球沙子的个数有点接近了,我们需要大约计算1000倍全球沙子个数的哈希结果后,能有约50%的概率找到一组碰撞。

密码学上认为,如果能找到一种方法,能在计算时间小于2^{80}的情况下,有超过生日攻击的概率下找到一组碰撞,则认为这个哈希函数就不安全了。

SHA-1自提出后,学者们一直认为它是安全的,也就是说没有找到计算时间小于2^{80}的攻击方法。在CRYPTO 2005上(没错,和上面的CRYPTO 2017是一个会议),中国著名密码学家王小云教授所在的团队提出了一个一种寻找SHA-1碰撞的,相对快速的攻击方法(原始论文:Finding Collisions in the Full SHA-1,发表在CRYPTO 2005上)。此攻击方法的计算量级为2^{69},这标志着SHA-1存在漏洞。这个成果使中国密码界闪耀在世界舞台!也正是因为这个研究结果,NIST不得不着手选择新的哈希函数,因此我们现在才有了SHA-256(知乎所用的哈希函数)、SHA-384、SHA-512等。(感谢 @swordfeng 指出的错误,SHA-256、SHA-384、SHA-512同属SHA-2系列哈希函数,原始描述将这几个名词并列放置,是不合理的)

王小云教授的开创性工作让进一步破解SHA-1成为可能。然而,王小云教授的方法仅可以破解SHA-1的广义抗碰撞性,且计算时间相对较长。因此,一段时间以内SHA-1还是可以使用的。学者们致力于寻找更加高效的SHA-1破解方法。截止Google的工作之前,最好的方法是Stevens提出的攻击方法,可以在2^{61}计算量级内找到一组哈希碰撞(原始论文:New Collision Attacks on SHA-1 Based on Optimal Joint Local-Collision Analysis,发表在与CRYPTO同等级的密码学顶级会议EUROCRYPT 2013上)。

上述方法都是纯使用CPU计算的方法。如果把显卡(也就是所谓的GPU)引入破解工作,使用大规模并行处理,是否能够进一步提高效率呢?Stevens等人又在2016年提出了新的攻击方法。他们指出,如果使用GPU并行计算,则计算量级会进一步降低到2^{57.5}(原始论文:Freestart Collision for Full SHA-1,发表在EUROCRYPT 2016上)。本次Google的工作也使用了类似的方法,不过由于有不可避免的困难,此次提出的攻击方法计算量级大约为2^{61}。既然计算量级反而增大了,为何这次的成果比之前的成果更加轰动呢?答案的后半部分会讲到此攻击方法的亮点。

当然了,如果你注意到的话,会发现Stevens正是Google所做工作论文的第一作者…

《The First Collision for Full SHA-1》工作简介(科普)

现在我们可以看看,Google的工作(同样也是Stevens的工作)到底是什么?我们直接引用此工作官方网站(原始链接:SHAttered)的介绍吧:

We have broken SHA-1 in practice.
我们从应用角度破解了SHA-1。

This industry cryptographic hash function standard is used for digital signatures and file integrity verification, and protects a wide spectrum of digital assets, including credit card transactions, electronic documents, open-source software repositories and software updates.
这一工业界应用的密码学哈希函数标准被用于数字签名、文件完整性验证中,并在多个领域保护着人们的数字财产,这些数字财产包括信用卡交易、电子文档、开源软件仓库、软件更新等。

It is now practically possible to craft two colliding PDF files and obtain a SHA-1 digital signature on the first PDF file which can also be abused as a valid signature on the second PDF file.
在实际中,我们可以构造两个SHA-1结果相同的PDF文件。这使得第二个文件SHA-1后的数字签名可以通过第一个文件SHA-1后数字签名的验证。

For example, by crafting the two colliding PDF files as two rental agreements with different rent, it is possible to trick someone to create a valid signature for a high-rent contract by having him or her sign a low-rent contract.
举例来说,可以构造两个SHA-1结果相同的PDF租赁协议文件,协议文件中标注的租金不同,但高租金文件的SHA-1后签名结果与低租金文件的SHA-1后签名结果一样。这样,可以让租赁方在低租金文件上签字,再用高租金文件替换,达到伪造租赁协议文件的目的。

Attack Proof

攻击证明

Here are two PDF files that display different content, yet have the same SHA-1 digest.
下方有两个PDF文件,其显示的内容不同,但SHA-1摘要结果相同。

从论述中可以发现,Stevens等人成功构造了两个PDF文件(这是有意义、可以真正打开的文件),使得SHA-1结果相同!这可是比较夸张了… 我们来看看这两个文件。

第一个文件打开后是这样的:

第二个文件打开后是这样的:

惊到了好吗!不光是能打开的PDF,PDF的内容竟然还有意义!这让我感觉Stevens的工作可不是找到了一组碰撞那么简单。实际上,官方网站后续的说明也侧面说明了这一点:

File tester
文件测试

Upload any file to test if they are part of a collision attack. Rest assured that we do not store uploaded files.
请上传任意文件,来检测文件本身是否可能被这种攻击威胁。我们保证不存储您所上传的文件。

那么,Stevens到底的工作到底如何?能做到什么效果呢?我们可能不得不阅读一下论文了。(感谢 @康尼扎罗反应 的修正建议,至于为何这样翻译,需要理解下面描述的工作原理)

《The First Collision for Full SHA-1》工作验证(非科普)

(本部分截图部分来自于Stevens等人的原始论文:shattered.it/static/sha

实际上,Stevens等人做的工作是这样的:给定任意一个前缀数据P和后缀数据S,可以找到四组数据M_1^{(1)},M_2^{(1)},M_1^{(2)},M_2^{(2)} ,使得:

/textsf{SHA-1}/left(P/|M_1^{(1)}/|M_2^{(1)}/|S/right)=/textsf{SHA-1}/left(P/|M_1^{(2)}/|M_2^{(2)}/|S/right)

(感谢 @凌云轩雅 的指正,之前答案中M_1^{(1)},M_2^{(1)},M_1^{(2)},M_2^{(2)}以及后续的编号有误)

于是,他们构造了一个满足PDF文件解码要求的文件前缀,内容为:

注意看右边的后3行。他们利用PDF文件编码方法的特性,在前缀P中插入了注释符号:$,并顽皮的接上了:“SHA-1 is dead!!!!!”,同时保证后面的部分可容下M_1^{(1)},M_2^{(1)},M_1^{(2)},M_2^{(2)} 。这样就可以保证这段恶意插入的数据不会导致PDF文件解码错误。而M_1^{(1)} 为:

M_2^{(1)} 为:

M_1^{(2)} 为:

M_2^{(2)} 为:

我个人不太理解PDF的编码方法,猜想M_1^{(1)},M_2^{(1)},M_1^{(2)},M_2^{(2)} 在PDF文件中所在的位置会控制图片上方的背景颜色。之所以这么猜想,是因为2个图片显示结果中,只有上方背景颜色发生了变化,其它地方保持不变。而攻击方法也要求后缀S必须相同。

既然如此,我们用二进制方式打开这两个PDF文件看一看是否真的如此。首先打开shattered-2.pdf(注意,先是第2个文件),观察文件开始部分:

可以看到:

  • 第000行至第0B0行是Stevens等人给出的前缀数据P
  • 第0C0行至第0F0行是M_1^{(1)}
  • 第100行至第130行是M_2^{(1)}
  • 后面是后缀数据S

再打开shattered-1.pdf(现在是第1个文件),观察文件开始部分:

可以看到:

  • 第000行至第0B0行仍然是前缀数据P
  • 第0C0行至第0F0行是 M_1^{(2)}
  • 第100行至第130行是 M_2^{(2)}
  • 后面是后缀数据S

这样一来,Stevens等人通过选择有意义的前缀数据P和后缀数据S,最终构造出满足PDF编码格式的文件。实际上,如果我们换一张原始图片,通过插入不同的M_1^{(1)},M_2^{(1)},M_1^{(2)},M_2^{(2)} ,也可以达到此目的。而官方网站提供的文件检测器(Filer tester)的目的就是为了检测上传的文件前缀后面是否能插入对应的M_1^{(1)},M_2^{(1)},M_1^{(2)},M_2^{(2)} ,且使得文件仍然可以正确打开… 如果能插入,那么攻击者就可以插入不同的M_1^{(1)},M_2^{(1)},M_1^{(2)},M_2^{(2)} ,从而构造出不同的文件,但SHA-1结果相同。

因此,Stevens等人的工作在特定条件下破解了SHA-1的抗碰撞性,即给定满足特定要求的消息m_0 ,可以比较快速地找到另一个消息m_1 ,使得/textsf{Hash}(m_0)=/textsf{Hash}(m_1) 。当然了,正如论文中所提到的,M_1^{(1)},M_2^{(1)},M_1^{(2)},M_2^{(2)} 的计算需要花费大约6500个CPU计算年和100个GPU计算年。虽然时间比较长,但利用云计算技术,已经可以在数天内完成计算了。

(图片来自上海交通大学LoCCS实验室理论密码研究组发布的专栏文章:《密码学大事件!研究人员公布第一例SHA-1哈希碰撞实例》:知乎专栏。感谢LoCCS实验室团队成员的指正,原始图片来自于Google安全博客security.googleblog.com

《The First Collision for Full SHA-1》工作意义(科普)

Stevens等人工作的最大意义是,可以在较短时间内寻找到有意义的两个文件,使得其SHA-1结果相同。虽然寻找碰撞的速度比已知的最好速度慢一些,但是输出文件有意义这一点是非常亮眼的。这对于哈希函数本身来说虽不能算是彻底的破解,但也已经很接近了。此工作基本可以宣告SHA-1的死刑。

不过,其实也还好。我们应该感谢一个叫做Kerckhoffs的研究者。这里引用 @王希 同学在问题在有限专家间评议加密算法是不是比直接公开更安全? - 网络安全 - 知乎下的回答:

(Kerckhoffs指出)开放密码学设计则有如下四点优势:

  1. 公开的设计可以承受公开的钻研和分析,因此可以更加强壮。构造良好的密码学方案非常困难,更广泛地被研究可以证明其安全性。
  2. 公开后有更大的可能被正义黑客发现,比被敌人发现要好。
  3. 系统的安全取决于算法的保密性,对代码的逆向抵抗力很差。密钥不是代码的一部分,不存在这个问题。
  4. 公开设计使标准更容易建立。

虽然Kerckhoffs是在加密算法的环境下提出了公开密码学算法的概念,这个理念也被传到了哈希函数上面。自2005年王小云教授指出SHA-1的漏洞后,NIST在2011年就提出反对使用SHA-1算法,应使用更安全的哈希函数。这给了业界大量的时间选择更好的算法,并逐渐替换SHA-1。现在,新生成的https数字证书已经基本淘汰了SHA-1。同时注意到,Stevens等人的攻击方法还是要求消息满足一定的条件,因此SHA-1还没到已经彻底不安全的程度。

不过,警钟都敲成这样了,换不换?!

以上。

来源:知乎 www.zhihu.com
作者:刘巍然-学酥

【知乎日报】千万用户的选择,做朋友圈里的新鲜事分享大牛。 点击下载

此问题还有 5 个回答,查看全部。

分享

如何评价 2 月 23 日谷歌宣布实现了 SHA-1 碰撞?:等您坐沙发呢!

Leave your comment