linux-kernel - Re: [PATCH v7 2/8] crypto: Add ML-DSA/Dilithium verify support

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: <62630.1762511649@warthog.procyon.org.uk>
Date: Fri, 07 Nov 2025 10:34:09 +0000
From: David Howells <dhowells@...hat.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: 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>,
    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 v7 2/8] crypto: Add ML-DSA/Dilithium verify support

Eric Biggers <ebiggers@...nel.org> wrote:

> On Thu, Nov 06, 2025 at 05:44:46PM +0000, David Howells wrote:
> > The interface to this code is through the crypto_sig API as the PKCS#7 code
> > wants to use that rather than calling it directly.  As such, I've placed it
> > in crypto/ rather than lib/crypto/.  Only the verification hooks are
> > implemented; the signing hooks return an error.
> 
> As I mentioned before
> (https://lore.kernel.org/linux-crypto/20250613170456.GA1284@sol/), this
> code should go in lib/crypto/.  There seems to be a clean API in
> crypto/ml_dsa/dilithium.h already.  Just make that the library API.

Fine.  Is it ever likely to be used directly, I wonder?

There is a downside of moving stuff to lib/crypto/: dynamically loadable
algorithms now need two modules instead of one.  For initial module signing,
granted, the algorithms for that must be built in.

> If "crypto_sig" support is really needed too, then put that in
> crypto/ml-dsa.c, built on top of the library API.  It's not clear the
> crypto_sig support is very useful, though.  For one, you had to add
> ML-DSA specific logic to the calling code anyway (see "pkcs7: Allow the
> signing algo to calculate the digest itself").

The actual signature check still goes through the same code path as everything
else, so crypto_sig will remain the API.  Otherwise I have to basically
reimplement crypto_sig inside crypto/asymmetric_keys/, including the on-demand
algorithm loading.

David