Message-ID: <1494600.1736519616@warthog.procyon.org.uk>
Date: Fri, 10 Jan 2025 14:33:36 +0000
From: David Howells <dhowells@...hat.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: dhowells@...hat.com, Eric Biggers <ebiggers@...nel.org>,
    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, qat-linux <qat-linux@...el.com>,
    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

Ard Biesheuvel <ardb@...nel.org> wrote:

> What is the reason for shoehorning any of this into the crypto API?

I was under the impression that that was what Herbert wanted.

> I agree with Eric here: it seems both the user (Kerberos) and the
> crypto API are worse off here, due to mutual API incompatibilities
> that seem rather fundamental.

My original take on this was to take the sunrpc code and turn it into a
library, placing that library in the crypto/ directory:

	https://lore.kernel.org/linux-crypto/160518586534.2277919.14475638653680231924.stgit@warthog.procyon.org.uk/

The crypto/ dir seems the right home for it (and not net/ or lib/), but the
way it's implemented here, it's a user of the crypto API, but does not itself
implement it.

That said, it would be convenient if if *could* be part of the crypto API in
some way.  As I outlined in one of my responses to Herbert, there are a number
of advantages to doing that.

> Are you anticipating other, accelerated implementations of the
> combined algorithms?

I think one can be done with x86 AES and SHA instructions provided there are
sufficient registers.

> Isn't it enough to rely on the existing Camellia and AES code?

The problem is that you have to do *two* crypto operations - and that it may
not be possible to parallellise them.  With AES+SHA1 and Camellia, they can be
parallellised as both sides work on the plaintext; but with the AES+SHA2, the
encryption is done and then the *encrypted* output is checksummed.

Note that "parallellising" might mean launching an async hash request and an
async skcipher request and then waiting for both to finish.  This can't,
however, be done unless the output buffer is separate from the input buffer.

> Mentioning 'something like the Intel QAT' doesn't suggest you have something
> specific in mind.

I have an Intel QAT card, and under some circumstances I could offload the
crypto to it...  But the only operations the driver currently makes available
are:

	authenc(hmac(sha1),cbc(aes))
	authenc(hmac(sha256),cbc(aes))
	authenc(hmac(sha512),cbc(aes))

The first one can't be used for kerberos's aes128-cts-hmac-sha1-96 as it
hashes the ciphertext, not the plain text.  I don't have anything that uses
the third.  The second is a possibility.  I think that could probably do
aes128-cts-hmac-sha256-128.

Now, it's possible that the QAT device range can do more than the driver
offers.  I'm presuming that the driver offers what IPsec wants to support.
Also, waving these ideas in front of Intel devs might expand the range of what
future QATs can do ;-)

Mostly, though, by "something like" I was just offering the possibility that
other architectures or crypto cards may also offer usable services - but I
haven't investigated.

> Also, this patch is rather big and therefore hard to review.

Yeah.  Mostly I wanted to wave it in front of Herbert before expending the
effort to slice it up.  Sadly, it doesn't seem that what I came up with is
what he wanted.

David

Powered by blists - more mailing lists