linux-kernel - Re: [PATCH v10 5/8] crypto: Add ML-DSA crypto

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251124202702.GA43598@google.com>
Date: Mon, 24 Nov 2025 20:27:02 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: "Jason A. Donenfeld" <Jason@...c4.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>,
	Ard Biesheuvel <ardb@...nel.org>,
	Stephan Mueller <smueller@...onox.de>,
	Lukas Wunner <lukas@...ner.de>,
	Ignat Korchagin <ignat@...udflare.com>,
	linux-crypto@...r.kernel.org, keyrings@...r.kernel.org,
	linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v10 5/8] crypto: Add ML-DSA crypto_sig support

On Mon, Nov 24, 2025 at 09:10:33PM +0100, Jason A. Donenfeld wrote:
> On Mon, Nov 24, 2025 at 8:54 PM David Howells <dhowells@...hat.com> wrote:
> > > > > Still not really sure what the point is.  There's only one user of
> > > > > crypto_sig, and it could just call the ML-DSA functions directly.
> > > >
> > > > Is it your aim to kill off the crypto/ dir and all the (old) crypto API?
> > >
> > > Probably entirely killing off the old API is going to be fraught
> > > because its abstraction has leaked out to userspace. But to the extent
> > > we can minimize its use over time, I think that's a good thing. Even
> > > for crypto usages that generalize to a few different ciphers of one
> > > variety or another, I think being explicit about which ciphers and
> > > having purpose-built dispatchers is usually a better route.
> >
> > How are you proposing handling the autoloading feature of the old API?
> 
> I don't know. Not all features will have direct replacements. Not all
> usages will be replaced. Not all use cases benefit from being
> replaced. You asked if it was an "aim." I replied by telling you that
> I think killing it is going to be difficult, but that over time, usage
> will decline. I think that'll be a natural thing. For now, when
> something uses the library API, there's a pretty easy and obvious case
> to be made for it, as there are still such obvious low hanging use
> cases. I suppose in a while, we might run out of those perhaps. But
> that hasn't happened yet, I guess.
> 
> Jason

+1 to what Jason said.  The traditional API generally isn't going away.
However, there's no need to add new functionality to it when the library
is a better fit.  The crypto_sig abstraction doesn't seem very helpful,
since it was added only recently and has only one user (public_key).

The traditional crypto API's dynamic loading by name also tends to be
more harmful than helpful.  Linux users and distros keep running into
problems where algorithms aren't available in the initramfs when they
should be, or where the slow generic code is used instead of the
optimized code.  The direct linking finally just fixes that.

You may also still be thinking of the ML-DSA code as something
heavyweight.  I reduced it to under 4 KB of object code.

It should also become the recommended algorithm anyway, right?

Either way, 4 KB seems awfully small to be wanting to be dynamically
loaded.  Last year I shrunk the x86_64 AES-GCM code (which most Linux
distros build in to avoid the dynamic loading issues) by over 200 KB.
No one even seemed to care that much...  We can add a lot of stuff
before we're even back to where we were before that.

- Eric