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

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Dec 31, 2025 at 04:20:40PM +0700, Rusydi H. Makarim wrote:
> 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.

It's no different from any other Linux kernel feature.

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

I haven't actually seen any demand for alternative hash functions in
fs-verity.  Though, dm-verity is sometimes used with BLAKE2b for the
reason you mention.  But this also means the kernel crypto subsystem
already has alternatives to SHA-256.  With that being the case, it's not
clear that adding another one would bring anything new to the table.
How does the performance compare with BLAKE2s and BLAKE2b?

- Eric