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

["Rusydi H. Makarim" <rusydi.makarim@kriptograf.id>]

On Tue, Dec 16, 2025 at 08:06:17PM -0800, Eric Biggers wrote:
> 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.

Looking at both lib/crypto/ and crypto/ directories, I initially did not
have an impression that mandatory in-kernel use of a cryptographic hash
function is a strict requirement for its inclusion in the linux kernel.
Such requirement is also not mentioned in the section "Adding New Algorithms"
of https://docs.kernel.org/crypto/api-intro.html. Now that you give a
historical context of it, so I completely understand your point.

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

I am an external contractor working for a client that asked an implementation
of Ascon family of algorithms in the linux kernel, but did not disclose
its use case.

Just a heads up: I will send v2 of this patch to fix a compilation error
and a build warning. I will also send a separate patch that implements
Ascon-XOF128 and Ascon-CXOF128. I hope you understand that I simply have to
finish the tasks assigned to me, and these are not meant as an attempt to
put pressure for their acceptance.

On the other hand, I am also keen to see its possible use cases in the linux
kernel. Ascon-Hash256 specifically can be an alternative to SHA-256. For
instance, it can be an additional option of hash function in fs-verity for
processors with no SHA256 dedicated instructions. If that something that
interests you, I am open for further discussion.

> - Eric
>

Best,
Rusydi