From: Stephan =?ISO-8859-1?Q?M=FCller?= Subject: Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API Date: Fri, 11 Aug 2017 08:30:23 +0200 Message-ID: <4460438.43jVvca0Xd@positron.chronox.de> References: <26359147.tCiuJ5s8mz@positron.chronox.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Mat Martineau , Herbert Xu , Linux Crypto Mailing List , dhowells@redhat.com To: Marcel Holtmann Return-path: Received: from mail.eperm.de ([89.247.134.16]:58518 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750909AbdHKGaZ (ORCPT ); Fri, 11 Aug 2017 02:30:25 -0400 In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: Am Freitag, 11. August 2017, 07:13:30 CEST schrieb Marcel Holtmann: Hi Marcel, > > > > 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? > we have also seen hardware now where the private key will never leave the > crypto hardware. They public and private key is only generated for key > exchange purposes and later on discarded again. Asymmetric ciphers are > really not a good fit for AF_ALG and they should be solely supported via > keyctl. Thanks for the reminder. I have looked at that but I am unsure about whether this one covers asym crypto appropriately, too. The issue is that some hardware may only offer accelerators without a full blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others). How do you propose to cover raw primitives with keyctl? Ciao Stephan