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:46:21 +0300
Message-ID: <CAKv+Gu9Yx3Jk_ikZC1GrR8rR1zV_5CzkXv5NntXnLYim2n+R9g@mail.gmail.com> (raw)
In-Reply-To: <20190815113548.GA27723@gondor.apana.org.au>

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.

  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 [this message]
2019-08-15 17:59               ` Ard Biesheuvel
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+Gu9Yx3Jk_ikZC1GrR8rR1zV_5CzkXv5NntXnLYim2n+R9g@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 linux-crypto@archiver.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