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]

Message-ID: <4101B942-6327-49A9-BE8B-9E51F0427F50@intel.com>
Date:   Wed, 5 Jan 2022 21:55:17 +0000
From:   "Bae, Chang Seok" <chang.seok.bae@...el.com>
To:     Eric Biggers <ebiggers@...nel.org>,
        "dm-devel@...hat.com" <dm-devel@...hat.com>
CC:     Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...e.de>,
        "Dave Hansen" <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...nel.org>,
        "Lutomirski, Andy" <luto@...nel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Gairuboyina, Charishma1" <charishma1.gairuboyina@...el.com>,
        "Dwarakanath, Kumar N" <kumar.n.dwarakanath@...el.com>,
        "Krishnakumar, Lalithambika" <lalithambika.krishnakumar@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>
Subject: Re: [PATCH v4 00/13] x86: Support Key Locker

On Dec 15, 2021, at 17:09, Eric Biggers <ebiggers@...nel.org> wrote:
> On Mon, Dec 13, 2021 at 04:51:59PM -0800, Chang S. Bae wrote:
>> == Disk Encryption Use Case ==
<snip>
>>   $ cryptsetup luksFormat --cipher="capi:xts-aes-aeskl-plain" <device>
> 
> plain64 is supposed to be used these days, not plain.

I see.

>> == 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.

Oh, I should have included them. I was not aware of this mailing address.

Hi DM-crypt folks,

Here is the patch series:
    https://lore.kernel.org/lkml/20211214005212.20588-1-chang.seok.bae@intel.com/t/

I would appreciate if you give any feedback on this feature’s use case with yours.

>> +-----------+---------------+---------------+
>> | 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.

Analyzing and understanding this with specific hardware implementation takes
time for us. Will come back and update you when we have anything to share here.

> Also, is the AES-CBC support really useful, given that for disk encryption,
> AES-XTS is recommended over AES-CBC these days?

Yes, we understand that AES-XTS is the primary option for disk encryption.

But it seems that AES-CBC had been used for disk encryption, [1]:

    Comparing XTS to CBC for hard disk encryption
        If a storage device vendor is seeking FIPS 140-2 certification today,
        they will typically use CBC encryption, or even ECB. CBC is a good
        mode, ...

As long as it is factual that the mode was once popular, it can help somebody
who wants to use Key Locker for an old disk image I think.

Thanks,
Chang

[1] https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-Techniques/documents/BCM/Comments/XTS/XTS_comments-Ball.pdf