linux-kernel - Re: How to get my krb5 crypto lib upstream?

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: <726863.1685563684@warthog.procyon.org.uk>
Date:   Wed, 31 May 2023 21:08:04 +0100
From:   David Howells <dhowells@...hat.com>
To:     Chuck Lever III <chuck.lever@...cle.com>
Cc:     dhowells@...hat.com, Herbert Xu <herbert@...dor.apana.org.au>,
        "linux-afs@...ts.infradead.org" <linux-afs@...ts.infradead.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: How to get my krb5 crypto lib upstream?

Chuck Lever III <chuck.lever@...cle.com> wrote:

> > int crypto_krb5_decrypt(const struct krb5_enctype *krb5,
> > struct krb5_enc_keys *keys,
> > struct scatterlist *sg, unsigned int nr_sg,
> 
> So are we going to stick with struct scatterlist here,
> or should it be rather an iterator of some kind?

For my purposes, a scatterlist is more useful as I have an skbuff to work
with - plus I have to pass a scatterlist into the crypto functions inside of
the krb5 lib.

> It's not clear why something like this would need to be
> exposed to crypto/krb5 consumers. There are a few items
> in here that XDR needs to know about (lengths and such)
> but that kind of thing can be provided by a function
> call rather than by having direct access to a structure.

Fair point.  In rxgk, I use key_len, key_bytes, block_len, cksum_len plus the
name for procfs purposes.  I also wonder if I need separate key_len and
key_bytes if I'm not supporting DES (DES keys gets expanded IIRC).  Also, some
of the checks I'm doing could perhaps be moved into the krb5 lib.

The krb5 selftest code makes use of more of the fields, but I guess that's
internal to krb5lib.

David