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?

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.

FTR cryptsetup in OpenStack is in os-brick project: https://github.com/openstack/os-brick/blob/4baa502ec8c6c62184c474f126c0ad07eb3409f1/os_brick/encryptors/cryptsetup.py#L106-L129
used by both Cinder and Nova.

Adding Lee since he also worked on that code, for the Nova perspective.

(In reply to Alan Pevec from comment #3)
> FTR cryptsetup in OpenStack is in os-brick project:
> https://github.com/openstack/os-brick/blob/
> 4baa502ec8c6c62184c474f126c0ad07eb3409f1/os_brick/encryptors/cryptsetup.
> py#L106-L129
> used by both Cinder and Nova.
> 
> Adding Lee since he also worked on that code, for the Nova perspective.

LUKS is not affected in any way. It's only plain mode.

I hope we can fix this upstream (in cryptsetup openssl backed wrapper, I will try it) but also I think it is time to completely deprecate RIPEMD160, even it means incompatibilities...

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

(In reply to Alan Pevec from comment #3)
Plain mode is not supported for encrypted Cinder volumes in OSP, only LUKS is.  This is documented in section 2.2.6.1 here re: "Provider":

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html-single/storage_guide/index#section-volumes_advanced_encryption

The recommendation upstream would also be to use LUKS instead of plain mode, but plain is technically still available for now.

There is a relatively easy patch for cryptsetup that enables legacy provider support if used with OpenSSL3. 
(It is not only RIPEMD160 hash, we need support for older block ciphers for other disk encryption formats backward compatibility.)

Unfortunately it crashes in deallocatuion inside OpenSSL, I need to ask OpenSSL developers what's the problem there,
seems like we are the first real users of this API... :-)

Legacy providers were enabled in upstream with: https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/178

Hi,

Hit the bug with cryptsetup-2.3.6-2.el9.x86_64

[root@storageqe-66 ~]# sh 1.sh 
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0665328 s, 158 MB/s
Hash algorithm ripemd160 not supported.
NAME                        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0                         7:0    0    10M  0 loop 
sda                           8:0    0 558.9G  0 disk 
├─sda1                        8:1    0     1G  0 part /boot
└─sda2                        8:2    0 557.9G  0 part 
  ├─rhel_storageqe--66-root 253:0    0    70G  0 lvm  /
  ├─rhel_storageqe--66-swap 253:1    0  15.6G  0 lvm  [SWAP]
  └─rhel_storageqe--66-home 253:2    0 472.3G  0 lvm  /home
sdb                           8:16   1     0B  0 disk 
[root@storageqe-66 ~]# rpm -qa | grep cryptsetup
cryptsetup-libs-2.3.6-2.el9.x86_64
cryptsetup-2.3.6-2.el9.x86_64
[root@storageqe-66 ~]# rpm -qa | grep openssl
openssl-pkcs11-0.4.11-6.el9.x86_64
openssl-libs-3.0.0-0.beta1.4.el9.x86_64
compat-openssl11-1.1.1k-1.el9.x86_64
openssl-3.0.0-0.beta1.4.el9.x86_64
[root@storageqe-66 ~]# cat 1.sh
dev=`losetup -f`
dd if=/dev/urandom of=/home/secret_dir bs=1M count=10
losetup $dev /home/secret_dir
echo 'redhat redhat'|cryptsetup open $dev test-device --type plain -c aes-xts-plain64 
lsblk

Hi

Test pass with cryptsetup-2.4.0-1.el9.

No regression found, move to verified.