Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190614083404.20514-1-ard.biesheuvel@linaro.org> <9cd635ec-970b-bd1b-59f4-1a07395e69a0@gmail.com>
In-Reply-To: <9cd635ec-970b-bd1b-59f4-1a07395e69a0@gmail.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Sun, 16 Jun 2019 21:13:01 +0200
Message-ID: <CAKv+Gu88tYOmO=8mi7yP2oj=x_SOB_o7D9jo6v_3xfbUxY2R1A@mail.gmail.com>
Subject: Re: [RFC PATCH 0/3] crypto: switch to shash for ESSIV generation
To:     Milan Broz <gmazyland@gmail.com>
Cc:     "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Eric Biggers <ebiggers@google.com>,
        device-mapper development <dm-devel@redhat.com>,
        Mike Snitzer <msnitzer@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Sat, 15 Jun 2019 at 20:19, Milan Broz <gmazyland@gmail.com> wrote:
>
> 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 agree that XTS should be preferred. But for some reason, the
kernel's XTS implementation does not support ciphertext stealing (as
opposed to, e.g., OpenSSL), and so CBC ended up being used for
encrypting the filenames in fscrypt.

I am trying to serve both customers with the same solution here,
regardless of whether it is the recommended approach or not.

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

True. But we don't have the proper abstractions to make this
distinction, and so a shash is currently the best match.

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

OK, that is helpful, thanks. Mind if I ping you once we reach a state
where we need to test for correctness? At the moment, this is still
mostly a discussion piece.