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

131–140 of 273 posts

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

#131

Post by astrodust »

paulddraper wrote: post #60
astrodust wrote: post #53

Earlier quoted context omitted.

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.

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.

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

#132

Post by darklajid »

tlrobinson wrote: post #129
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. I would say cryptographic integrity definitely counts as "security". I agree this isn't currently a big deal, but it's probably time to start migrating to a better hash.

But .. that's what Linus is saying in his mail. Like, really exactly what you say in your last sentence..?

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

#133

Post by _qxjp »

robertelder wrote: post #44

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

Take a look at multihash[0]. I don't know the inner workings of the program, but I imagine it would be possible for `multihash` to periodically rehash files (as a cron job?) when a new crypto algorithm gets introduced.

[0]: https://github.com/multiformats/multihash

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

#134

Post by hvidgaard »

AgentME wrote: post #121
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 often see the suggestion that storing the length of the file too helps secure against hash collisions because it adds the additional requirement that both files be the same length, but every single MD5 and SHA1 collision I've seen are between values of the same length anyway! Where does this myth come from?

It's not a myth. It is obvious that you can find collisions with this constraint. When you make a collision attack such as this, you start with 2 inputs and have a target size, i.e. with a specific size of the padded data, then you simply iterate over paddings (of the same size), and when you find a collision, it will be of the correct size.

But it does add an extra constraint, and it prevent attacks that rely on random length filler data. This is not much of an improvement, but an improvement non the less.

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

#135

Post by hvidgaard »

otabdeveloper wrote: post #110
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.

Moore's law still holds, and is expected to hold true until at least 2025 (see wikipedia). I don't think it will be done by then, but that is just guess work.

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

#136

Post by mverwijs »

dozzie wrote: post #127
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…

> 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. Ansible gives larger and easier to exploit attack vectors than git. And then, with pulling semi-random things from internets you have much bigger problems with your deployment procedure. You should never ever download a git repository with software, instead you shou…

> you should be using package system supplied by your operating system

2005-me vehemently agrees with you.

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

#137

Post by amingilani »

stonogo wrote: post #115
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…

Sounds like sentence three is where you got it wrong. You should be pulling your software to a development host, building it after verification, and uploading the deployment package to an artifact repository inside your security perimeter. Sentence three becomes 'pull library X from my artifact server.' There is no way to securely deploy a package directly from the internet. The sooner you understand that, the sooner…

Either way he'd be pulling from Github.com at some point, whether in the build environment or production. He won't ever know that the repository was compromised.

Besides, some people use Heroku simply to deploy their rails or node apps, and they don't have an artefacts server.

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

#138

Post by amingilani »

dozzie wrote: post #127
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…

> 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. Ansible gives larger and easier to exploit attack vectors than git. And then, with pulling semi-random things from internets you have much bigger problems with your deployment procedure. You should never ever download a git repository with software, instead you shou…

Package managers allow you to download from git repositories too. He'd suffer from the same attack vector.

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

#139

Post by rocqua »

perlgeek wrote: post #81
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. I thought that if you signed your git commits or tags with GPG, you implicitly relied on the commit checksum, and thus on SHA1. Is that right?

That's what I read in the thread about the collision that was found.

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

#140

Post by hvidgaard »

kqr wrote: post #89
stickfigure wrote: post #25

Several years ago I worked on a security product that used git as a sort of tripwire-type database. Since SHA1 was considered inadequate for Real Security, we had to hack jgit to use SHA256. It took a stupid amount of work - the 160-bit hash size was scattered all over the codebase in countless magic numbers. But it worked. The product was cancelled. I always wondered if the patch would be of any use to anyone.

160 bits are still quite many. You could have done what Linus suggests and use a better hash but truncate it. If it's a good hash, a truncation of it should still be good (modulo the fewer number of bits, of course.)

That is jerry rigging it. If a stronger hash function is known to be secure, you throw all that confidence out the window if you truncate it. At best you reduce the brute force complexity, at worst you enable pre-image attacks.
Post reply on HN