LWN: Comments on "Removing SHA-1 for signatures in Fedora"

Breaks listing or upgrading SHA-1 RPMs

AdamW — Wed, 23 Mar 2022 06:41:28 +0000

IIRC it is possible to implement something more finely grained than just "pick DEFAULT or LEGACY" with the crypto-policies system, but it's more complicated and difficult. This again is similar to SELinux, where it's usually a much better idea to create a custom policy than just switch to permissive mode, but doing so is more than a single command so people just use the big hammer...

Removing SHA-1 for signatures in Fedora

hkario — Mon, 21 Mar 2022 19:03:27 +0000

There has been interfaces to perform certificate verification at a given time for decades now.
The thing is that basically no signature includes a trustworthy timestamp that allows you to perform verification at any other time than *now*.

Those interfaces are used for systems that handle CAdES or PAdES, not S/MIME, SSH and TLS.

Removing SHA-1 for signatures in Fedora

mathstuf — Mon, 21 Mar 2022 04:56:59 +0000

> Or to put it other way, just like certificates have expiry dates on them, so do hashes.

It seems like the API for verifying signatures needs to be richer then. Allow verifying anything, but have it decorated with an "expiry date" kind of tag so that you can get tags like:

> Verified (trusted)
> Verified (be suspicious if signed after 2022-01)

Basically, it sounds like a simple boolean is just not rich enough to convey signature validity.

Breaks listing or upgrading SHA-1 RPMs

jccleaver — Thu, 17 Mar 2022 23:59:22 +0000

Yeah, the RPM signature incompatibility between EL5 and EL6 was ugly, and a pain during that entire transition for people that were heavily using RPMs for configuration and deployment, with SRPMs going back and forth.

Removing SHA-1 for signatures in Fedora

hkario — Thu, 17 Mar 2022 11:28:23 +0000

> Either API, which may your mail client uses, was extensible exough and it would transparently switch to SHA-512 or something… or it wasn't flexible and you need to change source and recompile it.

You're completely missing the issue.

The problem is not what my client creates. It's about what my client will accept from the network. And my client was able to accept SHA-256 and SHA-512 10 years ago, the problem is that what it gets doesn't depend on my client, it's completely up to the sender.

What's changing, is the set of algorithms the underlying cryptographic library will accept when verifying the signatures. Now that set doesn't include SHA-1, just like it didn't include MD4 and MD5. The difference being that SHA-1 was far more widespread than MD5 so deprecating it is much more complex.

Or to put it other way, just like certificates have expiry dates on them, so do hashes. Just because a certificate worked yesterday doesn't mean it will work today. It just isn't as clear-cut with hashes.

Breaks listing or upgrading SHA-1 RPMs

rwmj — Thu, 17 Mar 2022 08:32:27 +0000

One thing that isn't clear about this change is that it breaks listing out and upgrading installed RPMs that are using SHA-1 signatures. So it's not only a question of whether third party repos are still using SHA-1, but whether third party repos have ever used SHA-1 signatures and those packages could still be installed.

The way around this is (and indeed any other SHA-1 related problem) is:

update-crypto-policies --set LEGACY

but this is a huge hammer, reducing security across the whole system. This might become the new "disable SELinux" which took years and years to overcome. I asked the developers to look again and see if we can make safer tools:

https://bugzilla.redhat.com/show_bug.cgi?id=2064740

For me the RPM / SHA-1 change particularly affected libguestfs which wants to analyze the RPMs in old guests (eg. RHEL < 5). We worked around it by turning off RPM signature validation, which is (arguably) bad, but it's only for examining already installed RPMs so I guess it'll be OK.

Removing SHA-1 for signatures in Fedora

rwmj — Thu, 17 Mar 2022 08:25:25 +0000

The primary goal should be the introduction of a mechanism that makes removal of insecure cryptographic algorithms in general easier in the future in software affected by making uses and implementations easier to discover as well as making algorithms configurable where they are used and flexible where they are part of some standard.

This is sort of what crypto-policies does. In fact this SHA-1 change is done by changing the system crypto policy, and I don't think very much else changed if anything.

Removing SHA-1 for signatures in Fedora

nim-nim — Thu, 17 Mar 2022 08:24:07 +0000

> 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.

Removing SHA-1 for signatures in Fedora

nix — Wed, 16 Mar 2022 23:51:14 +0000

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

NYKevin — Wed, 16 Mar 2022 22:43:04 +0000

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

khim — Wed, 16 Mar 2022 22:20:29 +0000

> It doesn't matter if my mail client was compiled 10 years ago, I don't want it to trust SHA-1 signatures today because they could have been forged yesterday.

You can not have your cake and eat it, too. Deal with it.

Either API, which may your mail client uses, was extensible exough and it would transparently switch to SHA-512 or something… or it wasn't flexible and you need to change source and recompile it.

There are no silver bullet or magic wand which may solve that dilemma.

It's the same story as with Y2K change.

> The other problem is that the RHEL-9 change doesn't remove SHA-1 hash, or any symbols associated with it, it forbids the combination of SHA-1 and public key cryptography.

What does it change? Yes, it affects not the raw low-level libcrypto, but higher-level libssl (and other such libraries).

Approach doesn't change, target does.

Removing SHA-1 for signatures in Fedora

neverpanic — Wed, 16 Mar 2022 17:49:15 +0000

Working on it, stay tuned.

Removing SHA-1 for signatures in Fedora

hkario — Wed, 16 Mar 2022 17:48:47 +0000

That's because the behaviour of the symbols isn't changing to make developers lives easier.
It's changing because with the exception of verifying signatures you can prove were made way, way back, you should really not trust SHA-1 signatures.

It doesn't matter if my mail client was compiled 10 years ago, I don't want it to trust SHA-1 signatures today because they could have been forged yesterday.

The other problem is that the RHEL-9 change doesn't remove SHA-1 hash, or any symbols associated with it, it forbids the combination of SHA-1 and public key cryptography.

Removing SHA-1 for signatures in Fedora

neverpanic — Wed, 16 Mar 2022 17:24:06 +0000

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

epa — Wed, 16 Mar 2022 14:27:52 +0000

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

foom — Wed, 16 Mar 2022 13:35:22 +0000

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

pbonzini — Wed, 16 Mar 2022 12:00:32 +0000

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.

Removing SHA-1 for signatures in Fedora

foom — Wed, 16 Mar 2022 11:49:55 +0000

Git's signatures are pretty-much worthless if sha1 is considered fully broken, because all that's signed is name, email, time, message, and the sha1 hash of the commit or tree object the signature is for.

https://git-scm.com/docs/signature-format

Removing SHA-1 for signatures in Fedora

khim — Wed, 16 Mar 2022 11:30:07 +0000

That's self-inflicted wound: just create a separate shim libraries and use them to compile programs which misbehave with SHA1 disabled.

Third-party apps (which you couldn't test) wouldn't be affected. And you may even do what Android does: certain other, new, libraries would be incompatible with these shims. That way developers would be forced to stop using them if they want new features.

Removing SHA-1 for signatures in Fedora

pbonzini — Wed, 16 Mar 2022 10:17:13 +0000

git does not use SHA1 for signing, only as a message digest.

Removing SHA-1 for signatures in Fedora

taladar — Wed, 16 Mar 2022 09:11:12 +0000

Removing SHA-1 should only be a secondary goal here in my opinion. The primary goal should be the introduction of a mechanism that makes removal of insecure cryptographic algorithms in general easier in the future in software affected by making uses and implementations easier to discover as well as making algorithms configurable where they are used and flexible where they are part of some standard.

Also, am I missing something or are they forgetting about the elephant in the room when it comes to SHA-1 use, git.

Removing SHA-1 for signatures in Fedora

pabs — Wed, 16 Mar 2022 04:35:31 +0000

It would be great to have a way to turn off SHA-1 on a system so that things depending on SHA-1 could be discovered and fixed.

Removing SHA-1 for signatures in Fedora

nevyn — Wed, 16 Mar 2022 03:08:53 +0000

Fedora recompiles everything each release, so having a new symbol (and maybe new config. options) just to remove sha1 as a default allowed signature still affects all users using all Fedora binaries.

Removing SHA-1 for signatures in Fedora

khim — Tue, 15 Mar 2022 22:21:49 +0000

Can anyone explain what I'm missing?

We have special tool made just to handle that case.
We want to get what that tool is designed to provide (programs are broken for developers, not users).
Yet we refuse to use it, because… umm… why exactly it's not supposed to be used?