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

111–120 of 273 posts

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

#111

Post by more_original »

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

The PDFs have the same size, but they do not have a header in the file that states their overall size. If PDF had a header at the beginning of the file that states the file size, then it could be harder to find a collision. From what I understand, the attack works by inserting garbage data after a fixed file prefix and before a fixed file suffix (anyone please correct me if I'm wrong).

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

#112

Post by uiri »

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 security. It relies on HTTPS, and a web of trust.

I don't think I've ever (intentionally) used git over HTTPS. I always clone using ssh (which has its own authentication mechanisms) or the git protocol (which is read-only).

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

Thankfully, the collision attack doesn't apply to git (see above) so the cost ought to be greater than 2^n for a collision.

3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's objects, they'd still have to convince you pull from their repo. This requires trust.

Find a popular git host (say, Github but if a popular project is on Git Lab or Bitbucket, they will do just as well) and compromise them. Target a recent release for a popular project (say, Rails) and poison a relevant object that gets pulled down by all the downstream maintainers to package the release.

The benefit to straight up compromising a git repo without faking the hash lies in introducing a vulnerability without the maintainers nor developers of the project noticing (or noticing months/years after the fact).

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

#113

Post by chmike »

There is not mutch risk now, but git should be able to switch to another and longer hash. Truncating another hash to 40 chars does not "fix" the problem. It just move it into another place.

Another possibility, but this is a hack to keep key length to 40 chars, would be to change key encoding from hex encoding to base64. In 40 chars you could encode 240 bits instead of 160. It is preferable to get rid of the hard coded 40 char limit. It shouldn't be that hard.

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

#114

Post by hvidgaard »

dlubarov wrote: post #79
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. 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 immediate concern. Should they upgrade to a more secure hash function, yes. Ideally they make it rather straight forward to use different function in the future and perhaps multiple hash functions. 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.

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

#115

Post by stonogo »

orblivion wrote: post #106
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, 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 you'll be able to sleep through needless catastrophes like this hypothetical attack -- or leftpad.js.

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

#116

Post by dlubarov »

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…

> Git prepends type and length, that makes an attack significantly more difficult, and certainly you cannot just directly translate the pdf attack to Git.

With the attack vectors discussed above, the type would always be blob. I don't think the length field is much help either; see https://news.ycombinator.com/item?id=13720725

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

#118

Post by balnaphone »

tanderson92 wrote: post #34
jessaustin wrote: post #32

Earlier quoted context omitted.

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!"

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.

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

#119

Post by flamedoge »

cbhl wrote: post #17
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'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.

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

#120

Post by AgentME »

more_original wrote: post #111
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? --…

The PDFs have the same size, but they do not have a header in the file that states their overall size. If PDF had a header at the beginning of the file that states the file size, then it could be harder to find a collision. From what I understand, the attack works by inserting garbage data after a fixed file prefix and before a fixed file suffix (anyone please correct me if I'm wrong).

Why would that make the attack harder? Both PDFs are the same length.
Post reply on HN