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