Live data from Hacker News

Linus on Git and SHA-1

plus.google.com

161–170 of 187 posts

Re: Linus on Git and SHA-1

#161

Earlier quoted context omitted.

I recently worked on a project where I had to choose a hash function for non-cryptographic error checking. I investigated CRC in detail for it, even wrote two different implementations from scratch. CRC-X is complicated to use and terrible choice. First of all, it is not a single algorithm, it is a family of algorithms . For a CRC of size N, you have to also choose a N-bit polynomial, N-bit starting value, and N-bit…

Would MD5 also not satisfy all the availablity and standardization problems you mentioned just as well as SHA-x ? and also meet other non security requirements of git just as well ? So why SHA-1 over MD5 which probably is move available and order of magnitude faster ? what problems MD5 has outside of its security that SHA-1 does not ?

So why SHA-1 over MD5 which probably is more available and order of magnitude faster?

This actually ends up not being true. Try

    openssl speed md5
    openssl speed sha1 
On a somewhat recent Intel CPU.

Re: Linus on Git and SHA-1

#162
post #79

Earlier quoted context omitted.

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…

> 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!!") Are we both reading the same GP comment? It reads as "If he took this stuff seriously, he wouldn't have waited 12 years since SHA-1 was broken to even start consid…

It's equivalent to the other comments. The others just have more facts to back it up & should've probably been the original. If The reason it's equivalent is:

1. Saw a known issue that cryptographers and security people were warning him about.

2. Alternatives existed that didn't have that issue. People were pushing on it.

3. Ignored all that to tell them it wasn't a problem, the issue could never have real-world consequences, and he wasn't interested in fixes.

In practice, that means he didn't take it seriously. He also made sure it wouldn't get fixed by letting people know he wasn't making a change to it. One more example in a long line of them where Linus doesn't give a shit about security enough to apply known, good practices.

Re: Linus on Git and SHA-1

#163
post #59
post #23

Earlier quoted context omitted.

Yes this is possible. It's called a preimage attack: https://en.wikipedia.org/wiki/Preimage_attack It's computationally infeasible against most cryptographically secure hash functions. However, Grover's algorithm results in a sqrt(keyspace) reduction in security levels (effectively halving bit-sized security levels): https://en.wikipedia.org/wiki/Grover's_algorithm

A successful preimage attack against a cryptographic hash would most likely find you a different message that gets you the same hash. You wouldn't do a preimage attack to find what the original input to create a hash was. You would do a preimage attack to find a new input with the same hash so that you could pass this new input around claiming it was the original (and have any signatures for the old input be valid fo…

What you described is called "second preimage attack", that's != "first preimage attack".

Re: Linus on Git and SHA-1

#164
post #159
post #157

Earlier quoted context omitted.

> people will cut and paste command lines from web pages [...] into root shells all the time! Do they? I've never encountered anyone using a root shell to go about their business unless they had to do some exclusive operation that could only be done as root, and even then they would rather just sudo that specific operation . Hell, even if they do do that, they have bigger problems than just git, given that cut and pa…

Do you know anyone who uses calibre, the e-book reader? You want to give it a try? Just cut and paste this: sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.py | sudo python -c "import sys; main=lambda:sys.stderr.write('Download failed\n'); exec(sys.stdin.read()); main()" Or you can trust my docker image, where I've done this for you: https://hub.docker.com/r/tytso/calibre/ (Hint: blindly us…

I actually don't know anyone who uses it. Any Linux users I know would just use the book reader from their distro's repository (in my case, FBReader).

EDIT: Also, holy s@@@ e-calibre, your advice (with a mild warning) if people get certificate errors is to pass in --no-check-certificate.

Re: Linus on Git and SHA-1

#165

Earlier quoted context omitted.

My takeaway from all that - the git project is internally taking steps to mitigate vulnerabilities from this particular attack (making it harder to insert the arbitrary binary data necessary into git metadata), but a) is just throwing up their hands at the problem of projects that store binary blobs like image data in their repos, and b) is not taking this as a signal that more serious sha-1 attacks are on the horizo…

SHA1 is only used for uniqueness. You still need to have write access to repo to perform attack. If you already have write access you do not need to make collision...

For this particular attack - what if you do not have write access, but have sufficient social capital to get a pull request merged with a benign-seeming file?

Re: Linus on Git and SHA-1

#166

Related, from Mozilla: * The end of SHA-1 on the Public Web https://blog.mozilla.org/security/2017/02/23/the-end-of-sha-... As announced last fall, we’ve been disabling SHA-1 for increasing numbers of Firefox users since the release of Firefox 51 using a gradual phase-in technique. Tomorrow [Feb 24th], this deprecation policy will reach all Firefox users. It is enabled by default in Firefox 52.

To be fair (although I've been commenting angrily about git's continued use of SHA-1 elsewhere) it's a lot easier for a browser to change hash algorithms than for git.

Re: Linus on Git and SHA-1

#167
post #88

Earlier quoted context omitted.

You're saying Linus's statements are "hugely misleading", but it's just that you wish git were designed to be used differently. So, your argument is "horseshit". Linus could have designed a cryptographically perfect system such that he could pull Tytso's signed commit from anywhere on the internet - but he didn't Linus used sha1 as a useful tool for an effective DVCS with an initially simple implementation. He still…

"Finally, no well-known SCM previous to git was based on perfect cryptographic proof of source history, or anything like that." This is actually false. Monotone, from which git takes a lot of cues (ask linus, or see wikipedia), was such a system.

Thus my qualification "well known". I was aware of monotone and Darcs ... but never used them, or knew anyone who did, or anyone who seriously considered it. I have no idea if Darcs is "cryptographically secure". But both of these were experimental and extremely slow at the time git was designed.

Re: Linus on Git and SHA-1

#168
post #159
post #157

Earlier quoted context omitted.

> people will cut and paste command lines from web pages [...] into root shells all the time! Do they? I've never encountered anyone using a root shell to go about their business unless they had to do some exclusive operation that could only be done as root, and even then they would rather just sudo that specific operation . Hell, even if they do do that, they have bigger problems than just git, given that cut and pa…

Do you know anyone who uses calibre, the e-book reader? You want to give it a try? Just cut and paste this: sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.py | sudo python -c "import sys; main=lambda:sys.stderr.write('Download failed\n'); exec(sys.stdin.read()); main()" Or you can trust my docker image, where I've done this for you: https://hub.docker.com/r/tytso/calibre/ (Hint: blindly us…

That docker file downloads Calibre over HTTP. Awesome!

Re: Linus on Git and SHA-1

#169

Earlier quoted context omitted.

"Finally, no well-known SCM previous to git was based on perfect cryptographic proof of source history, or anything like that." This is actually false. Monotone, from which git takes a lot of cues (ask linus, or see wikipedia), was such a system.

Thus my qualification "well known". I was aware of monotone and Darcs ... but never used them, or knew anyone who did, or anyone who seriously considered it. I have no idea if Darcs is "cryptographically secure". But both of these were experimental and extremely slow at the time git was designed.

"Thus my qualification "well known"." So that, to you, means "i don't know anyone who used them"?

Because that's a pretty small definition of "well known". For reference:

Inside the VCS community, they were very well known. Graydon also went on to start Rust, of course. Outside of that, even to corporations I dealt with (i was working on SVN at the time), plenty knew it existed, a few evaluated it.

" But both of these were experimental and extremely slow at the time git was designed."

I feel like this is just you trying to say "well, they never would have worked anyway".

DARCS was slow and couldn't be fixed, monotone was actually not that bad, and could be made very fast if necessary.

Monotone was slow precisely because it cared about integrity. If you made git care about integrity and security in the same way ... it would be just as slow!

Saying they were "experimental" is silly. Monotone was self hosting and nobody had found data corruption or other issues in quite a while (IE > 1 year), AFAIK. This is much better than git was for a long time. To put this in perspective, i converted the gcc repository (hundreds of thousands of revisions, in fact, many more than the kernel at the time, and history going back to 1983) to monotone, and 1. the conversion worked with no issues 2. Speed was fine in most cases. If i worked hard, i could find issues, but ....

git was beyond experimental at the time it was designed (IE data loss and repeated crashes). But it's design is essentially that of monotone in a different container and with slightly different goals. (IE they precisely gave up the integrity part that monotone verified and cared about, and people are now complaining about).

In truth, if Linus had cared about cryptographic security, he probably would have just stuck with monotone and rewritten parts of it. But he didn't, so he gave that up in the name of speed.

Which is fine, but let's not pretend that Linus somehow has a monopoly on design, or even was the first to design a VCS that was like git.

Any of the distributed VCSen could have beaten git. They just didn't care about the tradeoffs that git was making (IE non-portability in favor of speed), and honestly, it's pretty obvious git would have been laughed out of existence if it hadn't been supported by someone so popular to so many people.

In fact, it was laughed out of existence, the past N times people had devised VCSen that favored speed over portability.

Git is interesting as an example of how good marketing with the right figures sometimes leads to winning in the marketplace for long enough that you can fix the rest of your serious issues (IE everyone else had the OS/2 problem). Even more interesting is that everyone else backfills history to make it seem like it was the best and clearly the right set of tradeoffs from the start. It wasn't. It may not even be now! It's like any other system. Please don't try to backfill history here. I was there, as were many others.

Re: Linus on Git and SHA-1

#170
Newbie question .. can some one please help me understand the attack scenario. if I, as the attacker, want to inject malicious code/binary into a git repo, then I need to write my malicious code/binary in such a way that the resultant hash collides with one of the commits (? Or the last one?) in the repo. Is this correct?
Post reply on HN