From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B935C433E0 for ; Thu, 2 Jul 2020 07:45:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2ED4320936 for ; Thu, 2 Jul 2020 07:45:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726875AbgGBHpg (ORCPT ); Thu, 2 Jul 2020 03:45:36 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:38020 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726362AbgGBHpg (ORCPT ); Thu, 2 Jul 2020 03:45:36 -0400 Received: from gwarestrin.arnor.me.apana.org.au ([192.168.0.7]) by fornost.hmeau.com with smtp (Exim 4.92 #5 (Debian)) id 1jqtuX-0002g7-NC; Thu, 02 Jul 2020 17:45:34 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Thu, 02 Jul 2020 17:45:33 +1000 Date: Thu, 2 Jul 2020 17:45:33 +1000 From: Herbert Xu To: Ard Biesheuvel Cc: Horia =?utf-8?Q?Geant=C4=83?= , Aymen Sghaier , Linux Crypto Mailing List , Iuliana Prodan Subject: Re: [PATCH] crypto: caam - Remove broken arc4 support Message-ID: <20200702074533.GC4253@gondor.apana.org.au> References: <20200702043648.GA21823@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org 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. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt