Message-ID: <CALrw=nFYE8yP6ZjVmDCv36g4zHBtJZet1m55Rkv3firv=-QB3w@mail.gmail.com>
Date: Tue, 25 Nov 2025 20:51:51 +0000
From: Ignat Korchagin <ignat@...udflare.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: David Howells <dhowells@...hat.com>, Herbert Xu <herbert@...dor.apana.org.au>, 
	Luis Chamberlain <mcgrof@...nel.org>, Petr Pavlu <petr.pavlu@...e.com>, 
	Daniel Gomez <da.gomez@...nel.org>, Sami Tolvanen <samitolvanen@...gle.com>, 
	"Jason A . Donenfeld" <Jason@...c4.com>, Ard Biesheuvel <ardb@...nel.org>, Stephan Mueller <smueller@...onox.de>, 
	Lukas Wunner <lukas@...ner.de>, linux-crypto@...r.kernel.org, keyrings@...r.kernel.org, 
	linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 2/9] crypto: Add ML-DSA/Dilithium verify support

On Tue, Nov 25, 2025 at 8:24 PM Eric Biggers <ebiggers@...nel.org> wrote:
>
> On Tue, Nov 25, 2025 at 10:10:18AM +0000, Ignat Korchagin wrote:
> > Hi all,
> >
> > On Mon, Nov 17, 2025 at 5:11 PM Eric Biggers <ebiggers@...nel.org> wrote:
> > >
> > > On Mon, Nov 17, 2025 at 02:55:51PM +0000, David Howells wrote:
> > > >  lib/crypto/Kconfig                            |   1 +
> > > >  lib/crypto/Makefile                           |   2 +
> > > >  lib/crypto/mldsa/Kconfig                      |  29 ++
> > > >  lib/crypto/mldsa/Makefile                     |  20 +
> > > >  lib/crypto/mldsa/crypto_mldsa_44.c            | 166 ++++++++
> > > >  lib/crypto/mldsa/crypto_mldsa_65.c            | 166 ++++++++
> > > >  lib/crypto/mldsa/crypto_mldsa_87.c            | 166 ++++++++
> > > >  lib/crypto/mldsa/dilithium.h                  | 304 ++++++++++++++
> > > >  lib/crypto/mldsa/dilithium_44.c               |  33 ++
> > > >  lib/crypto/mldsa/dilithium_44.h               | 291 ++++++++++++++
> > > >  lib/crypto/mldsa/dilithium_65.c               |  33 ++
> > > >  lib/crypto/mldsa/dilithium_65.h               | 291 ++++++++++++++
> > > >  lib/crypto/mldsa/dilithium_87.c               |  33 ++
> > > >  lib/crypto/mldsa/dilithium_87.h               | 291 ++++++++++++++
> > > >  lib/crypto/mldsa/dilithium_common.c           | 117 ++++++
> > > >  lib/crypto/mldsa/dilithium_debug.h            |  49 +++
> > > >  lib/crypto/mldsa/dilithium_ntt.c              |  89 +++++
> > > >  lib/crypto/mldsa/dilithium_ntt.h              |  35 ++
> > > >  lib/crypto/mldsa/dilithium_pack.h             | 119 ++++++
> > > >  lib/crypto/mldsa/dilithium_poly.c             | 377 ++++++++++++++++++
> > > >  lib/crypto/mldsa/dilithium_poly.h             | 181 +++++++++
> > > >  lib/crypto/mldsa/dilithium_poly_c.h           | 141 +++++++
> > > >  lib/crypto/mldsa/dilithium_poly_common.h      |  35 ++
> > > >  lib/crypto/mldsa/dilithium_polyvec.h          | 343 ++++++++++++++++
> > > >  lib/crypto/mldsa/dilithium_polyvec_c.h        |  81 ++++
> > > >  lib/crypto/mldsa/dilithium_reduce.h           |  85 ++++
> > > >  lib/crypto/mldsa/dilithium_rounding.c         | 128 ++++++
> > > >  lib/crypto/mldsa/dilithium_service_helpers.h  |  99 +++++
> > > >  lib/crypto/mldsa/dilithium_signature_c.c      | 279 +++++++++++++
> > > >  lib/crypto/mldsa/dilithium_signature_c.h      |  37 ++
> > > >  lib/crypto/mldsa/dilithium_signature_impl.h   | 370 +++++++++++++++++
> > > >  lib/crypto/mldsa/dilithium_type.h             | 108 +++++
> > > >  lib/crypto/mldsa/dilithium_zetas.c            |  68 ++++
> > > >  .../mldsa/signature_domain_separation.c       | 204 ++++++++++
> > > >  .../mldsa/signature_domain_separation.h       |  30 ++
> > > >  35 files changed, 4801 insertions(+)
> > >
> > > Over the past week I've been starting to review this massive addition.
> > >
> > > I don't think this is on the right track.  This implementation is really
> > > messy, with lots of unused functionality and unnecessary abstractions,
> > > and code that doesn't follow kernel conventions.
> > >
> > > In comparison, BoringSSL has an entire implementation of ML-DSA,
> > > *including key generation and signing*, in a bit over 3000 lines in one
> > > file.  But about half of that code is specific to key generation or
> > > signing, which the kernel doesn't need, so in principle
> > > verification-only shouldn't be much more than a thousand.  I find it to
> > > be much easier to understand than leancrypto as well.
> > >
> > > Historically we've had a lot of problems with people integrating code
> > > from external sources into the kernel, like mpi, with properly "owning"
> > > it because they feel like it's not their code and someone else is
> > > responsible.  I feel like that's going to be a big problem here.
> > >
> > > I think we can do better here and put together a smaller implementation
> > > for the kernel that we'll actually be able to maintain.
> >
> > I was thinking about this lately for some time - even put forward a
> > small discussion proposal for upcoming Plumbers (which wasn't accepted
> > unfortunately). Should we consider somehow safely "outsourcing" at
> > least some (asymmetric - potentially slow anyway) crypto
> > implementations to userspace? Something similar to
> > request_module/request_firmware/request_key usermode helpers or an
> > io_uring interface or a crypto socket? This way we can bring any
> > well-maintained crypto library (and even multiple ones) to the kernel:
> >   * it can have any software license
> >   * can be written in any programming language
> >   * can use architecture vector instructions more easily
> >   * can have any certifications out of the box (looking at you - FIPS)
> >   * distros would have the ability to plug their own
> >   * maybe it can even do private key crypto (which I personally would
> > really like more support of and it would be acceptable to Herbert)
> >
> > Given the past experience of RSA and mpi - it is not that difficult to
> > port something to the kernel, but quite hard to maintain it over time
> > in a secure manner. With a userspace approach the kernel can
> > piggy-back on proven vendors like any other piece of open source
> > software out there.
> >
> > I understand that there probably still be a need for some in-kernel
> > crypto, so the proposal here is not to fully replace things, but
> > rather complement the current offerings with an interface, which could
> > enable faster adoption of newer (and more secure versions of existing)
> > crypto algorithms.
>
> The performance cost of that would be very high, so it would only have
> any chance at possibly being reasonable for some of the asymmetric
> algorithms.  It would also introduce reliability issues.

Yes, definitely. For the userspace approach I would think only
asymmetric algorithms. For "reliability issues" I don't know if it is
a problem of the kernel itself, or the user/admin of the system. The
kernel supports network-based and userspace-based filesystems and
userspace-based block devices even and users successfully use them as
root filesystems. Surely a small crypto agent running locally would
not be worse than this.

> I'll also note that the main reason that people seem to want private key
> operations in the kernel is for the keyctl() UAPIs for userspace, which
> is already a bad idea.  So I guess we end up with userspace calling into

Can you elaborate on this? (I want to understand for myself). I think
keyctl UAPIs for private keys are a great idea and allows building
good (and relatively simple) secure architectures. So I want to enable
more of this, not less.

> the kernel, which calls back into userspace to use some userspace crypto
> library which the original userspace program refused to use in the first
> place for some reason?  It makes no sense to me, sorry.

It does make sense for userspace programs (apart from potential keyctl
users which don't want to have private keys in their address space),
but what about in-kernel services? How is this fundamentally different
from request_module, for example? If the kernel needs a module, it
tells userspace and there is a userspace helper, which provides it. It
is an "external service" to the kernel. So crypto can be another
service. After all, microkernels have been doing this forever.

> There is the opportunity to share more code with userspace projects at
> the source code level.  Just it doesn't always work out due to different
> languages, licences, requirements, conventions, and implementation
> qualities.  For ML-DSA verification I didn't see a good alternative to
> just writing it myself.  But in other cases a different conclusion could
> be reached.  The kernel uses a lot of the assembly files from

What about sharing code at the binary level? At Cloudflare we have an
internal kernel crypto driver, which just imports its implementation
directly from compiled BoringSSL into the kernel space. So in the end
it is fully in-kernel and fast, but the advantage is that the code
itself comes from BoringSSL (and we regularly update it). There are
rough edges of course (like using vector instructions, different stack
alignment etc), but it kinda works and I think with some investment we
can make such an approach upstream. We even considered open sourcing
it, but not sure about licensing as we effectively have a bespoke
"module loader" for BoringSSL, which is Apache (I hope James is right
that Apache may be considered GPL-2 compatible in the future).

While I think such an approach is much more technically challenging,
it provides "best of both worlds" by having fast in-kernel crypto
directly from established libraries.

> CRYPTOGAMS, for example, and some of the Curve25519 code (including
> formally verified code) is imported from other sources.
>
> - Eric

Ignat

Powered by blists - more mailing lists