Re: [PATCH v4 1/3] crypto: ti - Add support for SHA224/256/384/512 in DTHEv2 driver

[T Pratham]

On 6/5/26 16:29, Herbert Xu wrote:
> On Fri, Jun 05, 2026 at 04:11:49PM +0530, T Pratham wrote:
>>
>> .cra_flags sets CRYPTO_AHASH_ALG_BLOCK_ONLY and
>> CRYPTO_AHASH_ALG_FINAL_NONZERO flags. An update of 64 bytes will do an
>> update of block size and carry over at least one byte to final. We
>> always go into this if block when there is non-zero data coming into update.
> 
> For AHASH_BLOCK_ONLY algorithms, the export format must be identical
> between different implementations.
> 
> Therefore FINAL_NONZERO cannot be used for only one implementation
> since the user can import the partial state from a different
> implementation which does not have FINAL_NONZERO set.
> 
> For sha you cannot use FINAL_NONZERO since the generic implementation
> doesn't use it.
> 
> Cheers,

Thanks for letting me know of the export format constraint.

However, this sounds contradictory to the stated purpose of the flag
itself. Commit 7650f826f7b2 ("crypto: shash - Handle partial blocks in
API"), in which you introduced FINAL_NONZERO, says:

"This will come in handy when this is extended to ahash where hardware
often can't deal with a zero-length final."

This is exactly the case for DTHEv2 hashing engine hardware. Along with
this, using BLOCK_ONLY is also necessary for DTHEv2 to delegate the
partial block management to the crypto layer. So you can see that most
hardware face both these constraints together. The above commit gives
the impression of solving both these issues for hardware hash engines.

If these flags, and the surrounding framework was introduced with hash
drivers in mind, this new constraint of import/export format consistency
makes it completely unusable for any standard hash algorithm like SHA.
In practice, this makes any hardware hash driver unable to utilize the
FINAL_NONZERO feature.

This looks to me like a gap in the framework; the implementation of the
feature does not exactly match the intention. What do you suggest should
be the approach here, and going forward?

-- 
Regards
T Pratham <t-pratham@xxxxxx>