linux-kernel - Re: [PATCH 0/3] Implementation of Ascon-Hash256

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] [day] [month] [year] [list]

Message-ID: <20251217040617.GA3424@sol>
Date: Tue, 16 Dec 2025 20:06:17 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: "Rusydi H. Makarim" <rusydi.makarim@...ptograf.id>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
	"David S. Miller" <davem@...emloft.net>,
	"Jason A. Donenfeld" <Jason@...c4.com>,
	Ard Biesheuvel <ardb@...nel.org>, linux-kernel@...r.kernel.org,
	linux-crypto@...r.kernel.org
Subject: Re: [PATCH 0/3] Implementation of Ascon-Hash256

On Wed, Dec 17, 2025 at 10:33:22AM +0700, Rusydi H. Makarim wrote:
> On 2025-12-17 01:02, Eric Biggers wrote:
> > On Tue, Dec 16, 2025 at 01:27:17PM +0700, Rusydi H. Makarim wrote:
> > > While no direct in-kernel use as of now
> > 
> > Thanks for confirming.  We only add algorithms when there is a real
> > user, so it's best to hold off on this for now.
> > 
> > - Eric
> 
> Rather than leaving this work idle, would it be better to move the
> implementation entirely into the Crypto API ?

No, that's actually the most problematic part because it would put it in
the name-based registry and become impossible to change later.

There's a large maintenance cost to supporting algorithms.  We've
learned this the hard way.  In the past the requirements to add new
algorithms to the kernel were much more relaxed, and as a result, the
Linux kernel community has ended up wasting lots of time maintaining
unused, unnecessary, or insecure code.

Just recently I removed a couple algorithms (keywrap and vmac).  Looking
back in more detail, there was actually never any use case presented for
their inclusion, and they were never used.  So all the effort spent
reviewing and maintaining that code was just wasted.  We could have just
never added them in the first place and saved tons of time.

So this is nothing about Ascon not being a good algorithm, but rather
we're just careful about adding unused code, as we don't want to repeat
past mistakes.  And as you've made clear, currently you'd like to add
the algorithm just for its own sake and there is no planned user --
which is concerning.  I'm not sure if this is a school project or what
not, but we don't really do that, sorry.  There has to be a clear
technical justification with an in-kernel use case.

- Eric