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.2 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 AF2E8C433DF for ; Fri, 29 May 2020 12:02:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8F13C207F5 for ; Fri, 29 May 2020 12:02:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726064AbgE2MCV (ORCPT ); Fri, 29 May 2020 08:02:21 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:40712 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725775AbgE2MCU (ORCPT ); Fri, 29 May 2020 08:02:20 -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 1jediK-00054o-R7; Fri, 29 May 2020 22:02:17 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Fri, 29 May 2020 22:02:16 +1000 Date: Fri, 29 May 2020 22:02:16 +1000 From: Herbert Xu To: Ard Biesheuvel Cc: Linux Crypto Mailing List , Linux ARM , Eric Biggers , Stephan Mueller Subject: Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr Message-ID: <20200529120216.GA3752@gondor.apana.org.au> References: <20200519190211.76855-1-ardb@kernel.org> <20200528073349.GA32566@gondor.apana.org.au> <20200529080508.GA2880@gondor.apana.org.au> <20200529115126.GA3573@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 Fri, May 29, 2020 at 02:00:14PM +0200, Ard Biesheuvel wrote: > > Even if this is the case, it requires that an skcipher implementation > stores an output IV in the buffer that skcipher request's IV field > points to. Currently, we only check whether this is the case for CBC > implementations, and so it is quite likely that lots of h/w > accelerators or arch code don't adhere to this today. They are and have always been broken because algif_skcipher has always relied on this. > This might be feasible for the generic CTS driver wrapping h/w > accelerated CBC. But how is this supposed to work, e.g., for the two > existing h/w implementations of cts(cbc(aes)) that currently ignore > this? They'll have to disable chaining. The way I'm doing this would allow some implementations to allow chaining while others of the same algorithm can disable chaining and require the whole request to be presented together. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt