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

291–300 of 524 posts

Re: Announcing the first SHA-1 collision

#291

Post by cesarb »

js2 wrote: post #244
0x0 wrote: post #180

I'm trying to play with this in git. Added the first file, committed, and then overwrote the file with the second file and committed again. But even when cloning this repository into another directory, I'm still getting different files between commit 1 and 2. What does it take to trick git into thinking the files are the same? I half expected "git status" to say "no changes" after overwriting the first (committed) pd…

This is because git adds a header and zlib compresses the PDFs such that they no longer collide when stored in git. But of course, they still collide when extracted from git: $ ls -l; for i in 1 2; do sha1sum See "Object Storage" for details at https://git-scm.com/book/en/v2/Git-Internals-Git-Objects It's worth noting that either of the changes, adding a header or deflating the content, would remove the collision. Th…

The compression is applied after the hashing, so it doesn't make any difference. Only the "blob " header matters.

Re: Announcing the first SHA-1 collision

#292

Post by jwilk »

refulgentis wrote: post #268
jwilk wrote: post #264

> How did you leverage the PDF format for this attack? > A picture is worth a thousand words, so here it is. > http://shattered.io/static/pdf_format.png This picture is meaningless to me. Can someone explain what's going on?

One can insert arbitrary data into JPGs. Given that, the researchers embedded a JPG in a PDF, and manipulated the arbitrary data until it resulted in a collision.

Sure, but you don't end up with two images that differ only in background of top half by accident...

Re: Announcing the first SHA-1 collision

#293

Post by vortico »

ksk wrote: post #284
mabbo wrote: post #74

One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't. Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've g…

>Edit: some people have pointed out some totally legitimate potential flaws in this idea. And they're probably right, those may sink the entire scheme. But keep in mind that this is one idea off the top of my head, and I'm not any security expert. Well to be fair to those people, you started out saying its a practical attack when it wasn't even a theoretical one.

Well, it's practical on a small scale. You could wait until a torrent has only 1-2 seeders, and then you can hope to give leechers all blocks of a file. Or, you could deliver a torrent with a 1GB installer (for some software package) and a 100kb keygen (which you replace with malware) fitting inside a 1MB block and you can be sure to spread that around regardless of the number of other seeders.

Re: Announcing the first SHA-1 collision

#294

Post by jwilk »

kazinator wrote: post #211

> In practice, collisions should never occur for secure hash functions. That is mathematically impossible when reducing an N bit string to an M bit string, where N > M. All hashes have collisions; it's just how hard are they to find.

They said "in practice" for a reason.

Re: Announcing the first SHA-1 collision

#295

Post by vortico »

sktrdie wrote: post #149
mabbo wrote: post #74

One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't. Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've g…

But you can't control the data in the malware. It will be garbage.

Your "computable nonce" can exist in an unimportant place of the binary. Such as an unused portion of .data

Re: Announcing the first SHA-1 collision

#296

Post by xanderstrike »

drzaiusapelord wrote: post #205
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…

Well, certainly there's a lot of work that can be done by a computer network that spans what? 500+k computers all pegging their many cpu/gpu/asic processors at 100% 24/7. The bitcoin network, if seen as one processing unit, is history's most powerful computer. Of course it can punch out difficult work quickly. That doesn't mean your average Russian hacker can. Of course this cuts both ways, we'll probably be seeing A…

Give it a few years and your average Russian hacker with a handful of stolen credit cards will be able to buy enough VPS muscle to crack it.

Re: Announcing the first SHA-1 collision

#299

Post by schoen »

problems wrote: post #262
jakob223 wrote: post #255

Earlier quoted context omitted.

> say, break SHA1 SSL certs Maybe, and probably, but probably not within the scope of this attack. This attack relies on being able to have a large similar prefix and a lot of control over further internal data; SSL certs are somewhat more constrainted.

Would a TLS certificate not offer such a large similar prefix? Just change the domain to a wildcard or something like the RapidSSL MD5 attack from a few years back.

In https://www.win.tue.nl/hashclash/rogue-ca/, Sotirov et al. were able to use the ability to create MD5 collisions to create a pair of colliding certificates because the content of an about-to-be-issued certificate was almost completely predictable. In response to this, the industry added requirements for CAs to include unpredictable values (such as an unpredictable serial number) in certificates. For example, the certificate for HN has serial number 00:EA:21:7C:EA:6C:1F:97:9E:6A:91:90:B7:68:52:D6:63, which is at least in part nonsequential and random, specifically in order to prevent an attacker who knows a collision attack in the hash function used by the CA from being able to exploit it.

This precaution means that an attack like this isn't immediately directly usable against TLS, because the work factor has been increased dramatically.

Edit: the adopted change to the rules is at https://cabforum.org/2016/07/08/ballot-164/ and requires at least 64 bits of CSPRNG entropy in the serial number, specifically as a response to Sotirov. I forgot the history of the section that it replaced (which recommended at least 20 unpredictable bits), but I think that may also have been a response to Sotirov; if the old recommendation had been in use then Sotirov's original attack would not have worked.

Re: Announcing the first SHA-1 collision

#300

Post by dantillberg »

mabbo wrote: post #74

One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't. Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've g…

It doesn't have to be a new torrent. You could just join the swarm for an existing torrent and seed different data for selected parts of the torrent.
Post reply on HN