Home / Blogs

Microsoft is Abandoning SHA-1 Hashes for Updates - But Why?

Steven Bellovin

Microsoft is shipping a patch to eliminate SHA-1 hashes from its update process. There's nothing wrong with eliminating SHA-1 — but their reasoning may be very interesting.

SHA-1 is a "cryptographic hash function". That is, it takes an input file of any size and outputs 20 bytes. An essential property of cryptographic hash functions is that in practice (though obviously not in theory), no two files should have the same hash value unless the files are identical.

SHA-1 no longer has that property; we've known that for about 15 years. But definitions matter. SHA-1 is susceptible to a "collision attack": an attacker can simultaneously create two files that have the same SHA-1 hash. However, given an existing file and hence its hash, it is not possible, as far as anyone knows, to generate a second file with that same hash. This attack, called a "pre-image attack", is far more serious. (There's a third type of attack, a "second pre-image attack", which I won't go into.)

In the ordinary sequence of events, someone at Microsoft prepares an update file. Its hash — its SHA-1 hash, in many cases — is calculated; this value is then digitally signed. Someone who wished to create a fake update would have to crack either the signature algorithm or, somehow, produce a fake update that had the same hash value as the legitimate update. But that's a pre-image attack, and SHA-1 is still believed to be secure against those. So: is this update useless? Not quite — there's still a risk.

Recall that SHA-1 is vulnerable to a collision attack. This means that if two updates are prepared simultaneously, one good and one evil, there can be a signed, malicious update. In other words, the threat model here is a corrupt insider. By eliminating use of SHA-1 for updates, Microsoft is protecting users against misbehavior by one of its own employees.

Now, perhaps this is just housekeeping. Microsoft can get SHA-1 out of its code base, and thus discourage its use. And it's past time to do that; the algorithm is about 25 years old and does have serious weaknesses. But it's also recognition that an insider who turns to the Dark Side can be very dangerous.

By Steven Bellovin, Professor of Computer Science at Columbia University
Follow CircleID on
Related topics: Cyberattack, Cybersecurity
SHARE THIS POST

If you are pressed for time ...

... this is for you. More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Vinton Cerf, Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Share your comments

Would it not be easier if... Karl Auerbach  –  Feb 26, 2019 2:25 PM PDT

When reading your note I was imagining that the evil insider would be substituting the evil version in lieu of all instances of the pure version.

In that situation would it not be easier for the evil insider to simply discard the good update, prepare the evil update, sign the evil update, and thus never have to be concerned about all of this?

Or are you positing a situation in which the evil insider wants to publish *both* an evil and a pure version such that the two can versions not be distinguished by the digest value?  (And then presumably channel the evil version to a selected set of targets.)

To post comments, please login or create an account.

Related

Topics

Cybersecurity

Sponsored byVerisign

Domain Names

Sponsored byVerisign

IP Addressing

Sponsored byAvenue4 LLC

New TLDs

Sponsored byAfilias

DNS Security

Sponsored byAfilias