Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

duo.com

Post reply on HN
Print view View original

161–170 of 210 posts

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

#161

Post by xinniethepooh »

perl4ever wrote: post #160
CobrastanJorji wrote: post #137

Earlier quoted context omitted.

Just to nitpick, I don't think that formula is valid. We're primarily interested in "unrelated" wolf attacks, but it counts the total fatalities, not the total number of fatal incidents. If we count each fatal attack as only one incident, regardless of the casualties, we get 2^-258 instead. But of course we also need to take into account where the 6-member team lives. If they all live in West Bengal, India, the consi…

There was an organization devoted to reintroducing wolves to the northeastern US, but I don't believe they found it politically feasible. However, I have seen (and photographed) something I called a coyote, but others insisted was a wolf. It has been asserted that coyotes tend to evolve to resemble wolves, when there are none in an ecosystem.

Wolves are slowly coming back, they were recently taken off the endangered species list in Idaho, Wyoming, and Montana.[1]

[1] https://www.nps.gov/yell/learn/nature/wolves.htm

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

#162

Post by nkmnz »

CobrastanJorji wrote: post #137
kragen wrote: post #123

Earlier quoted context omitted.

This turns out to be wrong; for a 6-member programming team, that probability is about 2⁻²⁴⁵, which is about 2⁸⁵·³ times less likely than an accidental 160-bit SHA-1 collision: http://canonical.org/~kragen/sw/dev3/rpn-edit#3_8_0_1_0_0_0_... Aside from being bullshit, it's also irrelevant, since we're discussing a collision being generated on purpose, not by accident.

Just to nitpick, I don't think that formula is valid. We're primarily interested in "unrelated" wolf attacks, but it counts the total fatalities, not the total number of fatal incidents. If we count each fatal attack as only one incident, regardless of the casualties, we get 2^-258 instead. But of course we also need to take into account where the 6-member team lives. If they all live in West Bengal, India, the consi…

Plot twist: two developers of your remote team live in Rome and have been raised by a female wolf. How to account for that?

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

#164

Post by ofou »

garmaine wrote: post #147
ofou wrote: post #84

For the ones interested, you can use SHA-256 today. Warning: Still in experimental mode. # .gitconfig file [extensions] objectFormat = sha256

Does GitHub support this?

Not yet [1]. "However, conversations around its implementation are ongoing and looks like it will be on the horizon."

[1]: https://github.community/t/support-for-sha-256-hashes/157493...

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

#165

Post by gjs278 »

asdfman123 wrote: post #55
bjarneh wrote: post #9

> The technique that the researchers developed is quite complex and required two months of computations on 900 individual GPUs.

I wonder how much money in Bitcoin they would have made if they had used those hashes to mine instead. Speaking of which, it would be funny if they were pretending to do security research but added a secret backdoor to mine bitcoin instead, somehow exporting those hashes or using the partial results of SHA-1 calculations (BTC isn't SHA-1). I'm just joking, but I wonder if that's possible. If anyone is Machiavellian e…

they would have made nothing because you can’t use gpus to mine bitcoin at any reasonable rate

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

#166

Post by lokedhs »

throw_away wrote: post #10
api wrote: 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…

Looks like there's a migration plan for git to SHA-256: https://git-scm.com/docs/hash-function-transition/

Last updated in 2017. What is the current status of this?

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

#167

Post by brirec »

zzo38computer wrote: post #157

My idea is a different hash construction, which is 2D construction, which has a infinite internal state and infinite output length. Each row and each column also has a sequence number input, and then there are two mixing up functions (each of which has a finite input and output of equal size than the input); part of the result is propagated horizontally and part of it vertically, so each cell has two inputs and the i…

Reading your post I’m sure you know far more about information theory than I do, so forgive me if this is a stupid question, but…

1. How is infinite internal state and output size possible? There has to be some actual limit for internal state, at least, right? Or else you’ll just run out of memory?

2. Wouldn’t a larger output size risk leaking data? The chance of collision becomes lower, but it also seems to toy with what I understand about why we use cryptographic hashes without ridiculous output size.

3A. What happens if you want a 1 MB hash of a 1 KB file?

3B. How predictable does a super long hash become?

At what point is it no longer a one-way hash?

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

#168

Post by dude187 »

sirclueless wrote: post #141
dude187 wrote: post #126

Earlier quoted context omitted.

You'd also need the actual patch to survive future commits, especially without introducing any merge conflicts

Commits aren't patches. They contain the whole tree. Retroactively changing a commit can't possibly introduce conflicts with other commits on top of it, the worst it can do is introduce big funny-looking diffs.

Well, the contents of the commit is a patch plus metadata. They point to a parent commit, and layer themselves in the tree.

The problem would be if a clone doesn't fetch the new version of the patch and generates a new commit that would conflict with the modified commit. You're changing the base all the future diffs are based off of. It might just jumble the source essentially corrupt the file, but I'm not sure.

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

#169

Post by beermonster »

lokedhs wrote: post #166
throw_away wrote: post #10

Earlier quoted context omitted.

Looks like there's a migration plan for git to SHA-256: https://git-scm.com/docs/hash-function-transition/

Last updated in 2017. What is the current status of this?

Here is discussion [1] on the issue on the Git mailing list at the time with some useful context WRT git. Unsure what current status is. Git 2.29 Had experimental support for sha256.. not sure what it’s current status is, but that was a year ago.

[1] https://marc.info/?t=148786884600001&r=1&w=2

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

#170

Post by lamontcg »

seoaeu wrote: post #140
lamontcg wrote: post #94

Earlier quoted context omitted.

Yeah I don't think any of these proposed attacks work without write access to the repo, at which point the game is already pretty much over already.

There's plenty of workflows where untrusted people have their proposed changes audited and then written to a git repo

How do they get through the auditing?

If I'm looking at a PR which contains a hash collision with code that does a `sudo rm -rf --no-preserve-root /` and I don't accept the malicious code, the hash collision becomes irrelevant.

Post reply on HN