Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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
