linux-kernel - Re: [PATCH v4 00/13] x86: Support Key Locker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 15 Dec 2021 17:09:05 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     "Chang S. Bae" <chang.seok.bae@...el.com>
Cc:     tglx@...utronix.de, bp@...e.de, dave.hansen@...ux.intel.com,
        mingo@...nel.org, luto@...nel.org, x86@...nel.org,
        herbert@...dor.apana.org.au, linux-kernel@...r.kernel.org,
        linux-crypto@...r.kernel.org, dan.j.williams@...el.com,
        charishma1.gairuboyina@...el.com, kumar.n.dwarakanath@...el.com,
        lalithambika.krishnakumar@...el.com, ravi.v.shankar@...el.com
Subject: Re: [PATCH v4 00/13] x86: Support Key Locker

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@...hat.com 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