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

221–230 of 273 posts

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

#221

Post by maligree »

Perseids wrote: post #182
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…

I don't like the living-on-the-edge-attitude that Linus and others here promote regarding Sha1 in git. First, attacks only get faster over time. What costs millions today is likely to be achievable on commodity hardware in the coming years. Second, attacks only get more flexible over time. A contrived collision on MD5 in 2004 got perfected to a single block collision in 2010 [1]. Third, devising an update strategy an…

"On the edge"

"A contrived collision on MD5 in 2004 got perfected to a single block collision in 2010 [1]" so they'd have at least years to fix it were they using md5?

He says they'll migrate, but it's no reason to go crazy. If anything, calmness of this sort is what we need more of (this industry, anyway... we go crazy about stuff way too much).

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

#223

Post by falsedan »

falsedan wrote: post #128
braveo wrote: post #105

Earlier quoted context omitted.

We're talking about a conversation amongst kernel/software developers about a very technical software issue. Anyone who doesn't understand why the risk was so small doesn't belong in the conversation. Can you even imagine where our medical field would be if we expected surgeons to talk amongst themselves as if they were speaking to the general public? It is absolutely acceptable for the speaker to make assumptions ab…

Technically, he was emphasizing how low the probability was, not the risk. Since the impact is pretty high in both cases (accepting a malicious object/mid-air collision), the risk (as a combination of probability & impact) is significant.

Hi downvoters, without some post setting me straight I will be wrong forever, where can I learn more about risk analysis and mitigation?

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

#224

Post by braveo »

barneycarroll wrote: post #130
watwut wrote: post #102

Earlier quoted context omitted.

Yet other times, people use analogies to gloss over important facts, to sort of hide them from listener. The logical conclusion taken from analogy will be different then what would be reasonable if all facts would be taken into account. Great when your arguments are weaker, but you still wanna convince.

Other times, people introduce seemingly impertinent colour into an analogy in order to engage the target audience's imagination and reasoning better. They may even tailor the duration of their analogy in order to match that of other analogies which have previously hit home with the intended target. And the target may trust this, and potentially end up believing a great many falsehoods, because of a lack of critical r…

If an analogy were perfect it would cease to be an analogy and would instead be the thing being discussed.

That's just the nature of an analogy, but that doesn't make it useless or fair to attack the speaker for using an analogy.

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

#225

Post by brillyfresh »

yellowapple wrote: post #192
Perseids wrote: post #149

Earlier quoted context omitted.

> Wow, Linus raises an entirely different issue which is that the PDF-based attack can't and won't work on git at all. Due to length prefixing it is extremely difficult to insert some nonsense into the middle of a git object which is how this attack works on PDFs. Please note that the shattered-{1,2}.pdf files both have exactly the same length. And even with cleartext it is easy to pad passages so they contain the sa…

I'd be more impressed if both paragraphs also had the same SHA-1 hash ;)

What if the hash of the second paragraph had exactly the same number of characters as the hash of the first one? ;)

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

#227

Post by amingilani »

barneycarroll wrote: post #130
watwut wrote: post #102

Earlier quoted context omitted.

Yet other times, people use analogies to gloss over important facts, to sort of hide them from listener. The logical conclusion taken from analogy will be different then what would be reasonable if all facts would be taken into account. Great when your arguments are weaker, but you still wanna convince.

Other times, people introduce seemingly impertinent colour into an analogy in order to engage the target audience's imagination and reasoning better. They may even tailor the duration of their analogy in order to match that of other analogies which have previously hit home with the intended target. And the target may trust this, and potentially end up believing a great many falsehoods, because of a lack of critical r…

I'd like to remind everyone that this thread started with angry funny quotes from Linus.

And now we're debating on what does and doesn't qualify as an analogy.

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

#228

Post by braveo »

falsedan wrote: post #223
falsedan wrote: post #128

Earlier quoted context omitted.

Technically, he was emphasizing how low the probability was, not the risk. Since the impact is pretty high in both cases (accepting a malicious object/mid-air collision), the risk (as a combination of probability & impact) is significant.

Hi downvoters, without some post setting me straight I will be wrong forever, where can I learn more about risk analysis and mitigation?

I think you're getting downvoted because while you may not necessarily be wrong, you're also not really disagreeing with what I said, just making a distinction that isn't all that important (in the context of this conversation).

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

#229

Post by runholm »

danmaz74 wrote: post #212
orblivion wrote: post #106

Earlier quoted context omitted.

I control a fleet of servers. I have a saltstack or ansible script. One of the steps in provisioning a new server is to pull library X from github.com. One day Egor Homakov finds a new hack and finds his way into access to the master branch for library X. As a prank, he force pushes a change to master. Being aware of such a possibility, instead of setting up my script to pull from master or even a specific tag, perha…

> Tomorrow, when preimage SHA-1 attacks are cheap, it will no longer save me. Well, Moore's law is petering out isn't it? :)

Computers are not getting better at the rate they used to, but we are still improving both on performance and power.

However, the largest change we have seen the last couple of years is the accessibility of computer power. These days an attacker can be concerned mostly by how many CPU/GPU hours he needs to rent from Amazon or equivalent providers to achieve his goal. So the accessibility, convenience, and price of processing power is still improving quite fast.

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

#230

Post by acqq »

more_original wrote: post #111
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? --…

The PDFs have the same size, but they do not have a header in the file that states their overall size. If PDF had a header at the beginning of the file that states the file size, then it could be harder to find a collision. From what I understand, the attack works by inserting garbage data after a fixed file prefix and before a fixed file suffix (anyone please correct me if I'm wrong).

> If PDF had a header at the beginning of the file that states the file size, then it could be harder to find a collision.

No. It doesn't change anything if the size is in the PDF header. The size of both PDFs are the same, the header of both PDF files is the same on the both "shattered" files now.

What Linus says is that if you tried to put these two PDF files in git, it would not see them as the same, as git calculates the sha1 differently. But Google would be able to produce two PDF files that would, as git sees them, appear to be same just as easy as these that were produced.

P.S. (answer to your answer to this message) Note, You wrote one level above

> If PDF had a header at the beginning of the file that states the file size, then it could be harder to find a collision.

And I argued that it isn't harder, but irrelevant.

From your answer:

> But to generate a collision with a different prefix q one would have to do the expensive computation all over again

Yes. Now read what your claim was again. It's not harder. Exactly as easy as the first time.

Post reply on HN