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: <CAMj1kXE2mhXJaa9uq==Xki3On9ZKYY+KV-oH0ednqWC6b9BTYw@mail.gmail.com>
Date: Fri, 10 Jan 2025 10:47:54 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: 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, 
	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, 10 Jan 2025 at 08:14, David Howells <dhowells@...hat.com> wrote:
>
> Eric Biggers <ebiggers@...nel.org> wrote:
>
> > 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.
>
> Yes.  That's how I did my first implementation.  I basically took the code
> from net/sunrpc/auth_gss/ and made it more generic.  Herbert wants it done
> this way, however.  :-/
>

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

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.

Are you anticipating other, accelerated implementations of the
combined algorithms? Isn't it enough to rely on the existing Camellia
and AES code? Mentioning 'something like the Intel QAT' doesn't
suggest you have something specific in mind.

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