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

Removing SHA-1 for signatures in Fedora

Posted Mar 16, 2022 14:27 UTC (Wed) by epa (subscriber, #39769)
In reply to: Removing SHA-1 for signatures in Fedora by foom
Parent article: Removing SHA-1 for signatures in Fedora

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.

to post comments

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.