News for hackers. Stuff that matters.
Re:Linus' reply on Git and SHA-1 collision by paulddraper on Thursday February 23, 2017 @08:21PM (#13719947)
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 mile high, and my command center is 5 miles under-ground and totally encased in 5 meters of lead").

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

> And we should all digitally sign every single object too, and we should use 4096-bit PGP keys and unguessable passphrases that are at least 20 words in length. And we should then build a bunker 5 miles underground, encased in lead, so that somebody cannot flip a few bits with a ray-gun, and make us believe that the sha1's match when they don't. Oh, and we need to all wear aluminum propeller beanies to make sure that they don't use that ray-gun to make us do the modification _outselves_.

> So please stop with the theoretical sha1 attacks. It is simply NOT TRUE that you can generate an object that looks halfway sane and still gets you the sha1 you want. Even the "breakage" doesn't actually do that. And if it ever _does_ become true, it will quite possibly be thanks to some technology that breaks other hashes too.

> I worry about accidental hashes, and in 160 bits of good hashing, that just isn't an issue.

http://www.gelato.unsw.edu.au/archives/git/0504/0885.html

Re:Linus' reply on Git and SHA-1 collision by zkms on Thursday February 23, 2017 @08:43PM (#13720079)
> "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"

I think this is a shockingly good example of how smart people get security questions utterly wrong. The right analogy when it comes to security has to involve some type of adversary, not just random, unmotivated natural phenomena -- as long as we're using aircraft analogies, it's not so much "a meteorite might randomly hit my plane in flight" as "there's angry and armed people shooting at my plane with armour-piercing ammunition".

Indeed, in the real world, putting hundreds of kilograms of armour on aircraft isn't the absurd/childish idea Linus seems to think it is:

https://en.wikipedia.org/wiki/Fairchild_Republic_A-10_Thunde...

Re:Linus' reply on Git and SHA-1 collision by aisofteng on Thursday February 23, 2017 @10:29PM (#13720676)
It was recently pointed out to me by a friend with a hobby for cryptography and mathematics that "secure" doesn't mean anything - something can only be secure with respect to a specific threat model.

It seems like a straightforward, almost painfully obvious definition in retrospect now, after having it articulated to me. I think education on security manners is poor and should be a standard topic.

Re:Linus' reply on Git and SHA-1 collision by sigil on Friday February 24, 2017 @12:32AM (#13721287)
When possible, measure security in attacker dollars.

What's interesting here is that, just 5 years ago, the 2017 cost of this very attack (the Stevens attack) was estimated at 2^18.4 = $350k [0]. The collision announced today cost about $100k. Perhaps even less. [1]

Cloud computing is cheaper today than many expected it to be, and it seems like we're only now entering the era of fierce competition. Who knows what the next decade will bring. If your modeled attacker cost is within an order of magnitude or two of the danger zone, beware. Better to have many orders of magnitude of headroom.

Along these lines, I really like what cperciva did with attacker cost modeling in his scrypt paper. See the table on page 14 [2]. I wish more security choices were presented this way, with estimated attacker costs. Taking that even further, I wish the numbers were updated dynamically against present day hardware & compute costs. Maybe even with trendline projections. It's difficult to make good security choices without knowing costs.

[0] https://www.schneier.com/blog/archives/2012/10/when_will_we_...

[1] https://sites.google.com/site/itstheshappening/

[2] https://www.tarsnap.com/scrypt/scrypt.pdf

Re:Linus' reply on Git and SHA-1 collision by DiabloD3 on Thursday February 23, 2017 @09:27PM (#13720341)
The A-10 isn't a plane, it's a gun with a plane wrapped around it.

And it hunts tanks.

Re:Linus' reply on Git and SHA-1 collision by hermitdev on Thursday February 23, 2017 @10:54PM (#13720820)
I'm sad that the AF wants to retire this plane. This plane was defined with one purpose: build a plane around this gun, that being a 30mm autocannon firing depleted uranium shells (not radioactive) that fires at such a rate that it retards the velocity of the plane carrying the gun, and would melt the gun if it fired from full to empty continuously.

The plane was built for survivability. It can withstand an engine being shot off (why the engines are external on "pods"). The cockpit is (I think) surrounded by a 2 inch titanium tub.

I'm not sure the JSF, i.e. F-35 will be capable of taking over this role, as is intended.

Re:Linus' reply on Git and SHA-1 collision by MereInterest on Friday February 24, 2017 @06:41AM (#13722756)
As a side note, depleted uranium is certainly still radioactive. "Depleted" refers to the percentage of U-235, the isotope used for making nuclear weapons. Only about 0.7% of naturally occurring uranium is U-235, with the rest being mainly U-238. U-238 emits alpha particles, with a half life of about 4 billion years.

The radioactivity is unrelated to its use as bullets, which relies on its high density, but it is radioactive.

Re:Linus' reply on Git and SHA-1 collision by protomyth on Thursday February 23, 2017 @09:37PM (#13720413)
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.
Re:Linus' reply on Git and SHA-1 collision by astrodust on Thursday February 23, 2017 @10:31PM (#13720686)
That zipper noise: To think that those are 30mm rounds being fired at that speed is just plain scary. http://www.xdtalk.com/attachments/img_7014-jpg.34438/

If one of those is lingering, I wouldn't even fight if I was the enemy.

It might not be able to kill a modern main battle tank, but I bet spraying it with rounds like that would fuck it up pretty seriously.

Re:Linus' reply on Git and SHA-1 collision by hermitdev on Thursday February 23, 2017 @10:58PM (#13720849)
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.

Re:Linus' reply on Git and SHA-1 collision by dotancohen on Friday February 24, 2017 @02:08AM (#13721675)
> 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 by ravingraven on Friday February 24, 2017 @04:55AM (#13722366)
The B-1 can not even reach Mach 1 at such a lot altitude. It's maximal operating velocity (at any altitude) is Mach 1.25.

People tend to really underestimate how much harder it is to go faster once you reach 0.90 or so, especially at low altitudes.

Re:Linus' reply on Git and SHA-1 collision by astrodust on Thursday February 23, 2017 @10:28PM (#13720672)
It's also going to present zero obstacle to a meteorite travelling at six times the speed of sound. It'll rip through that armor like it's not even there.
Re:Linus' reply on Git and SHA-1 collision by paulddraper on Thursday February 23, 2017 @10:41PM (#13720749)
Mach 6 is a heck of a slow meteorite.

But the if a small meteorite (only a few grams) were traveling that slow, 1.5 inches of titanium would do quite a bit.

Re:Linus' reply on Git and SHA-1 collision by astrodust on Friday February 24, 2017 @03:39AM (#13722067)
I'm not sure how fast these go once they hit the atmosphere. I've seen numbers in the 15 to 25km/hr range, which is pretty damned fast, but how much do they slow down in the thicker atmosphere closer to the ground?
Re:Linus' reply on Git and SHA-1 collision by kbart on Friday February 24, 2017 @04:09AM (#13722187)
15 to 25km/hr is a running speed of human, probably you meant 15 to 25 km/s here (actually, some meteorites hit atmosphere >70km/s). Seems like they decelerate pretty fast after that[0]:

"At some point, usually between 15 to 20 km (9-12 miles or 48,000-63,000 feet) altitude, the meteoroid remnants will decelerate to the point that the ablation process stops, and visible light is no longer generated. This occurs at a speed of about 2-4 km/sec (4500-9000 mph). From that point onward, the stones will rapidly decelerate further until they are falling at their terminal velocity, which will generally be somewhere between 0.1 and 0.2 km/sec (200 mph to 400 mph). Moving at these rapid speeds, the meteorite(s) will be essentially invisible during this final “dark flight” portion of their fall."

0. http://www.amsmeteors.org/fireballs/faqf/

Re:Linus' reply on Git and SHA-1 collision by throwayguestman on Friday February 24, 2017 @05:05AM (#13722431)
> 15 to 25km/hr

just btw, 25 km/s is almost 100.000 km/h.

Re:Linus' reply on Git and SHA-1 collision by pvg on Friday February 24, 2017 @04:45AM (#13722317)
That depends on the size. Smaller ones just never make it to the ground - take a look at this table:

https://en.wikipedia.org/wiki/Impact_event#Airbursts

One they get big enough, they slow down from ludicrously fast to still ludicrously fast. The smallest impactor shown in that table enters at 17 km/s, loses 90% of its energy traversing the atmosphere and smacks the ground at nearly 5km/s. You'll probably want to take your titanium armour and stand somewhere else.

Re:Linus' reply on Git and SHA-1 collision by jessaustin on Thursday February 23, 2017 @09:28PM (#13720357)
We took a couple of minutes off this afternoon to watch some Warthogs pulling some tight maneuvers... to think, USAF wants to sell them all to Poland...
Re:Linus' reply on Git and SHA-1 collision by jessaustin on Thursday February 23, 2017 @09:27PM (#13720343)
Haha you reminded me of the old riddle about how British engineers decided where to place armor on their bombers, because, "if they put it everywhere the plane wouldn't get off the ground!"
Re:Linus' reply on Git and SHA-1 collision by tanderson92 on Thursday February 23, 2017 @09:29PM (#13720362)
Specifically, during the war the engineers took a Bayesian approach and put armor on the bombers in locations where bombers which came back did not have damage. Reason being that hits in those sections of the planes were more likely than not resulting in fatalities. Smart thinking.
Re:Linus' reply on Git and SHA-1 collision by balnaphone on Friday February 24, 2017 @02:55AM (#13721859)
It appears that in the original 1943 memoranda by Wald takes a frequentist approach; see link below.

"A METHOD OF ESTIMATING PLANE VULNERABILITY BASED ON DAMAGE OF SURVIVORS" BY ABRAHAM WALD (1943) : http://www4.ncsu.edu/~swu6/documents/A_Reprint_Plane_Vulnera...

Re:Linus' reply on Git and SHA-1 collision by edanm on Thursday February 23, 2017 @09:53PM (#13720500)
Definitely smart thinning, but not sure what makes it Bayesian.
Re:Linus' reply on Git and SHA-1 collision by smallnamespace on Thursday February 23, 2017 @10:17PM (#13720615)
We're interested in the quantity:

  (1) P(crash | section hit)
and adding armour to those sections where that quantity is maximized (maybe with some thought to the relative weight of armour needed for each section, but I digress).

Let's directly apply Bayes' rule:

  (2) P(crash | section hit) = P(section hit | crash) * P(crash) / P(section hit)
The denominator can be further expanded:

  (3) P(section hit) = P(section hit | crash) * P(crash) + P(section hit | no crash) * P(no crash)
So we can see from the 2nd term that if aircraft regularly comes back with a section that's been hit and yet it hasn't crashed, then that directly reduces (1), meaning that section needs less relatively less protection, all else being equal.

Another point in this method's favor is if crashed aircraft frames are too damaged to permit us to identify which sections were damaged. In that case, we can still estimate (1) just by replacing all the P(section hit | crash) terms with a uniform term.

This analysis can be further expanded to the actual amount of damage each section took in a as well. The more damage a section took on surviving aircraft, the less protection it needs.

Re:Linus' reply on Git and SHA-1 collision by tanderson92 on Thursday February 23, 2017 @10:06PM (#13720564)
anti-aircraft fire is random so doesn't specifically target any section of the plane. Therefore, the planes that return to base are a biased sample of the planes that took on damage. See: http://www4.ncsu.edu/~swu6/documents/A_Reprint_Plane_Vulnera...
Re:Linus' reply on Git and SHA-1 collision by mamon on Saturday February 25, 2017 @03:40AM (#13730662)
Funny thing is, they used all this advanced math to reach the same conclusion the 5 years old child would come to: armor should be put around engine and ammunition storage. Too much education sometimes makes you really stupid.
Re:Linus' reply on Git and SHA-1 collision by flukus on Thursday February 23, 2017 @10:34PM (#13720704)
AA hits planes on the bottom, presumably they weren't adding all the armor to the top?
Re:Linus' reply on Git and SHA-1 collision by tanderson92 on Thursday February 23, 2017 @10:47PM (#13720780)
Does it? AA explodes at predetermined altitudes which may be above or below the plane. The resulting shrapnel....

It's not like a rifle bullet.

Re:Linus' reply on Git and SHA-1 collision by flukus on Thursday February 23, 2017 @11:17PM (#13720955)
There's the shell itself that can still hit a plane, also proximity mines, which I guess would be more likely to go off on the way app (unless there is a delay after the proximity is triggers). The air force would also know the approximate limit of the enemies AA fire and site above it if possible.
Re:Linus' reply on Git and SHA-1 collision by slavik81 on Thursday February 23, 2017 @10:34PM (#13720700)
I would interpret it more charitably than that. He was responding to a claim that malicious collisions could be passed off as being pure chance:

> it could be incredible bad luck that caused that good-looking patch to be mistakenly matching a dangerous object

Re:Linus' reply on Git and SHA-1 collision by squeaky-clean on Friday February 24, 2017 @11:27AM (#13725041)
This was also in response to the original sender's claim that plain ol' non-malicious bad luck could cause sha1 collisions in git commits.

So this is a shockingly good example of how quotes taken out of context are pretty useless in a discussion.

Re:Linus' reply on Git and SHA-1 collision by xkxx on Friday February 24, 2017 @12:07AM (#13721175)
A better counterargument to his argument would be: hashes are not "my plane", potential adversaries are not "a meteorite".

Using analogies is okay when you try to explain a difficult idea to somebody who wants to learn about your subject. Using analogies is not okay when you want to make a solid argument, when you want to convince somebody whose stance is very different from yours.

Re:Linus' reply on Git and SHA-1 collision by braveo on Thursday February 23, 2017 @10:57PM (#13720845)
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 understood the point. Which means the analogy was successful.

So please, stop trying to pull the conversation on some tangent so you expound on why smart people should spend more time on the perfect analogy that you approve of.

Re:Linus' reply on Git and SHA-1 collision by xkxx on Friday February 24, 2017 @12:25AM (#13721256)
> 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 are not smart enough to understand the real rationale behind my opinion, here is an oversimplified argument based on analogies I made just for you". The question is, did Torvalds have any real argument back then? Maybe he fell back to using analogies for the lack of any real argument.

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

To convey the idea that the risk is very small, one needs to have a proof. Real proofs shouldn't involve analogies. They should use facts and logic.

Re:Linus' reply on Git and SHA-1 collision by throwayguestman on Friday February 24, 2017 @05:28AM (#13722498)
>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

An analogy applies a principle to a common setting without loss of specificity. Specifically the dedicated adversary is lost in this abstraction, so it's a bad analogy.

Re:Linus' reply on Git and SHA-1 collision by watwut on Friday February 24, 2017 @02:08AM (#13721679)
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 by barneycarroll on Friday February 24, 2017 @03:36AM (#13722050)
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 reasoning in the contextualisation and import of the analogy.
Re:Linus' reply on Git and SHA-1 collision by braveo on Friday February 24, 2017 @09:17AM (#13723801)
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 by amingilani on Friday February 24, 2017 @09:29AM (#13723901)
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 by hulahoof on Friday February 24, 2017 @01:25AM (#13721518)
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 by xkxx on Friday February 24, 2017 @11:14AM (#13724926)
> abstracting ideas is core to problem solving

Sure. But don't confuse abstractions with analogies.

Here is a good proof about both the integers and rational numbers. Every integer and rational is a real number (abstraction). When you add any 2 real numbers, you get the same result regardless of their order (fact). So it must be true that, when you add any 2 integers, you get the same result regardless of their order (correct conclusion #1). It also must be true that, when you add any 2 rationals, you get the same result too (correct conclusion #2).

Here is a bad proof about the integers and rational numbers. Both the integers and rationals are very similar: you can add them, subtract them and so on (analogy). Between every 2 rational numbers there is another rational number (fact). So it must be true that between every 2 integers there is another integer (wrong conclusion).

Re:Linus' reply on Git and SHA-1 collision by braveo on Friday February 24, 2017 @02:15AM (#13721706)
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 by xkxx on Friday February 24, 2017 @10:51AM (#13724700)
> 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?

The Git devs are not heart surgeons, software development is not a medical field. Again, you are using an analogy to "prove" your point. Can you, please, use a real argument?

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

Do you disagree that using an analogy is oversimplification? If you don't, then that part about "to simplify a complex idea" in my statement should absolutely stay. If you do disagree, then please show why and how an analogy doesn't oversimplify a complex idea.

Re:Linus' reply on Git and SHA-1 collision by braveo on Friday February 24, 2017 @01:00PM (#13725939)
An analogy isn't a proof.

When someone uses an analogy they're not trying to prove anything, they're trying to get you to see things from a specific perspective, or they're trying to communicate an idea.

You can still walk away from the analogy and disagree with them, but you should have a better understanding of their perspective or their argument.

> Do you disagree that using an analogy is oversimplification?

I think your entire approach to analogies is unnecessarily combative. You view an analogy as someone trying to prove something rather than trying to communicate their position better (or just an idea in general).

And your approach is to point out that the analogy isn't perfect, and therefore you've "disproved" the analogy.

Only analogies are, by their very nature, imperfect. When an analogy is perfect it ceases to be an analogy and becomes the thing being discussed.

It should automatically be understood that there are the analogy isn't perfect and anyone can find flaws in it. That doesn't mean it isn't an effective way to communicate.

Re:Linus' reply on Git and SHA-1 collision by falsedan on Friday February 24, 2017 @03:24AM (#13722006)
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.
Re:Linus' reply on Git and SHA-1 collision by falsedan on Friday February 24, 2017 @09:13AM (#13723783)
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 by braveo on Friday February 24, 2017 @09:31AM (#13723910)
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 by throwayguestman on Friday February 24, 2017 @05:56AM (#13722591)
> Which means the analogy was successful.

Sure, if he's saying he is powerless against higher powers. But if he's trying to make a quantitative assertion, a qualitative analogy is not the right tool.

Re:Linus' reply on Git and SHA-1 collision by M_Grey on Thursday February 23, 2017 @11:48PM (#13721093)
Well you said it... it's not a misunderstanding, it's a podium.
Re:Linus' reply on Git and SHA-1 collision by oceanswave on Friday February 24, 2017 @01:12AM (#13721476)
Here's another example of a person getting the scenario completely wrong. The adversary here is aliens and they're lobbing meteorites to take down planes. Get your head out of the groupthink people! just because it's difficult to conceptualize the foe, doesn't mean that the foe Isn't targeting you! Collanders on!
Re:Linus' reply on Git and SHA-1 collision by btym on Thursday February 23, 2017 @09:55PM (#13720508)
> 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.

Re:Linus' reply on Git and SHA-1 collision by euyyn on Friday February 24, 2017 @01:18AM (#13721493)
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 by otabdeveloper on Friday February 24, 2017 @02:25AM (#13721740)
> 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 by victorNicollet on Friday February 24, 2017 @06:37AM (#13722741)
This is exactly what euyyn is saying: create two files with the same SHA1 (by adding bytes of gibberish to an unused section), commit one to the repository, and now you have an collision available.
Re:Linus' reply on Git and SHA-1 collision by mi100hael on Friday February 24, 2017 @11:01AM (#13724797)
That's not how git uses hashes. In that scenario, there would still be a diff and hence git would recognize the files were different.
Re:Linus' reply on Git and SHA-1 collision by philsnow on Thursday February 23, 2017 @09:07PM (#13720236)
> > 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, very difficult to ever attack, because an attacker would have to be able to generate collisions for both of your hash functions.

(I'm not a crypto expert -- maybe you are, if so and my above comment is totally wrong, can you explain how it's wrong?)

Re:Linus' reply on Git and SHA-1 collision by ckozlowski on Thursday February 23, 2017 @09:26PM (#13720338)
I think Linus' point at the time was that the computational cost added to every transaction to protect against a (at the time) highly infeasible event of questionable impact was a poor cost vs. benefit argument. Adding complexity isn't free, and there needs to be a measurable benefit against a threat.

But of course, now is not then. And I think zkms' metaphor "there's angry and armed people shooting at my plane with armour-piercing ammunition" is apt here. The threat is much more sizable now, and so the cost vs. benefit analysis has changed.

Incidentally, one of the requirements of the SHA-3 competition was that it not be related to previous hashes. So while there are no demonstratable attacks against SHA-2, we nonetheless have "two ...hashes, and that they are based on totally different principles."

Re:Linus' reply on Git and SHA-1 collision by loup-vaillant on Thursday February 23, 2017 @09:51PM (#13720486)
While we're at it, every SHA-3 finalist were deemed "good enough", so we now have more than 2 such hashes. (I personally love Blake2b.)
Re:Linus' reply on Git and SHA-1 collision by AlexandrB on Friday February 24, 2017 @01:58AM (#13721645)
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...

Re:Linus' reply on Git and SHA-1 collision by comex on Friday February 24, 2017 @02:22AM (#13721726)
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 by cbhl on Thursday February 23, 2017 @08:31PM (#13720003)
It's worth noting that selecting SHA-1 ten years ago is probably akin to selecting SHA-512 today -- a collision on MD5 was first announced in 2004, and computers and GPUs were a lot slower ten years ago.
Re:Linus' reply on Git and SHA-1 collision by petertodd on Thursday February 23, 2017 @08:38PM (#13720046)
FWIW, the first warnings that SHA-1 was insecure and "It's time for us all to migrate away from SHA-1." were published prior to git's initial 2005 release: https://www.schneier.com/blog/archives/2005/02/cryptanalysis...
Re:Linus' reply on Git and SHA-1 collision by vacri on Thursday February 23, 2017 @09:00PM (#13720188)
Because as we know, the security industry isn't a firehose of fear about everything that isn't airgapped (and then airgapping itself). Security recommendations come so thick and fast that even security researchers themselves don't bother following them. Even the bloke in your link explicitly apologises for using Word for some things, and he's considered a saint in the industry.

What all the commenters here doing a hatchet-job on Torvalds are missing is that he's saying "show me the money"/"perfect is the enemy of good". The hatchet-jobbers are too busy doing the usual tittering over his language to actually absorb the point.

Re:Linus' reply on Git and SHA-1 collision by fulafel on Friday February 24, 2017 @12:39AM (#13721315)
Security industry != crypto academia.
Re:Linus' reply on Git and SHA-1 collision by loup-vaillant on Thursday February 23, 2017 @09:55PM (#13720509)
Clearly, Linus didn't know at the time. If he'd know, he would have chosen another hash in 3 seconds —no additional complexity, no additional effort involved in not choosing a hash the security community starts to have doubts about.
Re:Linus' reply on Git and SHA-1 collision by dingo_bat on Thursday February 23, 2017 @10:16PM (#13720610)
Don't forget the extra computation cost with a more complex hash.
Re:Linus' reply on Git and SHA-1 collision by loup-vaillant on Friday February 24, 2017 @05:06AM (#13722435)
Nobody cares. Hashes are plenty fast. Even the code complexity doesn't matter: I've implemented both SHA-256, and SHA-512, take less than a hundred lines of code. And of course, Linus would have use some existing implementation.

Also, "more secure" doesn't necessarily mean "more complex", or "slower". Blake2b for instance is as fast as md5 and has a simple RAX (xor, rot, add) core from Chacha20.

Re:Linus' reply on Git and SHA-1 collision by Kubuxu on Friday February 24, 2017 @06:23AM (#13722691)
It wasn't like that in 2005.
Re:Linus' reply on Git and SHA-1 collision by KingMob on Friday February 24, 2017 @12:04AM (#13721156)
Which is largely irrelevant on desktops. Nobody's using git on embedded devices, so hash computational cost shouldn't be the deciding factor. Maybe people storing BLOBs will notice.
Re:Linus' reply on Git and SHA-1 collision by reacweb on Friday February 24, 2017 @04:58AM (#13722387)
There are blobs in the kernel and speed was a very important motivation when kernel switched to git.
Re:Linus' reply on Git and SHA-1 collision by loup-vaillant on Friday February 24, 2017 @05:08AM (#13722440)
So now we need to assess whether hashes are a significant bottleneck.
Re:Linus' reply on Git and SHA-1 collision by schoen on Thursday February 23, 2017 @08:48PM (#13720116)
I don't think that comparison is quite right: ten years ago we already had two of Xiaoyun Wang's attacks which significantly reduced the work factor to break SHA-1. They were already cited at the time as reasons to move away from the algorithm (and I doubt we'd be able to do the 2⁸⁰ work needed to get a collision without cryptanalytic research! — notably the successful Stevens attack today reported performing a total of 2⁶³ hash operations while claiming to be "one of the largest computations ever completed").

There's also important concern about SHA-512 (which has led to SHA-3 and other options), but I'm not sure it can be put in the same category; at least all of the best attacks today are significantly reduced-round.

https://en.wikipedia.org/wiki/SHA-2#Cryptanalysis_and_valida...

By contrast, Wang's original attack (which we had more than 10 years ago) achieved a 2¹¹ speedup for collisions against full SHA-1 and her second attack later the same year achieved 2¹⁷ speedup.

Evidently the speedup for the final version of Stevens's attack (which worked) was also around 2¹⁷. By contrast, a Moore's law improvement over 10 years would only be expected to make computers around 2⁶ times faster! (At the risk of mixed or mangled metaphors, we might say that mathematical insight during the time period you mention has been about 2¹¹ times more useful for attacking SHA-1 than computer power increases.)

Edit: someone else linked to Valerie Aurora's chart, which I'd forgotten about, which gives a synopsis of the historical status of the most popular hashes. On that chart, SHA-1 from 2005 was one category worse ("Weakened") than SHA-512 is today ("Minor weakness").

http://valerieaurora.org/hash.html

Re:Linus' reply on Git and SHA-1 collision by flamedoge on Friday February 24, 2017 @03:00AM (#13721887)
Something that bothers me is, why don't there exist dynamic encryption that scales with the current computing power? Then we might have less of a migration mess. Hope is that encryption breakers have to win by algorithmic strength rather than brute force "add more cores".
Re:Linus' reply on Git and SHA-1 collision by somerandser99 on Thursday February 23, 2017 @10:24PM (#13720659)
Where are the technical arguments? Just false analogies and hyperboles. I wouldn't like to work with a person like this in my team.
Re:Linus' reply on Git and SHA-1 collision by wapz on Thursday February 23, 2017 @08:32PM (#13720007)
Wow you could have copy pasted that whole response. Every single sentence was fairly aggressive.
Re:Linus' reply on Git and SHA-1 collision by DINKDINK on Thursday February 23, 2017 @08:32PM (#13720009)
Classic availability bias and round trip bias

"I have no evidence of SHA-1 being broken which is evidence that SHA-1 can't be broken"