Removing SHA-1 for signatures in Fedora [LWN.net]

Removing SHA-1 for signatures in Fedora

Posted Mar 16, 2022 12:00 UTC (Wed) by pbonzini (subscriber, #60935)
In reply to: Removing SHA-1 for signatures in Fedora by foom
Parent article: Removing SHA-1 for signatures in Fedora

If you have a non-malicious commit and would like to distribute a forged commit with different contents, you would need a second preimage attack, which is a very different thing from all current practical (or almost-practical) attacks on SHA-1. All such attacks are collision attacks, and would only be usable by maintainers that are themselves malicious.

to post comments

Removing SHA-1 for signatures in Fedora

Posted Mar 16, 2022 13:35 UTC (Wed) by foom (subscriber, #14868) [Link] (5 responses)

So, the collision issue arises when one (malicious) entity authors some content, and another (trusted) entity reads and validates the content, and then signs it using a sha1 hash.

In that case, the trusted entity can be tricked into signing a sha1 hash created by the malicious one, with an intentional collision: one signed content which is innocent/expected, and another with the same hash -- and thus same signature -- that is malicious, and appears to have been signed.

This seems like a completely feasible attack scenario for git. Someone contributes an innocent looking change, which gets approved by the maintainer and a signed tag for release.

Of course, a mitigating factor is that not that many (if any) people even rely on git signatures in the first place as a way of validating content. Much more common is to fetch from a trusted host over tls, and implicitly trust the resulting content.

And another is that git switched to a Sha1 variant which is supposedly more collision resistant, but I don't know how safe that actually is.

Removing SHA-1 for signatures in Fedora

Posted Mar 16, 2022 14:27 UTC (Wed) by epa (subscriber, #39769) [Link] (4 responses)

It sounds as though the maintainer could defeat that attack by adding some random data to the commit message before signing. Or perturb the timestamp, perhaps by cherry-picking the change into a new commit, which can then be signed. That makes life more awkward for the original contributor when merging back, but only slightly.

Removing SHA-1 for signatures in Fedora

Posted Mar 16, 2022 17:24 UTC (Wed) by neverpanic (subscriber, #99747) [Link] (1 responses)

Some work is being done to add better collision resistance to GitHub/Git despite its use of SHA-1: https://github.blog/2017-03-20-sha-1-collision-detection-.... I couldn't immediately find a reference to their work with upstream on the mailing list, but I have also not done an extensive search.

Yes, it should also go, and it sounds like the Git developers are working on this. However, it would not be affected by this particular change, since from the OpenSSL library's point of view, Git's use of SHA-1 looks like a message digest only.

Removing SHA-1 for signatures in Fedora

Posted Mar 16, 2022 23:51 UTC (Wed) by nix (subscriber, #2304) [Link]

The reason why you can't find any recent references to this work is that it's done: the collision-detecting SHA-1 implementation you cite has been the default in git for years now, and the only available implementation for a year or so (it's slower than accelerated implementations, but the actual slowdown in practical git use is a percent or two at most: insignificant).

Removing SHA-1 for signatures in Fedora

Posted Mar 16, 2022 22:43 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

Traditionally, hashes are designed to be secure against three kinds of attack:

1. Preimage attacks, in which the adversary is given a digest, and wants to compute some plaintext that hashes to that digest.
2. Second-preimage attacks, in which the adversary is given both a plaintext and a digest, and wants to create a different plaintext with the same digest.
3. Collision attacks,in which the adversary is given nothing, and wants to create two plaintexts with the same digest.

These properties are generally regarded as sufficient, in the sense that "most" (or preferably all) direct attacks against a cryptographic scheme which relies on a hashing algorithm will necessarily be reducible to one of those three attacks. That is, if you can perform attack X, for arbitrary X, then you can convert X into one of (1), (2), and (3), provided the cryptographic system is properly designed. As a consequence, if the hash function is secure against (1), (2), and (3), then it is also secure against X, for any value of X.

The problem is, when we no longer have security against (3), we have to start worrying about other attacks that can be reduced to (3) but can't necessarily be reduced to (1) or (2). My concern is that, if we start doing this sort of ad-hoc adjustment ("add a few random bytes here, perturb a few nonce bytes there..."), that does not actually recreate security against collision attacks, and therefore there may be more complicated attacks which are capable of defeating the modified scheme (e.g. a "tamper-resistant collision attack" which is not equivalent to a full second-preimage or preimage attack, but is instead a superset of regular collision attacks where we allow some limited modifications to the first plaintext, outside of the adversary's control, which the adversary gets to see before they create their second plaintext).

My other concern is that cryptography is hard and the adversaries are probably smarter than I am.

Removing SHA-1 for signatures in Fedora

Posted Mar 17, 2022 8:24 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> My other concern is that cryptography is hard and the adversaries are probably smarter than I am.

They don’t need to be smarter, they just need to luck on a bug and understand its security implications. That’s what scary about defense/attack : the defender needs to perform a perfect job, the attacker just needs some luck once.