On Fri, 12 Jun 2020 at 14:21, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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?
