From: Rodolfo Giometti <giometti@enneenne.com>
To: Ignat Korchagin <ignat@cloudflare.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:21:02 +0200 [thread overview]
Message-ID: <ef47b718-8c6b-4711-9062-cc8b6c7dc004@enneenne.com> (raw)
In-Reply-To: <CALrw=nEadhZVifwy-SrFdEcrjrBxufVpTr0BSnnCJOODioE1WA@mail.gmail.com>
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.
Furthermore, AF_ALG allows us to choose which driver actually performs the
encryption operation!
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: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
2025-09-16 11:21 ` Rodolfo Giometti [this message]
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=ef47b718-8c6b-4711-9062-cc8b6c7dc004@enneenne.com \
--to=giometti@enneenne.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=ignat@cloudflare.com \
--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).