RIPEMD160 missing in default provider although security is not worse than SHA1 and it is used in Bitcoin

[acostaja]

I've read the issues, the suggested path to enable legacy provider besides cumbersome its dangerous, developers should provide a SAFE methot to easy continue using this library as it despite alll the comments will stay for long time as is part of cryptocurrency algorithms.
Devs should provide an improvement to this situation you are responsible for.

[paulidale]

In what way is it dangerous?

Failing to find an old weak algorithm doesn't strike me as cause for concern.

[t8m]

Well, RIPEMD160 is definitely not worse than SHA1 in terms of security strength so there are some merits in not having it in legacy provider but in the default.

Summary for OTC decision: Should RIPEMD160 be moved back to default provider in some release given its use by Bitcoin and given that SHA1 is in default too?

It's fairly unfortunate that nobody from the cryptocurrency community noticed that RIPEMD160 was placed in the legacy provider before the 3.0 release.

[beldmit]

In my understanding of an ideal world :) we should have a separate provider for RIPEMD160. And probably, for SHA1.

[t8m]

That would be an overkill. IMO. Perhaps there should be a way to enable only selected algorithms from a provider?

Something like OSSL_PROVIDER_mask_algorithms(OSSL_PROVIDER *prov, char *enable_mask[], char *disable_mask[]);

[paulidale]

OTC: this will not change for 3.x. For 4.0 we can move algorithms back since it's a compatibility question.

[paulmillr]

I don't understand who has made this dumb decision to remove RIPEMD160, but not sha1. It's sha1, which has vulnerabilities — not RIPEMD, which is widely used.

[paulidale]

It might be possible to duplicate RIPEMD160 in the default provider & the legacy provider which circumvents the compatibility concern.

[t8m]

Let's ask OTC another question:

OTC: Should RIPEMD160 be added to the default provider in addition to keeping it in legacy provider in 3.2 release?

[paulidale]

3.1 release?

[t8m]

3.1 release?

or that one

[sebastianas]

3.1 release?

or that one

I don't see the point in deferring it to 3.1. We have 3.0 now in Debian unstable/testing and it will be part of the upcomming stable release. This means every piece of software that requries RIPEMD160 for normal operation needs to act by extending its code and ensuring that the legacy provider is loaded so that RIPEMD160 can be used.
OpenSSL 3.1 won't make it into the upcomming stable release given that the freeze (of the code that will make it into the Debian Stable release) is early next year. That means from Debian's point of view every piece of software needs a workaround for 3.0 relase of OpenSSL.
Once that has been added, I doubt that the affected projects are eager to remove it if compiled against 3.1 (or 3.2).

That said, if you plan to add ripemd160 to the default provider because there is nothing wrong with it from the security point of view, please do it starting with 3.0 where it has been identified as a regression by its users.

[beldmit]

We have 3.0 now in Debian unstable/testing and it will be part of the upcomming stable release. This means every piece of software that requries RIPEMD160 for normal operation needs to act by extending its code and ensuring that the legacy provider is loaded so that RIPEMD160 can be used.

No, it doesn't. If you have a lot of this software, you can load the legacy provider via system config. If you have a single program, you can craft a special openssl config for this application.

[t8m]

The change would have to get an OMC exception to get to the 3.0 releases. It is not a bug fix.

[acostaja]

Incredible this mess still waiting for a remedy.
This is very disappointing on what programmers expect from OpenSource.
Excessive bigotry from OTC to recognize the mess they created.
It's right to flag RIPEMD160 as unsafe and encourage coders/users to avoid it.
But WAS an BIG ACT OF IRRESPONSIBILITY to remove it as available provider.

[t8m]

The algorithm is legacy as it does not provide adequate security for a hash function (at least 128 bit security against collision attacks). It is another question why we have to keep sha1 in default provider as its use should go away as well.
Also the RIPEMD160 is not removed from OpenSSL as it is available in legacy provider and any application that needs it can load the legacy provider.

[dangell7]

RIPEMD160 is 160 bit algorithm. It was removed as a primary algorithm because collision attacks can occur on algorithms without at lease 128 bit.

SHA1 is a 160 bit algorithm. It was NOT removed as a primary algorithm because collision attacks can occur on algorithms without at lease 128 bit.

Some logic you have there.

[beldmit]

SHA1 is widely used for many purposes that aren't security-related. RIPEMD160 is used by a quite limited community.

[paulmillr]

RIPEMD160 is used by the biggest cryptocurrency in the world, which existed for 14 years.

[dangell7]

SHA1 is widely used for many purposes that aren't security-related. RIPEMD160 is used by a quite limited community.

SHA1 is dead and stop dictating who and what the algorithms are used for and by who.

Completely biased answer btw. Great work. FFS

[acostaja]

Actually ripemd160 is in use by an not so small community: Bitcoin, thankfully it's security ussues are harmless as it's purpose is almost cosmetic (p2pkh address from secp256k1 public address).

The mess is that this move broke services on attribution no coder expected from OTC, about the availability from legacy providers: ask an python crypto Library maintainer what's happens...

IMHO current OTC should move away and new OTC team should go in charge.sadly this is not an democracy neither an corporation where affected parts could start some procedures.

[dangell7]

Actually ripemd160 is in use by an not so small community: Bitcoin, thankfully it's security ussues are harmless as it's purpose is almost cosmetic (p2pkh address from secp256k1 public address).

The mess is that this move broke services on attribution no coder expected from OTC, about the availability from legacy providers: ask an python crypto Library maintainer what's happens...

IMHO current OTC should move away and new OTC team should go in charge.sadly this is not an democracy neither an corporation where affected parts could start some procedures.

The guy above even admitted they left SHA1 for "other" use cases. It was a biased decision not based on "security" at all.

[mattcaswell]

"bigotry" is a strong term with very negative connotations - strongly associated with prejudice and intolerance of particular groups of people. It is not the kind of term I would expect to see in a respectful debate. Some of the language used in this discussion I find personally upsetting. Please remember that the people that you engage with in online forums are real people with real thoughts and feelings.

I have no problem with dissent or disagreement on a technical issue. Some of the language used here goes way beyond that. Unfortunately I suspect it will have the effect of dissuading some of the people you would like to convince from actually taking part in the discussion.

I once again remind everyone to adhere to the code of conduct. If that cannot be done then discussion on this thread may have to be locked.

[dangell7]

bigotry

bigotry:

stubborn and complete intolerance of any creed, belief, or opinion that differs from one's own.

"SHA1 is widely used for many purposes that aren't security-related. RIPEMD160 is used by a quite limited community."

Your team literally will not accept the fact that there is a large community that uses RIPEMD160 and that most cryptography experts believe SHA1 is worse than RIPEMD160.

[acostaja]

Escuse me, English is not my native language, if the term bigotry seems offensive I retire lt, my apologies.

In exchange for the term, I could use 'lack of understanding and will to serve the community and be accountable for unprofessional irresponsible behavior'

My apologies If the term bigotry was irespectful , I'm so sorry.

[mattcaswell]

The OTC and the OpenSSL community draws from a wide range of backgrounds and opinions. Individuals express their own opinions - but they do not necessarily represent the view of the OTC as a whole. I think most people on the OTC are willing to engage on this topic.

FWIW, my opinion on this is that moving RIPEMD160 to the legacy provider in 3.0 was a mistake. However, since it was a deliberate decision to do this (even if the decision was incorrect), it is not a bug in 3.0. We have a policy which says we can only backport bug fixes to a stable branch. This policy exists for very good reasons. It is a key objective to maintain the stability of our stable branches. It is possible to agree exceptions to our policies from time-to-time. To do that though we would have to be very confident that the proposed change was not destabilising or would have undesirable impacts for current users. Also it would have to have strong arguments to justify the breaking of policy. I am not currently convinced that that bar has been met with the arguments presented so far. While it is certainly less than ideal there is a relatively easy workaround to the problem in the short term. I think moving RIPEMD160 back into the default provider from 3.1 might be a reasonable way to go.

most cryptography experts believe SHA1 is worse than RIPEMD160

I don't think anyone disputes this.

[dangell7]

And when was this policy implemented? Around the time you pulled RIMEMD160?

Do whatever you want, I can't follow any of your logic. You admit it was a mistake, you admit SHA1 is worse, you admit theres a large community that uses this. Yet your "policy" doesn't allow you to fix your own mistake.

Your policy should have a clause for breaking changes.

I can't imagine what would happen if openssl made a serious mistake. "Wait for the next major version"

ok

[acostaja]

What I see is someone at OTC has his EGO well over the community interest.

Fact: removing ripemd160 was an biased error, founded on bias not actual policy (if so, sha1 should have leave way before).

Fact: solving the issue is so simple and trivial it shouldn't ashame nobody at the OTC, a simple sorry here is again, won't allow the blood reach the pond.

Fact: OTC is aware this disaster for months and no solution yet (worse given how trivial is it).

Explain with actual published policy why there's no ripemd160 meanwhile sha1 still going on? Why if this evidently is an mistake trivial easy to repair it still delayed?

Something is wrong with OTC, behavior is not technical neither fair, and has no commitment with actual software lifecycles.

IMHO this situation exposed someone is unfit, I as employer won't consider any resume from people signing as openssl OTC given actuations like this don't provide any trust on profesional unbiased committed service.

It's an serious situation for OTC members.

[dangell7]

Can you imagine me doing this as a developer?

Hey, version 3.0 is out. Unfortunately it doesn't work on windows devices however because of our policy and because we made this decision on purpose, we're not going to make any changes until the next major version.

Also, we made this decision because we don't believe users are using windows

Really...

[mattcaswell]

And when was this policy implemented? Around the time you pulled RIMEMD160?

The policy was more formally implemented fairly recently. But it has been our working practice for the duration of the time I have worked on OpenSSL (and I believe a long time before that).

I have seen enough instances where an apparently innocuous change has had all sorts of unintended consequences and breakage that I firmly believe this policy is the right one.

Your policy should have a clause for breaking changes.

I can't imagine what would happen if openssl made a serious mistake. "Wait for the next major version"

3.0 was a major release and as such breaking changes were explicitly allowed. We knew that moving some algorithms to the legacy provider would be a breaking change for some users. We believed though that for security reasons it was worth it. IMO in the case of RIPEMD160 we got it wrong. But the fact that it was a breaking change is not a strong argument in itself. Moving from 1.1.1 to 3.0 is inherently breaking. We tried to keep the breakage to a minimum, but if that is the only breaking change you have encountered then you are doing quite well.

Our policies always have the option of being overridden by an explicit exception. In the event of a serious mistake we can always take that path. What is at debate here is whether this mistake is sufficiently serious to justify an exception to policy (and hence it should go to 3.0); whether we should fix it in a future release (and if so which one: 3.1, 3.2, 4.0); or whether we should just live with the mistake and keep it as it is.

Given the existence of a simple workaround for the problem I think it is difficult to justify an exception to policy.

[dangell7]

What I see is someone at OTC has his EGO well over the community interest.

Fact: removing ripemd160 was an biased error, founded on bias not actual policy (if so, sha1 should have leave way before).

Fact: solving the issue is so simple and trivial it shouldn't ashame nobody at the OTC, a simple sorry here is again, won't allow the blood reach the pond.

Fact: OTC is aware this disaster for months and no solution yet (worse given how trivial is it).

Explain with actual published policy why there's no ripemd160 meanwhile sha1 still going on? Why if this evidently is an mistake trivial easy to repair it still delayed?

Something is wrong with OTC, behavior is not technical neither fair, and has no commitment with actual software lifecycles.

IMHO this situation exposed someone is unfit, I as employer won't consider any resume from people signing as openssl OTC given actuations like this don't provide any trust on profesional unbiased committed service.

It's an serious situation for OTC members.

This issue goes WAY beyond RIPEMD160.

And when was this policy implemented? Around the time you pulled RIMEMD160?

The policy was more formally implemented fairly recently. But it has been our working practice for the duration of the time I have worked on OpenSSL (and I believe a long time before that).

I have seen enough instances where an apparently innocuous change has had all sorts of unintended consequences and breakage that I firmly believe this policy is the right one.

Your policy should have a clause for breaking changes.
I can't imagine what would happen if openssl made a serious mistake. "Wait for the next major version"

3.0 was a major release and as such breaking changes were explicitly allowed. We knew that moving some algorithms to the legacy provider would be a breaking change for some users. We believed though that for security reasons it was worth it. IMO in the case of RIPEMD160 we got it wrong. But the fact that it was a breaking change is not a strong argument in itself. Moving from 1.1.1 to 3.0 is inherently breaking. We tried to keep the breakage to a minimum, but if that is the only breaking change you have encountered then you are doing quite well.

Our policies always have the option of being overridden by an explicit exception. In the event of a serious mistake we can always take that path. What is at debate here is whether this mistake is sufficiently serious to justify an exception to policy (and hence it should go to 3.0); whether we should fix it in a future release (and if so which one: 3.1, 3.2, 4.0); or whether we should just live with the mistake and keep it as it is.

Given the existence of a simple workaround for the problem I think it is difficult to justify an exception to policy.

What other algorithms were removed in v3?

[mattcaswell]

What other algorithms were removed in v3?

No algorithms were removed. They were moved to the legacy provider and hence aren't available by default. It is straight forward to load the legacy provider. The list of algorithms in the legacy provider is here:
https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html

[dangell7]

Where is the policy, can I review it and see the change log for this policy?

[dangell7]

What other algorithms were removed in v3?

No algorithms were removed. They were moved to the legacy provider and hence aren't available by default. It is straight forward to load the legacy provider. The list of algorithms in the legacy provider is here: https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html

What algorithms were moved to legacy in v3?

[mattcaswell]

Where is the policy, can I review it and see the change log for this policy?

You can read the policy on our website here:

https://www.openssl.org/policies/technical/stable-release-updates.html

It is maintained in this git repo:

https://github.com/openssl/technical-policies

What algorithms were moved to legacy in v3?

All of those listed in the man page I linked to (the legacy provider (or the provider concept in general) did not exist prior to v3).

[dangell7]

So for anyone interested openssl v3 was announced September 7th 2021.

The first issue of RIPEMD160 was #16994 on November 8 2021.

A month later on December 14th 2021 a policy was ADDED, not amended, added that included the - replacement implementation of algorithms is not a bug fix.

The policy came AFTER your mistake...

[mattcaswell]

The policy came AFTER your mistake...

Like I said the "bug fixes only to stable releases" policy has long been our working practice. The most recent version of that policy is an attempt to more fully define what we mean by that - but it has long been the case. You can see earlier versions of some of this here

https://www.openssl.org/policies/releasestrat.html

Which says (for the old versioning scheme):

"Letter releases, such as 1.0.2a, exclusively contain bug and security fixes and no new features."

[acostaja]

OTC, there is enough evidence your proceed where unprofessional, unfair, inopportune, AND BIASED, against an not small neither invisible community: Bitcoin.

If you (OTC) had to go to trial, would have an very bad day, as no excuses exposed is either based on actual facts, neither exposes logical procedures, neither it's remedy (activate legacy providers don't work on python and neither it's trivial on other languages where openssl is used).
The simple and fair solution: move it back to the default provider's.

EDIT: removed rant vocabulary, my apologies

[mkoci-koca]

OTC, there is enough evidence your proceed where unprofessional, unfair, inopportune, AND BIASED, against an not small neither invisible community: Bitcoin.

If you (OTC) had to go to trial, would have an very bad day, as no excuses exposed is either based on actual facts, neither exposes logical procedures, neither it's remedy (activate legacy providers don't work on python and neither it's trivial on other languages where openssl is used). The OTC should be ashamed, and respect fellow programmers, most here have more extensive resumes than many of your current employers and all you do to justify this mess put you on evidence as mediocre coders not deserving support or job opportunities.

The more you justify more SHTF against yourselves as all this lack logic while the remedy suggested is inapplicable for most cases (as python crypto a.e. doesn't allows for legacy Openssl providers), while evaded the simple and fair solution: move it back to the default provider's.

IMHO both you (OTC) if working at my premises in related development now all of you should be fired.

OK, that's enough. This is inappropriate behavior and not a constructive discussion at all since you are not able to accept for discussion any other views and continue without a code of conduct [1] violation. People will not engage in this discussion if you act like this. Please, consider taking a break.

*[1] - https://www.openssl.org/community/conduct.html

[dangell7]

The policy came AFTER your mistake...

Like I said the "bug fixes only to stable releases" policy has long been our working practice. The most recent version of that policy is an attempt to more fully define what we mean by that - but it has long been the case. You can see earlier versions of some of this here

https://www.openssl.org/policies/releasestrat.html

Which says (for the old versioning scheme):

"Letter releases, such as 1.0.2a, exclusively contain bug and security fixes and no new features."

That makes NO mention of "algorithms"....

You didn't do a security audit. If you did you would have removed SHA1...

You made this decision on your own, internally, then when called out for it, you updated your policy to give you this "excuse".

Then you proceeded to marginalize anyone using it acting like we don't exist.

I don't buy this "mistake" after "mistake" after "mistake". You were told to remove it and you did.

Thank you for showing us who you are.

[sebastianas]

We have 3.0 now in Debian unstable/testing and it will be part of the upcomming stable release. This means every piece of software that requries RIPEMD160 for normal operation needs to act by extending its code and ensuring that the legacy provider is loaded so that RIPEMD160 can be used.

No, it doesn't. If you have a lot of this software, you can load the legacy provider via system config. If you have a single program, you can craft a special openssl config for this application.

Yes, I am aware of this. However: Very little software makes use of a section within the config file, most software goes with the default setting. Should individual software alter the openssl.cnf then the only way to make this work is by having something like

.include /etc/ssl/openssl.cnf.d/*.cnf

in the main openssl.cnf in order to include snippets of individual software.
Therefore I don't think that this will happen since adding what is considered a workaround is way easier within the program code.

[levitte]

OMC has published a blog post on this issue here: https://www.openssl.org/blog/blog/2022/10/18/rmd160-and-the-legacy-provider/