On Fri, 10 Jan 2025 at 08:14, David Howells <dhowells@xxxxxxxxxx> wrote: > > Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > > 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.
