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