On Fri, May 29, 2020 at 02:00:14PM +0200, Ard Biesheuvel wrote: > > Even if this is the case, it requires that an skcipher implementation > stores an output IV in the buffer that skcipher request's IV field > points to. Currently, we only check whether this is the case for CBC > implementations, and so it is quite likely that lots of h/w > accelerators or arch code don't adhere to this today. They are and have always been broken because algif_skcipher has always relied on this. > This might be feasible for the generic CTS driver wrapping h/w > accelerated CBC. But how is this supposed to work, e.g., for the two > existing h/w implementations of cts(cbc(aes)) that currently ignore > this? They'll have to disable chaining. The way I'm doing this would allow some implementations to allow chaining while others of the same algorithm can disable chaining and require the whole request to be presented together. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
