On Mon, Feb 03, 2025 at 02:23:19PM +0000, David Howells wrote:

[!] Note that the net/sunrpc/auth_gss/ implementation gets a pair of
ciphers, one non-CTS and one CTS, using the former to do all the aligned
blocks and the latter to do the last two blocks if they aren't also
aligned.  It may be necessary to do this here too for performance reasons -
but there are considerations both ways:

 (1) firstly, there is an optimised assembly version of cts(cbc(aes)) on
     x86_64 that should be used instead of having two ciphers;

 (2) secondly, none of the hardware offload drivers seem to offer CTS
     support (Intel QAT does not, for instance).

However, I don't know if it's possible to query the crypto API to find out
whether there's an optimised CTS algorithm available.

Linux's "cts" is specifically the CS3 variant of CTS (using the terminology of
NIST SP800-38A https://dl.acm.org/doi/pdf/10.5555/2206248) which unconditionally
swaps the last two blocks.  Is that the variant that is needed here?  SP800-38A
mentions that CS3 is the variant used in Kerberos 5, so I assume yes.  If yes,
then you need to use cts(cbc(aes)) unconditionally.  (BTW, I hope you have some
test that shows that you actually implemented the Kerberos protocol correctly?)

x86_64 already has an AES-NI assembly optimized cts(cbc(aes)), as you mentioned.
I will probably add a VAES optimized cts(cbc(aes)) at some point; I've just been
doing other modes first.  I don't see why off-CPU hardware offload support
should deserve much attention here, given the extremely high speed of on-CPU
crypto these days and the great difficulty of integrating off-CPU acceleration
efficiently.  In particular it seems weird to consider Intel QAT a reasonable
thing to use over VAES.  Regardless, absent direct support for cts(cbc(aes)) the
cts template will build it on top of cbc(aes) anyway.

- Eric