From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934521AbcAMOJR (ORCPT ); Wed, 13 Jan 2016 09:09:17 -0500 Received: from mga01.intel.com ([192.55.52.88]:11513 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932295AbcAMOJO (ORCPT ); Wed, 13 Jan 2016 09:09:14 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,289,1449561600"; d="scan'208";a="632799596" Subject: Re: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type To: David Howells , Tadeusz Struk References: <20151226155014.27615.14985.stgit@desktop.home> <10464.1452691882@warthog.procyon.org.uk> Cc: herbert@gondor.apana.org.au, smueller@chronox.de, linux-api@vger.kernel.org, marcel@holtmann.org, linux-kernel@vger.kernel.org, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, zohar@linux.vnet.ibm.com, dwmw2@infradead.org From: Tadeusz Struk Message-ID: <569659AC.9070506@intel.com> Date: Wed, 13 Jan 2016 06:05:32 -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: <10464.1452691882@warthog.procyon.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On 01/13/2016 05:31 AM, David Howells wrote: >> > + pkey = keyring->payload.data[asym_crypto]; >> > + if (!pkey) { >> > + key_put(keyring); >> > + goto out; >> > + } >> > + >> > + err = setkey(private, pkey->key, pkey->keylen); >> > + key_put(keyring); > Note that you may not assume that there's data there that you can use in this > manner. The key might be a pointer to some hardware device such as a TPM. I > have a TPM asymmetric subtype in progress. So is there anything in place that can be used to tell what the key actually is? The security/integrity/digsig_asymmetric.c is using this api in a similar way, so if it is incorrect digsig_asymmetric shouldn't work neither. > > I think this really needs to be driven from a keyctl() because you need to let > the asymmetric subtype decide how it wants to handle this. I would suggest > adding KEYCTL_{ASYM_GETINFO,SIGN,VERIFY,ENCRYPT,DECRYPT} - the problem is how > to pass sufficient arguments, how to decrypt the private key and what metadata > needs to be passed vs what is inline with the data. I agree, ideally keyctl should do the job for all the cases and request_key() should just return a key data. Thanks, -- TS