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 for Android: free password hash cracker in your pocket

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

Message-ID: <1232848.1762959317@warthog.procyon.org.uk>
Date: Wed, 12 Nov 2025 14:55:17 +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:

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

It's not that simple, as it turns out.  Various of the API structures are
dependent on the strength-specific #include magic stuff.
dilithium_{44,65,87}.h (or parts thereof) are used in the generation of those
structs.

Now, I can move all that stuff into one header file in include/crypto/, but
it's exposing a lot of the internals.

It also requires the caller to do some of the work in expanding the public key
and signature into those API structs, so it's probably better to wrap the
dilithium.h API to a simpler one with just init, update, fini and all-in-one
functions and have the crypto_sig interface call those (the helper functions
are pretty much the wrappers I need anyway).

David