On Thu, 9 Jul 2020 at 11:53, Horia Geantă <horia.geanta@xxxxxxx> wrote: > > On 7/9/2020 3:47 AM, Herbert Xu wrote: > > On Wed, Jul 08, 2020 at 07:24:08PM +0300, Horia Geantă wrote: > >> > >> I think the commit message should be updated to reflect this logic: > >> indeed, caam's implementation of ecb(arc4) is broken, > >> but instead of fixing it, crypto API-based ecb(arc4) > >> is removed completely from the kernel (hence from caam driver) > >> due to skcipher limitations in terms of handling the keystream. > > > > Actually that's not quite true. The reason I create this patch > > in the first place is to remove this limitation from skcipher. > > > But the reason / context has changed in the meantime right? > > If skcipher limitation is eliminated, > will it be possible to add ecb(arc4) implementation back in caam, > this time with the state stored in the request object? > > My understanding is: no, if Ard's arc4 RFC series is merged. > I would like the skcipher chaining discussion to focus on relevant and typical skciphers like XTS and CBC-CTS, which is already tricky enough to get right. As 'fixing' ecb(arc4) may open up security holes (given that leaving the TFM version of the key untouched makes it more likely that it gets reused inadvertently), I would prefer to get rid of it entirely. And what is the point of accelerated ecb(arc4) anyway? The internal users all require sync skciphers (and those WEP/WPA fallbacks are rarely used in practice, given that only ancient Wifi hardware relies on them). We did identify a AF_ALG skcipher user that will be better off using a C implementation in userland. And using RC4 for TLS was explicitly forbidden by RFC 7465 5 years ago ...
