On Mon, Dec 13, 2021 at 04:51:59PM -0800, Chang S. Bae wrote: > == Disk Encryption Use Case == > > Disk encryption uses Key Locker to mitigate key exfiltration as follows: > > 1. Configuration for Key Locker: AES-KL shows up in /proc/crypto as a > distinct cipher option. From there, tools like cryptsetup [5] can select > AES-KL vs AES-NI. For example, > > $ cryptsetup luksFormat --cipher="capi:xts-aes-aeskl-plain" <device> plain64 is supposed to be used these days, not plain. > Note: AES-KL has a performance tradeoff. See details in 'Performance' > below. > > 2. Disk encryption flow with key protection: > > * The cryptsetup utility is responsible for loading the volume key into the > kernel's keyring and passing a reference of the key. Once dm-crypt [6] > has set up the volume, user space is responsible for invalidating the key > material so that only the key handle remains in memory. Cryptsetup does > this, e.g. via crypt_free_volume_key() and crypt_safe_free(). > > * The AES-KL code in the kernel's crypto library uses the key handle > instead of the actual clear text key. > > == Non Use Cases == > > Bare metal disk encryption is the only use case intended by these patches. Since dm-crypt is the use case for these patches, you probably should CC this patchset to dm-devel@xxxxxxxxxx so that the dm-crypt developers are aware of it. > +-----------+---------------+---------------+ > | Cipher | Encryption | Decryption | > | (AES-KL) | (MiB/s) | (MiB/s) | > +-----------+---------------+---------------+ > | AES-CBC | 505.3 | 2097.8 | > | AES-XTS | 1130 | 696.4 | > +-----------+-------------------------------+ Why is AES-XTS decryption so much slower than AES-XTS encryption? They should be about the same. Also, is the AES-CBC support really useful, given that for disk encryption, AES-XTS is recommended over AES-CBC these days? - Eric
