From: Milan Broz <gmazyland@gmail.com>
To: Eric Biggers <ebiggers@kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-crypto@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
dm-devel@redhat.com, linux-fscrypt@vger.kernel.org,
Gilad Ben-Yossef <gilad@benyossef.com>,
Milan Broz <gmazyland@gmail.com>
Subject: Re: [PATCH v3 6/6] crypto: arm64/aes - implement accelerated ESSIV/CBC mode
Date: Thu, 20 Jun 2019 13:29:59 +0200 [thread overview]
Message-ID: <ed3113fb-8f5f-7045-75ba-b63e4ed669ff@gmail.com> (raw)
In-Reply-To: <20190619223710.GC33328@gmail.com>
On 20/06/2019 00:37, Eric Biggers wrote:
> On Wed, Jun 19, 2019 at 06:29:21PM +0200, Ard Biesheuvel wrote:
>> Add an accelerated version of the 'essiv(cbc(aes),aes,sha256)'
>> skcipher, which is used by fscrypt, and in some cases, by dm-crypt.
>> This avoids a separate call into the AES cipher for every invocation.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> I'm not sure we should bother with this, since fscrypt normally uses AES-256-XTS
> for contents encryption. AES-128-CBC-ESSIV support was only added because
> people wanted something that is fast on low-powered embedded devices with crypto
> accelerators such as CAAM or CESA that don't support XTS.
>
> In the case of Android, the CDD doesn't even allow AES-128-CBC-ESSIV with
> file-based encryption (fscrypt). It's still the default for "full disk
> encryption" (which uses dm-crypt), but that's being deprecated.
>
> So maybe dm-crypt users will want this, but I don't think it's very useful for
> fscrypt.
The aes-cbc-essiv:sha256 is still default for plain cryptsetup devices
(LUKS uses XTS for several years as a default already).
The reason is compatibility with older distros (if there is no cipher mode
specification in crypttab for plain device, switching default could cause data corruption).
But I think initscripts now enforce cipher and keysize crypttab options for some time,
so I can probably switch the default to XTS for plain devices soon.
(We have already compile time option for it anyway.)
IOW intention for dm-crypt is to slightly deprecate CBC mode use for all types of devices.
Milan
next prev parent reply other threads:[~2019-06-20 11:30 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 16:29 [PATCH v3 0/6] crypto: switch to crypto API for ESSIV generation Ard Biesheuvel
2019-06-19 16:29 ` [PATCH v3 1/6] crypto: essiv - create wrapper template " Ard Biesheuvel
2019-06-20 1:04 ` Eric Biggers
2019-06-20 1:13 ` Herbert Xu
2019-06-20 1:17 ` Herbert Xu
2019-06-20 7:30 ` Ard Biesheuvel
2019-06-20 12:52 ` Herbert Xu
2019-06-20 12:53 ` Herbert Xu
2019-06-20 13:02 ` Ard Biesheuvel
2019-06-20 13:35 ` Ard Biesheuvel
2019-06-20 13:40 ` Herbert Xu
2019-06-20 13:53 ` Ard Biesheuvel
2019-06-21 1:06 ` Herbert Xu
2019-06-21 5:39 ` Ard Biesheuvel
2019-06-21 6:44 ` Milan Broz
2019-06-20 18:27 ` Eric Biggers
2019-06-19 16:29 ` [PATCH v3 2/6] fs: crypto: invoke crypto API for ESSIV handling Ard Biesheuvel
2019-06-19 22:45 ` Eric Biggers
2019-06-19 16:29 ` [PATCH v3 3/6] md: dm-crypt: infer ESSIV block cipher from cipher string directly Ard Biesheuvel
2019-06-19 16:29 ` [PATCH v3 4/6] md: dm-crypt: switch to ESSIV crypto API template Ard Biesheuvel
2019-06-19 16:29 ` [PATCH v3 5/6] crypto: essiv - add test vector for essiv(cbc(aes),aes,sha256) Ard Biesheuvel
2019-06-19 16:29 ` [PATCH v3 6/6] crypto: arm64/aes - implement accelerated ESSIV/CBC mode Ard Biesheuvel
2019-06-19 22:37 ` Eric Biggers
2019-06-19 22:43 ` Ard Biesheuvel
2019-06-20 11:29 ` Milan Broz [this message]
2019-06-26 4:32 ` Eric Biggers
2019-06-20 7:07 ` [PATCH v3 0/6] crypto: switch to crypto API for ESSIV generation Gilad Ben-Yossef
2019-06-20 11:22 ` Milan Broz
2019-06-20 11:54 ` Ard Biesheuvel
2019-06-20 12:09 ` Milan Broz
2019-06-20 13:14 ` Milan Broz
2019-06-20 13:52 ` Ard Biesheuvel
2019-06-21 7:01 ` Milan Broz
2019-06-21 7:06 ` Ard Biesheuvel
2019-06-21 7:37 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ed3113fb-8f5f-7045-75ba-b63e4ed669ff@gmail.com \
--to=gmazyland@gmail.com \
--cc=ard.biesheuvel@linaro.org \
--cc=dm-devel@redhat.com \
--cc=ebiggers@kernel.org \
--cc=gilad@benyossef.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).