Bug 1975836

Summary:	add ripemd160 hash back? (how to enable legacy provider)
Product:	Red Hat Enterprise Linux 9	Reporter:	Yatin Karel <ykarel>
Component:	openssl	Assignee:	Sahana Prasad <sahana>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Alicja Kario <hkario>
Severity:	low	Docs Contact:	Mirek Jahoda <mjahoda>
Priority:	low
Version:	9.0	CC:	agk, apevec, bstinson, dbelyavs, eharney, geguileo, hkario, jbrassow, jwboyer, ltoscano, okozina, prajnoha, rdhasman, sahana, storage-qe, szidek
Target Milestone:	beta	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openssl-3.0.0-0.beta2.5.el9	Doc Type:	Deprecated Functionality
Doc Text:	.OpenSSL deprecates MD2, MD4, MDC2, Whirlpool, Blowfish, CAST, DES, IDEA, RC2, RC4, RC5, SEED, and PBKDF1 The OpenSSL project has deprecated a set of cryptographic algorithms because they are insecure, uncommonly used, or both. Red Hat also discourages the use of those algorithms, and RHEL 9 provides them for migrating encrypted data to use new algorithms. Users must not depend on those algorithms for the security of their systems. The implementations of the following algorithms have been moved to the legacy provider in OpenSSL: MD2, MD4, MDC2, Whirlpool, Blowfish, CAST, DES, IDEA, RC2, RC4, RC5, SEED, and PBKDF1. See the `/etc/pki/tls/openssl.cnf` configuration file for instructions on how to load the legacy provider and enable support for the deprecated algorithms.	Story Points:	---
Clone Of:	1975799	Environment:
Last Closed:	2021-12-07 21:24:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1975799

Description Yatin Karel 2021-06-24 14:26:03 UTC

+++ This bug was initially created as a clone of Bug #1975799 +++

Description of problem:

cryptsetup no longer works with default hash ripemd160 after moving to openssl3.

Version-Release number of selected component (if applicable):
cryptsetup-2.3.6-2.el9.x86_64
openssl-3.0.0-0.alpha16.4.el9.x86_64

How reproducible:
Always with openssl-3.0.0, with openssl-1.1 works fine.

Steps to Reproduce:

Detected while testing CentOS Stream 9 latest composes with RDO, cryptsetup create fails there, to simulate able to reproduce with below steps:-

# dev=`losetup -f`
# dd if=/dev/urandom of=/home/secret_dir bs=1M count=10
# losetup $dev /home/secret_dir
# cryptsetup open $dev test-device --type plain -c aes-xts-plain64 
Enter passphrase for /home/secret_dir: 
Hash algorithm ripemd160 not supported.

with other hash algo like sha256, sha512(-h sha256 or -h sha512) etc it worked fine. /me not sure on what's recommended one.

Actual results:
cryptsetup open --type plain with default hash(ripemd160) not working with openssl-3 

Expected results:
cryptsetup defaults should work with openssl-3.

Additional info:

Works fine with cryptsetup-2.3.6-1.el9.
# ldd /usr/sbin/cryptsetup|grep ssl
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f750cbfc000)

Fails in cryptsetup-2.3.6-2.el9.
# ldd /usr/sbin/cryptsetup|grep ssl                                                                                
libssl.so.3 => /lib64/libssl.so.3 (0x00007f71cd197000)


So defaults needs to be fixed so it works with openssl3 unless and until openssl3 re adds support for ripemd160.

--- Additional comment from Milan Broz on 2021-06-24 13:30:06 UTC ---

OpenSSL backend need to load non-default provider here (that allows ripemn160)
We cannot easily change default hash for plain password hasing here. (For LUKS we changed default years ago.)
Also, it must be available for compatibility reasons (to unlock older encrypted disks).

And what is completely broken is that OpenSSL3  is not yet in Fedora...

Anyway, just use --hash sha256 (ditto in crypttab), if you need to use plain mode.
LUKS is recommened anyway. Why are you using plain mode?

--- Additional comment from Yatin Karel on 2021-06-24 14:10:26 UTC ---

Thanks Milan for quick response, adding some storage(cinder) folks as they have more context on usage of plain and how to handle it in os-brick/cinder side. Seems it also needs to be reached out to openssl for readding ripemn160 as per your concerns.

Comment 1 Alan Pevec 2021-06-24 17:09:25 UTC

quote from original bug 1975799

> Openssl perhaps will not add RIPEMD hash bbck to suported algorithms, there is a reason for removing it from defaults.

Please confirm that ripemd160 will not be added back so we can discuss in OpenStack removal of plain mode crytsetup!

Comment 2 Alicja Kario 2021-06-25 12:47:52 UTC

The situation is a bit more complex. We are shipping an implementation of ripemd160, but it's in the legacy provider: https://github.com/openssl/openssl/blob/master/doc/man7/OSSL_PROVIDER-legacy.pod
The user needs to provide an openssl config file that loads the legacy provider for the ripemd160 to be available to applications.

So I think cryptsetup doesn't need to remove plain mode, but it should move it to "unsupported", with documentation stating how to migrate off of it (if changing the default hash is not possible).

Comment 3 Milan Broz 2021-06-25 13:11:40 UTC

Removing plain mode in cryptsetup was not even a question, it must remain there. It was about removing plain mode use in OpenStack.
Also cryptsetup will not move anything to unsupported, it will simply load legacy provider here. Actually I already tested that and there are some minor issues, but it is easily doable.

Cryptsetup plain mode is a simple wrapper around dm-crypt, it must support even old modes (ripemd hashing is here just because of historical and backward compatibility reasons - and here we perhaps switch default, despite it will cause breakage; but older configs must remain supported otherwise we will not be able to decrtypt older data for many people).

Nobody should use cryptsetup plain mode until there is very specific use case (like simulating some other priprietary system) - EVERYTHING related to storage should use LUKS.
The main reason is that we should no use encryption key that is directly derived from passphrase (as it is in plain mode if a passphrase is used; randomly generated keyfile behaves differently here).

TL;DR: I think OpenSSL does not need to do anything here, we should fix OpenSSL backend init in cryptsetup for OpenSSL3 to allow legacy provider use (even without openssl config file).

Comment 13 Alicja Kario 2021-08-06 15:40:04 UTC

*** Bug 1990877 has been marked as a duplicate of this bug. ***