On Fri, Jun 12, 2020 at 06:10:57PM +0200, Ard Biesheuvel wrote: > > 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 Sure. I was just too lazy to actually set the -1 everywhere. I'll try to do that before I repost again. > 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. I don't think we should support chaining for XTS at all so I don't see why we need to worry about the hardware accelerated XTS code. > 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? As I said we need to be able to differentiate between the ones that can chain vs. the ones that can't. Putting this knowledge directly into algif_skcipher is just too horrid. The alternative is to add this marker into the algorithms. My point was that if you're going to do that you might as well go a step further and allow cts to chain as it is so straightforward. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
