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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 76790C433F5 for ; Thu, 27 Jan 2022 05:37:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=l0LaLmKm/YLBcPcEsP00e3jVeFUz0Q68K5jCXdN/GnQ=; b=msufV7UQF7O+eR ai1tRarmFrL0Hdu7hVE016U7FVxTh9IzzSiDZMBdBPEa3mjYTVxF5EHF+ijCT84h8txOqLZEYkzrC htBA7NBmYL1/hQLqab1F0zsPv+qlBDcytV0SAqjwzOtRjPQHXJTyl4B70mh9vA6YDVyP+XQia1ze8 OEZOM8z55QDHs2uCjr/JA6zvPoJNjclL5FQ4VjJ5fbLVtxtJY4qp5M1RsTDqBZfNyrCnaVLhKRQZg yYwavx5uM+uHrn9u51HalVOZA9Cye71qg7szEfR0tvzKJBVnQPs6pl5Duf9t+05a+IVUID5cqmnv+ YayH8oEpqM3wFlxa3QmQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCxSB-00EPzO-En; Thu, 27 Jan 2022 05:36:15 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCxS8-00EPz2-JQ for linux-arm-kernel@lists.infradead.org; Thu, 27 Jan 2022 05:36:13 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 23C88617FE; Thu, 27 Jan 2022 05:36:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 573B7C340E4; Thu, 27 Jan 2022 05:36:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643261771; bh=SZ9CNXgBetCvzyn6zAdS1K6n9xh2YpDlNEWCHN4BVQU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mxddQNlAmsonNyPQGryjHNceG/5khC2uhJtR4D+WVovU+wHdCx0NvJLRhDbwbJNHE i1V/HjJmL5UUmRpSyUJGHhLNT6pT8O0sPkiqhGTVzbBvRFxipNXqpMFEX5g5u4VItC WjzVxfcv3XNfDcESBlz1xqHvJSsDD0J3tKNCaX5XKR+IqsGkxnfc+kE1CN8F4r0HvW 8+q1icvCs/RbnRTzlFxX5BaVvTf2pmSu+7d5l9WX3R1QAN+xlmRkNL0mzU7c9YOWEK IBG5lQWgXPSzcA79xR7qlzbB1xCIf35TaU94Z4GVQKAqlZTyGW5Rzr3Rq4l7kE5tF/ FqbN0kIaMSJow== Date: Wed, 26 Jan 2022 21:36:09 -0800 From: Eric Biggers To: Herbert Xu Cc: Nathan Huckleberry , linux-crypto@vger.kernel.org, "David S. Miller" , linux-arm-kernel@lists.infradead.org, Paul Crowley , Sami Tolvanen Subject: Re: [RFC PATCH 3/7] crypto: hctr2 - Add HCTR2 support Message-ID: References: <20220125014422.80552-1-nhuck@google.com> <20220125014422.80552-4-nhuck@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220126_213612_706150_562EA402 X-CRM114-Status: GOOD ( 28.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jan 27, 2022 at 04:20:47PM +1100, Herbert Xu wrote: > On Wed, Jan 26, 2022 at 09:08:38PM -0800, Eric Biggers wrote: > > > > The optional parameters mentioned in the comment above don't appear to be > > implemented. Also, the syntax described is ambiguous. I think you meant for > > there to be only one set of square brackets? > > > > xctr(blockcipher_name) should be xctr_name, since it would have to be a driver / > > implementation name, and those don't necessarily include parentheses like the > > algorithm names do. > > > > Did you consider not allowing the single block cipher implementation to be > > overridden? The single block cipher is a minor part compared to xctr. This > > would simplify the "full" syntax slighty, as then it would be > > "hctr2(xctr_name, polyval_name)" instead of > > "hctr2(blockcipher_name, xctr_name, polyval_name)". > > > > I suppose it does make sense to take the single block cipher parameter, given > > that it is used. But you'll need to make sure to make hctr2_create() enforce > > that the same block cipher is used in both parameters. > > For the single block cipher parameter, another option is to derive > it from the xctr_name. That is, once you have the skcipher for > xctr_name, you extract its cra_name, assuming that it must be of > the form xctr(%s) then you just strip away the xctr() and get the > single block cipher name that way. That's what I had in mind with "hctr2(xctr_name, polyval_name)". > > The purpose of having the parameter explicitly is so that the > instantiatied algorithm is automatically torn down when the > underlying algorithm is replaced with a better version. > > This is in general unnecessary if you're simply using the > single block cipher to generate setup material. > Well, the single block cipher isn't used just in ->setkey(), but also in ->encrypt() and ->decrypt() (not for the bulk of the data, but for 1 block). So allowing its implementation to be specified might make sense. Alternatively the single block cipher could be emulated with xctr which the template already has, similar to how the cts template only uses cbc, but I think that would be pretty messy here. - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel