Live data from Hacker News

SHA-1 'fully and practically broken' by new collision (2020)

duo.com

81–90 of 210 posts

Re: SHA-1 'fully and practically broken' by new collision (2020)

#81
post #24
post #19

Earlier quoted context omitted.

Natural data is easily identifiable.

Not it's not. You can't distinguish the complete works of Shakespeare from the complete works of Shakespeare with the words changed a bit, or switching to Harry Potter for a bit in the middle, or a completely dazzling and original work of fiction. Any hash might generate all three of these, and essentially boundless other works. It's a library of Babel.

Your examples really fall out of the scope of the premise.

Re: SHA-1 'fully and practically broken' by new collision (2020)

#82
post #3

Reminder that GitHub has blocked Git commit collisions since 2017, and as far as anybody is aware hasn't seen one in the wild. https://github.blog/2017-03-20-sha-1-collision-detection-on-...

> A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night. - Scott Chacon

This is stupid. The probability of any attack happening at random is close to zero. E.g. the probability of a buffer overflowing just right to give you a shell through random chance is less than being eaten by wolves.

The question is about the risk of someone intentionally performing the attack, not the probability it will accidentally happen at random.

Re: SHA-1 'fully and practically broken' by new collision (2020)

#83
post #66
post #60

Earlier quoted context omitted.

What is the thread model though? I don't think it's possible to create a collision that's also executeable code which adds a security hole or anything. So what exactly would they achieve with the collision? And how do they push these gigantic files that have the hash collisions to a server? The upload time would be significant.

A denial of service of sorts? (Something broken and unusable is delivered instead, as distinct from something usable but maliciously so.) I agree that the chances of ever getting a second pre-image that not only makes sense, but does so in some malicious way may as well be zero, surely?

The part about the 2nd pre-image chances being effectively zero may be true, but the nasty cases described upthread don't need a 2nd pre-image. (You could do a lot worse with one, granted!)

Re: SHA-1 'fully and practically broken' by new collision (2020)

#85
post #60
post #54

Earlier quoted context omitted.

Collisions definitely do matter for git security: many people pin explicit git hashes for their dependancies, and thus they can be tricked in running malicious forks. This requires placing a chosen commit in the git repo (so unlike second preimage break it does not mean that you could attack repos you have no control over) but that's not an unrealistic threat model overall.

What is the thread model though? I don't think it's possible to create a collision that's also executeable code which adds a security hole or anything. So what exactly would they achieve with the collision? And how do they push these gigantic files that have the hash collisions to a server? The upload time would be significant.

[deleted]

Re: SHA-1 'fully and practically broken' by new collision (2020)

#87
post #58

Earlier quoted context omitted.

Git was not intended (AFAIK) to be cryptographically secure. Being unsuitable for crypto != being unsuitable for other uses.

Surely signed tags and signed commits in git are supposed to be cryptographically secure? [0] Doesn't the security of those signatures depend on the security of the SHA-1 hashes that are being signed? [0] https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

No - after all, the most common use of digital signatures is to sign documents that can be easily tampered. All the security is in the signature, not the content being signed.

Re: SHA-1 'fully and practically broken' by new collision (2020)

#88
post #74
post #60

Earlier quoted context omitted.

What is the thread model though? I don't think it's possible to create a collision that's also executeable code which adds a security hole or anything. So what exactly would they achieve with the collision? And how do they push these gigantic files that have the hash collisions to a server? The upload time would be significant.

1) People systematically underestimate the possibility of creating collisions that still do something "interesting", like being polyglots (files that can be interpreted in multiple formats, executable or otherwise). See PoC||GTFO, specifically anything by Ange Albertini, for examples; grep https://github.com/angea/pocorgtfo/blob/master/README.md for "MD5". I specifically recommend this writeup: https://github.com/ang…

What do you mean by the `bis` and `cis` suffixes to your entry labels?

Re: SHA-1 'fully and practically broken' by new collision (2020)

#89
post #74

Earlier quoted context omitted.

1) People systematically underestimate the possibility of creating collisions that still do something "interesting", like being polyglots (files that can be interpreted in multiple formats, executable or otherwise). See PoC||GTFO, specifically anything by Ange Albertini, for examples; grep https://github.com/angea/pocorgtfo/blob/master/README.md for "MD5". I specifically recommend this writeup: https://github.com/ang…

What do you mean by the `bis` and `cis` suffixes to your entry labels?

It's just a subdivision; it might as well have said 1a, 1b... -- but "bis" and "cis/tris" (and possibly tetrakis) tend to emphasize that they're addenda, not equal points.

Re: SHA-1 'fully and practically broken' by new collision (2020)

#90
post #7

Earlier quoted context omitted.

Random collisions in 160-bit space are incredibly unlikely. This is talking about intentional collision, and means that it's entirely feasible for someone with significant compute power to create a git commit that has the exact same hash as another git commit. This could allow someone to silently modify a git commit history to e.g. inject malware or a known "bug" into a piece of software. The modified repository woul…

> This could allow someone to silently modify a git commit history to e.g. inject malware or a known "bug" into a piece of software. You need a collision. You also need it to be syntactically correct. You need it to not raise any red flags if you are contributing a patch. And ultimately you need it to do what you want. That's a pretty tall order.

All you need is one variable sufficiently large that you can change until you find a collision, such as a comment (which about all languages allow) or a meaningless number.

You could even vary whitespace until it fits, like spaces at the end of lines.

Post reply on HN