Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp339734imu; Fri, 25 Jan 2019 03:18:35 -0800 (PST) X-Google-Smtp-Source: ALg8bN7Rc77rQAB1OWosPdHg4KN5ftO+AdDywpNwIOg9vq7rjK3o3zZpyFo/tjOC8eyoDqJgfn7/ X-Received: by 2002:a65:4683:: with SMTP id h3mr9219169pgr.225.1548415115119; Fri, 25 Jan 2019 03:18:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548415115; cv=none; d=google.com; s=arc-20160816; b=uTMsaNBi5UQGwhbcnamqfXdnLplLEG/6bNMqdXuEZF41V0pWlaUphEhLMesKVOJqB1 9NQPF6e3jnHKoevQoIAcF/3lwLOqxeYfARJ/QXhiijMBddyNOCLpWZNQe9tTBRBLkvRO dU0KqQPBDbw082RxJ+mFWWOLqPAkRLsYWUmsdUH5rRBs3rE4/PiPL8tyQsDvVZdOWW21 m9eK3epljptwobFTn7Jf5ACwoqGFIKhQ10kIoxAi9n9bShg53oCkjFPwtkDkANQObKKk usRPywXXMzJ/+ZXal6S3/zBzhORjZVWc/uAk2JpNVakVPP6Y8/pau/Z4g+VADxlYwZSm OMAA== 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:mail-followup-to :message-id:subject:cc:to:from:date; bh=0w4iAznoemBEZeS9X3EfVQR0JofqkHfo15trYOaN+W0=; b=klotxaRYAYtv3pD8AMBPsXVad70uNRDmxJS4ukfoZd61+vSssWKAZTACQAOAWGVwbr tGguUiUWGpW5hYGS43DAEMqTE5ogFBLonfcEAIcS7SXv+E9kaDHBq7+ysWpum2STHAC5 +rbWPwZuiODk6tYHCEcStuWtCGPdAUOKu6Zm975BZFCD7prsptoeb/5CcGZ6eb35D4Ka ffuUtF4OFUCQl0KfdoaULCxn9TynhxRFOH4qRaqJb8ftPcKVi++jYXsEDxX4SEBNDY4K nynnPp+kxQAA3PgGCIi316nvt/dD4uYNQlg2XxI2b//JsdGkrSO2wdRuvqrOh6b4peP/ zkYA== 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 t6si25740786plz.96.2019.01.25.03.18.18; Fri, 25 Jan 2019 03:18:35 -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 S1726317AbfAYLSP (ORCPT + 99 others); Fri, 25 Jan 2019 06:18:15 -0500 Received: from vmicros1.altlinux.org ([194.107.17.57]:35680 "EHLO vmicros1.altlinux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725909AbfAYLSO (ORCPT ); Fri, 25 Jan 2019 06:18:14 -0500 Received: from imap.altlinux.org (imap.altlinux.org [194.107.17.38]) by vmicros1.altlinux.org (Postfix) with ESMTP id 66ECF72CC61; Fri, 25 Jan 2019 14:18:11 +0300 (MSK) Received: from altlinux.org (sole.flsd.net [185.75.180.6]) by imap.altlinux.org (Postfix) with ESMTPSA id 4B4354A4A16; Fri, 25 Jan 2019 14:18:11 +0300 (MSK) Date: Fri, 25 Jan 2019 14:18:09 +0300 From: Vitaly Chikunov To: Herbert Xu Cc: David Howells , Mimi Zohar , Dmitry Kasatkin , linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v3] akcipher: Introduce verify_rsa/verify for public key algorithms Message-ID: <20190125111808.slyoptlns53t7fiw@altlinux.org> Mail-Followup-To: Herbert Xu , David Howells , Mimi Zohar , Dmitry Kasatkin , linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org References: <20190118205846.20309-1-vt@altlinux.org> <20190125100929.zxmqbsibnnikh7tv@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20190125100929.zxmqbsibnnikh7tv@gondor.apana.org.au> User-Agent: NeoMutt/20171215-106-ac61c7 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 25, 2019 at 06:09:29PM +0800, Herbert Xu wrote: > On Fri, Jan 18, 2019 at 11:58:46PM +0300, Vitaly Chikunov wrote: > > Previous akcipher .verify() just `decrypts' (using RSA encrypt which is > > using public key) signature to uncover message hash, which was then > > compared in upper level public_key_verify_signature() with the expected > > hash value, which itself was never passed into verify(). > > > > This approach was incompatible with EC-DSA family of algorithms, > > because, to verify a signature EC-DSA algorithm also needs a hash value > > as input; then it's used (together with a signature divided into halves > > `r||s') to produce a witness value, which is then compared with `r' to > > determine if the signature is correct. Thus, for EC-DSA, nor > > requirements of .verify() itself, nor its output expectations in > > public_key_verify_signature() wasn't sufficient. > > > > Make improved .verify() call which gets hash value as parameter and > > produce complete signature check without any output besides status. > > > > RSA-centric drivers have replaced verify() with verify_rsa() which > > have old semantic and which they still should implement (if they want > > pkcs1pad to work). If akcipher have .verify_rsa() callback, it will be > > used for a partial verification, which then is finished in > > crypto_akcipher_verify(). > > > > Now for the top level verification only crypto_akcipher_verify() needs > > to be called. > > > > For pkcs1pad crypto_akcipher_verify_rsa() is introduced which directly > > calls .verify_rsa() for its backend. Without this api PKCS1 can not be > > implemented. > > > > Tested on x86_64. > > > > Signed-off-by: Vitaly Chikunov > > Thanks for working on this! > > We have been here before. We changed the AEAD interface in a way > that is not dissimilar to what you want to do here. > > So I think the basic plan should be: While time goes, I got another simpler idea how we should settle this: 1. Since we are know that by nature RSA sign/verify is just encrypt/decrypt, and since sign/verify calls should not be used directly by any normal users: - Remove sign/verify calls from all existing RSA backends. 2. pkcs1pad should use encrypt/decrypt API for its low level purposes (instead of sign/verify API, which now would be not implemented by them), and provide sign (same as before) and new verify (returning only status). Thus, we avoid verify_rsa call altogether while remaining its functionality, and skipping conversion step. > 1) Implement new top-level verify, alongside existing verify_rsa. > 2) For existing drivers implement a wrapper over verify_rsa. > 3) Convert *all* existing users to the new verify API. > 4) Remove top-level verify_rsa API. > 5) Convert existing drivers over to verify API. > 6) Remove verify_rsa completely. > > > +int crypto_akcipher_verify(struct akcipher_request *req, > > + const unsigned char *digest, unsigned int digest_len) > > We should not add new fields outside of akcipher_request. So > these fields need to go inside it. However, I think we don't > actually need two new fields. They could both go into the src > scatterlist. All we need is a new field, say textlen to indicate > where the text stops and where the hash starts. We could also > overlay textlen over dstlen as it would now be unused for verify. Well, if we allowed to reuse dst* fields why not just put digest over dst scatterlist? That would be much simpler. Thanks, > The advantage of having it in one scatterlist is that for those > users that already have the two pieces together could simply provide > a single SG element (I don't know how likely that is in practice > though). > > For others you would simply tack on an extra SG element. > > Thanks, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt