Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus on Git and SHA-1

plus.google.com

Post reply on HN
Print view View original

71–80 of 187 posts

Re: Linus on Git and SHA-1

#71

Post by wongarsu »

gkya wrote: post #45
bascule wrote: post #3

Linus's transition plan seems to involve truncating SHA-256 to 160-bits. This is bad for several reasons: - Truncating to 160-bits still has a birthday bound at 80-bits. That would still require a lot more brute force than the 2^63 computations involved to find this collision, but it is much weaker than is generally considered secure - Post-quantum, this means there will only be 80-bits of preimage resistance (Also:…

If a repo contains binary blobs, especially executables, well, that's very bad practices right there. Also, how can somebody else modify a binary in a meaningful way and send a patch to it? How can you review a patch to a binary file before applying? I'd say that any sane project, especially if open source , would not include binaries (maybe apart from images), and even if it did, would not accept patches to them (if…

Executables in git are bad practise, but not all that uncommon. Images in git are the norm, and if somebody comes in and creates a pull request with an improved version of the existing images (better compression, better adapted for color blind people, fixing whitespace issues etc.) that's pretty unsuspicious and likely to succeed (and I've seen it multiple times).

Re: Linus on Git and SHA-1

#72

Post by simplehuman »

AgentME wrote: post #57
simplehuman wrote: post #56

Earlier quoted context omitted.

> Linus just doesn't take this stuff seriously. I really wish he would, though. Can't downvote this enough. This is plain FUD. Did you even read the complete thread on the git mailing list? This was just one proposal by him.

If he took this stuff seriously, he wouldn't have waited 12 years since SHA-1 was broken to even start considering any changes.

So did anyone on this thread send patched to the mailing list? Obviously you guys are very serious right?

Re: Linus on Git and SHA-1

#73

Post by derefr »

runeks wrote: post #39
diminish wrote: post #13

Earlier quoted context omitted.

additionally cosmetics but instead of hex string could they not use a-zA-Z0-9 in the visual output to the user to make the git command line text output shorter? 0efaa. -> 2AdC..

Then you have stuff like 1, I and l, which are difficult to distinguish. Which was why base58 was invented (basically the range you suggested, without visually similar characters).

And zbase32 (https://philzimmermann.com/docs/human-oriented-base-32-encod...), which is my own preference for still being case-insensitive and thereby able to be used in subdomain names or email addresses.

Re: Linus on Git and SHA-1

#74

Post by simias »

While this post sounds very reasonable to me there's one point that I really don't get: why does he keep saying that git commit hashes have nothing to do with security?

If he believes that, why does git allow signing tags and commits and why does Linus himself sign kernel release tags? Isn't that the very definition of "using a hash for security"?

Re: Linus on Git and SHA-1

#75

Post by derefr »

hermitdev wrote: post #27
hdhzy wrote: post #14

Earlier quoted context omitted.

I think the truncation is considered because a lot of software assumes git commit id has 160 bit length. It's not because of performance.

There are only 2 reasonable rationales for the 160 bit restriction: it was arbitrary because that was the length of the chosen hash, or for performance (and no one will ever need more that 640kb of RAM, or 160 bits of hash). I'm guessing it was probably the first, though, and Linus designed for the immediate now, and not for the future.

It's not even a "restriction", so much as a fragile ecosystem of tools that parse the output of git commands. A lot of them assume particular column widths.

Re: Linus on Git and SHA-1

#76

Post by Anderkent »

bascule wrote: post #63
infinity0 wrote: post #58

Earlier quoted context omitted.

> "A hash that is used for security is basically a statement of trust [..] In contrast, in a project like git, the hash isn't used for "trust". I don't pull on peoples trees because they have a hash of a4d442663580. Our trust is in people, and then we end up having lots of technology measures in place to secure the actual data." This is horseshit, and Linus should not be saying these hugely misleading statements abou…

Yes, exactly. If Linus truly doesn't care about security, then git could use any error correcting code that produces a uniform distribution of tags, such as CRC64. The size of the tag only affects the number of objects we'd expect to be able to commit before we see a collision: over 4 billion in the case of CRC64. Linux mistakenly claims using a cryptographic hash function helps avoid non-malicious collisions, but th…

Well, if the cost of computation is not too relevant, and if you don't explicitly need the ability to craft collisions, why would you use a non-cryptographic hash function?

Like, when I'm building a lookup index for files, I'm going to use sha-(something), because it's easy and well known. I don't particularly care about the security aspect; I care that everyone immediately knows the contract of sha-1.

Re: Linus on Git and SHA-1

#77

Post by [deleted] »

bascule wrote: post #63
infinity0 wrote: post #58

Earlier quoted context omitted.

> "A hash that is used for security is basically a statement of trust [..] In contrast, in a project like git, the hash isn't used for "trust". I don't pull on peoples trees because they have a hash of a4d442663580. Our trust is in people, and then we end up having lots of technology measures in place to secure the actual data." This is horseshit, and Linus should not be saying these hugely misleading statements abou…

Yes, exactly. If Linus truly doesn't care about security, then git could use any error correcting code that produces a uniform distribution of tags, such as CRC64. The size of the tag only affects the number of objects we'd expect to be able to commit before we see a collision: over 4 billion in the case of CRC64. Linux mistakenly claims using a cryptographic hash function helps avoid non-malicious collisions, but th…

[deleted]

Re: Linus on Git and SHA-1

#78

Post by bascule »

Anderkent wrote: post #76
bascule wrote: post #63

Earlier quoted context omitted.

Yes, exactly. If Linus truly doesn't care about security, then git could use any error correcting code that produces a uniform distribution of tags, such as CRC64. The size of the tag only affects the number of objects we'd expect to be able to commit before we see a collision: over 4 billion in the case of CRC64. Linux mistakenly claims using a cryptographic hash function helps avoid non-malicious collisions, but th…

Well, if the cost of computation is not too relevant, and if you don't explicitly need the ability to craft collisions, why would you use a non-cryptographic hash function? Like, when I'm building a lookup index for files, I'm going to use sha-(something), because it's easy and well known. I don't particularly care about the security aspect; I care that everyone immediately knows the contract of sha-1.

There is nothing to be gained from using cryptographic primitives in a non-security context. You could just as easily use e.g. CRC32 for the case you're describing.

There is, however, a performance cost in using cryptographic primitives in non-security-related contexts. You may not care about performance, but it certainly matters for something like git.

Linus claims: "So in git, the hash is used for de-duplication and error detection, and the 'cryptographic' nature is mainly because a cryptographic hash is really good at those things."

CRC produces a distribution just as uniform as a cryptographic hash function, and it's faster to boot. If these are the only things he actually cares about, and he's explicitly discounting security, he's choosing a slower primitive for no reason.

He writes off CRC inexplicably earlier in the post:

"Other SCM's have used things like CRC's for error detection, although honestly the most common error handling method in most SCM's tends to be 'tough luck, maybe your data is there, maybe it isn't, I don't care'."

Linus seems to think that SHA1 has some sort of magic crypto sauce which magically makes the distribution it produces more uniform than CRC's. It doesn't. The only difference is SHA1 was originally designed to be resistant to preimage and collision attacks, both of which are irrelevant outside of a security context.

Re: Linus on Git and SHA-1

#79

Post by aseipp »

simplehuman wrote: post #72
AgentME wrote: post #57

Earlier quoted context omitted.

If he took this stuff seriously, he wouldn't have waited 12 years since SHA-1 was broken to even start considering any changes.

So did anyone on this thread send patched to the mailing list? Obviously you guys are very serious right?

This conversation has gone on several times over the course of years on the Git mailing list. In almost every situation it's been completely brushed off as a mostly non-issue to change from SHA-1 inside Git, despite the fact it's been known SHA-1 has basically been on life support. There are lots of opinions on both sides, but ultimately, until now, the Upstream decision seemed to be "WONTFIX".

Given this context, of course nobody wrote patches: they would have obviously been rejected and been a total waste of time. Until now, when we actually have to deal with it.

This is all aside from your argument being fundamentally weak, however ("you can't criticize anything unless i say so and contributed by meeting this arbitrary standards. i mean, didn't do anything either, i just get to make up the rules you abide by!!")

Re: Linus on Git and SHA-1

#80

Post by x1798DE »

hueving wrote: post #33
chainsaw10 wrote: post #21

Earlier quoted context omitted.

> reversing commit hashes back into their contents Somewhat off topic, but is this actually possible? Given hashing is inherently lossy, I'm inclined to assume it's not possible for anything must longer than a password, but commits are text, which I suppose is low entropy per character, so I don't know.

No, you're correct that for large inputs there are obviously going to be many that lead to the same hash (see pigeonhole principle).

This is presumably true also of small inputs, given that the large and small inputs are all mapping to the same space.
Post reply on HN