From: Mat Martineau Subject: Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API Date: Thu, 10 Aug 2017 17:48:37 -0700 (PDT) Message-ID: References: <26359147.tCiuJ5s8mz@positron.chronox.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0-998146653-1502408527=:33607" Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org, dhowells@redhat.com To: =?ISO-8859-15?Q?Stephan_M=FCller?= Return-path: Received: from mga14.intel.com ([192.55.52.115]:1835 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449AbdHKAsi (ORCPT ); Thu, 10 Aug 2017 20:48:38 -0400 In-Reply-To: <26359147.tCiuJ5s8mz@positron.chronox.de> Content-ID: Sender: linux-crypto-owner@vger.kernel.org List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-998146653-1502408527=:33607 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Hi Stephan, On Thu, 10 Aug 2017, Stephan M?ller wrote: > Hi, > > This patch set adds the AF_ALG user space API to externalize the > asymmetric cipher API recently added to the kernel crypto API. ... > Changes v8: > * port to kernel 4.13 > * port to consolidated AF_ALG code > > Stephan Mueller (4): > crypto: AF_ALG -- add sign/verify API > crypto: AF_ALG -- add setpubkey setsockopt call > crypto: AF_ALG -- add asymmetric cipher > crypto: algif_akcipher - enable compilation > > crypto/Kconfig | 9 + > crypto/Makefile | 1 + > crypto/af_alg.c | 28 ++- > crypto/algif_aead.c | 36 ++-- > crypto/algif_akcipher.c | 466 ++++++++++++++++++++++++++++++++++++++++++++ > crypto/algif_skcipher.c | 26 ++- > include/crypto/if_alg.h | 7 +- > include/uapi/linux/if_alg.h | 3 + > 8 files changed, 543 insertions(+), 33 deletions(-) > create mode 100644 crypto/algif_akcipher.c > > -- > 2.13.4 The last round of reviews for AF_ALG akcipher left off at an impasse around a year ago: the consensus was that hardware key support was needed, but that requirement was in conflict with the "always have a software fallback" rule for the crypto subsystem. For example, a private key securely generated by and stored in a TPM could not be copied out for use by a software algorithm. Has anything come about to resolve this impasse? There were some patches around to add keyring support by associating a key ID with an akcipher socket, but that approach ran in to a mismatch between the proposed keyring API for the verify operation and the semantics of AF_ALG verify. AF_ALG is best suited for crypto use cases where a socket is set up once and there are lots of reads and writes to justify the setup cost. With asymmetric crypto, the setup cost is high when you might only use the socket for a brief time to do one verify or encrypt operation. Given the efficiency and hardware key issues, AF_ALG seems to be mismatched with asymmetric crypto. Have you looked at the proposed keyctl() support for crypto operations? Thanks, --0-998146653-1502408527=:33607--