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 12:56:08 +0100 [thread overview]
Message-ID: <CALrw=nGHDW=FZcVG94GuuX9AOBC-N5OC2aXiybfAro6E8VNzPQ@mail.gmail.com> (raw)
In-Reply-To: <ef47b718-8c6b-4711-9062-cc8b6c7dc004@enneenne.com>
On Tue, Sep 16, 2025 at 12:21 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>
> On 16/09/25 12:21, Ignat Korchagin wrote:
> > 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).
>
> I see, but if we consider shared secret support, for example, keyctl doesn't
> support ECDH, while AF_ALG allows you to choose whether to use DH or ECDH.
But this is exactly the point: unlike symmetric algorithms, where you
can just use any blob with any algorithm, you can't use an RSA key for
ECDH for example. That is, you cannot arbitrarily select an algorithm
for any key and the algorithm is a property attached to the key
itself. So if you "cast" a blob to an EC key, you would need to select
the algorithm at cast time and the implementation should validate if
the blob actually represents a valid EC key (with all the proper
checks, like if the key is an a big in and is less than the order
group etc). With AF_ALG you would need to do this validation for every
crypto operation, which is not very efficient at the very least.
> Furthermore, AF_ALG allows us to choose which driver actually performs the
> encryption operation!
This is indeed a limitation of the current keyctl interface, but again
- we probably should not select the algorithm here, but we should
consider extending it so the user can specify a particular crypto
driver/implementation.
> In my opinion, keyctl is excellent for managing key generation and access, but
> using AF_ALG for using them isn't entirely wrong even in the case of asymmetric
> keys and, in my opinion, is much more versatile.
>
> > 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.
>
> IMHO the fact that trusted keys are binary blobs is perfect for use with AF_ALG,
> where we can specify different algorithms to operate on. :)
>
> 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 11:56 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
2025-09-16 11:21 ` Rodolfo Giometti
2025-09-16 11:56 ` Ignat Korchagin [this message]
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=nGHDW=FZcVG94GuuX9AOBC-N5OC2aXiybfAro6E8VNzPQ@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).