Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5977606pxb; Thu, 27 Jan 2022 03:58:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJxEE8DcjnlpKzFkmyfS+2tB6osPIMuQbEw8gfPJxNXXPlNpNoDGbCKuoYUN4woUlhk7Nm30 X-Received: by 2002:a05:6402:5188:: with SMTP id q8mr3284881edd.173.1643284696601; Thu, 27 Jan 2022 03:58:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643284696; cv=none; d=google.com; s=arc-20160816; b=A7f6+CihtfZadCKWVqqP/XzXxfOs8cZBgUNWAosPLkKzaP3ZOUWidRBI4XfHpuTRks AuZ86xKxkOvDLhB3pWxsRbLaBrAVRM6L9UmkJadeHkoUXCnLGl0TCu7XJZEL4AUwRuC2 4APUc0jps7dqX/PsVjTsw1y1/9IyjDYTqfpw2vSeeQJYrQtUADZxoYzD9l/DrFdGhUjv sEGvWPZYO/tT8JfWupMzuG94YQRbcUn/8XGOhjA1Mi+uUfmcy1iYWd0UC2thOu5J+NMr Y74H0AXGpKCH0X7uHaObXWU1INYyINXp3ruDc+Eo2Nd+0WwUZAqpVAuChHwc5VMIrzeh QwMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=nuSxGcCow9nR0B4Kr/1rmKb3l6CCaHrmZ49tze3Ob4o=; b=EMhZTLqAJXDZBMQShOrgdcIy1ATluKo2GudbQ8F8DDhOUzgJjb9JChF8MU2i5UvQgU kGKMfAiEtJYSakt/zcsD91BI56bizOz8k+9HSyMn/4fb1OqSJZnMFFYOG3dnvaFVUfhv Vf3XjjczKFRd4RJQqXjwrMOGJaFxlfHnR5BlALkYNew2a93zEcztTHU8rZPVRIUHbHyu 1S3zng8yIs9GFcg/iyBIZTbolasoi10bPv1WnQcdOwd74JjwrdexnPZ70UFOmuBEZZgA yKob6vRf+fR0eTUFLodZCG+Ppdd1J1UvR6snA4WV+KzVuZseqGG4G5RaGTCnpgaBgUT+ cN1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id el12si1218617edb.382.2022.01.27.03.57.51; Thu, 27 Jan 2022 03:58:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236107AbiA0FVH (ORCPT + 99 others); Thu, 27 Jan 2022 00:21:07 -0500 Received: from helcar.hmeau.com ([216.24.177.18]:60510 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231364AbiA0FVH (ORCPT ); Thu, 27 Jan 2022 00:21:07 -0500 Received: from gwarestrin.arnor.me.apana.org.au ([192.168.103.7]) by fornost.hmeau.com with smtp (Exim 4.92 #5 (Debian)) id 1nCxDE-0008DU-49; Thu, 27 Jan 2022 16:20:49 +1100 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Thu, 27 Jan 2022 16:20:48 +1100 Date: Thu, 27 Jan 2022 16:20:47 +1100 From: Herbert Xu To: Eric Biggers 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org 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. 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. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt