From: Ignat Korchagin <ignat@cloudflare.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Stefan Berger <stefanb@linux.ibm.com>,
Vitaly Chikunov <vt@altlinux.org>,
David Howells <dhowells@redhat.com>,
linux-crypto@vger.kernel.org, keyrings@vger.kernel.org,
Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH v2 3/4] crypto: ecdsa - Fix enc/dec size reported by KEYCTL_PKEY_QUERY
Date: Sun, 9 Feb 2025 13:16:50 +0000 [thread overview]
Message-ID: <CALrw=nEyTeP=6QcdEvaeMLZEq_pYB9WO=vFt2K2FuJ1TEmP1Lg@mail.gmail.com> (raw)
In-Reply-To: <Z6iRssS26IOjWbfx@wunner.de>
On Sun, Feb 9, 2025 at 11:29 AM Lukas Wunner <lukas@wunner.de> wrote:
>
> On Sun, Feb 09, 2025 at 05:58:07PM +0800, Herbert Xu wrote:
> > On Sun, Feb 02, 2025 at 08:00:53PM +0100, Lukas Wunner wrote:
> > > KEYCTL_PKEY_QUERY system calls for ecdsa keys return the key size as
> > > max_enc_size and max_dec_size, even though such keys cannot be used for
> > > encryption/decryption. They're exclusively for signature generation or
> > > verification.
> > >
> > > Only rsa keys with pkcs1 encoding can also be used for encryption or
> > > decryption.
> > >
> > > Return 0 instead for ecdsa keys (as well as ecrdsa keys).
> >
> > I think we should discuss who is using these user-space APIs
> > before doing any more work on them. The in-kernel asymmetric
> > crypto code is not safe against side-channel attacks. As there
> > are no in-kernel users of private-key functionality, we should
> > consider getting rid of private key support completely.
> >
> > As it stands the only user is this user-space API.
Please don't! Keyrings + asymmetric crypto is a great building block
for secure architectures. If anything we want more of this, not less.
We can get rid of various ssh-agents and anything that tries to keep
cryptographic material in a separate address space. It is the most
straightforward way to avoid heartbleed-like vulnerabilities [1].
Before this we had to design whole solutions just to separate private
keys from network facing code [2].
Now, in-kernel RSA implementation is indeed a downside, but again -
one could swap internal implementations and provide their own. We have
an internal BoringSSL-based in-kernel crypto driver (which I hope to
open source one day) which avoids this problem. I remember there was
also some work to expose TPMs through the keyrings API, which would
solve this problem as well [3]. In general this API allows adopting
various platform crypto chips very easily and should be encouraged. I
made a presentation explaining why this API is much better for TPMs,
for example, rather than directly using /dev/tpm from userspace [4].
On the topic of better RSA implementation: last year we've been
working with folks from a company called Cryspen with the hope to
produce better and even formally-verified RSA and ECDSA
implementations for the Linux kernel (based on their HACL open source
library). We got pretty good results [5] for RSA: tl;dr signing is
faster than the current in-kernel code, but verification is slower
(not a problem as we can use verification from the in-kernel
implementation as we don't care about side channels there).
Unfortunately the work was deprioritised this year, but if there is
enough interest from the kernel community (and hopefully support to
make the code more "kernel-integration friendly) I can try to make a
case to re-prioritise this again.
> Personally I am not using this user-space API, so I don't really
> have a dog in this fight. I just noticed the incorrect output
> for KEYCTL_PKEY_QUERY and thought it might be better if it's fixed.
>
> One user of this API is the Embedded Linux Library, which in turn
> is used by Intel Wireless Daemon:
>
> https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/key.c
> https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/src/eap-tls.c
>
> Basically IWD seems to be invoking the kernel's Key Retention Service for
> EAP authentication. It's still maintained and known to have active users,
> so removing the user-space keyctl ABI would definitely cause breakage.
>
> I've just checked for other reverse dependencies of the "libell0" package
> on Debian, it lists "bluez" and "mptcpd" but looking at their source code
> reveals they're not using the l_key_*() functions, so they would not be
> affected by removal.
>
> There's a keyring package for go, so I suppose there may be go applications
> out there using it:
>
> https://pkg.go.dev/pault.ag/go/keyring
>
> Then there's the keyutils library...
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git
>
> ...and listing the reverse dependencies for "libkeyutils1" on Debian
> reveals a slew of packages which are using it:
>
> gdm3 samba-libs sssd-common python3-keyutils nfs-common ndctl
> mokutil kstart libkrb5-3 kafs-client ima-evm-utils ceph-common
> libecryptfs1 ecryptfs-utils cifs-utils
>
> And "python3-keyutils" in turn has this reverse dependency:
>
> udiskie
>
> Finally, folks at cloudflare praised the kernel's Key Retention Service
> and encouraged everyone to use it... :)
>
> https://blog.cloudflare.com/the-linux-kernel-key-retention-service-and-why-you-should-use-it-in-your-next-application/
>
> In short, it doesn't seem trivial to drop this user-space API.
>
> Thanks,
>
> Lukas
Thanks,
Ignat
[1]: https://heartbleed.com/
[2]: https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/
[3]: https://lore.kernel.org/lkml/97dd7485-51bf-4e47-83ab-957710fc2182@linux.ibm.com/T/
[4]: https://youtu.be/g8b4K5FQUj8?si=yY8mkoRuyE_SKBjh
[5]: https://md.cryspen.com/cf_hacs_kernel
next prev parent reply other threads:[~2025-02-09 13:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-02 19:00 [PATCH v2 0/4] ecdsa KEYCTL_PKEY_QUERY fixes Lukas Wunner
2025-02-02 19:00 ` [PATCH v2 1/4] crypto: sig - Prepare for algorithms with variable signature size Lukas Wunner
2025-02-02 19:00 ` [PATCH v2 2/4] crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP() Lukas Wunner
2025-02-03 5:11 ` Lukas Wunner
2025-02-02 19:00 ` [PATCH v2 3/4] crypto: ecdsa - Fix enc/dec size reported by KEYCTL_PKEY_QUERY Lukas Wunner
2025-02-09 9:58 ` Herbert Xu
2025-02-09 11:29 ` Lukas Wunner
2025-02-09 13:16 ` Ignat Korchagin [this message]
2025-02-10 7:54 ` Herbert Xu
2025-02-10 18:53 ` Lukas Wunner
2025-02-10 20:29 ` Lukas Wunner
2025-02-11 9:16 ` Herbert Xu
2025-02-16 4:19 ` Herbert Xu
2025-02-16 10:45 ` Lukas Wunner
2025-03-02 7:47 ` Herbert Xu
2025-03-02 9:25 ` Lukas Wunner
2025-03-02 10:11 ` Herbert Xu
2025-03-15 14:37 ` Lukas Wunner
2025-03-17 9:37 ` Herbert Xu
2025-03-17 9:40 ` Herbert Xu
2025-02-02 19:00 ` [PATCH v2 4/4] crypto: ecdsa - Fix NIST P521 key " Lukas Wunner
2025-02-09 10:25 ` [PATCH v2 0/4] ecdsa KEYCTL_PKEY_QUERY fixes Herbert Xu
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=nEyTeP=6QcdEvaeMLZEq_pYB9WO=vFt2K2FuJ1TEmP1Lg@mail.gmail.com' \
--to=ignat@cloudflare.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=ebiggers@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=stefanb@linux.ibm.com \
--cc=vt@altlinux.org \
/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).