On Thu, 2 Jul 2020 at 09:45, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Jul 02, 2020 at 09:40:42AM +0200, Ard Biesheuvel wrote: > > > > I suppose you are looking into this for chaining algif_skipcher > > requests, right? So in that case, the ARC4 state should really be > > treated as an IV, which is owned by the caller, and not stored in > > either the TFM or the skcipher request object. > > Yes I have considered this approach previously but it's just too > messy. What I'm trying to do now is to allow the state to be stored > in the request object. When combined with the proposed REQ_MORE > flag, this should be sufficient. It evens works on XTS. > But that requires the caller to reuse the same skcipher request object when doing chaining, right? Currently, we have no such requirement, and it would mean that the request object's context struct should be aligned between different implementations, e.g., when a driver ends up invoking a fallback for the last N bytes of a chained request. I'll wait for the code to be posted (please put me on cc), but my suspicion is that carrying opaque state like that is going to bite us down the road.
