Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp273297imu; Fri, 25 Jan 2019 02:01:23 -0800 (PST) X-Google-Smtp-Source: ALg8bN5DNjxReyP9cJVGfAeVIr+6WjKBJlKM/bnHccuQ36itqRR/NrLzrkLXfQCSFrrsdYw3n7p2 X-Received: by 2002:a63:9b11:: with SMTP id r17mr9451591pgd.416.1548410483088; Fri, 25 Jan 2019 02:01:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548410483; cv=none; d=google.com; s=arc-20160816; b=W9fiygUpjWiUXPE8C+0dQW0pcMfT5aNTIti9diWKdDxgFIoJacJgQvS2Zk0Li3U6NC uUbLN7zW2ZM26aB5J2PZYw8OCXu9jyQqMsKPMzZha0aIp8lQj34nuakdASbH5KYRWSJH k9uSrfh6y34SXQXcKvrOzhWDzZK7LknTgoNgboYowKbFhHOSzEmvtqwO+7Q70ORv/VtB l+YqgHzSqBnHA52Hph1xhXI0a2gPuLIaM2XCM/XUFj9Jwjr/JeJ+3qZDmKkU/wA0+uLQ D1KmZKccff09vcfF/zFjX/doXesKfUkOPen+FmTeC6toSszx1OBmtHpGlhzH4imGY2re rovQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:to :from:date; bh=xr71E4cg3YJYrvk9Xohl2eDkx2SXfvXV+TVzM4grvSE=; b=Q7VtMef8RKHUWFKN9JJ0RN9qfaPJp9QKe9JCCwpk7cG7/UQpuFpdFfwt8TPiQZNXz2 tgEvorM55Xd9LWIpODQU6VespwwxinE6/Oqdluqb2GJLk3LEq+2WXtk2agAD8XYN+/9v I5kx7QO+prqY8THyUImppwXZ2DZTpf6lcDb8zUfWGgOf92bza1eXyS7w5tUytLP3e74k wSgXDuvVanISvTUVqXpt1S4HMLHApwc5EjX/r6FhUlEVFl3I7AQDwgcrrYGKithYbPYe byjm0IOH+KFBp5My5duQOrma2SsambKvh4pUCRKZYsacaUlMV7x+WpwNteYXtSDZh1+a vdIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w67si5595650pgb.45.2019.01.25.02.01.06; Fri, 25 Jan 2019 02:01:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728879AbfAYKAp (ORCPT + 99 others); Fri, 25 Jan 2019 05:00:45 -0500 Received: from orcrist.hmeau.com ([104.223.48.154]:44266 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726761AbfAYKAp (ORCPT ); Fri, 25 Jan 2019 05:00:45 -0500 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1gmyHi-0004lp-GK; Fri, 25 Jan 2019 18:00:26 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1gmyHR-0007Vp-TN; Fri, 25 Jan 2019 18:00:09 +0800 Date: Fri, 25 Jan 2019 18:00:09 +0800 From: Herbert Xu To: David Howells , Tudor Ambarus , "David S. Miller" , Maxime Coquelin , Alexandre Torgue , Horia =?utf-8?Q?Geant=C4=83?= , Aymen Sghaier , Tom Lendacky , Gary Hook , Giovanni Cabiddu , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, keyrings@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, qat-linux@intel.com Subject: Re: [RFC PATCH v2] akcipher: Introduce verify_rsa/verify for public key algorithms Message-ID: <20190125100009.i2ggpc7k7qvzayvj@gondor.apana.org.au> References: <20190116164703.9267-1-vt@altlinux.org> <24887.1547658740@warthog.procyon.org.uk> <20190116182719.j6ii6nmn4ciiurqr@altlinux.org> <20190118204100.6o3ovctanb62nvd2@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190118204100.6o3ovctanb62nvd2@altlinux.org> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 18, 2019 at 11:41:00PM +0300, Vitaly Chikunov wrote: > > a) RSA verify works differently (is it just disguised encrypt), > b) We have separate wrapper module for it (pkcs1pad). Thus: > > Old API can not be removed. In other words, we can not replace > .verify_rsa with .verify in these drivers or PKCS1 will not work. > > We can replace .verify_rsa with .verify in pkcs1pad, but there is no > need for that if we stay with two API calls, which we can't avoid. I think having two API calls during a transition period is fine. But it must not be the long-term outcome. In order to keep existing drivers working, I think we should make the API wrap the legacy verify_rsa and implement verify directly on top of it. IOW the driver remains unchanged for now but the crypto API code should provide a verify API that is implemented on top of the driver's verify_rsa call. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt