From: Milan Broz <gmazyland@gmail.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
linux-fscrypt@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
LKML <linux-kernel@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Paul Crowley <paulcrowley@google.com>,
Greg Kaiser <gkaiser@google.com>,
Michael Halcrow <mhalcrow@google.com>,
Samuel Neves <samuel.c.p.neves@gmail.com>,
Tomer Ashur <tomer.ashur@esat.kuleuven.be>
Subject: Re: [RFC PATCH v2 00/12] crypto: Adiantum support
Date: Sat, 17 Nov 2018 11:29:23 +0100 [thread overview]
Message-ID: <56883f08-26cb-ecef-5698-1c2948714773@gmail.com> (raw)
In-Reply-To: <20181116215249.GA27149@gmail.com>
On 16/11/2018 22:52, Eric Biggers wrote:
> Hi Milan,
>
> On Sat, Oct 20, 2018 at 12:26:20PM +0200, Milan Broz wrote:
>>
>> Adiantum (as in your current git branches on kernel.org) can be used for dm-crypt
>> without any changes (yes, I played with it :) and with some easy tricks directly
>> through cryptsetup/LUKS as well.
>>
>> I think we should have this as an alternative to length-preserving wide-block
>> cipher modes for FDE.
>>
>
> Yes, dm-crypt can use Adiantum by specifying the cipher as
> "capi:adiantum(xchacha12,aes)-plain64".
>
> But, I'm having trouble getting cryptsetup/LUKS to use Adiantum.
> Using LUKS1, the following works:
>
> cryptsetup luksFormat /dev/$partition --cipher='capi:adiantum(xchacha12,aes)-plain64' --key-size 256
>
> However, when possible we'd like people to use 4K sectors for better
> performance, which I understand requires using the LUKS2 format along with
> cryptsetup v2.0.0+ and Linux v4.12+. But the following does *not* work:
>
> cryptsetup luksFormat /dev/$partition --cipher='capi:adiantum(xchacha12,aes)-plain64' --key-size 256 --type luks2 --sector-size 4096
Hi Eric,
actually I planned to test it and then reply to these patches with example cryptsetup
commands, but did not have time for it yet.
So thanks for a reminder ;-)
Recent cryptsetup supports sector-size even for plain device.
You actually do not need to use capi: prefix, Adiantum is a composition,
so "xchacha20,aes-adiantum-plain64" works as well (and it should work even for old cryptsetup).
(It is ugly, but it should be compatible.)
# cryptsetup open --type plain -c xchacha20,aes-adiantum-plain64 -s 256 --sector-size 4096 /dev/sdb test
For LUKS and benchmark, Adiantum need to use 32 bytes IV. And we have these parameter,
unfortunately, hardcoded...
(I guess there is already a way how to get this dynamically from userspace crypto API now.)
So, I already added patch to devel branch patch for benchmark to support Adiantum few days ago
https://gitlab.com/cryptsetup/cryptsetup/commit/bce567db461e558af7d735c694a50146db899709
This allows trivial benchmark (but it just encrypts one big blob of data):
# cryptsetup benchmark -c xchacha20,aes-adiantum -s 256
# Tests are approximate using memory only (no storage IO).
# Algorithm | Key | Encryption | Decryption
xchacha20,aes-adiantum 256b 146.6 MiB/s 148.0 MiB/s
...
# ./cryptsetup benchmark -c xchacha12,aes-adiantum -s 256
xchacha12,aes-adiantum 256b 181.7 MiB/s 184.6 MiB/s
For LUKS2, we need a similar change to cryptoAPI IV size (unfortunately it does not
fallback to old keyslot handling, so LUKS2 does not work currently now).
I quickly added a workaround that fallbacks to default keyslot encryption for keyslots
in this case
https://gitlab.com/cryptsetup/cryptsetup/commit/29e87add5aac9d5eb0087881146988d9c4280915
then you can use LUKS2
# cryptsetup luksFormat --type luks2 --sector-size 4096 -c xchacha20,aes-adiantum-plain64 -s 256 /dev/sdb
(Example above will encrypt keyslots with AES-XTS and use Aviantum for data only.)
So, unfortunately yes, we need some small changes in cryptsetup for LUKS;
plain mode should work out of the box (with the syntax above).
Milan
WARNING: multiple messages have this Message-ID (diff)
From: gmazyland@gmail.com (Milan Broz)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 00/12] crypto: Adiantum support
Date: Sat, 17 Nov 2018 11:29:23 +0100 [thread overview]
Message-ID: <56883f08-26cb-ecef-5698-1c2948714773@gmail.com> (raw)
In-Reply-To: <20181116215249.GA27149@gmail.com>
On 16/11/2018 22:52, Eric Biggers wrote:
> Hi Milan,
>
> On Sat, Oct 20, 2018 at 12:26:20PM +0200, Milan Broz wrote:
>>
>> Adiantum (as in your current git branches on kernel.org) can be used for dm-crypt
>> without any changes (yes, I played with it :) and with some easy tricks directly
>> through cryptsetup/LUKS as well.
>>
>> I think we should have this as an alternative to length-preserving wide-block
>> cipher modes for FDE.
>>
>
> Yes, dm-crypt can use Adiantum by specifying the cipher as
> "capi:adiantum(xchacha12,aes)-plain64".
>
> But, I'm having trouble getting cryptsetup/LUKS to use Adiantum.
> Using LUKS1, the following works:
>
> cryptsetup luksFormat /dev/$partition --cipher='capi:adiantum(xchacha12,aes)-plain64' --key-size 256
>
> However, when possible we'd like people to use 4K sectors for better
> performance, which I understand requires using the LUKS2 format along with
> cryptsetup v2.0.0+ and Linux v4.12+. But the following does *not* work:
>
> cryptsetup luksFormat /dev/$partition --cipher='capi:adiantum(xchacha12,aes)-plain64' --key-size 256 --type luks2 --sector-size 4096
Hi Eric,
actually I planned to test it and then reply to these patches with example cryptsetup
commands, but did not have time for it yet.
So thanks for a reminder ;-)
Recent cryptsetup supports sector-size even for plain device.
You actually do not need to use capi: prefix, Adiantum is a composition,
so "xchacha20,aes-adiantum-plain64" works as well (and it should work even for old cryptsetup).
(It is ugly, but it should be compatible.)
# cryptsetup open --type plain -c xchacha20,aes-adiantum-plain64 -s 256 --sector-size 4096 /dev/sdb test
For LUKS and benchmark, Adiantum need to use 32 bytes IV. And we have these parameter,
unfortunately, hardcoded...
(I guess there is already a way how to get this dynamically from userspace crypto API now.)
So, I already added patch to devel branch patch for benchmark to support Adiantum few days ago
https://gitlab.com/cryptsetup/cryptsetup/commit/bce567db461e558af7d735c694a50146db899709
This allows trivial benchmark (but it just encrypts one big blob of data):
# cryptsetup benchmark -c xchacha20,aes-adiantum -s 256
# Tests are approximate using memory only (no storage IO).
# Algorithm | Key | Encryption | Decryption
xchacha20,aes-adiantum 256b 146.6 MiB/s 148.0 MiB/s
...
# ./cryptsetup benchmark -c xchacha12,aes-adiantum -s 256
xchacha12,aes-adiantum 256b 181.7 MiB/s 184.6 MiB/s
For LUKS2, we need a similar change to cryptoAPI IV size (unfortunately it does not
fallback to old keyslot handling, so LUKS2 does not work currently now).
I quickly added a workaround that fallbacks to default keyslot encryption for keyslots
in this case
https://gitlab.com/cryptsetup/cryptsetup/commit/29e87add5aac9d5eb0087881146988d9c4280915
then you can use LUKS2
# cryptsetup luksFormat --type luks2 --sector-size 4096 -c xchacha20,aes-adiantum-plain64 -s 256 /dev/sdb
(Example above will encrypt keyslots with AES-XTS and use Aviantum for data only.)
So, unfortunately yes, we need some small changes in cryptsetup for LUKS;
plain mode should work out of the box (with the syntax above).
Milan
next prev parent reply other threads:[~2018-11-17 20:45 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-15 17:54 [RFC PATCH v2 00/12] crypto: Adiantum support Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-15 17:54 ` [RFC PATCH v2 01/12] crypto: chacha20-generic - add HChaCha20 library function Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-19 14:13 ` Ard Biesheuvel
2018-10-19 14:13 ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 02/12] crypto: chacha20-generic - add XChaCha20 support Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-19 14:24 ` Ard Biesheuvel
2018-10-19 14:24 ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 03/12] crypto: chacha20-generic - refactor to allow varying number of rounds Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-19 14:25 ` Ard Biesheuvel
2018-10-19 14:25 ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 04/12] crypto: chacha - add XChaCha12 support Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-19 14:34 ` Ard Biesheuvel
2018-10-19 14:34 ` Ard Biesheuvel
2018-10-19 18:28 ` Eric Biggers
2018-10-19 18:28 ` Eric Biggers
2018-10-15 17:54 ` [RFC PATCH v2 05/12] crypto: arm/chacha20 - add XChaCha20 support Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-20 2:29 ` Ard Biesheuvel
2018-10-20 2:29 ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 06/12] crypto: arm/chacha20 - refactor to allow varying number of rounds Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-20 3:35 ` Ard Biesheuvel
2018-10-20 3:35 ` Ard Biesheuvel
2018-10-20 5:26 ` Eric Biggers
2018-10-20 5:26 ` Eric Biggers
2018-10-15 17:54 ` [RFC PATCH v2 07/12] crypto: arm/chacha - add XChaCha12 support Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-20 3:36 ` Ard Biesheuvel
2018-10-20 3:36 ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 08/12] crypto: poly1305 - add Poly1305 core API Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-20 3:45 ` Ard Biesheuvel
2018-10-20 3:45 ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 09/12] crypto: nhpoly1305 - add NHPoly1305 support Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-20 4:00 ` Ard Biesheuvel
2018-10-20 4:00 ` Ard Biesheuvel
2018-10-20 5:38 ` Eric Biggers
2018-10-20 5:38 ` Eric Biggers
2018-10-20 15:06 ` Ard Biesheuvel
2018-10-20 15:06 ` Ard Biesheuvel
2018-10-22 18:42 ` Eric Biggers
2018-10-22 18:42 ` Eric Biggers
2018-10-22 22:25 ` Ard Biesheuvel
2018-10-22 22:25 ` Ard Biesheuvel
2018-10-22 22:40 ` Eric Biggers
2018-10-22 22:40 ` Eric Biggers
2018-10-22 22:43 ` Ard Biesheuvel
2018-10-22 22:43 ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 10/12] crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305 Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-20 4:12 ` Ard Biesheuvel
2018-10-20 4:12 ` Ard Biesheuvel
2018-10-20 5:51 ` Eric Biggers
2018-10-20 5:51 ` Eric Biggers
2018-10-20 15:00 ` Ard Biesheuvel
2018-10-20 15:00 ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 11/12] crypto: adiantum - add Adiantum support Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-20 4:17 ` Ard Biesheuvel
2018-10-20 4:17 ` Ard Biesheuvel
2018-10-20 7:12 ` Eric Biggers
2018-10-20 7:12 ` Eric Biggers
2018-10-23 10:40 ` Ard Biesheuvel
2018-10-23 10:40 ` Ard Biesheuvel
2018-10-24 22:06 ` Eric Biggers
2018-10-24 22:06 ` Eric Biggers
2018-10-30 8:17 ` Herbert Xu
2018-10-30 8:17 ` Herbert Xu
2018-10-15 17:54 ` [RFC PATCH v2 12/12] fscrypt: " Eric Biggers
2018-10-15 17:54 ` Eric Biggers
2018-10-19 15:58 ` [RFC PATCH v2 00/12] crypto: " Jason A. Donenfeld
2018-10-19 15:58 ` Jason A. Donenfeld
2018-10-19 18:19 ` Paul Crowley
2018-10-19 18:19 ` Paul Crowley
2018-10-20 3:24 ` Ard Biesheuvel
2018-10-20 3:24 ` Ard Biesheuvel
2018-10-20 5:22 ` Eric Biggers
2018-10-20 5:22 ` Eric Biggers
2018-10-22 10:19 ` Tomer Ashur
2018-10-22 11:20 ` Tomer Ashur
2018-10-22 11:20 ` Tomer Ashur
2018-10-19 19:04 ` Eric Biggers
2018-10-19 19:04 ` Eric Biggers
2018-10-20 10:26 ` Milan Broz
2018-10-20 10:26 ` Milan Broz
2018-10-20 13:47 ` Jason A. Donenfeld
2018-10-20 13:47 ` Jason A. Donenfeld
2018-11-16 21:52 ` Eric Biggers
2018-11-16 21:52 ` Eric Biggers
2018-11-17 10:29 ` Milan Broz [this message]
2018-11-17 10:29 ` Milan Broz
2018-11-19 19:28 ` Eric Biggers
2018-11-19 19:28 ` Eric Biggers
2018-11-19 20:05 ` Milan Broz
2018-11-19 20:05 ` Milan Broz
2018-11-19 20:30 ` Jason A. Donenfeld
2018-11-19 20:30 ` Jason A. Donenfeld
2018-10-21 22:23 ` Eric Biggers
2018-10-21 22:23 ` Eric Biggers
2018-10-21 22:51 ` Jason A. Donenfeld
2018-10-21 22:51 ` Jason A. Donenfeld
2018-10-22 17:17 ` Paul Crowley
2018-10-22 17:17 ` Paul Crowley
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=56883f08-26cb-ecef-5698-1c2948714773@gmail.com \
--to=gmazyland@gmail.com \
--cc=Jason@zx2c4.com \
--cc=ebiggers@kernel.org \
--cc=gkaiser@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhalcrow@google.com \
--cc=paulcrowley@google.com \
--cc=samuel.c.p.neves@gmail.com \
--cc=tomer.ashur@esat.kuleuven.be \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.