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:

In memoriam: Prof. Ross Anderson

We were very sorry to learn of the passing of Professor Ross Anderson a few days ago.

In memoriam: Dr Alan Solomon

We were very sorry to learn of the passing of industry pioneer Dr Alan Solomon earlier this week.

New paper: Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

In a new paper, researchers Aditya K Sood and Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited in order to gather threat intelligence, and present a model of mobile AppInjects.

New paper: Collector-stealer: a Russian origin credential and information extractor

In a new paper, F5 researchers Aditya K Sood and Rohit Chaturvedi present a 360 analysis of Collector-stealer, a Russian-origin credential and information extractor.

VB2021 localhost videos available on YouTube

VB has made all VB2021 localhost presentations available on the VB YouTube channel, so you can now watch - and share - any part of the conference freely and without registration.

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.