From: Milan Broz <gmazyland@gmail.com> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>, linux-crypto@vger.kernel.org Cc: Herbert Xu <herbert@gondor.apana.org.au>, Eric Biggers <ebiggers@google.com>, device-mapper development <dm-devel@redhat.com>, Mike Snitzer <msnitzer@redhat.com> Subject: Re: [RFC PATCH 0/3] crypto: switch to shash for ESSIV generation Date: Sat, 15 Jun 2019 20:19:22 +0200 [thread overview] Message-ID: <9cd635ec-970b-bd1b-59f4-1a07395e69a0@gmail.com> (raw) In-Reply-To: <20190614083404.20514-1-ard.biesheuvel@linaro.org> On 14/06/2019 10:34, Ard Biesheuvel wrote: > This series is presented as an RFC for a couple of reasons: > - it is only build tested > - it is unclear whether this is the right way to move away from the use of > bare ciphers in non-crypto code > - we haven't really discussed whether moving away from the use of bare ciphers > in non-crypto code is a goal we agree on > > This series creates an ESSIV shash template that takes a (cipher,hash) tuple, > where the digest size of the hash must be a valid key length for the cipher. > The setkey() operation takes the hash of the input key, and sets into the > cipher as the encryption key. Digest operations accept input up to the > block size of the cipher, and perform a single block encryption operation to > produce the ESSIV output. > > This matches what both users of ESSIV in the kernel do, and so it is proposed > as a replacement for those, in patches #2 and #3. > > As for the discussion: the code is untested, so it is presented for discussion > only. I'd like to understand whether we agree that phasing out the bare cipher > interface from non-crypto code is a good idea, and whether this approach is > suitable for fscrypt and dm-crypt. If you want some discussion, it would be very helpful if you cc device-mapper list to reach dm-crypt developers. Please add at least dm-devel list. Just a few comments: - ESSIV is useful only for CBC mode. I wish we move to some better mode in the future instead of cementing CBC use... But if it helps people to actually use unpredictable IV for CBC, it is the right approach. (yes, I know XTS has own problems as well... but IMO that should be the default for sector/fs-block encryption these days :) - I do not think there is a problem if ESSIV moves to crypto API, but there it is presented as a hash... It is really just an IV generator. > - wiring up some essiv(x,y) combinations into the testing framework. I wonder > if anything other than essiv(aes,sha256) makes sense. In cryptsetup testsuite, we test serpent and twofish ciphers at least, but in reality, essiv(aes,sha256) is the most used combination. If it makes sense, I can run some tests with dm-crypt and this patchset. Thanks, Milan
WARNING: multiple messages have this Message-ID (diff)
From: Milan Broz <gmazyland@gmail.com> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>, linux-crypto@vger.kernel.org Cc: device-mapper development <dm-devel@redhat.com>, Mike Snitzer <msnitzer@redhat.com>, Herbert Xu <herbert@gondor.apana.org.au>, Eric Biggers <ebiggers@google.com> Subject: Re: [RFC PATCH 0/3] crypto: switch to shash for ESSIV generation Date: Sat, 15 Jun 2019 20:19:22 +0200 [thread overview] Message-ID: <9cd635ec-970b-bd1b-59f4-1a07395e69a0@gmail.com> (raw) In-Reply-To: <20190614083404.20514-1-ard.biesheuvel@linaro.org> On 14/06/2019 10:34, Ard Biesheuvel wrote: > This series is presented as an RFC for a couple of reasons: > - it is only build tested > - it is unclear whether this is the right way to move away from the use of > bare ciphers in non-crypto code > - we haven't really discussed whether moving away from the use of bare ciphers > in non-crypto code is a goal we agree on > > This series creates an ESSIV shash template that takes a (cipher,hash) tuple, > where the digest size of the hash must be a valid key length for the cipher. > The setkey() operation takes the hash of the input key, and sets into the > cipher as the encryption key. Digest operations accept input up to the > block size of the cipher, and perform a single block encryption operation to > produce the ESSIV output. > > This matches what both users of ESSIV in the kernel do, and so it is proposed > as a replacement for those, in patches #2 and #3. > > As for the discussion: the code is untested, so it is presented for discussion > only. I'd like to understand whether we agree that phasing out the bare cipher > interface from non-crypto code is a good idea, and whether this approach is > suitable for fscrypt and dm-crypt. If you want some discussion, it would be very helpful if you cc device-mapper list to reach dm-crypt developers. Please add at least dm-devel list. Just a few comments: - ESSIV is useful only for CBC mode. I wish we move to some better mode in the future instead of cementing CBC use... But if it helps people to actually use unpredictable IV for CBC, it is the right approach. (yes, I know XTS has own problems as well... but IMO that should be the default for sector/fs-block encryption these days :) - I do not think there is a problem if ESSIV moves to crypto API, but there it is presented as a hash... It is really just an IV generator. > - wiring up some essiv(x,y) combinations into the testing framework. I wonder > if anything other than essiv(aes,sha256) makes sense. In cryptsetup testsuite, we test serpent and twofish ciphers at least, but in reality, essiv(aes,sha256) is the most used combination. If it makes sense, I can run some tests with dm-crypt and this patchset. Thanks, Milan
next prev parent reply other threads:[~2019-06-15 18:19 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-14 8:34 [RFC PATCH 0/3] crypto: switch to shash for ESSIV generation Ard Biesheuvel 2019-06-14 8:34 ` [RFC PATCH 1/3] crypto: essiv - create a new shash template for IV generation Ard Biesheuvel 2019-06-14 8:34 ` [RFC PATCH 2/3] dm crypt: switch to essiv shash Ard Biesheuvel 2019-06-14 8:34 ` [RFC PATCH 3/3] fscrypt: switch to ESSIV shash Ard Biesheuvel 2019-06-15 18:19 ` Milan Broz [this message] 2019-06-15 18:19 ` [RFC PATCH 0/3] crypto: switch to shash for ESSIV generation Milan Broz 2019-06-16 19:13 ` Ard Biesheuvel 2019-06-16 19:13 ` Ard Biesheuvel 2019-06-16 21:09 ` [dm-devel] " Eric Biggers 2019-06-16 21:09 ` Eric Biggers 2019-06-16 21:09 ` [dm-devel] " Eric Biggers 2019-06-16 20:44 ` Eric Biggers 2019-06-16 20:44 ` Eric Biggers 2019-06-17 8:51 ` Gilad Ben-Yossef 2019-06-17 8:51 ` Gilad Ben-Yossef 2019-06-17 9:15 ` Ard Biesheuvel 2019-06-17 9:15 ` Ard Biesheuvel 2019-06-17 9:20 ` Herbert Xu 2019-06-17 9:20 ` Herbert Xu 2019-06-17 9:24 ` Ard Biesheuvel 2019-06-17 9:24 ` Ard Biesheuvel 2019-06-17 10:39 ` Milan Broz 2019-06-17 10:39 ` Milan Broz 2019-06-17 10:58 ` Ard Biesheuvel 2019-06-17 10:58 ` Ard Biesheuvel 2019-06-17 13:59 ` Ard Biesheuvel 2019-06-17 13:59 ` Ard Biesheuvel 2019-06-17 14:35 ` Milan Broz 2019-06-17 14:35 ` Milan Broz 2019-06-17 14:39 ` Ard Biesheuvel 2019-06-17 14:39 ` Ard Biesheuvel 2019-06-17 17:05 ` Milan Broz 2019-06-17 17:05 ` Milan Broz 2019-06-17 17:29 ` Ard Biesheuvel 2019-06-17 17:29 ` Ard Biesheuvel 2019-06-17 17:52 ` Milan Broz 2019-06-17 17:52 ` Milan Broz
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=9cd635ec-970b-bd1b-59f4-1a07395e69a0@gmail.com \ --to=gmazyland@gmail.com \ --cc=ard.biesheuvel@linaro.org \ --cc=dm-devel@redhat.com \ --cc=ebiggers@google.com \ --cc=herbert@gondor.apana.org.au \ --cc=linux-crypto@vger.kernel.org \ --cc=msnitzer@redhat.com \ /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: linkBe 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.