1. 50
  1.  

  2. 6

    I like the the cool blog name, funny.

    The only thing I use sha1 for nowadays is hit and this attack doesn’t seem to threaten git.

    1. 2

      I’m not sure I agree with that assessment about git. This would allow choosing the primary content of two blobs, generating a commented-out bit at the bottom, getting the benign one signed off, and polluting public repos with the malicious one.

      1. 5

        I would need multiple hash collisions. Even as the price drops from $75k each, that’s an expensive attack. And I would also need some identity to submit the request.

        So I imagine that if I submitted a merge with a suitable sha1 hash it would still be tracked to me and would need to be approved by someone with permissions on the repo. The diff processing for merges does not rely on sha1 to detect changes so my different bit would show up in the diff processing, I think.

        I’m trying to think of whether I can fake a release version but I think I would need to run my own git server (since GitHub/GitLab/sirht don’t allow this) and I think getting activity from a weird git server Is probably ignore.

        I think this is dangerous if git servers are breached because I would trust the server and not see a change when I pull down. But in this case, I already vet pull requests before using them, so if someone breaches GitHub they can just elevate privileges and make changes to repos using rebase to change history.

          1. 3

            Fortunately. I’m glad they are doing this.

            Linus Torvalds has post from 2017 when there was another paper about sha1 commissions [0] that helped me not worry too much. But I would rather not have this as an eventual topic for my security people to spend time on.

            [0] https://marc.info/?l=git&m=148787047422954

            1. 2

              Specifically, they’re planning on migrating to sha-256 and that decision was made in August 2018. I don’t know if any implementation has happened, though.

            2. 1

              If you were interested in getting a vulnerability introduced to a distributed binary, and were in a privileged network position, and the transmission was not encrypted (since the hashes are getting checked, they might not bother, like apt do), one hash collision would let you replace an existing file with your chosen text.

              1. 1

                It is possible to transmit unencrypted, but all the services I know require either TLS or SSH. So I would need root access over the server to change files.

                Also, I don’t think git uses sha1 for individual files, I would need a collision for all the various files that make up my commit. Even a commit with a single file change has hashes for all those little pieces. So for something I think would be dangerous, using git as a package repository, swapping out the package zip would require lots of collisions and either access to the two or breach.

                I’m interested in seeing a practical or a detailed theoretical attack on git.

                1. 1

                  Also, I don’t think git uses sha1 for individual files

                  It’s sha1 all the way down, including individual files!

                  https://git-scm.com/book/en/v2/Git-Internals-Git-Objects has the full details but the TL;DR is:

                  To generate the hash for a directory, a text file containing the filenames (IIRC alphabetically but unsure of order) along with their sha1 hashes, and that text file is then hashed.

                  The hash of the worktree (that is, the root directory of the repo) is therefore influenced by the hash of any directories it contains, and any files it contains. The hash of a commit includes its worktree and parent commit id.

                  As a result, if you could generate a chosen-text sha1 collision and be in a position to intercept transmission, you could replace a single file or folder without anything being the wiser (these are both quite expensive, however).

            3. 3

              I think there’s mitigation for that in git.

          2. 3

            So my question now is, how much does this affect SHA-256 and friends? SHA-256 is orders of magnitude stronger than SHA-1, naturally, but is it enough orders of magnitude?

            Also, it’s interesting to note that based on MD5 and SHA-1, the lifetime of a hash function in the wild seems to be about 10-15 years between “it becomes popular” and “it’s broken enough you really need to replace it”.

            1. 8

              […] the lifetime of a hash function in the wild seems to be about 10-15 years […]

              That’s assuming that we’re not getting better at creating cryptographic primitives. While there are still any number of cryptanalysis techniques remaining to be discovered, at some point we will likely develop Actually Good hashes etc.

              (Note also that even MD5 still doesn’t have a practical preimage attack.)

              1. 3

                It would stand to reason that we get as good at breaking cryptographic primitives as we get at creating them.

                1. 1

                  Why? Do you believe that all cryptographic primitives are breakable, and that it’s just a matter of figuring out in what way?

                  1. 1

                    I have no idea but that sounds like a GREAT theoretical math problem!

                2. 2

                  This seems likely, but we won’t know we’ve done it until 30-50 years after we do it.

                3. 5

                  In the response to the SHA1 attacks (the early, theoretical ones, not the practical ones) NIST started a competition, in part to improve research on hash function security.

                  There were voices in the competition that it shouldn’t be finished, because during the research people figured out the SHA2 family is maybe better than they thought. Eventually those voices weren’t heard and the competition was finished with the standardization of SHA3, but in practice almost nobody is using SHA3. There’s also not really a reason to think SHA3 is inherently more secure than SHA2, it’s just a different approach. Theoretically it may be that SHA2 stays secure longer than its successors.

                  There’s nothing even remotely concerning in terms of research attacking SHA2. If you want my personal opinion: I don’t think we’re going to see any practical attack on any modern hashing scheme within our lifetimes.

                  Also the “10-15 years” timeframe - there is hardly any trend here. How many relevant hash functions did we have overall that got broken? It’s basically 2. (MD5/SHA1). Cryptography just doesn’t exist long enough for there to be a real trend.

                  1. 5

                    As any REAL SCIENTIST knows, two data points is all you need to draw a line on a graph and extrapolate! :D

                    1. 1

                      FWIW, weren’t md2 and md4 were both used in real world apps? (I think some of the old filesharing programs used them.) They were totally hosed long before md5.

                      1. 1

                        I considered those as “not really in widespread use” (also as in: cryptography wasn’t really a big thing back then).

                        Surprising fact by the way: MD2 is more secure than MD5. I think there’s still no practical collision attack. (Doesn’t mean you should use it - an attack is probably just a dedicated scientist and some computing power away - but still counterindicating a trend.)

                        1. 1

                          I have a vague (possibly incorrect) recollection of hearing that RIAA members were using hash collisions to seed broken versions of mp3 files on early file sharing networks that used very insecure hashing which might have been md4 (iirc it was one where you could find collisions by hand on paper). Napster and its successors had pretty substantial user bases that I’d call widespread. :)

                    2. 2

                      The order of magnitude is a derivative of many years of cryptanalysis over the algorithm and the underlying construction. In this case (off the top of my head), this is mostly related to weaknesses to Merke-Damgard, which sha256 ony partially uses.

                      1. 1

                        How funny!

                        What are your relevant estimates for the time periods?

                        When was the SHA-256 adoption, again?

                        1. 12

                          Here’s a good reference for timelines: https://valerieaurora.org/hash.html

                          1. 2

                            That site is fantastic, thank you.