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 13:43:36 +0100 [thread overview]
Message-ID: <CALrw=nFSsFYtz0vo7fGyBFCZ+HGHPGSVvoDECiSWfSVbPz4OeA@mail.gmail.com> (raw)
In-Reply-To: <ca36a11e-ca2e-41ee-b0d3-f56586d50fd4@enneenne.com>
On Tue, Sep 16, 2025 at 1:33 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>
> On 16/09/25 13:56, Ignat Korchagin wrote:
> > 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).
>
> I understand your point; however, I believe that allowing the AF_ALG developer
> to use a generic data blob (of the appropriate size, of course) as a key is more
> versatile and allows for easier implementation of future extensions.
>
> > With AF_ALG you would need to do this validation for every
> > crypto operation, which is not very efficient at the very least.
>
> I think this might be acceptable if we consider the security we gain compared to
> using any existing user-space implementation!
I don't think the alternative approach I proposed compromises on
security. That is it has the same security level (using a trusted key
to do ECDH without exposing it to userspace). Unless I'm missing
something?
> >> 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.
>
> Furthermore, I think one solution isn't mutually exclusive. So, why not give the
> developer the freedom to choose which interface to use? ;)
>
> Furthermore, there's nothing stopping us from strengthening the current AF_ALG
> support so that it can also be used well with asymmetric keys.
>
> >> 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
>
>
> --
> 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 12:43 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
2025-09-16 12:33 ` Rodolfo Giometti
2025-09-16 12:43 ` Ignat Korchagin [this message]
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=nFSsFYtz0vo7fGyBFCZ+HGHPGSVvoDECiSWfSVbPz4OeA@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).