On Thu, 2 Jul 2020 at 09:27, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>
> On Thu, 2 Jul 2020 at 06:36, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > The arc4 algorithm requires storing state in the request context
> > in order to allow more than one encrypt/decrypt operation. As this
> > driver does not seem to do that, it means that using it for more
> > than one operation is broken.
> >
> > Fixes: eaed71a44ad9 ("crypto: caam - add ecb(*) support")
> > Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> >
>
> Acked-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
>
> All internal users of ecb(arc4) use sync skciphers, so this should
> only affect user space.
>
> 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?
>
> 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.
>
Actually, it seems the generic ecb(arc4) is broken as well in this regard.
