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.
SHA-1 'fully and practically broken' by new collision (2020)
81–90 of 210 posts
Re: SHA-1 'fully and practically broken' by new collision (2020)
#82Reminder 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
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)
#83Earlier 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?
Re: SHA-1 'fully and practically broken' by new collision (2020)
#84 # .gitconfig file
[extensions]
objectFormat = sha256Re: SHA-1 'fully and practically broken' by new collision (2020)
#85Earlier 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.
Re: SHA-1 'fully and practically broken' by new collision (2020)
#86Obligatory link: https://shattered.io/
It's a chosen-prefix attack.
Re: SHA-1 'fully and practically broken' by new collision (2020)
#87Earlier 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
Re: SHA-1 'fully and practically broken' by new collision (2020)
#88Earlier 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…
Re: SHA-1 'fully and practically broken' by new collision (2020)
#89Earlier 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?
Re: SHA-1 'fully and practically broken' by new collision (2020)
#90Earlier 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.
You could even vary whitespace until it fits, like spaces at the end of lines.