Home / Blogs

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

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

Bellovin is the co-author of Firewalls and Internet Security: Repelling the Wily Hacker, and holds several patents on cryptographic and network protocols. He has served on many National Research Council study committees, including those on information systems trustworthiness, the privacy implications of authentication technologies, and cybersecurity research needs.

Visit Page

Filed Under

CircleID Newsletter The Weekly Wrap

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

Comments

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

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.)

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

Related

Topics

Cybersecurity

Sponsored byVerisign

Domain Names

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

IPv4 Markets

Sponsored byIPv4.Global