Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Google is Hurrying the Web to Kill SHA-1

konklone.com

Post reply on HN
Print view View original

11–20 of 136 posts

Re: Why Google is Hurrying the Web to Kill SHA-1

#11

Post by crazypyro »

valarauca1 wrote: post #3

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 w…

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.

Re: Why Google is Hurrying the Web to Kill SHA-1

#14

Post by tptacek »

[deleted] wrote: post #12
tptacek wrote: post #7

Earlier quoted context omitted.

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

[deleted]

Someone on HN knows this subject much better than I do, but as I understand it, there's no attack in the literature that takes a good certificate request and $2MM as an input and spits out a validating certificate as an output.

This is different than the situation with MD5, where the components needed for a successful attack were known to the literature, and the real work was (a) scaling the attack so that it could perform within the time windows needed to forge a TLS certificate and (b) putting all the pieces together.

(But see upthread with 'pbsd, who is one of those people on HN who knows the subject much better than me).

Re: Why Google is Hurrying the Web to Kill SHA-1

#15

Post by thefreeman »

kajarya wrote: post #5

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 )

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.

Re: Why Google is Hurrying the Web to Kill SHA-1

#16

Post by personZ »

thefreeman wrote: post #15
kajarya wrote: post #5

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 )

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.

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?

Re: Why Google is Hurrying the Web to Kill SHA-1

#17

Post by atonse »

tux1968 wrote: post #13

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

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.

Re: Why Google is Hurrying the Web to Kill SHA-1

#18

Post by simias »

tux1968 wrote: post #13

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

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.

Re: Why Google is Hurrying the Web to Kill SHA-1

#20

Post by higherpurpose »

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

Post reply on HN