Re: Adding algorithm agility to the crypto library functions

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Oct 14, 2025 at 12:01:34PM -0400, James Bottomley wrote:
> The TPM session calculation functions recently got converted to use the
> rawkey functions instead of open coding it 64a7cfbcf548 ("tpm: Use
> HMAC-SHA256 library instead of open-coded HMAC").

To be clear, drivers/char/tpm/tpm2-sessions.c has always been hard-coded
to use SHA-256 and HMAC-SHA256, and it's always used the SHA-256
library.  It just open-coded the HMAC construction.

> because the user has no input on the hmac hash algorithm so, although
> the TPM specifies it to be agile, we can simply choose sha256. 
> However, we have plans to use what are called policy sessions, which
> have require the same hash as the user supplied object used for its
> name (essentially a hash chosen by the user).  In a TPM these hashes
> can be any of the family sha1 sha256, sha384 sha512 plus a few esoteric
> ones like sm3.  So the question becomes: to avoid going back to open
> coding the hmac and using the shash API, is there a way of adding hash
> agility to the library algorithms?  I suppose I could also do this
> inside our hmac code using a large set of switch statements, but that
> would be a bit gross.
> 
> If no-one's planning to do this I can take a stab ... it would probably
> still be a bunch of switch statements, but not in my code ...

This isn't the job of lib/crypto/.

If a caller would like to support a certain set of algorithms, it should
just write the 'if' or 'switch' statement itself.

The nice thing about that is that it results in the minimum number of
branches and the minimum stack usage for the possible set of algorithms
at that particular call site.  (Compare to crypto_shash which always
uses indirect calls and always uses almost 400 bytes for each
SHASH_DESC_ON_STACK().  SHASH_DESC_ON_STACK() has to be sized for the
worst possible case among every hash algorithm in existence, regardless
of whether the caller is actually using it or not.)

That approach is already used successfully in fs/verity/ and net/sctp/.
I'm planning to make fs/btrfs/ adopt it too.  It works fine, and it's
the most efficient solution.

If a particular caller has a super long list of algorithms or is dealing
with a legacy arbitrary user-specified string, then it's of course still
free to use crypto_shash.

But I have to wonder, do you really need to add support for all these
hash algorithms?  Adding SHA-1 and SM3 support, really?

What stops you from just saying that the kernel supports SHA-256 for
these user supplied objects, and that's it?

Getting kernel developers to think carefully about what set of crypto
algorithms they'd like to support in their features, rather than punting
the problem to a generic crypto layer that supports all sorts of
insecure and esoteric options, isn't necessarily a bad thing...

- Eric