On Fri, 10 Jan 2025 at 08:14, David Howells [off-list ref] wrote:

Eric Biggers [off-list ref] wrote:

quoted

It sounds like a lot of workarounds had to be implemented to fit these
protocols into the crypto_aead API.

It also seems unlikely that there will be other implementations of these
protocols added to the kernel, besides the one you're adding in crypto/krb5/.

Given that, providing this functionality as library functions instead would be
much simpler.  Take a look at how crypto/kdf_sp800108.c works, for example.

Yes.  That's how I did my first implementation.  I basically took the code
from net/sunrpc/auth_gss/ and made it more generic.  Herbert wants it done
this way, however.  :-/

What is the reason for shoehorning any of this into the crypto API?

I agree with Eric here: it seems both the user (Kerberos) and the
crypto API are worse off here, due to mutual API incompatibilities
that seem rather fundamental.

Are you anticipating other, accelerated implementations of the
combined algorithms? Isn't it enough to rely on the existing Camellia
and AES code? Mentioning 'something like the Intel QAT' doesn't
suggest you have something specific in mind.

Also, this patch is rather big and therefore hard to review.