Linus Torvals spoke about the SHA-1 collisions in the Git repositories: there is nothing to fear

A few days ago, Google and the Center for Mathematics and Computer Science in Amsterdam presented the first collision generation algorithm for SHA-1. For ten years of the existence of SHA-1, not a single practical method of generating documents with the same SHA-1 hash and digital signature as in another document was known, but now this possibility has appeared.

The SHA-1 hash function is used everywhere, so the news of the generation of documents with identical hashes caused natural concern among users. This includes users of the Git version control system , which also uses SHA-1 hashes. A detailed response to these concerns was given by Linus Torvals. In short, there is nothing to fear .

Linus believes that this attack on the search for collisions will not do anything crucial. According to him, there is a big difference between using a cryptographic hash for digital signatures in encryption systems and for generating “content identification” in a system like Git.

In the first case, the hash is a kind of statement of trust. The hash acts as a source of trust that fundamentally protects you from people you cannot verify in other ways.
')
On the contrary, in projects like Git the hash is not used for “trust”. Here, trust extends to people , not to hashes, says Linus. In projects like Git, SHA-1 hashes are used for a completely different, technical purpose - just to avoid accidental conflicts and as a really good way to detect errors. It is simply a tool that helps you quickly identify corrupted data. This is not about data security, but about the technical convenience of de-duplication and error detection. Other version control systems often use error detection methods like CRC.

Linus acknowledges that SHA-1 is also used in Git to sign branches, so in this sense it is also part of the trust network, so the appearance of an attack on the search for collisions really has negative consequences for Git.

But in reality, you need to keep in mind that this particular attack is very easy to avoid for several reasons.

First, in this attack, the attacker can not simply create a document with a given hash. He needs to create two documents at once , since the attack is carried out on the same prefix.

Secondly, the developers of the attack to search for collisions SHA-1 published a scientific article and laid out the tools to recognize the signs of an attack. It is very easy to recognize documents that have this prefix suitable for generating a second document with an identical hash.

That is, in practice, if you implement the appropriate measures to protect against documents with this prefix, the attack will not be feasible. By the way, such protection is already implemented in Gmail and GSuite. Vulnerable Document Detector is openly available on shattered.io . The sha1collisiondetection collision detection library is published on Github.

When all the data are in the public domain, then the real attack is almost impossible. The authors of the scientific paper give an example of an attack on PDF documents with an identical prefix. This attack succeeds because the prefix itself is “closed” inside the document, like a blob. If we have open source in the repository, then it is quite another matter. It is hardly possible to make such a prefix from the source code (only from the blob). In other words, to create an identical prefix and then generate code branches with the same SHA-1 hashes, you will have to inject some random data into the code, which will be noticed immediately . Linus says that there are places where you can hide the data, but git fsck already catches such tricks.

Linus Torvalds acknowledges that only tracking PDF documents with Git can be a real concern. Here you can recommend using the tools for detecting the signs of attack mentioned above. Such patches have already been created for github.com and kernel.org, they will soon become active, so there is nothing to worry about.

Well, among other things, Git will go away from using SHA-1 in the future, Linus said, there is a plan so that no one even has to convert their repositories. But as is already clear, it is not such a critical thing to rush with her.

By the way, the problem of tracking PDF documents with identical SHA-1 hashes, mentioned by Torvalles, has already proven itself in the Apache SVN version control system, which is used in the WebKit repository and other large projects. On Friday evening, on the information site of the attack on the search for collisions SHA-1, new information appeared regarding the action of the attack on the SVN version control system. It indicates that PDF files with the same SHA-1 hash already break SVN repositories.

It turned out that if you upload two different files with the same hashes, the version control system does not cope with the bug. Someone uploaded such files to the WebKit repository, after which he jammed and stopped accepting new commits .

These two PDF files with the same hashes:

• https://shattered.it/static/shattered-1.pdf
• https://shattered.it/static/shattered-2.pdf

  $ls -l sha*.pdf -rw-r--r--@ 1 amichal staff 422435 Feb 23 10:01 shattered-1.pdf -rw-r--r--@ 1 amichal staff 422435 Feb 23 10:14 shattered-2.pdf $shasum -a 1 sha*.pdf 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf