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
