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

[Ard Biesheuvel]

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.