Re: [v2 PATCH 0/3] crypto: skcipher - Add support for no chaining and partial chaining

[Ard Biesheuvel <ardb@kernel.org>]

On Fri, 12 Jun 2020 at 14:21, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> v2
>
> Fixed return type of crypto_skcipher_fcsize.
>
> --
>
> This patch-set adds support to the Crypto API and algif_skcipher
> for algorithms that cannot be chained, as well as ones that can
> be chained if you withhold a certain number of blocks at the end.
>
> It only modifies one algorithm to utilise this, namely cts-generic.
> Changing others should be fairly straightforward.  In particular,
> we should mark all the ones that don't support chaining (e.g., most
> stream ciphers).
>

I understand that there is an oversight here that we need to address,
but I am not crazy about this approach, tbh.

First of all, the default fcsize for all existing XTS implementations
should be -1 as well, given that chaining is currently not supported
at all at the sckipher interface layer for any of them (due to the
fact that the IV gets encrypted with a different key at the start of
the operation). This also means it is going to be rather tricky to
implement for h/w accelerated XTS implementations, and it seems to me
that the only way to deal with this is to decrypt the IV in software
before chaining the next operation, which is rather horrid and needs
to be implemented by all of them.

Given that

a) this is wholly an AF_ALG issue, as there are no in-kernel users
currently suffering from this afaik,
b) using AF_ALG to get access to software implementations is rather
pointless in general, given that userspace can simply issue the same
instructions directly
c) fixing all XTS and CTS implementation on all arches and all
accelerators is not a small task

wouldn't it be better to special case XTS and CBC-CTS in
algif_skcipher instead, rather than polluting the skipcher API this
way?