大新闻？

在刚刚过去的2017年2月23日，Cryptology Group at Centrum Wiskunde & Informatica (CWI)和Google的研究人员公开了2个PDF文件，我也第一时间下载并按提示检查了SHA-1的校验值。文件内容和SHA1的结果如图1所示。

↑ 图1 重现大新闻

图1说明了一个很简单的事实：这是2个不同的PDF文档，但是它们的SHA-1校验值是一样的。
这个简单的事实（We have broken SHA-1 in practice.）轰动了安全界，因为这说明世界上首次实际意义上公开的SHA-1的碰撞试验取得了成功。

SHA-1是啥？

一句话：SHA-1是Hash算法的中广泛使用的一种。

哈希（Hash）又称为散列，或者杂凑，是一种算法。这种算法接受任意长度的数据输入，然后给出一个固定长度的输出。

↑ 图2 Hash示意图

如图2所示，Hash函数的输出反而没有特别的意义，一个设计一个优良的Hash函数，需要（尽量）满足如下条件：

Hash的输出值（称为散列值或者数据的摘要）通常可以作为数据的指纹，这在密码学领域有重要的意义。

SHA（Secure Hash Algorithm）是由National Institute of Standards and Technology (NIST) 制定的作为U.S. Federal Information Processing Standard (FIPS)的散列函数家族。

↑ 图3 SHA家族

这次被发现碰撞的是SHA-1散列算法，是目前依然使用非常广泛的一种算法，它的输出是160个bits，图1中用了40个16进制数来表示。SHA-1被发现碰撞之所以能成为大新闻，和它的应用场景分不开。

大新闻做了啥？

虽然说在2005年文献[2]已经提出了复杂度小于

的理论碰撞，在2013年文献[5]将这一数字优化到

，但是他们都是理论分析，并没有给出实证。在不见棺材不掉泪的情况下，给出一个实例才是最好的。所以，The first collision for full SHA-1一文创造了第一个碰撞的实例。

他们基于[5]的研究，使用一种名为相同前缀碰撞攻击（identical-prefix collision attack）的方法：

即2条消息的前缀P是一样的，主要寻找2个数据对

使得2个完整消息的SHA-1输出相等，而后缀S可以是任意值。一旦这样的数据对找到，就严重违背了“不能找出2个不同的输入，使得输出一样”这一要求，也就宣布了SHA-1算法已经变得不安全。

当然找到这样一个碰撞的难度很大，得益于研究人员对算法的不断优化和GPU技术的发展，现在终于实现了在

复杂度下的实际碰撞攻击。如果认为图1还是一个巧合的话（实际上这样的巧合发生概率趋近于0），论文中还给出了另外一组实例，如图4所示。

↑ 图4 SHA-1碰撞实例

这次的实际攻击是拿JPEG开刀，所以PDF中是2幅图像不同，也算是比较有视觉说服力的实例。按照惯例，这次碰撞攻击的细节（包括技术细节和源代码）将会在以后条件成熟时公开。

以Git为例

Git的本质是一种内容寻址的文件系统（Content-addressable filesystem），也就是说Git内部是通过键值对的方式存储的，而检索的本质是通过键来查找对应内容。因此向Git提交的任意内容，都会通过Hash算法得到一个唯一的键，以后可以通过这个键唯一地检索到存储的内容。而Git使用的Hash算法正是SHA-1。

接下来验证这一点。

以一个文件为例，Git对于该文件取Hash的方法如下：

sha1(‘blob ’ + filesize + ‘\0’ + filedata)

↑ 图5 Git中的Hash

图5中，3个红框代表了3次hash操作。

第一次是使用openssl提供的sha1算法计算hash

第二次是git提供的 hash-object方法计算hash

第三次是实际创建了一个仓库并在commit后检查hash

三次计算的结果完全一致，说明了Git在内部完全依赖SHA-1算法作为其hash算法。

实际上，Git并不关心文件或者处理的对象的名称，而只通过Hash值来区分他们。在Git的世界里，一个对象的Hash就是一个对象的唯一ID。如果ID可以伪造，那么就没有然后了。

接下来分析Git在遇到Hash碰撞的时候如何处理。

是不是很期待再来一发截图玩坏Git，然而现在并不行。实际情况由于碰撞需要的计算量依然远超过PC的能力，以及技术细节并没有完全公开，真实的情况还有待验证。而且Git并不是直接计算文件的Hash，所以图1给出的样例碰撞不会影响Git的运作。

要不“稍微”修改一下Git的实现，人为创造碰撞试试。文献[1]通过修改源码的方式，构造了一个简化的4 –bit SHA1版本来探究了碰撞的情况。

实验的结果是，在不少常见场景下，Git不报错，而实际上仓库已经出现了不同类型的损坏。

一种简单的修复方法是报错并提示用户，虽然此时Git不能正常运作，但是可以及时止损。

再看HTTPS

相比Git的问题，HTTPS使用的证书，情况似乎好很多。

SHA-1的不安全性，王小云教授早就在2005年就已经指出了[2]。

近几年各大公司也正逐渐的淘汰SHA-1：

对于SSL证书，Windows已于2017年1月1日起停止支持SHA1证书。

对于代码签名证书，Windows早在2016年1月1日就停止接受没有时间戳的SHA-1签名的代码和SHA-1证书。

Google的Chrome浏览器已经逐步地废弃了SHA-1证书支持，现在最新版的Chrome已经彻底不支持了。

Mozilla自2017 年 1 月1 日后不再信任SHA-1证书。

……

可以看到，不再支持SHA-1只是一个时间问题。或许这次的大新闻将加速这一进程。

So far so good。这是由于，对于大公司而言，更换新的证书很简单，因为不涉及到客户端的分发。

真正的挑战还是客户端：对于写应用程序的工程师来说，困难在于老旧的客户端不支持某些新特性，而在安全领域是倒过来的，困难的是老旧的客户端支持了过时的特性。