Re: gssapi, crypto and afs/rxrpc
On Fri, Oct 16, 2020 at 05:18:26PM +0100, David Howells wrote: > 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/. I'd love to share whatever we can, though I'm not really sure what's involved. Certainly some careful testing at least. It's been about 15 years since I really worked on that code. I remember struggling with struct xdr_buf. The client and server support zero-copy, so requests and replies are represented by a combination of a couple of linear buffers plus an array of pages. My memory is that the (undocumented) meanings of the fields of the xdr_buf were different for request and replies and for server and client, and getting them right took some trial and error. --b.
Re: gssapi, crypto and afs/rxrpc
On Fri, Oct 16, 2020 at 05:18:26PM +0100, David Howells wrote: > > 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. Generally it makes sense to create a Crypto API for an algorithm if there are going to be at least two implementations of it. In particular, if there is hardware acceleration available then it'd make sense. Otherwise a library helper would be more appropriate. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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.
