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

141–150 of 273 posts

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

#141

Post by dozzie »

amingilani wrote: post #138
dozzie wrote: post #127

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

Erm... Which ones?

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

#142

Post by Perseids »

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…

> There is no way to securely deploy a package directly from the internet.

Fetching a file from the internet and verifying it against a hash or signature is the only way to securely deploy a package from the internet. This is exactly one of the use cases theses cryptographic primitives are built for. Don't blame the users when they utilize the tools the way they are supposed to be, blame the tools when they fail when doing so.

And by the way, if you ever need to run `apt-get upgrade` or `apt-get install` on your production server from a public mirror, then you are guilty of "deploying a package directly from the internet", too. (My apologies and congratulations if don't.)

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

#143

Post by hvidgaard »

clusmore wrote: post #97
trengrj wrote: post #23

So would it be possible to migrate to a different hash seamlessly?

From reading various discussions, it sounds like there are quite a few places that make implicit assumptions about the length of the hash, so from a technical perspective it might be a hassle to migrate to longer hashes. I think the bigger problem would be external -- tooling and other integrations. I'm guessing if they did move to another algorithm, as part of the migration git would need to re-compute the hash for…

You could add the new hash functionality, and enable Git to use variable length hash functions and multiple different hashes based on setup. So for compatibility, you keep SHA-1, but for future you use a better hash function.

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

#144

Post by kbart »

astrodust wrote: post #131
paulddraper wrote: post #60

Earlier quoted context omitted.

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?

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

#145

Post by johncolanduoni »

hvidgaard wrote: post #114
dlubarov wrote: post #79

Earlier quoted context omitted.

> 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. HTTPS lets you verify that you're fetching changes from, say, a Github server. Just because a repo is hosted by Github doesn't mean that you can trust its contents. > 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 att…

Git prepends type and length, that makes an attack significantly more difficult, and certainly you cannot just directly translate the pdf attack to Git. For applications, such as signing pdf or other documents, SHA-1 should be retired. But the collective crypto community have said that for more than a decade, so I have little sympathy for companies that is affected by this. But for Git, there is no reason for immedia…

> I doubt anyone is able to find an input that MD5 and SHA-1 both hash to the same value. It would significantly reduce reliance on a single hash function.

As was mentioned in the original collision thread, concatenating insecure hash functions has fundamental weaknesses: https://www.iacr.org/archive/crypto2004/31520306/multicollis...

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

#146

Post by shasheene »

dozzie wrote: post #141
amingilani wrote: post #138

Earlier quoted context omitted.

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

Erm... Which ones?

I believe Homebrew on macOS uses it for formulae (Ruby scripts to actually download and build the application)

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

#148

Post by olavgg »

hvidgaard wrote: post #135
otabdeveloper wrote: post #110

Earlier quoted context omitted.

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

How much faster is a cpu from 2012 and a cpu from today when you compare them by single thread performance @ 3 ghz.

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

#149

Post by Perseids »

uiri wrote: post #112
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…

Wow, Linus raises an entirely different issue which is that the PDF-based attack won't work on git at all . Due to length prefixing, it is extremely difficult to insert nonsense into the middle of a git object which is how this attack works on PDFs. Linus correctly notes that using the first forty bytes of SHA-256 is an option if an attack against git's use of SHA1 were developed. 1) Git doesn't rely on SHA-1 for sec…

> 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 same amount of bytes. See how the quoted paragraph above has exactly the same number of characters as this one.

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

#150

Post by hvidgaard »

johncolanduoni wrote: post #145
hvidgaard wrote: post #114

Earlier quoted context omitted.

Git prepends type and length, that makes an attack significantly more difficult, and certainly you cannot just directly translate the pdf attack to Git. For applications, such as signing pdf or other documents, SHA-1 should be retired. But the collective crypto community have said that for more than a decade, so I have little sympathy for companies that is affected by this. But for Git, there is no reason for immedia…

> I doubt anyone is able to find an input that MD5 and SHA-1 both hash to the same value. It would significantly reduce reliance on a single hash function. As was mentioned in the original collision thread, concatenating insecure hash functions has fundamental weaknesses: https://www.iacr.org/archive/crypto2004/31520306/multicollis...

Sort of. It does not improve brute force resistance in a meaningful way, but that is not the purpose either. It protects against one of the hash functions being broken.

Let us assume that we have 2 160bit hash functions, and one is broken to the degree that we can find collisions in constant time. This now means that we can break the combined hash in 2^80 rather than 2^80 + 2^80. The total brute force complexity was not improved, but the reliance on either hash function was.

Post reply on HN