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

Announcing the first SHA-1 collision

security.googleblog.com

Post reply on HN
Print view View original

301–310 of 524 posts

Re: Announcing the first SHA-1 collision

#301

Post by schoen »

Ajedi32 wrote: post #257
Natanael_L wrote: post #191

Earlier quoted context omitted.

No, that's not the big problem. Every collision of this kind so far just requires a random looking section, and allows another section to be whatever you want. You can just swap out one file for malware.

Ah, sorry. I got confused by this section on shattered.it, which seemed to be saying that merely requiring a certain level of entropy in the resulting documents would be enough to mitigate the attack: > Are TLS/SSL certificates at risk? [...] it is required that certificate authorities insert at least 20 bits of randomness inside the serial number field. If properly implemented this helps preventing a practical explo…

The project's site is referring to an outdated version of the requirement. As I noted above, the requirement they refer to is only a SHOULD (some CAs might not have complied with it) and was replaced at the end of September with a SHALL which requires 64 bits rather than 20.

https://cabforum.org/2016/07/08/ballot-164/

Edit: I told them about this and they've fixed it; it now says "64 bits" instead of "20 bits".

Re: Announcing the first SHA-1 collision

#302

Post by stepik777 »

problems wrote: post #242
m3ta wrote: post #144

To put things into perspective, let the Bitcoin network hashrate (double SHA256 per second) = B and the number of SHA1 hashes calculated in shattered = G. B = 3,116,899,000,000,000,000 G = 9,223,372,036,854,775,808 Every three seconds the Bitcoin mining network brute-forces the same amount of hashes as Google did to perform this attack. Of course, the brute-force approach will always take longer than a strategic appr…

A few considerations though: - Google used GPUs, much of the Bitcoin network relies on fully custom ASICs now and mining without them isn't really profitable anymore - SHA1 hashes can also be computed over twice as fast as SHA256 even on GPUs, so if someone were to go out and build SHA1 ASICs, you could probably do this very, very fast. It's almost certain that intelligence agencies could invest this effort to say, b…

> break SHA1 SSL certs.

It's not possible to break existing SHA1 certificates because this attack is to generate collisions, not finding preimages.

Re: Announcing the first SHA-1 collision

#303

Post by loeg »

Aissen wrote: post #195
Natanael_L wrote: post #187

Earlier quoted context omitted.

Polyglot files are trivial to create, that's the easiest part here.

I didn't say it wasn't, it was for context. Also you need to be polyglot + have enough space for the collision computation. I just checked, it should be really easy. A piece/chunk size in torrents is 64kB. The total size of each PDF in the paper is 2.7kB.

A more common chunk size would be 256 kb - 2 MiB. Yeah, very doable.

Re: Announcing the first SHA-1 collision

#304

Post by chronial »

anilgulecha wrote: post #259
kinkrtyavimoodh wrote: post #245

Earlier quoted context omitted.

No, a commit is not the SHA-1 of the diff. The fundamental object model of Git does not store diffs, it stores the actual state of the source tree as represented by a commit. For instance, here's a commit file [1]— $ git cat-file -p fdf4fc3 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 author Scott Chacon 1243040974 -0700 committer Scott Chacon 1243040974 -0700 first commit A commit object just points to the tree obj…

Correct -- I was being terse: the commit is a function of the changes going in (and metadata like time, authorship). Details: https://gist.github.com/masak/2415865

That is not correct and also not supported by your link. A git commit does not contain any changes. It is always a full sapshot of the repo state.

To have any kind of concept of "change", you need two gït commits. Just like a simple text file.

Re: Announcing the first SHA-1 collision

#307

Post by btilly »

problems wrote: post #242
m3ta wrote: post #144

To put things into perspective, let the Bitcoin network hashrate (double SHA256 per second) = B and the number of SHA1 hashes calculated in shattered = G. B = 3,116,899,000,000,000,000 G = 9,223,372,036,854,775,808 Every three seconds the Bitcoin mining network brute-forces the same amount of hashes as Google did to perform this attack. Of course, the brute-force approach will always take longer than a strategic appr…

A few considerations though: - Google used GPUs, much of the Bitcoin network relies on fully custom ASICs now and mining without them isn't really profitable anymore - SHA1 hashes can also be computed over twice as fast as SHA256 even on GPUs, so if someone were to go out and build SHA1 ASICs, you could probably do this very, very fast. It's almost certain that intelligence agencies could invest this effort to say, b…

It's almost certain that intelligence agencies could invest this effort to say, break SHA1 SSL certs.

To the contrary, it is unlikely that they can do so.

There is a world of difference between "come up with two things that hash to the same value" and "come up with something that hashes to a particular known value". It gets harder still if you're trying to add constraints about the format of your text (such as making them look like a potentially valid SSL cert).

To illustrate the difference, suppose that you can constrain the algorithm to produce one of a trillion values. If you generate a million possibilities, odds are good that 2 of them will have the same hash value. You've generated a collision! But you need to do a million times as much work to have good odds of generating any particular value.

That said, attacks only improve over time. While it is highly unlikely that intelligence agencies can break SHA1 certs today, it is extremely likely that they will eventually. Where eventually is 5-20 years.

Re: Announcing the first SHA-1 collision

#308

Post by problems »

btilly wrote: post #307
problems wrote: post #242

Earlier quoted context omitted.

A few considerations though: - Google used GPUs, much of the Bitcoin network relies on fully custom ASICs now and mining without them isn't really profitable anymore - SHA1 hashes can also be computed over twice as fast as SHA256 even on GPUs, so if someone were to go out and build SHA1 ASICs, you could probably do this very, very fast. It's almost certain that intelligence agencies could invest this effort to say, b…

It's almost certain that intelligence agencies could invest this effort to say, break SHA1 SSL certs. To the contrary, it is unlikely that they can do so. There is a world of difference between "come up with two things that hash to the same value" and "come up with something that hashes to a particular known value". It gets harder still if you're trying to add constraints about the format of your text (such as making…

> There is a world of difference between "come up with two things that hash to the same value" and "come up with something that hashes to a particular known value".

Doesn't the PDF on their site pretty much prove they can do both of these - at least, in a way? They were able to change the color without impacting the contents of the PDF and get the same SHA1.

They probably have a fair bit of garbage data to work with in the PDF format, but it seems likely that you might be able to do similar in certificate formats.

Remember, you only need a very small modification to change a valid web cert into a CA cert or a global wildcard.

Re: Announcing the first SHA-1 collision

#309

Post by Natanael_L »

sktrdie wrote: post #237
Natanael_L wrote: post #198

Earlier quoted context omitted.

They controlled the visual appearance of the different PDF files in the example. Why couldn't you inject malware instead?

Are you sure this isn't only possible because of the PDF file format? http://shattered.it/static/pdf_format.png Hence shouldn't be possible for general malware.

General malware can be injected in almost anything. Few formats are strict enough to stop that.

Re: Announcing the first SHA-1 collision

#310

Post by Natanael_L »

Ajedi32 wrote: post #257
Natanael_L wrote: post #191

Earlier quoted context omitted.

No, that's not the big problem. Every collision of this kind so far just requires a random looking section, and allows another section to be whatever you want. You can just swap out one file for malware.

Ah, sorry. I got confused by this section on shattered.it, which seemed to be saying that merely requiring a certain level of entropy in the resulting documents would be enough to mitigate the attack: > Are TLS/SSL certificates at risk? [...] it is required that certificate authorities insert at least 20 bits of randomness inside the serial number field. If properly implemented this helps preventing a practical explo…

CA certs are different than the general case.
Post reply on HN