Live data from Hacker News

Announcing the first SHA-1 collision

security.googleblog.com

171–180 of 524 posts

Re: Announcing the first SHA-1 collision

#171
post #84

Earlier quoted context omitted.

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.

But instead, they injected torrents into a torrent tracker and then DoS'd it when the files were removed. https://web.archive.org/web/20080530115944/http://revision3....

Re: Announcing the first SHA-1 collision

#172

Earlier quoted context omitted.

No. Signatures provide the same amount of integrity protection. In fact, all practical asymmetric signature schemes sign a hash. If an attacker can control what somebody signs, he can switch out signed documents using this vulnerability.

well I would say that if an attacker controls what you sign, your security model is already toast, isn't it ?

Not if you sign with an ideal cryptography hash. (Rather than spend expensive compute on signing the whole message, you create a hash, and sign that.)

The big news here is that SHA1 is now definitively not a cryptographically secure hash.

Re: Announcing the first SHA-1 collision

#173

For those of us who are totally clueless about the construction of these hash functions, what is the fundamental flaw in SHA-1 that allows this attack? How do newer hash functions avoid it?

The newest SHA members are based on sponge functions. http://keccak.noekeon.org/ gives a good overview.

Re: Announcing the first SHA-1 collision

#174
post #113

Earlier quoted context omitted.

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?

that depends on the attacker objective, if you just want to trash the file you can just search for any piece that have a hash collision, but if you want to turn the file into a malware you will need to modify the file in a specific way, possibly spanning multiple pieces, and there's less room for fuzzing the hash.

People do exploits by changing 1 bit! I'm sure you can distribute malware using just one chunk, given some cleverness.

Re: Announcing the first SHA-1 collision

#175

If you trust a signer, does this attack do anything to invalidate their SHA-1-based signatures? Or is the scenario strictly an attacker generating both versions of the message?

This only works if the attacker controls both sides, or at least a piece of both sides. That's a collision attack, and it's much easier than a pre-image or second pre-image attack which tries to match an existing hash.

Re: Announcing the first SHA-1 collision

#176

For those of us who are totally clueless about the construction of these hash functions, what is the fundamental flaw in SHA-1 that allows this attack? How do newer hash functions avoid it?

In 90 days the team will release their PoC code and you can take a look.

Re: Announcing the first SHA-1 collision

#177
post #168

Earlier quoted context omitted.

Linus' answer: http://marc.info/?l=git&m=115678778717621&w=2 tl;dr it's a non-issue

No. Linus' answer is correct, as far as it goes, but the threats he considers are only a subset of the real problems. Laying aside the fact that this attack isn't the one you need to attack a hit repo, and recognizing that the theoretical weakness of SHA-1 (that has been known since (IIRC) before the conception of git) has now become a practical weakness If an attacker can forge an arbitrary part of a git tree, then…

Addendum: given a known good repo, an infected repo can be detected by diffing all elements of the repo. A parallel hash scheme with a strong hash function (SHA-3 at this point) could be used, which would easily detect if parties have differing histories by comparing commit hashses using both schemes (both should match!)

We should assume that nation state adversaries may have known this for a while - whether they have acted on it remains to be seen. I suspect it is unlikely for git because it is measurable after the fact (unless you contaminate every instance) I'd be more worried about signing schemes.

(Wrote previous while bathing a toddler)

Re: Announcing the first SHA-1 collision

#178
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's easier just to upload malware to a torrent site. Windows crack, let other people or botnet to download it and suckers will get your malware too. If AV complains, say that is an expected behavior.

Re: Announcing the first SHA-1 collision

#179
post #153

Never forget: when Facebook, Twitter, and Cloudflare tried to slow-down SHA-1 deprecation: https://www.facebook.com/notes/alex-stamos/the-sha-1-sunset/... https://blog.twitter.com/2015/sunsetting-sha-1 https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef... I think Microsoft tried to do it too early on, but eventually agreed to a more aggressive timeline.

Worth noting that Facebook stopped offering SHA-1 back in November[1]. Cloudflare still offers SHA-1 for paying customers (via a root certificate pulled from trust stores, i.e. which are only supported on outdated devices/browsers). Not sure about Twitter.

[1]: https://www.facebook.com/notes/protect-the-graph/retiring-sh...

Re: Announcing the first SHA-1 collision

#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) pdf with the second pdf?
Post reply on HN