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

41–50 of 273 posts

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

#41

Post by btym »

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.

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

#42

Post by loup-vaillant »

vacri wrote: post #27
petertodd wrote: post #20

Earlier quoted context omitted.

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

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 ha…

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

#43

Post by sverige »

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? --…

>> 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 it's interesting because it is another example of his basic attitude toward security, and a lot of people who should know better use Linux believing it is secure because "it hasn't been broken yet."

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

#44

Post by robertelder »

I posted this on the reddit thread, but I thought it would be interesting to hear feedback here too:

I don't know much about git internals, so forgive me if that is a bad idea, but what does everyone think about it working like this:

If future versions of git were updated to support multiple hash functions with the 'old legacy default' being sha1. In this mode of operation you could add or remove active hashes through a configuration, so that you could perform any integrity checks using possibly more than one hash at the same time (sha1 and sha256). If the performance gets bad, you could turn off the one that you didn't care about.

This way by the time the same problem rolls around with the next hash function being weakened, someone will probably have already added support for various new hash functions. Once old hash functions become outdated you can just remove them from your config like you would remove insecure hash functions from HTTPS configurations or ssh config files. Also, you could namespace commit hashes with sha1 beging the default:

git checkout sha256:7f83b1657ff1fc53b92dc18148a1d...

git checkout sha512:861844d6704e8573fec34d967e20bcfef3...

Enabling/disabling active hash functions would probably an expensive operation, but you wouldn't be doing it every day so it probably wouldn't be a huge problem.

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

#45

Post by mixologic »

lamontcg wrote: post #29
nialv7 wrote: post #22

> but git doesn't actually just hash the data, it does prepend a type/length field to it. To me it feels like this would just be a small hurdle? But I don't really know this stuff that well. Can someone with more knowledge share their thoughts? I think Linus also argued that SHA-1 is not a security feature for git ( https://youtu.be/4XpnKHJAok8?t=57m44s ). Has that been changed?

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 with your existing objects. But since git falls back to whatever was there first, I think it would be very challenging indeed to subvert a repo. You'd essentially have to find somebody who's forked a repo with the intention of submitting a PR, say, on a long running feature branch.

You could then submit your PR based off hashes in their repo before they do, which would probably mean your colliding object would get preference.

Its pretty far fetched, but the vector is non-zero.

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

#46

Post by tanderson92 »

edanm wrote: post #40
tanderson92 wrote: post #34

Earlier quoted context omitted.

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.

Definitely smart thinning, but not sure what makes it Bayesian.

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

#47

Post by kalenx »

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? --…

That's not it's claim. He specifically goes down on saying how PDF are different than source files, and why while it is trivial to produce two forged PDF with the same size, it is not with source files.

That being said, his motto is more like "don't freak out", and in the specific git context, I can only agree.

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

#49

Post by dingo_bat »

loup-vaillant wrote: post #42
vacri wrote: post #27

Earlier quoted context omitted.

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 ha…

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.

Don't forget the extra computation cost with a more complex hash.

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

#50

Post by smallnamespace »

edanm wrote: post #40
tanderson92 wrote: post #34

Earlier quoted context omitted.

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.

Definitely smart thinning, but not sure what makes it Bayesian.

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.

Post reply on HN