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

101–110 of 273 posts

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

#101

Post by dotancohen »

hermitdev wrote: post #66
protomyth wrote: post #38

Earlier quoted context omitted.

I am told the gun is also quite good at shooting ground troops. A relative of mine had an A-10 stay with his group most of the night. Every time the enemy decided to go after them the A-10 came back and made them rethink their actions.

The A-10 delivers rounds at a rate that the individual shots are indistinguishable to the the human ear. Another story that I've heard is that a B-1 flying at operational altitude (200 ft above ground level, mach 2) was often as effective as dropping munitions.

> Another story that I've heard is that a B-1 flying at operational altitude (200 ft above ground level, mach 2) was often as effective as dropping munitions.

That very topic is being discussed right now on the Aviation Stack Exchange: http://aviation.stackexchange.com/questions/35771/is-it-corr...

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

#102

Post by watwut »

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…

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.

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

#104

Post by kalenx »

euyyn wrote: post #94
cldellow wrote: post #36

Earlier quoted context omitted.

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.

Let's assume that you can use spaces, tabs, newlines and linefeeds. It's still only 4 bytes amongst 128 possibilities (using ASCII)... Good luck with that. Or, in other words : good luck to conceal pseudo-random _bits_ in _text_ files...

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

#105

Post by braveo »

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…

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 about the listeners knowledge, and that doesn't reflect poorly on the speaker.

> 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.

It's to convey an idea. That's it, anything you add to that is your own bias at work.

Linus was trying to get across the scale of just how small the risk was.

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

#106

Post by orblivion »

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 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, perhaps I pull from a specific sha1sum. That way I know I'm getting the exact version I want. That's today. Tomorrow, when preimage SHA-1 attacks are cheap, it will no longer save me.

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

#107

Post by comex »

AlexandrB wrote: post #100
philsnow wrote: post #28

Earlier quoted context omitted.

> > 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...

Not much harder than creating a collision in each of the hash functions, sequentially. You can't combine two broken hashes into a strong hash. But as long as at least one of them remains unbroken, then their concatenation is clearly secure too - assuming you keep the full result of each hash function and concatenate them into a long output, rather than trying to combine them somehow. Since it's impossible to know how resilient a given hash function will turn out to be against future cryptanalysis, it can make sense to hedge your bets by combining dissimilar functions.

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

#108

Post by otabdeveloper »

euyyn wrote: post #91
btym wrote: post #41

Earlier quoted context omitted.

> 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.

> Not saying it's easy, but now it's on the horizon.

Not really. It's not a preimage attack. They spent several hundred dollars to find two random byte strings with the same SHA1 hash. There's still no way to SHA1-collide a specific byte string instead of random junk.

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

#109

Post by vidarh »

euyyn wrote: post #94
cldellow wrote: post #36

Earlier quoted context omitted.

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.

"git diff" highlights, in bright red if you have color enabled, trailing whitespace. The changes you'd be able to make without making it suspicious would be highly limited.

Maybe it's possible, but it doesn't seem very likely for source. You'd be more likely to succeed if someone stores binary files in git where people don't have an easy way to audit what's causing the difference. But in that case it would seem you likely have simpler attack vectors.

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

#110

Post by otabdeveloper »

mcbits wrote: post #67

In 20 years, the $100,000 attack will be a $100 attack (or perhaps a $1 attack), but programmers of the day will be overwhelmed with fixing all the 32-bit timestamps that everyone ignored for 50 years because the clearly forecast problem hadn't blown up in their faces quite yet.

> In 20 years, the $100,000 attack will be a $100 attack (or perhaps a $1 attack)

No. Moore's Law has been dead for years and will never come back. The benefits we saw in recent years came from people figuring out how to compile code for SIMD processors like GPU's, not faster or cheaper silicon.

Post reply on HN