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

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250110055058.GA63811@sol.localdomain>
Date: Thu, 9 Jan 2025 21:50:58 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
	Chuck Lever <chuck.lever@...cle.com>,
	Trond Myklebust <trond.myklebust@...merspace.com>,
	"David S. Miller" <davem@...emloft.net>,
	Marc Dionne <marc.dionne@...istor.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>, linux-crypto@...r.kernel.org,
	linux-afs@...ts.infradead.org, linux-nfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/8] crypto/krb5: Provide Kerberos 5 crypto through
 AEAD API

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