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 14:33:43 +0200 [thread overview]
Message-ID: <ca36a11e-ca2e-41ee-b0d3-f56586d50fd4@enneenne.com> (raw)
In-Reply-To: <CALrw=nGHDW=FZcVG94GuuX9AOBC-N5OC2aXiybfAro6E8VNzPQ@mail.gmail.com>
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!
>> 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:36 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 [this message]
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=ca36a11e-ca2e-41ee-b0d3-f56586d50fd4@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).