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

[David Laight]

On Thu, 1 Jan 2026 13:06:02 -0800
Eric Biggers <ebiggers@xxxxxxxxxx> wrote:

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

FYI blake2b (64bit) runs at a little under 3 clocks/byte fully unrolled
on my Zen5 cpu (I've not tried in Intel cpu yet, and need a newer one).
With the main loop not unrolled it is about 4 clocks/byte.
(I've not yet tried to see why it makes that much difference.)
But the 'elephant in the room' is the 'cold cache' case.
The break-even point is somewhere between 4k and 8k bytes
(and that is excluding the effect of evicting other code from the I-cache).

Blake2s (32bit) will run at half the speed - provided the cpu has
enough registers.
Blake2s and blake2b really need a few more than 16 registers - which 32bit
x86 doesn't have.

So something with a much smaller I-cache footprint might be useful.

	David


> 
> - Eric
>