Ask HN: How will Git get around the discovery of SHA-1 collissions? | Hacker News Reader

Ask HN: How will Git get around the discovery of SHA-1 collissions?

9 pointsverandaguy5 comments

With the recent (practical) discovery of SHA-1 collisions, Git is particularly affected, as this hash is part of its core functionality.

Practically, how can a VCS as widely-deployed as Git get around this kind of issue?

View on HN

It won't. Linus shot down that idea in 2006, long after the basic concept for this attack was originally published. According to Linus, people shouldn't depend on Git's hashing algorithm for cryptographic authenticity. If they want authenticity they should sign commits with GnuPG and, presumably, rebuild the tree occasionally from the authenticated commits to expose any malicious modifications.

kerneltrap.org is unresponsive at the moment but I believe the relevant e-mail threads are here:

  http://kerneltrap.org/mailarchive/git/2006/8/27/211001
  http://kerneltrap.org/mailarchive/git/2006/8/28/211065

My engineering intuition is that from a practical standpoint, this isn't an issue for Git. It's much more likely that the network will go down or all the copies of the repository become deleted or a developer will use Git tooling maliciously than for an unintended collision to occur.

Could a malicious actor construct a collision and use it to subvert some code base? Sure. And it has probably already happened. Crytography is considered a munition in the US and there are US government agencies which have been devoted to cryptography continuously since the Second World War and there are similar agencies in other countries and every last one of them employs many highly motivated highly educated and highly skilled cryptographic experts and the latest money is not an object compute hardware to find exactly this type of vulnerability, create capabilities based on that discovery, and to deploy them into the wild for national and political and economic interests.

To put it a different way, by the time something like this hits Hacker News, the odds are that organizations with the capability and funding to do things like inventing computers have already figured it out. Just as there is a discontinuity between what Google and SpaceX can do that looks like the future and the average engineer with a laptop or a garage can do that looks like the future, there is a similar gap between the future that Space X and Google can build and what a government institution can build. Space X hauls payloads to an existing station in LEO and Google runs on an internet that existed before it did.

The horses are long gone before anyone realizes the barn door is open.

It will not be an issue for existing commits, at least not yet.

Practically possible are collision attacks, which means someone with google-level hardware can craft 2 commits (one malicious) and keep the later for later.

Technically, the fix is for git to move to SHA256 or higher, and I'm sure there'll be discussions around this shortly in the git community.

The main idea behind the collision is that you can put a lot of garbage inside a pdf in a zone that the pdf reader will ignore. This is very common for most file formats, like jpg, doc, ... so the same idea applies to most of them.

But it will be very difficult to disguise that in a PR. If you send a PR that says

- printf("Helo");

+ printf("Hello");

+ // UIHIUEDN7heuiheuih7h00eduhuihoiu[...]hiouHIGo77OUIHIUHJ&g6(&(HHHIUHIIOJIOJK8jjoijoijdnYIHIHI

the maintainer will be very suspicious. (And if you do this in a business, they will fire you.)

Can you explain how git uses the sha-1 hash? If the maintainer still has to merge PRs I don't see how it's affected.

Reply on news.ycombinator.com