Linux-Crypto Archive on lore.kernel.org
 help / color / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	Eric Biggers <ebiggers@google.com>,
	device-mapper development <dm-devel@redhat.com>,
	linux-fscrypt@vger.kernel.org,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	Milan Broz <gmazyland@gmail.com>
Subject: Re: [PATCH v11 1/4] crypto: essiv - create wrapper template for ESSIV generation
Date: Thu, 15 Aug 2019 20:59:21 +0300
Message-ID: <CAKv+Gu9wK_8RxOer5x5UuMu4rTZOWP+6xaCu+LpSDff2o_ukOg@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu9Yx3Jk_ikZC1GrR8rR1zV_5CzkXv5NntXnLYim2n+R9g@mail.gmail.com>

On Thu, 15 Aug 2019 at 20:46, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Thu, 15 Aug 2019 at 14:35, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >
> > On Thu, Aug 15, 2019 at 08:15:29AM +0300, Ard Biesheuvel wrote:
> > >
> > > So what about checking that the cipher key size matches the shash
> > > digest size, or that the cipher block size matches the skcipher IV
> > > size? This all moves to the TFM init function?
> >
> > I don't think you need to check those things.  If the shash produces
> > an incorrect key size the setkey will just fail naturally.  As to
> > the block size matching the IV size, in the kernel it's not actually
> > possible to get an underlying cipher with different block size
> > than the cbc mode that you used to derive it.
> >
>
> dm-crypt permits any skcipher to be used with ESSIV, so the template
> does not enforce CBC to be used.
>
> > The size checks that we have in general are to stop people from
> > making crazy combinations such as lrw(des3_ede), it's not there
> > to test the correctness of a given implementation.  That is,
> > we assume that whoever provides "aes" will give it the correct
> > geometry for it.
> >
> > Sure we haven't made it explicit (which we should at some point)
> > but as it stands, it can only occur if we have a bug or someone
> > loads a malicious kernel module in which case none of this matters.
> >
>
> OK.
>
> > > Are there any existing templates that use this approach?
> >
> > I'm not sure of templates doing this but this is similar to fallbacks.
> > In fact we don't check any gemoetry on the fallbacks at all.
> >
>
> OK, so one other thing: how should I populate the cra_name template
> field if someone instantiates essiv(cbc(aes),sha256-ce)? We won't know
> until TFM init time what cra_name allocating the sha256-ce shash
> actually produces, so the only way to populate those names is to use
> the bare string supplied by the caller, which could be bogus.
>
> To me, it seems like retaining the spawn for the shash is more
> idiomatic, and avoids strange issues like the one above. Dropping the
> spawn for the encapsulated cipher (which is tightly coupled to the
> skcipher/aead being encapsulated) does seem feasible, so I'll go with
> that.

Actually, I should be able to lookup the alg without using it to
create a spawn. Let me try that instead.

  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14 16:37 [PATCH v11 0/4] crypto: switch to crypto API " Ard Biesheuvel
2019-08-14 16:37 ` [PATCH v11 1/4] crypto: essiv - create wrapper template " Ard Biesheuvel
2019-08-15  2:37   ` Herbert Xu
2019-08-15  4:59     ` Ard Biesheuvel
2019-08-15  5:13       ` Herbert Xu
2019-08-15  5:15         ` Ard Biesheuvel
2019-08-15 11:35           ` Herbert Xu
2019-08-15 17:46             ` Ard Biesheuvel
2019-08-15 17:59               ` Ard Biesheuvel [this message]
2019-08-14 16:37 ` [PATCH v11 2/4] crypto: essiv - add tests for essiv in cbc(aes)+sha256 mode Ard Biesheuvel
2019-08-14 16:37 ` [PATCH v11 3/4] crypto: arm64/aes-cts-cbc - factor out CBC en/decryption of a walk Ard Biesheuvel
2019-08-14 16:37 ` [PATCH v11 4/4] crypto: arm64/aes - implement accelerated ESSIV/CBC mode Ard Biesheuvel

Reply instructions:

You may reply publically 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=CAKv+Gu9wK_8RxOer5x5UuMu4rTZOWP+6xaCu+LpSDff2o_ukOg@mail.gmail.com \
    --to=ard.biesheuvel@linaro.org \
    --cc=dm-devel@redhat.com \
    --cc=ebiggers@google.com \
    --cc=gilad@benyossef.com \
    --cc=gmazyland@gmail.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

Linux-Crypto Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-crypto/0 linux-crypto/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-crypto linux-crypto/ https://lore.kernel.org/linux-crypto \
		linux-crypto@vger.kernel.org
	public-inbox-index linux-crypto

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-crypto


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git