How broken is SHA-1 really?

Posted by   Martijn Grooten on   Mar 15, 2016

Earlier this month, I gave a talk entitled "How Broken Is Our Crypto Really?" at the RSA Conference in San Francisco. In the presentation, I looked at vulnerabilities found in cryptographic protocols and analysed the likeliness of these being exploited in practice.

I spent a few minutes talking about SHA-1 and stated that it is unlikely that we will see fake TLS certificates exploiting SHA-1 collisions in the next few years.

Afterwards, someone from the audience told me that, just the day before, Adi Shamir had told an audience at the same conference that he believes a SHA-1 collision will be found within the next few months. Bart Preneel, from the University of Leuven, made a similar statement at another conference. So who is right?

I wouldn't dare to disagree with either Adi Shamir or Bart Preneel, let alone with both of them, so if I were to find myself with an opposing opinion, I would humbly spend a few days reading research papers. But in this case, our statements don't contradict.

SHA-1 is a hash function: a function that turns any arbitrary sequence of bytes — whether it's a short string or a huge file — into a fixed-length block, called a "hash". While a simple cardinality argument shows that the output of a hash-function isn't unique, it should be impossible in practice to find two byte sequences with the same hash. Given a hash, it should also be impossible to find a byte sequence with that hash.

In TLS, including HTTPS, hash functions are used in certificates that demonstrate proof of ownership, in this case of a domain. To show the validity of the certificate, it is signed by a "higher authority". For practical reasons, this signature is actually the signature of the hash of the certificate, using one of a number of hash functions.

To create a fake but valid certificate, one needs to take an existing certificate and forge a second certificate with the same hash, so that their signatures will match. The existing certificate doesn't have to be that of the domain one is trying to impersonate: any so-called intermediate certificate (a certificate of a slightly higher authority) will do, as this can then be used to sign the actual certificate.

SHA-1-round.png

So how broken is SHA-1 really?

As a hash function, it is broken if someone can find a collision. We're not there yet, but Marc Stevens from CWI in the Netherlands is getting pretty close (he has found a collision for a slightly weaker form of SHA-1), and it may well be that he or someone else will find a proper collision. The time has come to move away from SHA-1.

But a collision doesn't mean one can forge certificates. For that to happen, someone needs to find a string of bytes that is both a valid certificate and whose SHA-1 is the same as that of a given certificate. This is orders of magnitude more difficult than finding a SHA-1 collision — in part because of a number of mitigations built into certificates to prevent these kinds of attacks — and although one can never be certain, it is likely that it will take years before someone is able to fake a certificate in this way.

However, we can't just wait for that moment and then quickly disable SHA-1 certificates all over the Internet. Certificates are often valid for several years and even if your own certificates don't use SHA-1, someone could fake an intermediate certificate and thus impersonate your domain. Hence the process of phasing out SHA-1 has started already.

I am confident that SHA-1 certificates will have long ceased to be accepted by the time they can be faked by the most powerful adversaries, but there are voices who argue that we should speed up the process. After all, we have been there before with another hash function, MD5, which was broken in 2004 and for which a hash collision was used to impersonate Microsoft by the Flame malware. We don't want to be caught out again!

Unfortunately, security vendors aren't all at the front of this phasing-out process. Mozilla recently had to revert part of the phasing-out process, due to the fact that some security devices generated certificates on-the-fly that used SHA-1 hashes.

And it's not just in certificates that SHA-1 is being used. A lot of security software uses SHA-1 or even MD5 internally. In many cases, even for MD5, this will be fine in practice, but there are implementations where it isn't and where it could, for instance, be used to bypass a security scanner.

It also remains common practice for security researchers to include MD5 hashes of malware samples in their research reports.

So let's calm down and realise that reports of the death of SHA-1 certificates are greatly exaggerated. But let's also practice what we preach and, especially as security researchers, get rid of MD5 and SHA-1.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest posts:

Nominations opened for sixth Péter Szőr Award

Virus Bulletin is seeking nominations for the sixth annual Péter Szőr Award.

Haroon Meer and Adrian Sanabria to deliver VB2019 closing keynote

New additions to the VB2019 conference programme include a closing keynote address from Thinkst duo Haroon Meer and Adrian Sanabria and a talk on attacks against payment systems.

Free VB2019 tickets for students

Virus Bulletin is excited to announce that, thanks to generous sponsorship from Google Android, we are able to offer 20 free tickets to students who want to attend VB2019.

VB2018 paper: Lazarus Group: a mahjong game played with different sets of tiles

The Lazarus Group, generally linked to the North Korean government, is one of the most notorious threat groups seen in recent years. At VB2018 ESET researchers Peter Kálnai and Michal Poslušný presented a paper looking at the group's various…

Book your VB2019 ticket now for a chance to win a ticket for BSides London

Virus Bulletin is proud to sponsor this year's BSides London conference, which will take place next week, and we have a number of tickets to give away.

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.