SHA-1 Deprecation Update | Hacker News Reader

SHA-1 Deprecation Update

blogs.windows.com

70 pointsrobin_reala38 comments

If the cost of creating a collision is $75K, it's far too late to be deprecating SHA1.

Even if everyone were to somehow remove SHA1 instantly now, there is stuff that has (for example) been authenticated using SHA1-HMAC over the last year which will still be relevant for years. It's not hard to think of cases where spoofed messages from a user a year ago are useful to a malicious attacker.

As to the specific hmac-sha1 construction -- hmac are not simply sha sums. If the hmac key is not shared, the hmac does not solely rely on the collision resistance of the prf. see: https://cseweb.ucsd.edu/~mihir/papers/hmac-new.html

Interesting. The only proof of HMAC efficacy I had seen was one by contradiction, where a false HMAC that validates would imply a collision on the underlying hash. (I'm saying this from memory, which is widely known to be unreliable).

Exactly why Google moved to an "aggressive" timeline to deprecate SHA-1. Schneier predicted the cost of SHA-1 collisions years ago and said criminal groups will be able to create collisions by 2018 - which means you needed to start pushing for killing SHA-1 support years earlier.

But when Google did that everyone jumped on them for "trying to control the Internet" or something (because obviously trying to make the Internet adopt stronger security is a power tripping thing). I hope at least now they've seen the error in their ways.

Oh, and it turns out Schneier was actually too optimistic about the costs of SHA-1 collissions - by about an order of magnitude:

> 211 * 28.4 = 219.4 ~ $700K by 2015

https://www.schneier.com/blog/archives/2012/10/when_will_we_...

And Google's push to deprecate SHA-1 to try to drag the internet into modern security practices pales in comparison to Apple's ATS implementation, which has a brutally modern set of minimum requirements (TLS1.2, 256-bit elliptic curve, SHA-256, 2048-bit RSA key).

And given Apple's extremely vocal stance on privacy and security, and their 'sudden' addition of ATS, it wouldn't surprise me if ATS became a hard requirement in iOS 10.

ATS has nothing to do with web browsing though.

HMAC tolerates collisions in the underlying hash function.

That said, stop using SHA1.

The basis of it is interesting to me: breakthroughs in finding collisions have lowered cost estimates to about $75k to break a single collision (based on GPU rented from Amazon EC2). It's interesting to see it quantified that way.

It's been common to rank computational security in that manner for a long time.

I would prefer it be measured in size of botnet. Criminals don't use EC2. They use hacked boxes. They have no cost beyond compromising the machine.

Sure, but it provides an interesting context. $75k at Amazon's EC2 prices gives you a good idea of what the ballpark is - i.e. reasonably accessible for any large organization, esp. criminal organizations.

If EC2 can collide SHA-1 with $75k of rented GPU time, imagine how trivial it is for an organization willing to buy $100k of dedicated GPU compute hardware to devote to colliding SHA-1 certificates. You don't even have to botnet once you have enough working capital.

Never mind how trivial it is for an organization like the NSA or GCH to do this sort of thing with their existing hardware.

Just to note, with large GPU farms the cost of the power to run them will exceed the hardware cost in a matter of weeks.

The biggest risk doing this on a botnet that I can see is that there's a chance some researcher looks at what you're doing and alarms the world before you get a result. There's no big risk of that on EC2.

Using a botnet for compute has opportunity cost attached to it. However, I have no idea about the usual prices when they are rented.

If certs would have included both MD5 and SHA1 signatures, and required both to match, would that have bought a lot of safety? What if another hash had been added too? Because then you'd need to find simultaneous collisions across multiple functions, which at least sounds a lot tougher. But perhaps not?

Combining weak hashes doesn't provide any assurance. Let's assume that finding a new way to break MD5 is a rite of passage into certain professional cryptoanalyst circles. Do you know what they know?

Besides, there are no X509 signature types that are a combination. You'd need to update browsers... and it would be much easier to just update your hash.

Well I'm thinking more along the lines of future-proofing designs. Like right now, should a new protocol use both SHA2 and SHA3, just to be safe?

"new protocol" is likely going to be less secure than TLS1.2. And TLS1.2 doesn't allow multiple signatures - it's usually in the form of "(hash)-with-(encryption)" (for example oid 1.2.840.113549.1.1.5 - SHA-1 with RSA Encryption) and since that's embedded in the hashed contents, you can't easily add new signatures that require specific parameters.

I don't mean related at all to TLS. I mean in general, is the principle of using multiple algorithms that bad? If, in an alternative universe certs were signed with MD5 and SHA1, would that not have been a practical defense to buy some more time? And thus for new, incompatible protocols, is it not a safer choice to use a couple of algorithms? That way if SHA2 or 3 are found to have some terrible weakness, you're still OK. And if practical attacks are found on both, it still might not mean that such attacks work together?

There's a bit of precedent in 3DES which just runs the same algorithm 3 times in a row... Which I guess you could do by using the same hash algorithm several times on the same input plus some fixed data or transform. So even though you can find two inputs a and b that h(a) = h(b), you might not be able to get h(f(a)) = h(f(b)) hmm? (Though I understand certain hash attacks will do exactly that for certain values of f.)

In the case of SSL certificates, the SHA-1 or SHA-256 hash algorithm is being used to verify the integrity of the certificate. It assures that the information in the "To be signed" certificate sequence (e.g. domain name, organization, country, etc.) matches what the CA signed.

While the motivation to move to SHA-256 is motivated by SHA-1's susceptibility to collisions, the concern for many is that legacy systems may not support SHA-256, meaning older clients won't be able to connect to sites using SHA-256 signed certificates. In general as long as a client is on Windows XP SP3+ or OS X 10.5+ they'll be all set [1].

While this isn't a feature of X.509 certs, if you were to implement "Dual Hashes" (using SHA1/SHA2 as an example), you'd have a scenario where older operating systems may not be able to validate the newer hash and only the older, now insecure hash essentially defeating the purpose.

Changing a cert from SHA-1 to SHA-256 in most cases is a matter of reissuing or re-keying your certificate with your CA. Most CAs offer this for free, though some may charge.

Side note: In the case of document signatures, there is an XML signature standard called XAdES. There are different levels of XAdES signatures, the strongest being XAdES-A [2] where the -A is for "Archive". When you place a signature on a document, to make it valid long term (beyond the expiration date of your certificate) you can add a 3rd party timestamp and embed revocation data into the signature. But what happens when the hash algorithm used by the timestamp server is considered insecure? XAdES allows you to go back and add additional timestamps with newer hash algorithms to make this "future proof". Similar, but not quite the same as what you were suggesting.

[1] SHA-256 Compatibility: https://support.globalsign.com/customer/en/portal/articles/1...

[2] XAdES-A: http://www.w3.org/TR/XAdES/#Syntax_for_XAdES-A_form

While Microsoft is still debating whether it should disable SHA-1 in mid-2016, early 2017 or at the end of 2017, Google is already moving to require all certificates to support Certificate Transparency, to vastly increase the trust we can put in Certificate Authorities. As per their article they are still only "considering" removing SHA-1 support by mid-2016.

Microsoft needs to stop wasting time with obvious stuff (like deprecating SHA-1, RC4, MD5, and all that), and be a little more aggressive with securing their products as well.

Keep in mind that Microsoft is a large organization, and they have to carefully consider which action is actually 'the greater good'. For example, making a breaking change (like deprecating SHA-1 in Edge) might force external developers/vendors to update their servers to SHA-256, but it might also encourage enterprises to avoid updating to Windows 10 entirely, and, overall, that's far worse than letting SHA-1 certificates kick around for another six months (especially since those certs won't work with iOS 9, Chrome, or Firefox anyway).

Apple can get away with ATS because for every service/site/app that doesn't bother to update, there are ten other apps waiting in the wings to steal your users. On Windows, there's little incentive for most people to upgrade, and strong existing disincentives for enterprises/schools/organizations.

Good, they should accelerate it.

However, I wish that Microsoft made it extremely clear in these announcements that root certificates are not subject to SHA-1 collision attacks. Certain people [1] have misunderstood the situation and removed trust for SHA-1 signed roots (and that project is definitely not alone). Mozilla's announcement [2] does draw a distinction, but it's quite easy to miss. CAs like Entrust are much more clear about this, since their business relies on it.

It is security theater [3] to tell users that they shouldn't use a SHA-1 signed root if they want their connections to be secure. Security vulnerabilities need to be very simply and clearly communicated -- otherwise you get solutions based on preconceived notions and simplistic "X is always BAD" thinking that do more harm than good.

In this instance, people have spent days debugging connectivity issues and opening tickets with service providers. And the reasoning behind the move is not based in fact -- Mozilla has NOT removed SHA1 certs from their trusted roots [4] and they have announced no timetable in which to do so. It's simply because someone heard "SHA-1 is bad" and acted accordingly.

The current SHA-1 deprecation push applies only to chain and end certificates, not to roots -- removing trust for SHA-1 signed roots is not necessary to prevent these sorts of attacks and it is much too soon to take that step in any environment that talks to systems which you don't control on the public Internet.

[1] http://certifiio.readthedocs.org/

[2] https://blog.mozilla.org/security/2015/10/20/continuing-to-p...

[3] https://github.com/certifi/python-certifi/issues/26#issuecom...

[4] https://mozillacaprogram.secure.force.com/CA/IncludedCACerti...

Can anyone point to an existing published SHA-1 collision?

FTA: https://sites.google.com/site/itstheshappening/

There are freestart collisions, but no actual collisions yet.

It seems surprising that if it's that cheap to find one no one has credibly claimed to have done it yet.

While there is no published sha1 collision as of now, we do have a freestart collision: https://sites.google.com/site/itstheshappening/ (Linked in the article as well).

The issue being that sha1 collisions are so close that they are in the price range of criminal syndicates and nation states. Its better to deprecate sha1 before that happens.

Slight nitpick: I wish they would use the term "other browser suppliers" instead of "other browser vendors", as Firefox, Chrome, Opera, etc. are not sold for money, they are supplied for free.

But this is good news. Die SHA-1, die!

Honest question. This is the sentence you're referring to:

> We will continue to coordinate with other browser vendors to evaluate the impact of this timeline based on telemetry and current projections for feasibility of SHA-1 collisions

How does "supplier" vs "vendor" impede your understanding there?

Because not all of the development teams, often run by volunteers, are vendors.

Free to me doesn't matter. By one definition a vendor is a company that supplies goods. Some definitions go further to say that they "sell" the goods. However there is nothing to indicate in any definition of vendor that money has to change hands. A company could be a vendor for a particular product and give it away for free. Additionally whether an organization is non profit or for profit really doesn't change the situation.

http://www.investopedia.com/terms/v/vendor.asp

http://www.yourdictionary.com/supplier

Counter-point: https://www.gnu.org/philosophy/words-to-avoid.en.html#Vendor

Counter-point to your counter-point!

https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Pre...

Here are some other entries on that page so you can tell how seriously you should take that list: "LAMP system” "Content" "Compensation" "Creator"

Wow, what a page! My personal favorite is "Creative commons licensed", which you apparently shouldn't use because it's universally more important to distinguish the license based on the FSF's definition of free.

Also replacing various biased, propaganda terms (fair point) with "corrected" biased, propaganda terms (less fair) is an interesting choice.

edit: typo

I'm confused; IE isn't sold for money either.

Now I'm confused, because I didn't ever imply that it was.

In CSS they're referred to as "Vendor Prefixes": https://wiki.csswg.org/spec/vendor-prefixes

Regardless of usage in normal English, in the context of web browsers "Vendor" seem to be the correct terminology.

One of the bigger sources for browser revenue is to be the default search provider in the address bar, or failing that, being one of the handful of default options.

These companies/organizations all engage in financial or service transactions with each other even if they give their product away to end users for 'free'.

Reply on news.ycombinator.com