netdev - Re: [PATCH net 03/24] crypto: Add 'krb5enc' hash and cipher AEAD algorithm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250207200419.GA2819332@google.com>
Date: Fri, 7 Feb 2025 20:04:19 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: netdev@...r.kernel.org, Herbert Xu <herbert@...dor.apana.org.au>,
	Marc Dionne <marc.dionne@...istor.com>,
	Jakub Kicinski <kuba@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	Trond Myklebust <trond.myklebust@...merspace.com>,
	Chuck Lever <chuck.lever@...cle.com>,
	Ard Biesheuvel <ardb@...nel.org>, linux-crypto@...r.kernel.org,
	linux-afs@...ts.infradead.org, linux-nfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 03/24] crypto: Add 'krb5enc' hash and cipher AEAD
 algorithm

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