From: Herbert Xu <herbert@gondor.apana.org.au>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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 21:35:48 +1000 [thread overview]
Message-ID: <20190815113548.GA27723@gondor.apana.org.au> (raw)
In-Reply-To: <CAKv+Gu_OVUfXW6t+j1RHA4_Uc43o50Sspke2KkVw9djbFDd04g@mail.gmail.com>
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.
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.
> 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.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2019-08-15 11:36 UTC|newest]
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 for ESSIV generation 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 [this message]
2019-08-15 17:46 ` Ard Biesheuvel
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 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=20190815113548.GA27723@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=ard.biesheuvel@linaro.org \
--cc=dm-devel@redhat.com \
--cc=ebiggers@google.com \
--cc=gilad@benyossef.com \
--cc=gmazyland@gmail.com \
--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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).