Adam Majer <ad...@zombino.com> writes: > On the other hand, if you are going to put any sort of trust into the > system, it's impossible to trust SHA1. It's being phased out in all > forms[1]. Currently, it takes about $50k to get a collision AFAIK.
Is that a collision against generic SHA1, or a collision against SHA1DC as is used in Git? > The bottom line is, GPG uses SHA256 or SHA512 for signing a message. But > when this message is SHA1 ... that signature is practically useless from > a security standpoint. At very least, it's *severely* weakened. The complaint I am always going to make about claims like this is that this is a very absolute statement to make about the properties of a system without additional context. This has some merit in providing people with simple rules of thumb to avoid tricky morasses that there is no need to trudge through, but rules of thumb are by definition sacrificing accuracy for simplicity. The context sometimes matters a great deal. Ask any Kerberos person about the constant carping about SHA1 in the Kerberos protocol, where it is used in ways that make hash collisions irrelevant. For example, there are a lot of situations in which the SHA1 weaknesses don't matter in Git because there is no realistic opportunity for an attacker to substitute an object with the same SHA1 hash. Is it complex to be certain that's the case? Yes. Is there some constant risk that you may start in such a situation and accidentally slip into a situation that is vulnerable to attack? Yes. Is it better to avoid SHA1 entirely so that you don't have to think about it? Absolutely. Is it correct to say, as an absolute statement, that a signature over a SHA1 hash is practically useless? No, it is not. This is far too strong of a claim. You have to analyze the attack first: what does the attacker have to do to substitute an underlying colliding object in such a way that the signature provides an incorrect promise? In some cases, this is a very real attack. In other cases, it is not. In the case of Git in particular, the provenance of the signed Git tree is relevant. In many usage scenarios, you are obtaining the Git tree from some other service or location that is at least partly trusted, which makes a practical attack via SHA1 collisions considerably harder. Would it be better to have a signature that is completely independent of provenance so that you don't have to think about this at all? Yes, absolutely. But the real world is full of trade offs. > We are now trying to use SHA256 repos with Gitea -- I've added SHA256 > support there last year and currently it "just works". Forgejo (gitea > fork) backported this support already too. This is excellent, and I hope progress on this front continues. Debian is effectively blocked on adopting SHA256 hashes for most of our Git repositories until GitLab adopts them. (That isn't the only obstacle, but it's probably the biggest one.) Analyzing SHA1 collision properties is quite annoying and tedious and I would love to stop having to do it by instead using a hash with better security properties everywhere. I hope the Git community can find a way to complete their migration. I am worried about some of the choices they made about how to do the migration (usually it's best practice to add general hash agility when fixing this type of issue), but I am not part of that development community and I'm sure they had their reasons. > IFF moving to SHA256 repos is impossible because no one cares to fix it, > then at very least these tags must use additional hashing for purposes of > tree verification. I consider it an ethical obligation as someone who works in security to object whenever people make these types of absolute statements about security properties. Security is almost always a trade off. You can usually get more security by trading off functionality, up to the obvious end point of securing a computer by turning it off. The best point to occupy on that trade-off curve is a hard question that always involves more factors than only security. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
