From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpcmd02102.aruba.it (smtpcmd02102.aruba.it [62.149.158.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C486928C87C for ; Tue, 16 Sep 2025 08:25:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.149.158.102 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758011158; cv=none; b=QBCL8vEJrfjaCSH4zdixPfqs2ZNBFcfbX91jC3aBxSRXIc406sk5TpVQt5p16289kMINz9+b4AI3H4G2yWimVMdfPMZZOpxbXkvVCILOmTFXGPi6TQ+G7bTo/FWFCgL91Cbczb1KKp9Q9mAA/Aim5zeV4bNXZpMeMbPTd9r1j08= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758011158; c=relaxed/simple; bh=0xHfYEY3U6CDYFIi4LYTmBP7CI66AU2qyZG8HO0xiPw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=N1fx/qBC0+kDK6ptBYM8yV5TX4HQSHahmx0opHQi6IejODJpmtF61R8IfUtR7+6jCxk9/Y0+UsjsTQIFzPXhslCIncPjcK8E8JJAaKhjkLGJrBuF9pE1BqcuSf4lvILr+oKGtuUeiTovjAvI+p/A1X/rIPtLAqQCRW6UkYy3Oho= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=enneenne.com; spf=pass smtp.mailfrom=enneenne.com; dkim=pass (2048-bit key) header.d=aruba.it header.i=@aruba.it header.b=UEOv1bMQ; arc=none smtp.client-ip=62.149.158.102 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=enneenne.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=enneenne.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=aruba.it header.i=@aruba.it header.b="UEOv1bMQ" Received: from [192.168.1.58] ([79.0.204.227]) by Aruba SMTP with ESMTPSA id yQxZuEUb3loieyQxZuaXbq; Tue, 16 Sep 2025 10:22:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it; s=a1; t=1758010967; bh=0xHfYEY3U6CDYFIi4LYTmBP7CI66AU2qyZG8HO0xiPw=; h=Date:MIME-Version:Subject:To:From:Content-Type; b=UEOv1bMQQ+RImCi2Rb/+bJk9ZjB0GuoVPJw0+CiVNN6D+18hZdgcx+d2rYk1K4DUG 4gqJ8ty3OmEJSeGNwxhtWr0GjiRL+dBEtBJEuvx6j9JBsPuX5wdpLn7bSH3fWHmXt0 LnDlKemDCn80PatL+3SI1mjQmj6MttXj2P17UeA3ZV4Wghe8ocmF51GzSMQ0m2ZPVh q8Hvre8H/4zI/ZZGF70pk+bV9sn2s+wG9aMsVZd0H58f7xhos2rZ1er5o/cDsTYtV4 IuScrdASIJ38DE+Wb8AK6dNc/ub+RoFMmjdQyeCbsHWTnmNPOs+/7kdVH3+QpJkEaa LmgC47MyuIVcw== Message-ID: Date: Tue, 16 Sep 2025 10:22:45 +0200 Precedence: bulk X-Mailing-List: linux-crypto@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [V1 0/4] User API for KPP Content-Language: en-US To: Herbert Xu Cc: Eric Biggers , linux-crypto@vger.kernel.org, "David S . Miller" , keyrings@vger.kernel.org, David Howells , Lukas Wunner , Ignat Korchagin References: <20250915084039.2848952-1-giometti@enneenne.com> <20250915145059.GC1993@quark> <87f17424-b50e-45a0-aefa-b1c7a996c36c@enneenne.com> From: Rodolfo Giometti In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfKtUpiwpljX/5MMPsGZCvOo4KkAe2n3nmZxPezNVocF86QlDDyZiRDpQmr7cW+70dQcSCjrijyyatTlzyCGgWdcEFju9x+W1csd/+8RnPQrPmVsybDqr BVqlQdO8G1qzcZ06zu89XbgqEIq2zOPGMSRYtOxMV5WMKwsd9ddC3Hc5upgPis1Fgr101IrUswaPgJI2PV+CtXT2t6gjZ3GJzBYCpbLOEqKdjJQhgaH48/NZ obfqV1oOj15qiPgWktOakQlv+w0JQ8lSp6KlmVT+SUaoD5ez40syrKDEhkVvWnwQGzsBnEzfsw+91zN03a4/JDRgdUwv7S5pnkPwS3wkWeNzcRXIeT8xDDE3 hrEKRkYO2WTBFNdaL1DQF+3Jd15XfQdOLlG4/FJnUgroAzId4b4c1acdeNL7yzx+qzu5gIxx On 16/09/25 06:10, Herbert Xu wrote: > On Mon, Sep 15, 2025 at 05:47:56PM +0200, Rodolfo Giometti wrote: >> >> The main purpose of using this implementation is to be able to use the >> kernel's trusted keys as private keys. Trusted keys are protected by a TPM >> or other hardware device, and being able to generate private keys that can >> only be (de)encapsulated within them is (IMHO) a very useful and secure >> mechanism for storing a private key. > > If the issue is key management then you should be working with > David Howell on creating an interface that sits on top of the > keyring subsystem. > > The Crypto API doesn't care about keys. No, the problem concerns the use of the Linux keyring (specifically, trusted keys and other hardware-managed keys) with cryptographic algorithms. From a security standpoint, AF_ALG and keyctl's trusted keys are a perfect match to manage secure encryption and decryption, so why not do the same with KPP operations (or other cryptographic operations)? I know there might be issues with allowing user space to use this interface, but: 1) I think this mechanism can get its best when implemented in hardware, and 2) (hey!) we're developers who know what they're doing! :) This patch series is just a sample of the improvements I'd like to make on this front. Please tell me if you don't intend to add these mechanisms to the kernel at all, or if I have any chances, so I can decide whether to proceed or stop here. Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming