On Thu, Jul 02, 2020 at 09:27:33AM +0200, Ard Biesheuvel wrote: > > I do wonder if the others are doing any better - n2 and bcm iproc also > appear to keep the state in the TFM object, while I'd expect the > setkey() to be a simple memcpy(), and the initial state derivation to > be part of the encrypt flow, right? bcm at least appears to be doing the right thing, but of course without the hardware or a reference manual I can't be sure. David can probably tell us whether n2 is capable of updating the state at ent->enc_key_addr after each arc4 operation. > Maybe we should add a test for this to tcrypt, i.e., do setkey() once > and do two encryptions of the same input, and check whether we get > back the original data. Yes we could certainly add an arc4-only test. Alternatively we could kill the only in-kernel user (auth_gss) and then try to remove the arc4 interface completely (and hope that nobody complains :) Thanks, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
