Message-ID: <20251125202419.GB3061247@google.com>
Date: Tue, 25 Nov 2025 20:24:19 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: Ignat Korchagin <ignat@...udflare.com>
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 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.

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
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.

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
CRYPTOGAMS, for example, and some of the Curve25519 code (including
formally verified code) is imported from other sources.

- Eric

Powered by blists - more mailing lists