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: <1488634.1736507389@warthog.procyon.org.uk>
Date: Fri, 10 Jan 2025 11:09:49 +0000
From: David Howells <dhowells@...hat.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: dhowells@...hat.com, 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

Herbert Xu <herbert@...dor.apana.org.au> wrote:

> On Fri, Jan 10, 2025 at 10:26:38AM +0000, David Howells wrote:
> >
> > However the point of having a library is to abstract those details from the
> > callers.  You wanted me to rewrite the library as AEAD algorithms, which I
> > have done as far as I can.  This makes the object for each kerberos enctype
> > look the same from the PoV of the clients.
> 
> I think there is some misunderstanding here.  For a library outside
> of the Crypto API you can do whatever you want.
> 
> I only suggested AEAD because I thought you wanted to bring this within
> the Crypto API.

Not precisely.  What I (and Chuck when I discussed it with him) were thinking
is that the kerberos crypto stuff probably belongs in the crypto/ *directory*
rather than in the net/ directory - but not necessarily as part of the crypto
API.  It mediates use of the crypto API on the part of its users (probably
just sunrpc and rxrpc's rxgk).

That said, I kind of like the implementation of the pure crypto part as AEAD
crypto algorithms as it provides a number of advantages:

 (1) The client can be given a single AEAD object to use for each usage and
     call the encrypt and decrypt on that directly, no matter what enctype or
     mode of operation it is doing.

     Of course, it's not quite so simple that I can just share the code for
     encrypt-mode and checksum-mode at the client level (eg. rxgk).  In the
     former, some metadata is placed in the message; in the latter it's just
     added into the hash.

 (2) The AEAD object looks after inserting the checksum into the right place
     for the enctype, which means the client doesn't have to do that and could
     therefore more easily asynchronise it through the crypto API.

 (3) Since these do just the crypto and not the laying out, it may be feasible
     to substitute the AES2 encrypt-mode kerberos AEAD driver with an
     authenc() AEAD object.

 (4) The possibility exists of providing optimised drivers to directly
     substitute the kerberos AEAD algorithms.

David