From: Ignat Korchagin <ignat@cloudflare.com>
To: Rodolfo Giometti <giometti@enneenne.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Eric Biggers <ebiggers@kernel.org>,
linux-crypto@vger.kernel.org,
"David S . Miller" <davem@davemloft.net>,
keyrings@vger.kernel.org, David Howells <dhowells@redhat.com>,
Lukas Wunner <lukas@wunner.de>
Subject: Re: [V1 0/4] User API for KPP
Date: Tue, 16 Sep 2025 11:21:19 +0100 [thread overview]
Message-ID: <CALrw=nEadhZVifwy-SrFdEcrjrBxufVpTr0BSnnCJOODioE1WA@mail.gmail.com> (raw)
In-Reply-To: <fc1459db-2ce7-4e99-9f5b-e8ebd599f5bc@enneenne.com>
On Tue, Sep 16, 2025 at 9:22 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>
> 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 generally find the AF_ALG API ugly to use, but I can see the use
case for symmetric algorithms, where one needs to encrypt/decrypt a
large stream in chunks. For asymmetric operations, like signing and
KPP it doesn't make much sense to go through the socket API. In fact
we already have an established interface through keyctl(2).
Now, in my opinion, the fundamental problem here is that we want to
use trusted keys as asymmetric keys, where currently they are just
binary blobs from a kernel perspective (so suitable only for symmetric
use). So instead of the AF_ALG extension we need a way to "cast" a
trusted key to an asymmetric key and once it is "cast" (or type
changed somehow) - we can use the established keyring interfaces both
for signatures and KPP. For example, what if we somehow extend the
add_key(2)/request_key(2) syscalls to be able to initialise an
asymmetric key from a trusted key payload instead of providing the
payload directly via a buffer (similar to how
ALG_SET_KEY_BY_KEY_SERIAL does it for symmetric keys for socket crypto
API)?
Ignat
> 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
next prev parent reply other threads:[~2025-09-16 10:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250915084039.2848952-1-giometti@enneenne.com>
[not found] ` <20250915145059.GC1993@quark>
[not found] ` <87f17424-b50e-45a0-aefa-b1c7a996c36c@enneenne.com>
2025-09-16 4:10 ` [V1 0/4] User API for KPP Herbert Xu
2025-09-16 8:22 ` Rodolfo Giometti
2025-09-16 10:21 ` Ignat Korchagin [this message]
2025-09-16 11:21 ` Rodolfo Giometti
2025-09-16 11:56 ` Ignat Korchagin
2025-09-16 12:33 ` Rodolfo Giometti
2025-09-16 12:43 ` Ignat Korchagin
2025-09-16 13:07 ` Rodolfo Giometti
2025-09-16 19:03 ` Simo Sorce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALrw=nEadhZVifwy-SrFdEcrjrBxufVpTr0BSnnCJOODioE1WA@mail.gmail.com' \
--to=ignat@cloudflare.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=giometti@enneenne.com \
--cc=herbert@gondor.apana.org.au \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=lukas@wunner.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).