From patchwork Mon Dec 14 18:06:21 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tadeusz Struk X-Patchwork-Id: 7846461 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Original-To: patchwork-linux-crypto@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id E53FFBEEE1 for ; Mon, 14 Dec 2015 18:09:43 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 06D8120304 for ; Mon, 14 Dec 2015 18:09:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0F034202EC for ; Mon, 14 Dec 2015 18:09:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753087AbbLNSJk (ORCPT ); Mon, 14 Dec 2015 13:09:40 -0500 Received: from mga04.intel.com ([192.55.52.120]:61439 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752898AbbLNSJk (ORCPT ); Mon, 14 Dec 2015 13:09:40 -0500 Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP; 14 Dec 2015 10:09:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,428,1444719600"; d="scan'208";a="12982190" Received: from tstruk-mobl1.jf.intel.com (HELO tstruk-mobl1.intel.com) ([134.134.171.161]) by fmsmga004.fm.intel.com with ESMTP; 14 Dec 2015 10:09:40 -0800 Subject: Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API To: Marcel Holtmann , Stephan Mueller , David Woodhouse References: <1831785.BBs8Hj3CxY@myon.chronox.de> Cc: Herbert Xu , linux-crypto@vger.kernel.org, linux-kernel , linux-api@vger.kernel.org, David Howells From: Tadeusz Struk Message-ID: <566F051D.4080408@intel.com> Date: Mon, 14 Dec 2015 10:06:21 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, On 10/26/2015 09:54 PM, Marcel Holtmann wrote: > Hi Stephan, > >> This patch set adds the AF_ALG user space API to externalize the >> asymmetric cipher API recently added to the kernel crypto API. >> >> The patch set is tested with the user space library of libkcapi [1]. >> Use [1] test/test.sh for a full test run. The test covers the >> following scenarios: >> >> * sendmsg of one IOVEC >> >> * sendmsg of 16 IOVECs with non-linear buffer >> >> * vmsplice of one IOVEC >> >> * vmsplice of 15 IOVECs with non-linear buffer >> >> * invoking multiple separate cipher operations with one >> open cipher handle >> >> * encryption with private key (using vector from testmgr.h) >> >> * encryption with public key (using vector from testmgr.h) >> >> * decryption with private key (using vector from testmgr.h) > > after having discussions with David Howells and David Woodhouse, I don't think we should expose akcipher via AF_ALG at all. I think the akcipher operations for sign/verify/encrypt/decrypt should operate on asymmetric keys in the first place. With akcipher you are pretty much bound to public and private keys and the key is the important part and not the akcipher itself. Especially since we want to support private keys in hardware (like TPM for example). > > It seems more appropriate to use keyctl to derive the symmetric session key from your asymmetric key. And then use the symmetric session key id with skcipher via AF_ALG. Especially once symmetric key type has been introduced this seems to be trivial then. > > I am not really in favor of having two userspace facing APIs for asymmetric cipher usage. And we need to have an API that is capable to work with hardware keys. If we would have something like this: diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h index f2acd2f..02e6162 100644 --- a/include/uapi/linux/if_alg.h +++ b/include/uapi/linux/if_alg.h @@ -34,9 +34,12 @@ struct af_alg_iv { #define ALG_SET_OP 3 #define ALG_SET_AEAD_ASSOCLEN 4 #define ALG_SET_AEAD_AUTHSIZE 5 +#define ALG_SET_PUBKEY 6 +#define ALG_SET_PUBKEY_ID 7 in case of ALG_SET_PUBKEY the key will be provided by user space and in case of ALG_SET_PUBKEY_ID the PF_ALG layer will retrieve the key from the keyring using the ID provided form user space. Will this be ok with you Marcel and David? Thanks,