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

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

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

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.

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.

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.

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

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

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

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…

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.

It’s hard OTC has to ask to adhere the conduct code, I understand how angry are developers posting here, yes they should adhere the conduct code here and everywhere, but OTC should admit they triggered this situation and shamefully and bigotry avoid assume his part, quite disappointed, BTW the actual community remedy is to move away from openssl and start sponsoring an alternative headed by actual programmers not by ‘academic’ people following guidelines unsafe for software cycles.

Yes, we need to move away from openssl as its clear they have no idea what they are doing.

They have prioritized an algorithm with collision over one that has no collision because “its used for other things”.

Not only this but they are refusing to acknowledge their mistake and fix it.

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.

It’s hard OTC has to ask to adhere the conduct code, I understand how angry are developers posting here, yes they should adhere the conduct code here and everywhere, but OTC should admit they triggered this situation and shamefully and bigotry avoid assume his part, quite disappointed, BTW the actual community remedy is to move away from openssl and start sponsoring an alternative headed by actual programmers not by ‘academic’ people following guidelines unsafe for software cycles.

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.