[dm-devel] [PATCH v11 1/4] crypto: essiv - create wrapper template for ESSIV generation

[Ard Biesheuvel]

On Thu, 15 Aug 2019 at 20:46, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>
> On Thu, 15 Aug 2019 at 14:35, Herbert Xu <herbert at 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.