[PATCH v5 04/19] crypto: cmh - add SHA-2/SHA-3/SHAKE ahash

[Ousherovitch, Alex]

On Mon, Sep 28, 2026 at 03:17:17PM +1000, Herbert Xu wrote:
> Hang on, if an algorithm isn't even implemented in generic C for
> the Crypto API, then it should not be implemented by a driver
> either.
>
> The reason these algorithms aren't in the Crypto API is because
> they have no users.
>
> So please drop them.

Understood.  v6 drops SHAKE-128/256, cSHAKE-128/256, KMAC-128/256 and
the standalone Poly1305.

> Sorry, that is not supported by our API.  If you cannot export the
> hash state in a compatible format, then you will have to switch over
> to fallbacks and only support digest operations.

Will do.  For the algorithms that have a generic provider -- SHA-2,
SHA-3, SM3, HMAC(SHA-2/SHA-3), CMAC(AES), CMAC(SM4) and XCBC(SM4) --
v6 switches to the fallback/digest-only model:

  - drop the NO_FALLBACK / BLOCK_ONLY / REQ_VIRT flags and the
    hand-rolled partial-block and fallback handling, and let the Crypto
    API install the generic fallback;
  - hardware-accelerate .digest() only;
  - route everything else -- .init()/.update()/.final()/.finup()/
    .export()/.import(), and .setkey() for the keyed ones -- through the
    fallback, so the statesize and the exported state are the generic
    ones.

That also answers your NO_FALLBACK question: the flag is gone.

> Please also elaborate what you mean by opaque checkpoint, does it
> contain the entire hash state or not?

It holds everything needed to resume, but not in a portable layout.  The
SAVE output is a fixed-size hardware container (600 bytes worst case)
holding the core's internal state, the buffered partial block, the block
counters, the mode and a CRC.  The state portion varies by algorithm:

  - SHA-3/SHAKE: the 200-byte Keccak state is stored as two shares (the
    core is DPA/side-channel protected), so it is not the canonical
    state.
  - SHA-2: a single 64-byte register block plus the partial block and
    byte count, in a hardware-internal layout.
  - Keyed SHA-3 HMAC state cannot be saved by the hardware at all.

None of these is the canonical export format the API needs, so the
fallback/digest-only model above is the right fit and we are not pursuing
incremental hashing upstream.

One process question, if you don't mind: we would like to fold as much as
possible into v6 rather than spinning several revisions.  Have you had a
chance to look at the rest of the series, or should we expect further
comments on the remaining patches?  No rush at all -- it would just help
us decide whether to post v6 now or hold it until the rest of your
feedback has landed.

Thanks for the review.

Alex