[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9pPWGKAdm83wKhc3iHCjgZ8gOtZnt=+6x5V6D1prMb2Gw@mail.gmail.com>
Date: Mon, 24 Nov 2025 19:06:20 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: David Howells <dhowells@...hat.com>
Cc: Eric Biggers <ebiggers@...nel.org>, 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 6:25 PM David Howells <dhowells@...hat.com> wrote:
>
> Eric Biggers <ebiggers@...nel.org> 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.
Jason
Powered by blists - more mailing lists