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

Removing SHA-1 for signatures in Fedora

Posted Mar 16, 2022 17:48 UTC (Wed) by hkario (subscriber, #94864)
In reply to: Removing SHA-1 for signatures in Fedora by khim
Parent article: Removing SHA-1 for signatures in Fedora

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.

to post comments

Removing SHA-1 for signatures in Fedora

Posted Mar 16, 2022 22:20 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

> 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

Posted Mar 17, 2022 11:28 UTC (Thu) by hkario (subscriber, #94864) [Link] (2 responses)

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

Removing SHA-1 for signatures in Fedora

Posted Mar 21, 2022 4:56 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

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

Removing SHA-1 for signatures in Fedora

Posted Mar 21, 2022 19:03 UTC (Mon) by hkario (subscriber, #94864) [Link]

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.