From: David Howells <dhowells@redhat.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: dhowells@redhat.com, Chuck Lever <chuck.lever@oracle.com>,
Trond Myklebust <trond.myklebust@hammerspace.com>,
"David S. Miller" <davem@davemloft.net>,
Marc Dionne <marc.dionne@auristor.com>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
linux-crypto@vger.kernel.org, linux-afs@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/8] crypto/krb5: Provide Kerberos 5 crypto through AEAD API
Date: Fri, 10 Jan 2025 10:39:27 +0000 [thread overview]
Message-ID: <1486113.1736505567@warthog.procyon.org.uk> (raw)
In-Reply-To: <Z4DwNPgLFcfy6jdl@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > Authentication tags are not used at all and should cause EINVAL if used (a
> > later patch does that).
>
> What do you mean by this? The authentication tag is the checksum
> that you're referring to and you appear to be using it in the rfc8009
> encrypt/decrypt functions.
Is it? That's entirely unclear. The algorithm should deal with inserting the
checksum in the appropriate place. The caller should not need to know about
that or where the checksum is or about extra bits of metadata that may need to
be inserted (as I think the extra gssapi layer does for sunrpc).
One of the reason the library has a number of layout functions is to handle
that stuff transparently. Unfortunately, I couldn't make it work in the AEAD
interface. The previous library implementation was better in that regard.
> > 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.
>
> Please elaborate on what you mean by this. For IPsec, the main
> benefit with reframing cbc(aes)+hmac as aead is having a single
> code-path that supports both types of algorithms.
By "dual" I mean, for example, a piece of code that does the cipher and the
hash concurrently. I think it may be possible to do this using x86 AES and
SHA instructions - if there are sufficient registers. What I want to do is
avoid having to call a cipher and a hash sequentially. It appears that the
Intel QAT can actually do this with authenc combos - but the one I have
doesn't offer CTS(CBC(AES)) but only CBC(AES).
> So does your use-case support both standard AEAD algorithms such
> as GCM as well as these legacy algorithms?
At the moment AFS's rxgk does not support GCM. The same goes for sunrpc in
the kernel.
David
next prev parent reply other threads:[~2025-01-10 10:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-10 1:03 [RFC PATCH 0/8] crypto: Add generic Kerberos library with crypto as AEAD algorithms David Howells
2025-01-10 1:03 ` [RFC PATCH 1/8] crypto/krb5: Add some constants out of sunrpc headers David Howells
2025-01-10 1:03 ` [RFC PATCH 2/8] crypto/krb5: Provide Kerberos 5 crypto through AEAD API David Howells
2025-01-10 5:50 ` Eric Biggers
2025-01-10 7:13 ` David Howells
2025-01-10 9:47 ` Ard Biesheuvel
2025-01-10 14:33 ` David Howells
2025-01-10 9:48 ` Herbert Xu
2025-01-10 10:26 ` David Howells
2025-01-10 10:30 ` Herbert Xu
2025-01-10 11:09 ` David Howells
2025-01-17 8:13 ` David Howells
2025-01-17 8:30 ` David Howells
2025-01-10 10:02 ` Herbert Xu
2025-01-10 10:39 ` David Howells [this message]
2025-01-10 10:42 ` Herbert Xu
2025-01-10 18:22 ` Jeffrey E Altman
2025-01-10 1:03 ` [RFC PATCH 3/8] crypto/krb5: Test manager data David Howells
2025-01-10 1:03 ` [RFC PATCH 4/8] rxrpc: Add the security index for yfs-rxgk David Howells
2025-01-10 1:03 ` [RFC PATCH 5/8] rxrpc: Add YFS RxGK (GSSAPI) security class David Howells
2025-01-10 1:03 ` [RFC PATCH 6/8] rxrpc: rxgk: Provide infrastructure and key derivation David Howells
2025-01-10 1:03 ` [RFC PATCH 7/8] rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI) David Howells
2025-01-10 1:03 ` [RFC PATCH 8/8] rxrpc: rxgk: Implement connection rekeying David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1486113.1736505567@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-afs@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=marc.dionne@auristor.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=trond.myklebust@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).