netdev - gssapi, crypto and afs/rxrpc

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-next>] [day] [month] [year] [list]

Date:   Fri, 16 Oct 2020 17:18:26 +0100
From:   David Howells <dhowells@...hat.com>
To:     herbert@...dor.apana.org.au, davem@...emloft.net,
        trond.myklebust@...merspace.com
cc:     dhowells@...hat.com, linux-crypto@...r.kernel.org,
        linux-nfs@...r.kernel.org, linux-afs@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: gssapi, crypto and afs/rxrpc

Hi Herbert, Dave, Trond,

I've written basic gssapi-derived security support for AF_RXRPC:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rxgk

I've borrowed some bits from net/sunrpc/auth_gss/ but there's a lot in there
that is quite specific to the sunrpc module that makes it hard to use for
rxrpc (dprintk, struct xdr_buf).

Further, I've implemented some more enctypes that aren't supported yet by
gssapi (AES with sha256/sha384 and Camellia), and that requires some changes
to the handling as AES with sha384 has a 24-byte checksum size and a 24-byte
calculated key size for Kc and Ki but a 32-byte Ke.

Should I pull the core out and try to make it common?  If so, should I move it
to crypto/ or lib/, or perhaps put it in net/gssapi/?

There are two components to it:

 (1) Key derivation steps.

     My thought is to use xdr_netobj or something similar for to communicate
     between the steps (though I'd prefer to change .data to be a void* rather
     than u8*).

 (2) Encryption/checksumming.

     My thought is to make this interface use scattergather lists[*] since
     that's what the crypto encryption API requires (though not the hash API).

If I do this, should I create a "kerberos" crypto API for the data wrapping
functions?  I'm not sure that it quite matches the existing APIs because the
size of the input data will likely not match the size of the output data and
it's "one shot" as it needs to deal with a checksum.

Or I can just keep my implementation separate inside net/rxrpc/.

David

[*] That said, I'm not exactly sure how the sunrpc stuff works, so this might
not work for that.