Re: [RFC PATCH 2/8] crypto/krb5: Provide Kerberos 5 crypto through AEAD API

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Jan 10, 2025 at 01:03:04AM +0000, David Howells wrote:
> Use the AEAD crypto API to provide Kerberos 5 crypto, plus some
> supplementary library functions that lie outside of the AEAD API.
> 
> The crypto algorithms only perform the actual crypto operations; they do
> not do any laying out of the message and nor do they insert any metadata or
> padding.  Everything is done by dead-reckoning as the AEAD API does not
> provide a useful way to pass the extra parameters required.
> 
> When setting the key on a crypto algorithm, setkey takes a composite
> structure consisting of an indication of the mode of transformation to be
> applied to the message (checksum only or full encryption); the usage type
> to be used in deriving the keys; an indicator indicating what key is being
> presented (K0 or Kc/Ke+Ki); and the material for those key(s).  Based on
> this, the setkey code allocates and keys the appropriate ciphers and
> hashes.
> 
> When dispatching a request, both checksumming (MIC) and encryption use the
> encrypt and decrypt methods.  A source message, prelaid out with
> confounders or other metadata inserted is provided in the source buffer.
> The cryptolen indicates the amount of source message data, not including
> the trailer after the data (which includes the integrity checksum) and not
> including any associated data.
> 
> Associated data is only used by checksumming encrypt/decrypt.  The
> associated data is added to the checksum hash before the data in the
> message, but does not occupy any part of the output message.
> 
> Authentication tags are not used at all and should cause EINVAL if used (a
> later patch does that).
> 
> For the moment, the kerberos encryption algorithms use separate hash and
> cipher algorithms internally, but should really use dual hash+cipher and
> cipher+hash algorithms if possible to avoid doing these in series.  Offload
> off this may be possible through something like the Intel QAT.

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.

- Eric