Re: Sha1 is not exactly secure
Adam Majer <adamm@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: