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

Linus' reply on Git and SHA-1 collision

marc.info

Post reply on HN
Print view View original

91–100 of 273 posts

Re: Linus' reply on Git and SHA-1 collision

#91

Post by euyyn »

btym wrote: post #41
paulddraper wrote: post #16

Linus has toned down a lot from a decade ago. > You are _literally_ arguing for the equivalent of "what if a meteorite hit my plane while it was in flight - maybe I should add three inches of high-tension armored steel around the plane, so that my passengers would be protected". > That's not engineering. That's five-year-olds discussing building their imaginary forts ("I want gun-turrets and a mechanical horse one mi…

> It is simply NOT TRUE that you can generate an object that looks halfway sane and still gets you the sha1 you want This was his point, and it's still true. Generating a specific SHA-1 hash is still not feasible.

It's not so inconceivable, after seeing the PDF collision, to contribute to another project a commit whose hash has a collision with another malicious commit you keep up your sleeve. Not saying it's easy, but now it's on the horizon.

Re: Linus' reply on Git and SHA-1 collision

#92

Post by tmsldd »

notfed wrote: post #56

Pertinent facts for the worried: 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. 2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage attack costs 2^(2n). 3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's…

Fine with all this, and you are right: nothing to worry by now... but in the end we should trust the math, and nothing else. And so, we need a schedule for update it..

Re: Linus' reply on Git and SHA-1 collision

#93

Post by hulahoof »

xkxx wrote: post #80
braveo wrote: post #65

Earlier quoted context omitted.

What's shocking is how badly people understand the purpose of an analogy. It's to communicate an idea to another person in a way that can also convey subtleties, and not just the literal words being conveyed. In this case, he was trying to convey the idea that the risk is so small and so remote that it really isn't worth spending a lot of time on. You understood the point, I understood the point, and everyone else un…

> What's shocking is how badly people understand the purpose of an analogy. The purpose of an analogy is to simplify something that's too hard to understand for the person you try to convey your idea to. Sometimes analogies are appropriate, e.g. when you teach something. When you want to convince somebody whose opinion is very different from yours, analogies aren't appropriate. They sound condescending: "because you…

Sometimes facts and logic can be extremely verbose - I feel many analogies are in place not to be condescending, but because the author has faith in the reader that they can make the connection between the analogy and the problem.

And to be quite honest abstracting ideas is core to problem solving, and I think it's a bit disingenuous to say that anyone misunderstood what Linus was getting at there.

Re: Linus' reply on Git and SHA-1 collision

#94

Post by euyyn »

cldellow wrote: post #36
Strom wrote: post #26

Downloading the PDFs [1] and comparing their sizes takes less than a minute. They're the exact same size. Yet here we have Linus making one bet after another that size has to be different for this attack. Now to be fair, he also keeps repeating that he hasn't seen the attack yet . Which leads me to question why is this post interesting to HN? Is it to show how Linus aimlessly speculates and gets his guesses wrong? --…

I think you're violently agreeing with Linus here. He says: > pdf's don't have that issue, they have a fixed header and you can fairly arbitrarily add silent data to the middle that just doesn't get shown. In other words, he expects the PDFs to have the same size because silent data has been arbitrarily added to the middle that doesn't get shown.

Padding a code commit with extra whitespace, in indentation, between operators and operands, and trailing the lines, isn't rocket science. As another commenter said, you then helpfully fix the style in the following commit.

Re: Linus' reply on Git and SHA-1 collision

#95

Post by meta_AU »

swsieber wrote: post #77
meta_AU wrote: post #76

Painful to read all the 'this isn't an issue because of bad reason X, Y, Z'. Git can implement checking for easily collided data and warn the user, potentially even look to implement the safer hash countermeasures too. The fact that this isn't a second preimage, or that SHA1 isn't used to auth a repo doesn't really factor in to it.

But he doesn't say that they won't implement checks for collided data and warn the user (not in this post anyway). He does say that the sky isn't falling, and there are some steps they can take to mitigate it. Edit: or do you mean all the posts here in the comments?

Yes to your edit, but I can see the ambiguity.

Re: Linus' reply on Git and SHA-1 collision

#96

Post by E6300 »

mixologic wrote: post #45
lamontcg wrote: post #29

Earlier quoted context omitted.

Yeah what is the attack here? If you don't have permissions to my repo that already limits the scope of attackers to people who already have repo access. At that points there's tons of abuse avenues open that are simpler. If someone could fork a repo, submit a pull request and push a sha for an already existing commit and that would get merged and accepted (but not show up in the PR on github) well that would certain…

Repo access doens't stop people from injecting code into your repository. A pull request actually puts objects into your repo, but under a different ref than heads and tags. 1. Go to github, do a git clone 'repo' --mirror 2. cd to the bare repo.git and do a git show-ref and you will see all the pull requests in that repo. If any of those pull requests contained a duplicate hash, then in theory they would be colliding…

It's easier than that. Someone could create a benign patch and a malicious patch that collides the hash. But what could they do with that?

For example, let's say it goes (letter##number represents the hashes):

State 1:

Real repo: R3 -> R2 -> R1 -> R0 (note: R3 is the head)

Benign PR: B1 -> B0 -> R1

Malicious PR: M1 -> M0 -> R1 (note: M0 = B0, but the contents are different)

State 2, after merging Benign PR:

Real repo: R4 -> R3 -> R2 -> R1 -> R0, R4 -> B1 -> B0 -> R1

If Malicious PR was merged now, Git would, I imagine, just believe that M1 is a commit that branched off of B0, since that's where the "pointer" is at.

So, yeah, what would this actually accomplish?

Re: Linus' reply on Git and SHA-1 collision

#97

Post by clusmore »

trengrj wrote: post #23

So would it be possible to migrate to a different hash seamlessly?

From reading various discussions, it sounds like there are quite a few places that make implicit assumptions about the length of the hash, so from a technical perspective it might be a hassle to migrate to longer hashes.

I think the bigger problem would be external -- tooling and other integrations. I'm guessing if they did move to another algorithm, as part of the migration git would need to re-compute the hash for every single object in all of our repos and migrate all our refs over to the new hashes, so that repos created before and after the change would be indistinguishable. This would mean that every commit hash which appears in plaintext in commit logs, emails, bug trackers, etc. would be wrong. Not to mention 3rd party tools which make the same assumptions about hashes that git itself does. It sounds like a nightmare to me, and one that I would only want to force on the community if absolutely necessary.

Re: Linus' reply on Git and SHA-1 collision

#98

Post by EGreg »

dlubarov wrote: post #79
notfed wrote: post #56

Pertinent facts for the worried: 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. 2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage attack costs 2^(2n). 3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's…

> 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. HTTPS lets you verify that you're fetching changes from, say, a Github server. Just because a repo is hosted by Github doesn't mean that you can trust its contents. > 2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage att…

For 3 though, how is trusting a random author on git (with fake stars etc) practically different than a random author who has the exact sha1 of a "trusted" repo in their history? If you pull from a random author are you really doing a diff with the last trusted commit or something?

Face it - it's far more likely that a github account is compromised and that repo you rely on has been amended. And you don't really have a good way of verifying which commits are "safe" whatever that means. At best, commits can be cryptographically signed by ther authors, to prevent this. But if the author goes rogue then all who depend on them are up the creek.

And all this for what?

Re: Linus' reply on Git and SHA-1 collision

#99

Post by pg314 »

xenadu02 wrote: post #88
dlubarov wrote: post #59

> That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header. > pdf's don't have that issue, they have a fixed header and you can fairly arbitrarily add silent data to the middle that just doesn't get shown. This doesn't seem like much of an obstacle, since you can add silent data to all ki…

Yes but the arbitrary data in the PDF doesn't have to be rendered. It is much more difficult to change source code in a way that: 1) generates a collision 2) is still valid source code 3) the changes cause a desired effect (like a backdoor) 4) has the same file size

People store all kinds of binary data in git, not just source files. E.g. images or PDF files with specs or documentation.

Re: Linus' reply on Git and SHA-1 collision

#100

Post by AlexandrB »

philsnow wrote: post #28
paulddraper wrote: post #16

Linus has toned down a lot from a decade ago. > You are _literally_ arguing for the equivalent of "what if a meteorite hit my plane while it was in flight - maybe I should add three inches of high-tension armored steel around the plane, so that my passengers would be protected". > That's not engineering. That's five-year-olds discussing building their imaginary forts ("I want gun-turrets and a mechanical horse one mi…

> > If we want to have any kind of confidence that the hash is reall yunbreakable, we should make it not just longer than 160 bits, we should make sure that it's two or more hashes, and that they are based on totally different principles. Why is this quoted in support of an argument that Linus used to come across as a lunatic in online correspondence ? This seems to me like an entirely reasonable way to make it very,…

I actually asked this exact question in the SHA-1 thread and got an informative response [1]. Apparently creating a collision in two hash functions is not much harder [2].

[1] https://news.ycombinator.com/item?id=13715146

[2] https://www.iacr.org/archive/crypto2004/31520306/multicollis...

Post reply on HN