Message-ID: <CALrw=nG6X5Opjb1H4VVzCNpJ4QtmHUK3nQ1XQ5GKMvnE9NnZsQ@mail.gmail.com>
Date: Tue, 25 Nov 2025 10:10:18 +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

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.

> - Eric

Ignat

Powered by blists - more mailing lists