Description of problem: Libcryptsetup should not allow selecting specific cipher implementation when using 'capi' cipher format. For example aes-generic is SW implementation of AES cipher in kernel that does not use HW acceleration specific to available CPU. Selecting specific cipher implementation should always be delegated to kernel crypto layer. This may allow loading cipher implementations that are susceptible to side-channel attacks on volume keys. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. cryptsetup luksFormat -c 'capi:xts(ecb(aes-generic))-plain64' /dev/device 2. cryptsetup open /dev/device Actual results: It passes in both step 1) and step 2) Expected results: Neither luksFormat or subsequent open commands shall pass. It also applies on LUKS2 headers previously formated/changed to use aes-generic implementation in kernel. Additional info: aes-generic driver is AES software implementation using lookup tables, susceptible to side-channel attacks.
cryptsetup-2.6.0-2.el9.x86_64 [root@dell-per730-43 ~]# cryptsetup luksFormat -c 'capi:xts(ecb(aes-generic))-plain64' t.tar -q Enter passphrase for t.tar: [root@dell-per730-43 ~]# $? -bash: 0: command not found [root@dell-per730-43 ~]# cryptsetup-2.6.0-3.el9.x86_64 [root@storageqe-100 ~]# cryptsetup luksFormat -c 'capi:xts(ecb(aes-generic))-plain64' t.tar No known cipher specification pattern detected. [root@storageqe-100 ~]# $? -bash: 1: command not found [root@storageqe-100 ~]# so the fixed package have passed.