All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Milan Broz <gmazyland@gmail.com>
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: Fri, 16 Nov 2018 13:52:50 -0800	[thread overview]
Message-ID: <20181116215249.GA27149@gmail.com> (raw)
In-Reply-To: <1f65ce09-93b3-f43e-49d5-9d9d6c0bb9e0@gmail.com>

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

The problem seems to be that when cryptsetup tries to encrypt the keyslot in
luks2_encrypt_to_storage(), it tries to use the algorithm via AF_ALG, but it
incorrectly requests "plain64(capi:adiantum(xchacha12,aes))" which fails.
It should request just "adiantum(xchacha12,aes)".

What are the "easy tricks" you had in mind -- do you mean there's already a way
to use Adiantum with cryptsetup, or do you mean that cryptsetup still needs to
be updated to fully support algorithms using the crypto API syntax?

Thanks,

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiggers@kernel.org (Eric Biggers)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 00/12] crypto: Adiantum support
Date: Fri, 16 Nov 2018 13:52:50 -0800	[thread overview]
Message-ID: <20181116215249.GA27149@gmail.com> (raw)
In-Reply-To: <1f65ce09-93b3-f43e-49d5-9d9d6c0bb9e0@gmail.com>

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

The problem seems to be that when cryptsetup tries to encrypt the keyslot in
luks2_encrypt_to_storage(), it tries to use the algorithm via AF_ALG, but it
incorrectly requests "plain64(capi:adiantum(xchacha12,aes))" which fails.
It should request just "adiantum(xchacha12,aes)".

What are the "easy tricks" you had in mind -- do you mean there's already a way
to use Adiantum with cryptsetup, or do you mean that cryptsetup still needs to
be updated to fully support algorithms using the crypto API syntax?

Thanks,

- Eric

  parent reply	other threads:[~2018-11-17  8:07 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 [this message]
2018-11-16 21:52         ` Eric Biggers
2018-11-17 10:29         ` Milan Broz
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=20181116215249.GA27149@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=gkaiser@google.com \
    --cc=gmazyland@gmail.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.