On 7/2/2020 7:36 AM, Herbert Xu 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
On Thu, 9 Jul 2020 at 11:53, Horia Geantă 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,
> >
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 rem
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 c
On 7/6/2020 4:43 PM, Ard Biesheuvel wrote:
> On Sun, 5 Jul 2020 at 22:11, Horia Geantă wrote:
>>
>> On 7/2/2020 7:36 AM, Herbert Xu 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 no
On Sun, 5 Jul 2020 at 22:11, Horia Geantă wrote:
>
> On 7/2/2020 7:36 AM, Herbert Xu 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 m
On 7/2/2020 7:36 AM, Herbert Xu 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.
>
The fact that smth. i
On Thu, 2 Jul 2020 at 09:56, Herbert Xu wrote:
>
> On Thu, Jul 02, 2020 at 09:51:29AM +0200, Ard Biesheuvel wrote:
> >
> > I'll wait for the code to be posted (please put me on cc), but my
>
> Sure I will.
>
> > suspicion is that carrying opaque state like that is going to bite us
> > down the roa
On Thu, Jul 02, 2020 at 05:56:16PM +1000, Herbert Xu wrote:
>
> For XTS I haven't decided whether to go this way or not. If it
> does work out though we could even extend it to AEAD.
But there is clearly a need for this functionality, and it's
not just af_alg. Have a look at net/sunrpc/auth_gss/
On Thu, Jul 02, 2020 at 09:51:29AM +0200, Ard Biesheuvel wrote:
>
> I'll wait for the code to be posted (please put me on cc), but my
Sure I will.
> suspicion is that carrying opaque state like that is going to bite us
> down the road.
Well it's only going to be arc4 at first, where it's definit
On Thu, 2 Jul 2020 at 09:45, Herbert Xu 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 t
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 skciphe
On Thu, Jul 02, 2020 at 09:32:32AM +0200, Ard Biesheuvel wrote:
>
> Actually, it seems the generic ecb(arc4) is broken as well in this regard.
Not in the same way. The generic arc4 stores the state in the
tfm so it works until you have two requests that share the same
tfm.
Since we only have two
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 enc
On Thu, 2 Jul 2020 at 09:32, Ard Biesheuvel wrote:
>
> On Thu, 2 Jul 2020 at 09:27, Ard Biesheuvel wrote:
> >
> > On Thu, 2 Jul 2020 at 06:36, Herbert Xu wrote:
> > >
> > > The arc4 algorithm requires storing state in the request context
> > > in order to allow more than one encrypt/decrypt oper
On Thu, 2 Jul 2020 at 09:27, Ard Biesheuvel wrote:
>
> On Thu, 2 Jul 2020 at 06:36, Herbert Xu 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
On Thu, 2 Jul 2020 at 06:36, Herbert Xu 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: ea
17 matches
Mail list logo
