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

111–120 of 524 posts

Re: Announcing the first SHA-1 collision

#111

Post by lawless123 »

mavdi wrote: post #84
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…

To be honest this is a lovely evil plan. cough MPAA cough

If they MPAA could subvert torrents of their property and and replace sections of the footage with just warnings (ruinning the download) i would find that much less objectionable than DRM.

Frustrate the people pirating instead of punishing everyone else.

Re: Announcing the first SHA-1 collision

#112

Post by nstj »

dragonwriter wrote: post #103
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…

I may be confusing p2p protocols, but doesn't BitTorrent grab different chunks from different sources, so that if there are different people spreading different versions that are viewed as the same, people are going to mostly get either the original (and initially more common) version or broken junk that is a mix of the two versions?

jinx.

Re: Announcing the first SHA-1 collision

#113

Post by cesarb »

chaosfox wrote: post #91
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…

this isn't quite true, bittorrent have checksums for each piece in the torrent, I not saying its impossible to do but its significantly harder than just finding 2 files with the same hash.

Wouldn't that make the attack easier, since you just have to manufacture a pair of pieces with the same hash, instead of having to make the whole file have the same hash?

Re: Announcing the first SHA-1 collision

#114

Post by michaelt »

raverbashing wrote: post #17
koolba wrote: post #11

What's the impact to something like git that makes extensive use of SHA-1? In their example they've created two PDFs with the same SHA-1. Could I replace the blob in a git repo with the "bad" version of a file if it matches the SHA-1?

It's probably doable, but your commit will be huge with a lot of comments or dummy files to make the collision possible.

Previous brute forcing efforts [1] have fiddled with commit and author timestamps.

If you had seven commits, and two timestamps per commit, and each timestamp could be fudged by 90 minutes without detection, you might not need any dummy comments or files at all.

[1] https://github.com/bradfitz/gitbrute

Re: Announcing the first SHA-1 collision

#115

Post by runeks »

dragonwriter wrote: post #103
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…

I may be confusing p2p protocols, but doesn't BitTorrent grab different chunks from different sources, so that if there are different people spreading different versions that are viewed as the same, people are going to mostly get either the original (and initially more common) version or broken junk that is a mix of the two versions?

Not only that, BitTorrent also uses a Merkle tree of the torrent data split into pieces (e.g. 1 MB per piece), meaning you need to compute thousands of colliding hashes, with the added restriction that the data must be exactly the piece length.

The torrent ID is the Merkle root hash, which is a hash of all the piece-hashes hashed together in a tree structure: https://i.stack.imgur.com/JVdvj.png

Re: Announcing the first SHA-1 collision

#116

Post by zo1 »

mavdi wrote: post #84
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…

To be honest this is a lovely evil plan. cough MPAA cough

It'll only work for a few days/months after people start noticing it.

Re: Announcing the first SHA-1 collision

#117

Post by maxerickson »

jgrahamc wrote: post #95

How am I going to explain this to my wife? Actually a serious question. How do we communicate something like this to the general public?

Google created a complicated and expensive method of undermining an integrity check, making that integrity check less safe to use. The method will get cheaper and easier to use, so systems using that integrity check have to be moved to integrity checks that are believed to be better.

Re: Announcing the first SHA-1 collision

#118

Post by ktta »

dragonwriter wrote: post #103
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…

I may be confusing p2p protocols, but doesn't BitTorrent grab different chunks from different sources, so that if there are different people spreading different versions that are viewed as the same, people are going to mostly get either the original (and initially more common) version or broken junk that is a mix of the two versions?

Well, you really don't need the complete file either. Since torrents are usually shared unzipped, they can just replace a chunk with a bad one (It varies usually from 256KB-2MB) and a single chunk can be replaced with a bad one embedded with malware to cause problems.

Especially something like a buffer overflow attack on a video file.

Re: Announcing the first SHA-1 collision

#119

Post by cesarb »

On a quick scroll of the comments, I haven't seen this posted so far: http://valerieaurora.org/hash.html

We're at the "First collision found" stage, where the programmer reaction is "Gather around a co-worker's computer, comparing the colliding inputs and running the hash function on them", and the non-expert reaction is "Explain why a simple collision attack is still useless, it's really the second pre-image attack that counts".

Re: Announcing the first SHA-1 collision

#120

Post by StavrosK »

anilgulecha wrote: post #67
contravariant wrote: post #62

Earlier quoted context omitted.

>* Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many). Maybe I'm mistaken, but isn't the purpose of those mainly to verify that you've downloaded the file correctly? At least, the use of MD5 suggests that this is the case.

Correct, and if you have 2 images that have the same hash, you can serve one or the other at different times. This is the attack.

The GP probably means "that it wasn't corrupted during the download", as there are a few attack vectors for someone who could serve a different file (they could trivially serve a different hash).
Post reply on HN