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