From: Simo Sorce <simo@redhat.com>
To: Rodolfo Giometti <giometti@enneenne.com>,
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 15:03:22 -0400 [thread overview]
Message-ID: <70efab856f0940cba715572c417e0b249388da14.camel@redhat.com> (raw)
In-Reply-To: <ca36a11e-ca2e-41ee-b0d3-f56586d50fd4@enneenne.com>
On Tue, 2025-09-16 at 14:33 +0200, Rodolfo Giometti wrote:
> 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.
The only thing something like this allow is huge foot guns.
The current trend in cryptography circles is the exact opposite, ie
strong typing where keys are defined such that they can be used for a
single purpose even when the general mechanisms allows different
operations.
Ie even if an algorithm that allows both encryption and signing the key
is specified to be used only for one or the other operation with
metadata that accompanies they key itself at all times
so the cryptographic implementation can enforce the binding and fail
the un-permitted operation.
In general using random blobs as asymmetric keys is just not possible,
the size alone is no guarantee you have a valid key, so you would have
to spend significant amount of CPU cycles to validate that the blob is
a valid key for the given algorithm, rendering any HW acceleration
effectively pointless by the time you cross all the layers, context
switch back and forth from the kernel, validate the blobs and all.
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
prev parent reply other threads:[~2025-09-16 19:03 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
2025-09-16 13:07 ` Rodolfo Giometti
2025-09-16 19:03 ` Simo Sorce [this message]
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=70efab856f0940cba715572c417e0b249388da14.camel@redhat.com \
--to=simo@redhat.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=giometti@enneenne.com \
--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).