RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1975836 - add ripemd160 hash back? (how to enable legacy provider)
Summary: add ripemd160 hash back? (how to enable legacy provider)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: openssl
Version: 9.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: beta
: ---
Assignee: Sahana Prasad
QA Contact: Hubert Kario
Mirek Jahoda
URL:
Whiteboard:
: 1990877 (view as bug list)
Depends On:
Blocks: 1975799
TreeView+ depends on / blocked
 
Reported: 2021-06-24 14:26 UTC by Yatin Karel
Modified: 2023-04-24 10:31 UTC (History)
16 users (show)

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.
Clone Of: 1975799
Environment:
Last Closed: 2021-12-07 21:24:13 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker CRYPTO-5653 0 None None None 2021-12-02 14:41:50 UTC

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 Hubert 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 Hubert Kario 2021-08-06 15:40:04 UTC 
*** Bug 1990877 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.