From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760822AbcALF74 (ORCPT ); Tue, 12 Jan 2016 00:59:56 -0500 Received: from mga03.intel.com ([134.134.136.65]:28586 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751283AbcALF7x (ORCPT ); Tue, 12 Jan 2016 00:59:53 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,556,1444719600"; d="scan'208";a="891318793" Subject: Re: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type To: Tadeusz Struk , herbert@gondor.apana.org.au, marcel@holtmann.org, dhowells@redhat.com, dwmw2@infradead.org References: <20151226155014.27615.14985.stgit@desktop.home> Cc: smueller@chronox.de, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, zohar@linux.vnet.ibm.com From: Tadeusz Struk X-Enigmail-Draft-Status: N1110 Message-ID: <5694957D.7080904@intel.com> Date: Mon, 11 Jan 2016 21:56:13 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20151226155014.27615.14985.stgit@desktop.home> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, David and Marcel, On 12/26/2015 07:50 AM, Tadeusz Struk wrote: > From: Tadeusz Struk > > Created on top of patchset from Stephan Mueller > https://patchwork.kernel.org/patch/7877921/ > https://patchwork.kernel.org/patch/7877971/ > https://patchwork.kernel.org/patch/7877961/ > > This patch adds support for asymmetric key type to AF_ALG. > It will work as follows: A new PF_ALG socket options will be > added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely > ALG_SET_PUBKEY_ID and ALG_SET_KEY_ID for setting public and > private keys respectively. When these new options will be used > the user instead of providing the key material, will provide a > key id and the key itself will be obtained from kernel keyring > subsystem. The user will use the standard tools (keyctl tool > or the keyctl syscall) for key instantiation and to obtain the > key id. The key id can also be obtained by reading the > /proc/keys file. > > When a key will be found, the request_key() function will > return a requested key. Next the asymmetric key subtype will be > used to obtain the public_key, which can be either a public key > or a private key from the cryptographic point of view, and the > key payload will be passed to the akcipher pf_alg subtype. > Pf_alg code will then call crypto API functions, either the > crypto_akcipher_set_priv_key or the crypto_akcipher_set_pub_key, > depending on the used option. Subsequently the asymmetric key > will be freed and return code returned back to the user. > > Currently the interface will be restricted only to asymmetric > ciphers, but it can be extended later to work with symmetric > ciphers if required. > > The assumption is that access rights for a given user will be > verified by the key subsystem so the pf_alg interface can call > the request_key() without checking if the user has appropriate > rights (Please verify this assumption). > > Changes in v2: > Separate logic for setkey and setkey_id into two separate > functions as proposed by Stephan. > > Signed-off-by: Tadeusz Struk > --- > crypto/af_alg.c | 49 +++++++++++++++++++++++++++++++++++++++---- > include/uapi/linux/if_alg.h | 2 ++ > 2 files changed, 47 insertions(+), 4 deletions(-) Do you have any comments on this? Based on your feedback after Stephan sent the v2 algif_akcipher patches the conclusion was that having both setkey and setkey_id will be acceptable. This is exactly what this patch does, so will the algif_akcipher patches with this one on top work for you? Thanks, -- TS