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

121–130 of 136 posts

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

#121

Post by walterbell »

illumen wrote: post #120
cgjaro wrote: post #99

Earlier quoted context omitted.

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

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.

> 20,000 viewers for two hours can be bought for $20

Is that pricing from a botnet or a company like crowdprocess.com?

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

#122

Post by spatz »

orblivion wrote: post #77

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…

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

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

#123

Post by teddyh »

GeneralMayhem wrote: post #114
cwyers wrote: post #103

Earlier quoted context omitted.

It has to be so frustrating to Google that the people responsible for Android make it so hard for users to upgrade to versions that support SHA-2.

It's not Google's fault the telecoms cripple every phone they sell.

Well, Google knew it would happen, and allowed them to do it.

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

#124

Post by wgoulet »

zaroth wrote: post #60

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

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.

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

#125

Post by nly »

Retric wrote: post #110
silentOpen wrote: post #108

Earlier quoted context omitted.

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

High quality hashes are unique in practice. Suppose every person generates 1 billion files a second * 7 billion people * 1,000 years = ~3x10 ^ 28 call it 10^29. For a collusion among non identical files using a good 256 bit hash you get ~1/(2^256) * (10^29) * (10^29) = ~1/(2^198). Or 1 chance in ~4 * 10 ^ 59 of finding even one collision.

Your math is off a bit[0][1] but you're right, it's a vanishingly small probability of a single collision. This is fairly academic though, when you're talking about an adversary exploiting weaknesses in the algorithm itself, and not a perfect PRF.

[0] http://preshing.com/20110504/hash-collision-probabilities/

[1] http://www.wolframalpha.com/input/?i=%281+billion+*+7+billio...

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

#126

Post by Retric »

nly wrote: post #125
Retric wrote: post #110

Earlier quoted context omitted.

High quality hashes are unique in practice. Suppose every person generates 1 billion files a second * 7 billion people * 1,000 years = ~3x10 ^ 28 call it 10^29. For a collusion among non identical files using a good 256 bit hash you get ~1/(2^256) * (10^29) * (10^29) = ~1/(2^198). Or 1 chance in ~4 * 10 ^ 59 of finding even one collision.

Your math is off a bit[0][1] but you're right, it's a vanishingly small probability of a single collision. This is fairly academic though, when you're talking about an adversary exploiting weaknesses in the algorithm itself, and not a perfect PRF. [0] http://preshing.com/20110504/hash-collision-probabilities/ [1] http://www.wolframalpha.com/input/?i=%281+billion+*+7+billio...

Ops, when counting exponents make sure there in the same base.

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

#127

Post by aeden »

agwa wrote: post #76
zaroth wrote: post #60

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

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…

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?

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

#128

Post by mike_hearn »

avz wrote: post #105
mike_hearn wrote: post #97

Earlier quoted context omitted.

No. They've been quite clear about this. CA's are still selling SHA1 certs because customers are asking for them. They're asking for them because they're compatible with more apps/devices and - until now - browsers treated them the same. So why sacrifice compatibility for no improvement. The Chrome team are right to push this along, but I do have some sympathy for the CA's here too. I read the whole discussion and it…

> So why sacrifice compatibility for no improvement. No improvement? How about improvement in security?

The reality is most people running websites that use SSL are not security experts and cannot evaluate the weakness of SHA1 vs SHA2. So they trust the defaults, which are SHA1 (in e.g. openssl). Their goal is to get the padlock, not to achieve some other notion of security.

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

#129

Post by bitJericho »

sleevi wrote: post #109
bitJericho wrote: post #81

Earlier quoted context omitted.

Then what is the signature for?

Because it was seen as easier to use X.509 (aka a certificate) as a delivery of a Trust Anchor (specifically, a "subject name" and "public key" pair) than to invent yet another storage format. Certificate verification stops when you encounter a TA. Some libraries do the wrong thing and check that the terminal cert is self-signed, but that's not actually required (nor recommended). You just check that the previous cer…

That makes perfect sense, thanks!

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

#130

Post by hevsuit »

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
Post reply on HN