Why Google is Hurrying the Web to Kill SHA-1

https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1

by mathias • 12 years ago

423 130 12 years ago

tptacek9• 12 years ago

Two nits, both pedantic:

An attack on SHA1 that makes certificate forgery viable within the next few years doesn't seem very likely, although over the long term it might be. The attack on SHA1 isn't like the attacks on RSA-1024; my sense is that the literature already knows how to break RSA-1024 given enough compute, but does not know how to do that with SHA1. Further, factoring RSA-1024 provides an attacker with a total break of RSA-1024 TLS, but not every attack on SHA1 will necessarily do the same.

Second, there's a subtext that SHA-3 having been standardized somehow puts the writing on the wall (albeit, a far-away wall) for SHA-2. Not so; SHA-2 could remain secure (in its TLS certificate use case) indefinitely.

konklone11• 12 years ago

@tptacek - I tried to include enough detail to make it clear that a SHA-1 forgery isn't as trivial as a brute force. That you'd have to "coax a Certificate Authority" into issuing you a targeted forgery, and that that's what the MD5 team did.

The SHA-3 mention at the very bottom was in the spirit of "all things are broken eventually", not a specific comment on SHA-2 (though my understanding is that there are some conceptual weaknesses that have been identified). I don't think I've confused the issue there, but if I see confusion I'll definitely update it.

tptacek9• 12 years ago

Another way to think about SHA2 and SHA3 is that it's entirely possible that SHA3 could fall before SHA2 does. They are unrelated algorithms.

I'm also not comparing attacks on SHA1 to brute force (which is also not how MD5 fell).

It would be helpful, when people posit attacks on SHA1, if they'd cite the literature they're referring to.

xkiwi2• 12 years ago

Why SHA-2 instead of RSA 4096 or SHA-256? Even the RSA is compromised but 4096-bit will take a lot more(maybe few more hours) resources to decrypt.

==edited==

Thank you for the reply.

konklone11• 12 years ago

SHA-256 is a form of SHA-2.

schmichael• 12 years ago

SHA-256 is one of SHA-2's hash functions: http://en.wikipedia.org/wiki/SHA-2

wyager• 12 years ago

You use a hash function (e.g. SHA256) to make the hash of the page and a signature algorithm (like RSA 4096) to sign it.

pbsd2• 12 years ago

To out-pedant you: even assuming that the differential collision attacks we know about are incorrect [1], we absolutely know how to break SHA-1 given enough compute, that is, roughly the same resources needed to break RSA-1024. The answer is generic collision finding with parallel rho [2].

[1] https://marc-stevens.nl/research/papers/EC13-S.pdf [2] http://people.scs.carleton.ca/~paulv/papers/JoC97.pdf

tptacek9• 12 years ago

You haven't so much out-pedanted me as refuted me. :)

yuhong2• 12 years ago

It seems that the identical prefix collision would be good to investigate doing an ASIC on.

cgjaro• 12 years ago

I don't know if "10 years" falls in your definition of "next few years".

For a viable rogue CA attack, you need a chosen-prefix attack. Current best research (https://marc-stevens.nl/research/papers/EC13-S.pdf) shows it should take 2^77.1 SHA-1 compression calls to do a chosen-prefix attack. Say this is improved to 2^65 within the next 10 years. Right now a good GPU (AMD R9 290) can do 3 billion SHA-1 compression calls per second. Say Moore's Law continues for the next 10 years and that 10 years from now a GPU can do 20 billion SHA-1 per second. So 10 year from now, 100 high-end GPUs should be able to produce a rogue CA with colliding SHA-1 signature in 7 month of compute time.

Change one little assumption and assume the best attack ends up being 2^60 instead of 2^65. In this case, a viable attack could certainly be carried out in the next 3-4 years.

You can't cross your fingers and hopes such an attack will not be discovered. The time to abandon SHA-1 is now.

tptacek9• 12 years ago

I agree.

illumen• 12 years ago

Firstly, GPUs haven't followed More.

Secondly, multiple sha1 ASIC exists.

Thirdly, WebGL has made it trivial to gain vast GPU resources. 20,000 viewers for two hours can be bought for $20.

Fourthly, I don't care.

userbinator• 12 years ago

my sense is that the literature already knows how to break RSA-1024 given enough compute

"given enough compute", we can break any crypto just with pure bruteforce, although in practice I believe there's a point at which the amount of power that would be required becomes physically impossible due to the limits of computation within the universe (i.e. Moore's Law will definitely end sometime). To me, that says using extremely large hash sizes can keep things quite secure - even attacks that reduce complexity by many orders of magnitude could be impossible in practice - e.g. a 2048-bit hash for which a 2^500 complexity attack is found won't be any less practically secure.

...unless we somehow discover that P = NP, in which case the world could become a very interesting place...

valarauca13• 12 years ago

Also its not exactly fair to compare the Flame attack on MD5 and compare it immediately to SHA-1. Unless you are the US or China you likely don't have the resources necessary to pull off that sort of attack.

The Flame attack's math was invented by an internal government cryptographic think tank. And still had to leverage massive computational power, just not in the order of 100's of millions.

The idea a rogue group who have access to (both of) these resources is slightly idiotic. It would be far easier for them to attack RSA directly if you had 10's of millions of dollars of computers. There are a lot of 1024 bit certs you could pick off for easy profit.

brador• 12 years ago

Botnet.

ErikRogneby• 12 years ago

Exactly.

valarauca13• 12 years ago

As I stated.

The computation power needed to break SHA-1 is higher then attacking RSA. So if you are financially motivated attacking RSA has a higher ROI.

crazypyro• 12 years ago

Is it not far easier to acquire the necessary computing power than it was in past? As more and more people converge on the internet, the attack vector increases dramatically as well. How much easier is it today to get the same botnet the government used for Flame? Furthermore, the idea of safety behind computational difficulty is going to be eroding away quicker than ever, in the future.

kajarya• 12 years ago

Everyone is vulnerable: https://www.google.com, https://www.facebook.com, https://www.svyft.com as per the link provided in the article (https://shaaaaaaaaaaaaa.com)

tptacek9• 12 years ago

Vulnerable to what? Perhaps better to say, "everyone would be vulnerable".

xkiwi2• 12 years ago

Https is to prevent wiretapping and man-in-the-middle attacks.

The problem now is even you established HTTPS connection, the weak SHA-1 encryption will not protect you.

mathias• 12 years ago

Luckily shaaaaaaaaaaaaa.com itself is fine: https://shaaaaaaaaaaaaa.com/check/shaaaaaaaaaaaaa.com

thefreeman• 12 years ago

From the OP:

If you poke around Google's SSL configuration, you'll see that (!) they use certificates signed with SHA-1. But each certificate expires in 3 months, a short-lived window that reduces the chances that a certificate could be forged, while they migrate to SHA-2 in 2015.

personZ• 12 years ago

If going SHA-2 only requires a request flag, why so long for a transition? Is there some downside (e.g. old clients that don't support it) that holds Google off?

the_watcher• 12 years ago

My company website is one of the only ones I tested that actually passed. At first I thought there was simply a shocking lack of adoption, but based on this thread, seems like there is some level of "wow, this is nowhere near as common as it should be," and some level of the tool being somewhat overly strict on what passes.

Either way, Google has made it pretty clear that they want at least SHA-2 certificates, which, so long as they call it out in address bars, warning interstitials, and make noise about SERP impact, means that this is the way things are going.

Perseids5• 12 years ago

You have it kind of backwards. Not these sites or their certificates are vulnerable, but the certificate signing process itself is. And by extension all browsers that accept SHA1 certificates anywhere are. To clarify, what the attack does is generate two certificates that have the same SHA1 hash, one of them legitimate and one of them illegitimate. In the worst case scenario the illegitimate one is an itself an intermediate CA, which means the illegitimate one can MITM any connection. You send the legitimate one to the CA to get it signed. When you get it back you swap the legitimate certificate with the illegitimate one - which is possible as both have the same hash - and voila, you have broken TLS world wide.

Having a certificate with SHA2 will not save you. A client under attack will not even see it. The only thing that helps is stop accepting SHA1 certificates (and especially SHA1 intermediate CAs) globally. All this stuff about accepting short lived certificates is only a publicity stunt by Google to raise awareness about the issue (an attacker can forge a certificate with any expiry time she wishes).

raldi3• 12 years ago

Can someone post a summary of the part of the story hinted to by the headline? I couldn't find it.

squeaky-clean3• 12 years ago

It's one of the links early in the story. (It's pretty link heavy, so it can be hard to miss. 6th link in).

Basically, by 2015, Google will update Chrome to show websites with HTTPS certificates using SHA-1 as "insecure." The level of insecurity shown will get more severe over time, as well as being based on when your certificate expires. Here is the full link for details:

http://googleonlinesecurity.blogspot.com/2014/09/gradually-s...

raldi3• 12 years ago

That's What. The headline hints at Why, but never delivers.

tux1968• 12 years ago

Would be interesting to know how this affects Git version control, which has SHA-1 at its core.

atonse• 12 years ago

This is for SSL and certificate validation - Google's move won't affect git in any way.

Git uses it to ensure that the data that comes out is exactly what went in (like a much better checksum than md5 or crc32 etc).

I don't know what the security implications are on the git side... I suppose an attacker could try to figure out how to change source code in a way that it preserves a commit log.

simias• 12 years ago

I assume you would need to forge a meaningful (and potentially harmful) commit with the same SHA-1 as an existing one to do arm. That's probably more difficult than forging an SSL certificate (since the actual contents of the blob are more constrained that the certificate file, probably). I'm also not really sure what would happen if commits made after the "compromised" one happened to conflict with it but I'm pretty sure the devs would notice something fishy going on pretty quickly.

That being said git/mercurial and friends will have to transition to an other hashing algorithm sooner or later but it's not as urgent as web certificates security-wise.

x1798DE• 12 years ago

It seems to me like the time horizon for an attack on git based on SHA-1 collisions would be much, much longer than other similar collision attacks (like signing binary executables), because of the sequential nature of version control. Presumably the utility of such an attack would be to maliciously insert code into an earlier version of the code to hide its origins, in which case for each commit on the file, they'd need to calculate a collision that contains their changes plus whatever legitimate changes have been made to that file.

I'm not familiar enough with the inner workings of git to know, but I imagine it would be a pain to juggle updating new commits from people working from a local copy of the repo - potentially your malfeasance would be detected quickly if you tried to calculate a diff between the old file and the new file from the local copy (which would presumably not be updated, given that the checksums match).

That said, if people are in the habit of signing their tags/commits using SHA-1, then that would be just as vulnerable as any other signing problem.

0x0• 12 years ago

I'd think the content of the blob is less constrained, because you can put whatever padding fluff you need at the end of the commit message to adjust the sha1 of the commit. To cause harm, you'd include the trojanized code in a different file which your colliding commit blob references. (So, you'd need to include multiple blobs, but only the commit-message one needs to collide with an existing one)

A collision in commit hashes would mean you could no longer trust a signed tag, for example.

Look up the old stripe-ctf "gitcoin" challenge and you'll see it really is quite easy to meddle with commit hashes :)

slavik81• 12 years ago

Google's decisions with respect to certificates don't really affect git much. But, if you're curious about how git handles pulling from repositories containing malicious hash collisions, Linus has talked about that in the past:

If it has the same SHA1, it means that when we receive the object from the other end, we will not overwrite the object we already have.
So what happens is that if we ever see a collision, the "earlier" object in any particular repository will always end up overriding. But note that "earlier" is obviously per-repository, in the sense that the git object network generates a DAG that is not fully ordered, so while different repositories will agree about what is "earlier" in the case of direct ancestry, if the object came through separate and not directly related branches, two different repos may obviously have gotten the two objects in different order.
However, the "earlier will override" is very much what you want from a security standpoint: remember that the git model is that you should primarily trust only your own repository.
So if you do a "git pull", the new incoming objects are by definition less trustworthy than the objects you already have, and as such it would be wrong to allow a new object to replace an old one.

...

in this case, the collision is entirely a non-issue: you'll get a "bad" repository that is different from what the attacker intended, but since you'll never actually use his colliding object, it's literally no different from the attacker just not having found a collision at all, but just using the object you already had (ie it's 100% equivalent to the "trivial" collision of the identical file generating the same SHA1).

http://stackoverflow.com/q/9392365

kilovoltaire2• 12 years ago

Seems like the SSL certificates that CloudFlare automatically generates for sites are SHA-1 signed.

Anyone know if they're planning to upgrade to SHA-2?

konklone11• 12 years ago

They can be seen in the Chrome discussion thread, complaining to Google that the timeline is too aggressive. But they're a good company, and I imagine they'll update as soon as they can.

kilovoltaire2• 12 years ago

Ah interesting, thanks.

(For anyone else, here's the link: https://groups.google.com/a/chromium.org/d/msg/blink-dev/2-R...)

jgrahamc• 12 years ago

We are going to do the following:

1. Reissue our SHA-1 based certs to meet the deadlines specified by Chrome so that no customer sees a warning in Chrome.

2. In the future, we will also have an automatic fallback system so that for poor clients (that only support SHA-1) we are able to dynamically provide 'old' certificates. For up to date clients we will not use SHA-1 at all.

higherpurpose• 12 years ago

I'd like to see them gradually downgrade all non-PFS connections. Non-PFS connections should be considered medium-to-highly vulnerable, and shouldn't receive a green icon in browsers.

Unfortunately, they've just recommended everyone to use "2048-bit keys" when they announced the HTTPS Google ranking policy. A lot of developers won't understand the difference between a 2048-bit RSA key and a 256-bit ECC key, so they'll just pick RSA, since "Google said 2048-bit keys!". Sooo...maybe this policy will come in 10 years.

http://googlewebmastercentral.blogspot.com/2014/08/https-as-...

phlo• 12 years ago

This seems to be a case of a slightly unfortunate wording.

Google calls for the use of 2048-bit key certificates, a very reasonable demand. In the forward secure use case, the certificate key is only used for authentication. Using, say, ECDHE_RSA as your key exchange mechanism allows for small but secure elliptic curve keys (EC), forward security (DHE) and uses the certificate's RSA key for initial authentication (RSA).

Certificates can actually use ECDSA keys, and some companies will support this (Symantec and CloudFlare off the top of my head), but I'm not exactly sure about browser support. The chief advantage, as far as I know and assuming no new breaks in RSA, is a strong reduction in certificate file size (256-bit vs 3k RSA equivalent), not forward security.

taf2• 12 years ago

The issue here is old clients... Does anyone know how old clients would handle SHA-2 certs, would they just get a warning saying the site is insecure but still be able to visit the site over an encrypted connection or do they break completely... I guess - I'll have to run a few tests this afternoon and see how windows XP performs.

Gregordinary• 12 years ago

Windows XP will need Service Pack 3 to support SHA2 certs.

Windows Server 2003 will require a couple manual hotfixes to get SHA2 support.

http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-w...

bpoyner• 12 years ago

Please let us know. Here's a table showing when SHA-2 support was added to various browsers.

http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_br...

rythie• 12 years ago

I've seen in a lot of places that Chrome only supported SHA-2 since version 26 (2013). I find this hard to believe (Firefox supported it since 2005) and I can't find a solid reference for it. However I note that this page from 2008, says Chrome supports it https://www.tbs-certificates.co.uk/FAQ/en/476.html (e.g. from version 1)

bla2• 12 years ago

It's surprising how much energy Certificate Authorities invest into arguing about this. Instead, they should invest that energy into improving their SHA-2 support and helping their customers migrate.

tptacek9• 12 years ago

Nothing should surprise you about the obstinacy of CAs.

mike_hearn3• 12 years ago

They are businesses. Their customers are mostly businesses. SHA1 is, for most businesses that only want a padlock to reassure their customers, just peachy. A CA that hassles their customers and says "you need to do complicated extra work" is put at a disadvantage to other CA's that have a "customer is always right" kind of attitude. Combined with tools that default to SHA1, and customers that may depressingly actually have Windows XP SP2 terminals still in production use, and you get feet dragging.

I don't think this is inherently a problem with the CA model. Rather it's what you'd expect in a competitive market that is basically selling a binary commodity product (a padlock icon), given textbook economics.

mlissner• 12 years ago

What's weird though is that they have a consortium. They could have all agreed simultaneously to stop issuing SHA1 certs years ago and at no market loss. But they didn't.

michaelbuckbee2• 12 years ago

A while back I launched a SSL scanner [1] and got tons of feedback from people at Facebook, Google, Microsoft.

The most divisive item was how to represent SHA1 deprecation. The OPs article doesn't really touch on it, but the reason that Google and everyone else haven't moved on is that there still exist a sizeable number of clients that can only accept SHA1 (and will error on anything else).

I actually suspect that large sites like Facebook, etc will maintain multiple certs at the different levels and dynamically serve the best one up that the client can support. They're already doing things like only serving HSTS to browsers that identify as Chrome, etc.

1 - https://www.expeditedssl.com/simple-ssl-scanner/scan?target_...

konklone11• 12 years ago

a) This is great. Also, a friend linked me to Expedited SSL yesterday and I link to it in the bottom of this post.

b) I think its SHA-1 scanner is mistaken - it flags my site as using SHA-1, but it's SHA-2 in every cert in its chain: https://www.expeditedssl.com/simple-ssl-scanner/scan?target_...

Someone12342• 12 years ago

The root CA, USERTrust, is SHA-1 signed.

Everything else is SHA-2 however as you said.

michaelbuckbee2• 12 years ago

Thanks for the link! Also, I'm investigating the issue as you are correct that your certs all look good.

Perseids5• 12 years ago

I actually suspect that large sites like Facebook, etc will maintain multiple certs at the different levels and dynamically serve the best one up that the client can support.

How would you do that? When the TLS connection is established you know nothing about the client except its IP address. All of the interesting information about the browser is transported via the HTTP stream which is tunneled inside the TLS connection.

HSTS is simple by comparison, as it's only an HTTP header.

sk5t• 12 years ago

Not true; consider SNI as an example of the server choosing a certificate as part of the handshake, without a cleartext exchange of the hostname.

http://en.wikipedia.org/wiki/Server_Name_Indication

nitrogen• 12 years ago

I think they would use the list of ciphers the browser says it will accept in the TLS handshake, or maybe TLS version.

Anything from ClientHello could be used: http://en.wikipedia.org/wiki/Transport_Layer_Security#Basic_...

zaroth2• 12 years ago

So where is the fully automated solution for rotating certificates?

I've been looking for a CA who will provide an API to send the cert request, an easy way to prove the domain ownership which doesn't involve SMTP, and the signed cert handed straight back from the API, but haven't found it.

So far the most I've been able to streamline my certificate requests is to automate generating the CSR, skip setting the MX record, just bind SMTP to www.domain.com, get the validation email at 'admin@www.domain.com' and auto-forward to my actual email address... so it's mostly automated, but I still have to copy/paste the cert request string into the CA's webform, click the 'Approve' link in the forwarded DV mail, and then copy/paste the final cert from inside email back to the shell where it can finish the import.

agwa3• 12 years ago

I'm working on this problem: https://sslmate.com/

Right now it's just a command line client, but a public API is in the works. And this week we'll be announcing a solution to the cert rotation problem (basically, you'll be able to drive your renewals from cron - it's going to be really cool). You might want to follow @sslmate on Twitter - this is just the beginning of some very exciting stuff for automating SSL cert deployment. Also feel free to email me (address is in my profile).

Sadly, we're still SHA-1 only, because that's all that our certificate authority (RapidSSL) supports at the moment. On the other hand, once we make renewals dead simple, you can just buy 1 year certs and it won't be a big deal upgrading to SHA-2 in a year's time. (After all, even Google is still using SHA-1, but they can easily switch thanks to their 3 month certs and well-oiled cert deployment machinery.)

zaroth2• 12 years ago

Very interesting, thanks! I unpacked the .deb, the nodejs source is pretty easy to follow, so I'd say you pretty much already have the public API done. ;-)

The /link API is interesting, versus generating a token on your site through the UI. You might want to consider allowing an explicit $$ limit on /buy, since you store the api-key in the clear (albeit in a config file set to 0600).

It looks like you still rely on being able to receive an email on the domain and click an approval link, though. I'm sure this is a RapidSSL requirement, but it makes full automation more complex (certainly not impossible).

aeden• 12 years ago

Are you certain RapidSSL is not accepting SHA-2 is not accepted by RapidSSL? Section 6.1.5.1 of http://www.rapidssl.com/resources/pdfs/geotrustCPSv1dot10.pd... seems to indicate that they do support SHA-2.

Did you speak with them about this yet?

wgoulet• 12 years ago

Commercial solutions exist too; the company I work for (Venafi https://www.venafi.com) makes certificate management software that is designed to solve this very problem.

mjhoyer• 12 years ago

When I use the sha tool against google.com, it shows them using SHA-1.

zachberger• 12 years ago

Google has stated they wont complete their transition until 2015

Cyranix• 12 years ago

Just to be clear, since I often end up confused on this point — is the use of SHA-1 with HMAC, outside of the context of SSL, still acceptable?

cbr• 12 years ago

It depends how motivated your attacker is. Could someone make a lot of money if they could get SHA-1 collisions with your application?

Perseids5• 12 years ago

The use of SHA1 with HMAC, inside as well as outside of the context of SSL is still acceptable, yes. Even against a nation state attacker. The reason attacks on HMAC(k,m)~=SHA1(k||SHA1(k||m)) are much more difficult than general collision attacks is that as an attacker you do not know the internal state of the hash function when you are trying to create a collision with m, as the secret key is input in the hash function first.

The attack vector for TLS certificates is the (asymmetric) signature which signs a plain SHA1 hash message. I'm still disappointed that after all the experiences they have had with MD5 they haven't yet started to randomize the hash in the signature (sign SHA1(random||message) instead of SHA1(message) ) which would boost the signature security to that of HMAC.

orblivion2• 12 years ago

Understanding that this is a naive outsider perspective, I find it strange that it's any sort of emergency when a single collision has yet to be produced. And then, does the latest hash collision attack allow you to make a collision with a _specific_ target or just make a collision in general? Finally, even if you hit the target with some junk that happens to hash to the same thing, is it going to be in correct file format, and within an acceptable size? It seems like there are a handful of hurdles for the bad guys to go over before we're in danger.

I know crypto is not to be taken lightly, and I'm glad people would rather be safe than sorry, and I'll avoid SHA-1 in my own personal security use (`sha256sum` is sha-2 right?). I'm just curious.

paulannesley• 12 years ago

when a single collision has yet to be produced

No collisions published to the public doesn't mean no collisions have been found.

As the article says; “we should assume that the worst vulnerabilities go undisclosed.”

PeterisP• 12 years ago

The point is that currently producing a single collision may cost a couple million dollars of brute force for now. So we should expect it to be used (there are attacks where that much money is invested, either a very valuable target or very many low-value targets), but we should expect to see one only after a highly targeted attack is detected and analyized - in the case of Flame, those steps took a few years.

Some government agency MITM'ing major social sites or email providers would be rather possible at that cost.

spatz• 12 years ago

When a collision is produced it will be too late. The time to act is before that happens.

orblivion2• 12 years ago

I guess that's the surprising part. I figured that that's just the first hurdle, there's still the file length and format.

vtlynch• 12 years ago

This article is amazing! I work in the SSL industry and this is a huge help in summarizing exactly whats going on.

@konklone, have you followed the CAB Forum's mailing on this topic? Its the most I've seen them argue in well over a year.

konklone11• 12 years ago

I have, it's one of the links in there. I truly loved reading that discussion.

sbierwagen• 12 years ago

An unrelated annoying thing: I want to disable TLSv1 support for my site, for obvious reasons. I don't care about backwards compatibility for my personal site, but I still can't flip the switch... because Googlebot doesn't support anything newer than TLSv1.

ankit4282• 12 years ago

Ironically, www.google.com - Itself is using SHA-1 :)

ankit4282• 12 years ago

Ironically, www.google.com itself is using SHA-1

Ref: https://shaaaaaaaaaaaaa.com/check/www.google.com

jrochkind1• 12 years ago

Thank you google.

I'm a developer, but I'm not responsible for SSL cert acquisition.

The ONLY way I can get the people responsible for that to stop using SHA-1, is to tell them that user's browsers are sending a warning/error message on it.

I will eagerly await Chrome doing that.

brongondwana• 12 years ago

"SHA1 and other hash algorithms generate a digital fingerprint that in theory is unique for each different file or text input they sign."

... and there it goes, any credibility I would give the author. There's dumbing down the content for a non-technical audience, and there's not understanding.

blibble• 12 years ago

what's wrong with that statement exactly?

waitwhat• 12 years ago

maybe the use of "sign"?

silentOpen• 12 years ago

Two things:

1. Hashes don't "sign" things (not directly anyway)

2. Hashes aren't unique in theory or practice (using a 256-bit hash on every 257-bit number will generate 2^256 collisions by the pigeonhole principle).

konklone11• 12 years ago

I could have said "practically unique", instead of "in theory is unique" there, but I make the distinction more clear just below that and note that there are always collisions out there.

maxtaco• 12 years ago

SHA1 is the only supported hash algorithm for PGP key fingerprints.

bjornsing• 12 years ago

I'm not saying the conclusion is wrong, but the reasoning likely is: there's a huge difference between a collision attack and a so-called second pre-image attack [1]. To impersonate a website protected with an SHA-1 certificate you'd have to mount the second kind.

Walker's estimate suggested then that a SHA-1 collision would cost $2M in 2012, $700K in 2015, $173K in 2018, and $43K in 2021.

If you adjust those cost estimates for the fact that a second pre-image is needed they look more something like this:

An SHA-1 second pre-image attack (needed to e.g. impersonate an SSL protected website) would likely cost about 10^26 USD in 2021... By comparison world GDP is only about 10^14 USD.

Better safe than sorry though. :)

1. https://www.ietf.org/mail-archive/web/pkix/current/msg30395....

blueking• 12 years ago

Another PR stunt Google ? No that wont work.

hevsuit• 12 years ago

One would think it would have been a good opportunity to change to SHA-2 after Heartbleed, since most websites had to get reissued certificates anyway. Since this process is a pain in the * then one could have killed two birds with one stone at the time. Alas

konklone11• 12 years ago

In fact, Heartbleed helped a lot: http://news.netcraft.com/archives/2014/05/05/sha-2-very-cryp... But there's a long way to go.

foomen• 12 years ago

Or cut to the chase and just deploy DANE, so that we don't need CAs to sign anything?

http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Nam...

dennisgorelik• 12 years ago

What does stop Google Chrome simply disallow new SHA-1 hashes that collide with known list of SHA-1 hashes for existing certificates?

That would allow non-colliding SHA-1 certificates function as usual and prevent millions of people from major headaches related to speedy certificate migration.

Why Google is Hurrying the Web to Kill SHA-1

Related Stories