Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Tue, Dec 01, 2020 at 09:12:38AM +, David Howells wrote: > > That depends on whether the caller has passed it elsewhere for some other > parallel purpose, but I think I'm going to have to go down that road and > restore it afterwards. Sure but even if you added it to the API the underlying implementataions would just have to do the same thing. Since this is particular to your use-case it's better to leave the complexity where it's needed rather than propagting it to all the crypto drivers. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
Herbert Xu wrote: > Couldn't you just change the output sg to include the offset? That depends on whether the caller has passed it elsewhere for some other parallel purpose, but I think I'm going to have to go down that road and restore it afterwards. David
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Tue, Dec 01, 2020 at 08:44:33AM +, David Howells wrote: > Btw, would it be feasible to make it so that an extra parameter can be added > to the cipher buffer-supplying functions, e.g.: > > skcipher_request_set_crypt(req, input, ciphertext_sg, esize, iv); > > such that we can pass in an offset into the output sg as well? Couldn't you just change the output sg to include the offset? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
Btw, would it be feasible to make it so that an extra parameter can be added to the cipher buffer-supplying functions, e.g.: skcipher_request_set_crypt(req, input, ciphertext_sg, esize, iv); such that we can pass in an offset into the output sg as well? David
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Thu, Nov 26, 2020 at 08:19:41AM +, David Howells wrote: > > I haven't done that yet. Sorry, I should've been more explicit with what I > was after. I was wanting to find out if the nfs/nfsd people are okay with > this (and if there are any gotchas I should know about - it turns out, if I > understand it correctly, the relevant code may being being rewritten a bit > anyway). > > And from you, I was wanting to find out if you're okay with an interface of > this kind in crypto/ where the code is just used directly - or whether I'll > be required to wrap it up in the autoloading, module-handling mechanisms. I don't have any problems with it living under crypto. However, I'd like to see what the sunrpc code looks like before going one way or another. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
Herbert Xu wrote: > > Here's my first cut at a generic Kerberos crypto library in the kernel so > > that I can share code between rxrpc and sunrpc (and cifs?). > > I can't find the bit where you are actually sharing this code with > sunrpc, am I missing something? I haven't done that yet. Sorry, I should've been more explicit with what I was after. I was wanting to find out if the nfs/nfsd people are okay with this (and if there are any gotchas I should know about - it turns out, if I understand it correctly, the relevant code may being being rewritten a bit anyway). And from you, I was wanting to find out if you're okay with an interface of this kind in crypto/ where the code is just used directly - or whether I'll be required to wrap it up in the autoloading, module-handling mechanisms. David
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote: > > Hi Herbert, Bruce, > > Here's my first cut at a generic Kerberos crypto library in the kernel so > that I can share code between rxrpc and sunrpc (and cifs?). Hi David: I can't find the bit where you are actually sharing this code with sunrpc, am I missing something? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
> On Nov 12, 2020, at 4:07 PM, Bruce Fields wrote: > > On Thu, Nov 12, 2020 at 04:54:06PM +, David Howells wrote: >> Chuck Lever wrote: >> >>> Really? My understanding of the Linux kernel SUNRPC implementation is >>> that it uses asynchronous, even for small data items. Maybe I'm using >>> the terminology incorrectly. >> >> Seems to be synchronous, at least in its use of skcipher: > > Yes, it's all synchronous. The only cases where we defer and revisit a > request is when we need to do upcalls to userspace. > > (And those upcalls mostly come after we're done with unwrapping and > verifying a request, so now I'm sort of curious exactly what Chuck was > seeing.) I vaguely recall that setting CRYPTO_TFM_REQ_MAY_SLEEP allows the crypto API to sleep and defer completion. -- Chuck Lever
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Thu, Nov 12, 2020 at 04:54:06PM +, David Howells wrote: > Chuck Lever wrote: > > > Really? My understanding of the Linux kernel SUNRPC implementation is > > that it uses asynchronous, even for small data items. Maybe I'm using > > the terminology incorrectly. > > Seems to be synchronous, at least in its use of skcipher: Yes, it's all synchronous. The only cases where we defer and revisit a request is when we need to do upcalls to userspace. (And those upcalls mostly come after we're done with unwrapping and verifying a request, so now I'm sort of curious exactly what Chuck was seeing.) --b.
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
> On Nov 12, 2020, at 1:37 PM, J. Bruce Fields wrote:
>
> On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>>
>> Hi Herbert, Bruce,
>>
>> Here's my first cut at a generic Kerberos crypto library in the kernel so
>> that I can share code between rxrpc and sunrpc (and cifs?).
>>
>> I derived some of the parts from the sunrpc gss library and added more
>> advanced AES and Camellia crypto. I haven't ported across the DES-based
>> crypto yet - I figure that can wait a bit till the interface is sorted.
>>
>> Whilst I have put it into a directory under crypto/, I haven't made an
>> interface that goes and loads it (analogous to crypto_alloc_skcipher,
>> say). Instead, you call:
>>
>>const struct krb5_enctype *crypto_krb5_find_enctype(u32 enctype);
>>
>> to go and get a handler table and then use a bunch of accessor functions to
>> jump through the hoops. This is basically the way the sunrpc gsslib does
>> things. It might be worth making it so you do something like:
>>
>> struct crypto_mech *ctx = crypto_mech_alloc("krb5(18)");
>>
>> to get enctype 18, but I'm not sure if it's worth the effort. Also, I'm
>> not sure if there are any alternatives to kerberos we will need to support.
>
> We did have code for a non-krb5 mechanism at some point, but it was torn
> out. So I don't think that's a priority.
>
> (Chuck, will RPC-over-SSL need a new non-krb5 mechanism?)
No, RPC-over-TLS does not involve the GSS infrastructure in any way.
>> There are three main interfaces to it:
>>
>> (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
>>
>> These all do in-place crypto, using an sglist to define the buffer
>> with the data in it. Is it necessary to make it able to take separate
>> input and output buffers?
>
> I don't know. My memory is that the buffer management in the existing
> rpcsec_gss code is complex and fragile. See e.g. the long comment in
> gss_krb5_remove_padding.
And even worse, the buffer handling is slightly different in the NFS
client and server code paths.
> --b.
>
>> (*) PRF+ calculation for key derivation.
>> (*) Kc, Ke, Ki derivation.
>>
>> These use krb5_buffer structs to pass objects around. This is akin to
>> the xdr_netobj, but has a void* instead of a u8* data pointer.
>>
>> In terms of rxrpc's rxgk, there's another step in key derivation that isn't
>> part of the kerberos standard, but uses the PRF+ function to generate a key
>> that is then used to generate Kc, Ke and Ki. Is it worth putting this into
>> the directory or maybe having a callout to insert an intermediate step in
>> key derivation?
>>
>> Note that, for purposes of illustration, I've included some rxrpc patches
>> that use this interface to implement the rxgk Rx security class. The
>> branch also is based on some rxrpc patches that are a prerequisite for
>> this, but the crypto patches don't need it.
>>
>> ---
>> The patches can be found here also:
>>
>>
>> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=crypto-krb5
>>
>> David
>> ---
>> David Howells (18):
>> crypto/krb5: Implement Kerberos crypto core
>> crypto/krb5: Add some constants out of sunrpc headers
>> crypto/krb5: Provide infrastructure and key derivation
>> crypto/krb5: Implement the Kerberos5 rfc3961 key derivation
>> crypto/krb5: Implement the Kerberos5 rfc3961 encrypt and decrypt
>> functions
>> crypto/krb5: Implement the Kerberos5 rfc3961 get_mic and verify_mic
>> crypto/krb5: Implement the AES enctypes from rfc3962
>> crypto/krb5: Implement crypto self-testing
>> crypto/krb5: Implement the AES enctypes from rfc8009
>> crypto/krb5: Implement the AES encrypt/decrypt from rfc8009
>> crypto/krb5: Add the AES self-testing data from rfc8009
>> crypto/krb5: Implement the Camellia enctypes from rfc6803
>> rxrpc: Add the security index for yfs-rxgk
>> rxrpc: Add YFS RxGK (GSSAPI) security class
>> rxrpc: rxgk: Provide infrastructure and key derivation
>> rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)
>> rxrpc: rxgk: Implement connection rekeying
>> rxgk: Support OpenAFS's rxgk implementation
>>
>>
>> crypto/krb5/Kconfig |9 +
>> crypto/krb5/Makefile | 11 +-
>> crypto/krb5/internal.h | 101 +++
>> crypto/krb5/kdf.c| 223 ++
>> crypto/krb5/main.c | 190 +
>> crypto/krb5/rfc3961_simplified.c | 732 ++
>> crypto/krb5/rfc3962_aes.c| 140
>> crypto/krb5/rfc6803_camellia.c | 249 ++
>> crypto/krb5/rfc8009_aes2.c | 440 +++
>> crypto/krb5/selftest.c | 543 +
>> crypto/krb5/selftest_data.c | 289 +++
>> fs/afs/misc.c| 13 +
>> include/crypto/krb5.h| 100 +++
>> include/keys/rxrpc-type.h| 17 +
>> include/trace/events/rxrpc.h |4 +
>>
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>
> Hi Herbert, Bruce,
>
> Here's my first cut at a generic Kerberos crypto library in the kernel so
> that I can share code between rxrpc and sunrpc (and cifs?).
>
> I derived some of the parts from the sunrpc gss library and added more
> advanced AES and Camellia crypto. I haven't ported across the DES-based
> crypto yet - I figure that can wait a bit till the interface is sorted.
>
> Whilst I have put it into a directory under crypto/, I haven't made an
> interface that goes and loads it (analogous to crypto_alloc_skcipher,
> say). Instead, you call:
>
> const struct krb5_enctype *crypto_krb5_find_enctype(u32 enctype);
>
> to go and get a handler table and then use a bunch of accessor functions to
> jump through the hoops. This is basically the way the sunrpc gsslib does
> things. It might be worth making it so you do something like:
>
> struct crypto_mech *ctx = crypto_mech_alloc("krb5(18)");
>
> to get enctype 18, but I'm not sure if it's worth the effort. Also, I'm
> not sure if there are any alternatives to kerberos we will need to support.
We did have code for a non-krb5 mechanism at some point, but it was torn
out. So I don't think that's a priority.
(Chuck, will RPC-over-SSL need a new non-krb5 mechanism?)
> There are three main interfaces to it:
>
> (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
>
> These all do in-place crypto, using an sglist to define the buffer
> with the data in it. Is it necessary to make it able to take separate
> input and output buffers?
I don't know. My memory is that the buffer management in the existing
rpcsec_gss code is complex and fragile. See e.g. the long comment in
gss_krb5_remove_padding.
--b.
> (*) PRF+ calculation for key derivation.
> (*) Kc, Ke, Ki derivation.
>
> These use krb5_buffer structs to pass objects around. This is akin to
> the xdr_netobj, but has a void* instead of a u8* data pointer.
>
> In terms of rxrpc's rxgk, there's another step in key derivation that isn't
> part of the kerberos standard, but uses the PRF+ function to generate a key
> that is then used to generate Kc, Ke and Ki. Is it worth putting this into
> the directory or maybe having a callout to insert an intermediate step in
> key derivation?
>
> Note that, for purposes of illustration, I've included some rxrpc patches
> that use this interface to implement the rxgk Rx security class. The
> branch also is based on some rxrpc patches that are a prerequisite for
> this, but the crypto patches don't need it.
>
> ---
> The patches can be found here also:
>
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=crypto-krb5
>
> David
> ---
> David Howells (18):
> crypto/krb5: Implement Kerberos crypto core
> crypto/krb5: Add some constants out of sunrpc headers
> crypto/krb5: Provide infrastructure and key derivation
> crypto/krb5: Implement the Kerberos5 rfc3961 key derivation
> crypto/krb5: Implement the Kerberos5 rfc3961 encrypt and decrypt
> functions
> crypto/krb5: Implement the Kerberos5 rfc3961 get_mic and verify_mic
> crypto/krb5: Implement the AES enctypes from rfc3962
> crypto/krb5: Implement crypto self-testing
> crypto/krb5: Implement the AES enctypes from rfc8009
> crypto/krb5: Implement the AES encrypt/decrypt from rfc8009
> crypto/krb5: Add the AES self-testing data from rfc8009
> crypto/krb5: Implement the Camellia enctypes from rfc6803
> rxrpc: Add the security index for yfs-rxgk
> rxrpc: Add YFS RxGK (GSSAPI) security class
> rxrpc: rxgk: Provide infrastructure and key derivation
> rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)
> rxrpc: rxgk: Implement connection rekeying
> rxgk: Support OpenAFS's rxgk implementation
>
>
> crypto/krb5/Kconfig |9 +
> crypto/krb5/Makefile | 11 +-
> crypto/krb5/internal.h | 101 +++
> crypto/krb5/kdf.c| 223 ++
> crypto/krb5/main.c | 190 +
> crypto/krb5/rfc3961_simplified.c | 732 ++
> crypto/krb5/rfc3962_aes.c| 140
> crypto/krb5/rfc6803_camellia.c | 249 ++
> crypto/krb5/rfc8009_aes2.c | 440 +++
> crypto/krb5/selftest.c | 543 +
> crypto/krb5/selftest_data.c | 289 +++
> fs/afs/misc.c| 13 +
> include/crypto/krb5.h| 100 +++
> include/keys/rxrpc-type.h| 17 +
> include/trace/events/rxrpc.h |4 +
> include/uapi/linux/rxrpc.h | 17 +
> net/rxrpc/Kconfig| 10 +
> net/rxrpc/Makefile |5 +
> net/rxrpc/ar-internal.h | 20 +
> net/rxrpc/conn_object.c |2 +
> net/rxrpc/key.c | 319
> net/rxrpc/rxgk.c | 1232
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
Chuck Lever wrote:
> Really? My understanding of the Linux kernel SUNRPC implementation is
> that it uses asynchronous, even for small data items. Maybe I'm using
> the terminology incorrectly.
Seems to be synchronous, at least in its use of skcipher:
grep -e skcipher *
gss_krb5_crypto.c:#include
gss_krb5_crypto.c: struct crypto_sync_skcipher *tfm,
gss_krb5_crypto.c: if (length % crypto_sync_skcipher_blocksize(tfm) != 0)
gss_krb5_crypto.c: if (crypto_sync_skcipher_ivsize(tfm) >
GSS_KRB5_MAX_BLOCKSIZE) {
gss_krb5_crypto.c: crypto_sync_skcipher_ivsize(tfm));
gss_krb5_crypto.c: memcpy(local_iv, iv,
crypto_sync_skcipher_ivsize(tfm));
gss_krb5_crypto.c: skcipher_request_set_sync_tfm(req, tfm);
gss_krb5_crypto.c: skcipher_request_set_callback(req, 0, NULL, NULL);
gss_krb5_crypto.c: skcipher_request_set_crypt(req, sg, sg, length,
local_iv);
gss_krb5_crypto.c: ret = crypto_skcipher_encrypt(req);
gss_krb5_crypto.c: skcipher_request_zero(req);
gss_krb5_crypto.c: struct crypto_sync_skcipher *tfm,
gss_krb5_crypto.c: if (length % crypto_sync_skcipher_blocksize(tfm) != 0)
gss_krb5_crypto.c: if (crypto_sync_skcipher_ivsize(tfm) >
GSS_KRB5_MAX_BLOCKSIZE) {
gss_krb5_crypto.c: crypto_sync_skcipher_ivsize(tfm));
gss_krb5_crypto.c: memcpy(local_iv, iv,
crypto_sync_skcipher_ivsize(tfm));
gss_krb5_crypto.c: skcipher_request_set_sync_tfm(req, tfm);
gss_krb5_crypto.c: skcipher_request_set_callback(req, 0, NULL, NULL);
gss_krb5_crypto.c: skcipher_request_set_crypt(req, sg, sg, length,
local_iv);
gss_krb5_crypto.c: ret = crypto_skcipher_decrypt(req);
gss_krb5_crypto.c: skcipher_request_zero(req);
gss_krb5_crypto.c: struct skcipher_request *req;
gss_krb5_crypto.c: struct crypto_sync_skcipher *tfm =
gss_krb5_crypto.c: crypto_sync_skcipher_reqtfm(desc->req);
gss_krb5_crypto.c: fraglen = thislen &
(crypto_sync_skcipher_blocksize(tfm) - 1);
gss_krb5_crypto.c: skcipher_request_set_crypt(desc->req, desc->infrags,
desc->outfrags,
gss_krb5_crypto.c: ret = crypto_skcipher_encrypt(desc->req);
gss_krb5_crypto.c:gss_encrypt_xdr_buf(struct crypto_sync_skcipher *tfm, struct
xdr_buf *buf,
gss_krb5_crypto.c: BUG_ON((buf->len - offset) %
crypto_sync_skcipher_blocksize(tfm) != 0);
gss_krb5_crypto.c: skcipher_request_set_sync_tfm(req, tfm);
gss_krb5_crypto.c: skcipher_request_set_callback(req, 0, NULL, NULL);
gss_krb5_crypto.c: skcipher_request_zero(req);
gss_krb5_crypto.c: struct skcipher_request *req;
gss_krb5_crypto.c: struct crypto_sync_skcipher *tfm =
gss_krb5_crypto.c: crypto_sync_skcipher_reqtfm(desc->req);
gss_krb5_crypto.c: fraglen = thislen &
(crypto_sync_skcipher_blocksize(tfm) - 1);
gss_krb5_crypto.c: skcipher_request_set_crypt(desc->req, desc->frags,
desc->frags,
gss_krb5_crypto.c: ret = crypto_skcipher_decrypt(desc->req);
gss_krb5_crypto.c:gss_decrypt_xdr_buf(struct crypto_sync_skcipher *tfm, struct
xdr_buf *buf,
gss_krb5_crypto.c: BUG_ON((buf->len - offset) %
crypto_sync_skcipher_blocksize(tfm) != 0);
gss_krb5_crypto.c: skcipher_request_set_sync_tfm(req, tfm);
gss_krb5_crypto.c: skcipher_request_set_callback(req, 0, NULL, NULL);
gss_krb5_crypto.c: skcipher_request_zero(req);
gss_krb5_crypto.c:gss_krb5_cts_crypt(struct crypto_sync_skcipher *cipher,
struct xdr_buf *buf,
gss_krb5_crypto.c: skcipher_request_set_sync_tfm(req, cipher);
gss_krb5_crypto.c: skcipher_request_set_callback(req, 0, NULL, NULL);
gss_krb5_crypto.c: skcipher_request_set_crypt(req, sg, sg, len, iv);
gss_krb5_crypto.c: ret = crypto_skcipher_encrypt(req);
gss_krb5_crypto.c: ret = crypto_skcipher_decrypt(req);
gss_krb5_crypto.c: skcipher_request_zero(req);
gss_krb5_crypto.c: struct crypto_sync_skcipher *cipher, *aux_cipher;
gss_krb5_crypto.c: blocksize = crypto_sync_skcipher_blocksize(cipher);
gss_krb5_crypto.c: skcipher_request_set_sync_tfm(req, aux_cipher);
gss_krb5_crypto.c: skcipher_request_set_callback(req, 0, NULL,
NULL);
gss_krb5_crypto.c: skcipher_request_zero(req);
gss_krb5_crypto.c: struct crypto_sync_skcipher *cipher, *aux_cipher;
gss_krb5_crypto.c: blocksize = crypto_sync_skcipher_blocksize(cipher);
gss_krb5_crypto.c: skcipher_request_set_sync_tfm(req, aux_cipher);
gss_krb5_crypto.c: skcipher_request_set_callback(req, 0, NULL,
NULL);
gss_krb5_crypto.c: skcipher_request_zero(req);
gss_krb5_keys.c:#include
gss_krb5_keys.c:struct crypto_sync_skcipher *cipher;
gss_krb5_keys.c:cipher = crypto_alloc_sync_skcipher(gk5e->encrypt_name,
0, 0);
gss_krb5_keys.c:if (crypto_sync_skcipher_setkey(cipher, inkey->data,
inkey->len))
gss_krb5_keys.c:crypto_free_sync_skcipher(cipher);
gss_krb5_mech.c:#include
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
> On Nov 12, 2020, at 10:42 AM, David Howells wrote: > > Chuck Lever wrote: > >>> There are three main interfaces to it: >>> >>> (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic. >>> >>>These all do in-place crypto, using an sglist to define the buffer >>>with the data in it. Is it necessary to make it able to take separate >>>input and output buffers? >> >> Hi David, Wondering if these "I/O" APIs use synchronous or async >> crypto under the covers. For small data items like MICs, synchronous >> might be a better choice, especially if asynchronous crypto could >> result in incoming requests getting re-ordered and falling out of >> the GSS sequence number window. >> >> What say ye? > > For the moment I'm using synchronous APIs as that's what sunrpc is using (I > borrowed the basic code from there). Really? My understanding of the Linux kernel SUNRPC implementation is that it uses asynchronous, even for small data items. Maybe I'm using the terminology incorrectly. The problem that arises is on the server. The asynchronous API can schedule, and if the server has other work to do, that can delay a verify_mic long enough that the request drops out of the GSS sequence number window (even a large window). Whatever the mechanism, we need to have deterministic ordering, at least on the server-side. > It would be interesting to consider using async, but there's a potential > issue. For the simplified profile, encryption and integrity checksum > generation can be done simultaneously, but decryption and verification can't. > For the AES-2 profile, the reverse is true. > > For my purposes in rxrpc, async mode isn't actually that useful since I'm only > doing the contents of a UDP packet at a time. Either I'm encrypting with the > intention of immediate transmission or decrypting with the intention of > immediately using the data, so I'm in a context where I can wait anyway. > > What might get me more of a boost would be to encrypt the app data directly > into a UDP packet and decrypt the UDP packet directly into the app buffers. > This is easier said than done, though, as there's typically security metadata > inserted into the packet inside the encrypted region. -- Chuck Lever
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
Chuck Lever wrote: > > There are three main interfaces to it: > > > > (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic. > > > > These all do in-place crypto, using an sglist to define the buffer > > with the data in it. Is it necessary to make it able to take separate > > input and output buffers? > > Hi David, Wondering if these "I/O" APIs use synchronous or async > crypto under the covers. For small data items like MICs, synchronous > might be a better choice, especially if asynchronous crypto could > result in incoming requests getting re-ordered and falling out of > the GSS sequence number window. > > What say ye? For the moment I'm using synchronous APIs as that's what sunrpc is using (I borrowed the basic code from there). It would be interesting to consider using async, but there's a potential issue. For the simplified profile, encryption and integrity checksum generation can be done simultaneously, but decryption and verification can't. For the AES-2 profile, the reverse is true. For my purposes in rxrpc, async mode isn't actually that useful since I'm only doing the contents of a UDP packet at a time. Either I'm encrypting with the intention of immediate transmission or decrypting with the intention of immediately using the data, so I'm in a context where I can wait anyway. What might get me more of a boost would be to encrypt the app data directly into a UDP packet and decrypt the UDP packet directly into the app buffers. This is easier said than done, though, as there's typically security metadata inserted into the packet inside the encrypted region. David
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
> On Nov 12, 2020, at 7:57 AM, David Howells wrote:
>
>
> Hi Herbert, Bruce,
>
> Here's my first cut at a generic Kerberos crypto library in the kernel so
> that I can share code between rxrpc and sunrpc (and cifs?).
>
> I derived some of the parts from the sunrpc gss library and added more
> advanced AES and Camellia crypto. I haven't ported across the DES-based
> crypto yet - I figure that can wait a bit till the interface is sorted.
>
> Whilst I have put it into a directory under crypto/, I haven't made an
> interface that goes and loads it (analogous to crypto_alloc_skcipher,
> say). Instead, you call:
>
>const struct krb5_enctype *crypto_krb5_find_enctype(u32 enctype);
>
> to go and get a handler table and then use a bunch of accessor functions to
> jump through the hoops. This is basically the way the sunrpc gsslib does
> things. It might be worth making it so you do something like:
>
> struct crypto_mech *ctx = crypto_mech_alloc("krb5(18)");
>
> to get enctype 18, but I'm not sure if it's worth the effort. Also, I'm
> not sure if there are any alternatives to kerberos we will need to support.
>
> There are three main interfaces to it:
>
> (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
>
> These all do in-place crypto, using an sglist to define the buffer
> with the data in it. Is it necessary to make it able to take separate
> input and output buffers?
Hi David, Wondering if these "I/O" APIs use synchronous or async
crypto under the covers. For small data items like MICs, synchronous
might be a better choice, especially if asynchronous crypto could
result in incoming requests getting re-ordered and falling out of
the GSS sequence number window.
What say ye?
> (*) PRF+ calculation for key derivation.
> (*) Kc, Ke, Ki derivation.
>
> These use krb5_buffer structs to pass objects around. This is akin to
> the xdr_netobj, but has a void* instead of a u8* data pointer.
>
> In terms of rxrpc's rxgk, there's another step in key derivation that isn't
> part of the kerberos standard, but uses the PRF+ function to generate a key
> that is then used to generate Kc, Ke and Ki. Is it worth putting this into
> the directory or maybe having a callout to insert an intermediate step in
> key derivation?
>
> Note that, for purposes of illustration, I've included some rxrpc patches
> that use this interface to implement the rxgk Rx security class. The
> branch also is based on some rxrpc patches that are a prerequisite for
> this, but the crypto patches don't need it.
>
> ---
> The patches can be found here also:
>
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=crypto-krb5
>
> David
> ---
> David Howells (18):
> crypto/krb5: Implement Kerberos crypto core
> crypto/krb5: Add some constants out of sunrpc headers
> crypto/krb5: Provide infrastructure and key derivation
> crypto/krb5: Implement the Kerberos5 rfc3961 key derivation
> crypto/krb5: Implement the Kerberos5 rfc3961 encrypt and decrypt
> functions
> crypto/krb5: Implement the Kerberos5 rfc3961 get_mic and verify_mic
> crypto/krb5: Implement the AES enctypes from rfc3962
> crypto/krb5: Implement crypto self-testing
> crypto/krb5: Implement the AES enctypes from rfc8009
> crypto/krb5: Implement the AES encrypt/decrypt from rfc8009
> crypto/krb5: Add the AES self-testing data from rfc8009
> crypto/krb5: Implement the Camellia enctypes from rfc6803
> rxrpc: Add the security index for yfs-rxgk
> rxrpc: Add YFS RxGK (GSSAPI) security class
> rxrpc: rxgk: Provide infrastructure and key derivation
> rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)
> rxrpc: rxgk: Implement connection rekeying
> rxgk: Support OpenAFS's rxgk implementation
>
>
> crypto/krb5/Kconfig |9 +
> crypto/krb5/Makefile | 11 +-
> crypto/krb5/internal.h | 101 +++
> crypto/krb5/kdf.c| 223 ++
> crypto/krb5/main.c | 190 +
> crypto/krb5/rfc3961_simplified.c | 732 ++
> crypto/krb5/rfc3962_aes.c| 140
> crypto/krb5/rfc6803_camellia.c | 249 ++
> crypto/krb5/rfc8009_aes2.c | 440 +++
> crypto/krb5/selftest.c | 543 +
> crypto/krb5/selftest_data.c | 289 +++
> fs/afs/misc.c| 13 +
> include/crypto/krb5.h| 100 +++
> include/keys/rxrpc-type.h| 17 +
> include/trace/events/rxrpc.h |4 +
> include/uapi/linux/rxrpc.h | 17 +
> net/rxrpc/Kconfig| 10 +
> net/rxrpc/Makefile |5 +
> net/rxrpc/ar-internal.h | 20 +
> net/rxrpc/conn_object.c |2 +
> net/rxrpc/key.c | 319
> net/rxrpc/rxgk.c | 1232 ++
> net/rxrpc/rxgk_app.c | 424 ++
>
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
Would it be possible/practical to make the skcipher encrypt functions take an offset into the scatterlist rather than always starting at the beginning? David
[RFC][PATCH 00/18] crypto: Add generic Kerberos library
Hi Herbert, Bruce,
Here's my first cut at a generic Kerberos crypto library in the kernel so
that I can share code between rxrpc and sunrpc (and cifs?).
I derived some of the parts from the sunrpc gss library and added more
advanced AES and Camellia crypto. I haven't ported across the DES-based
crypto yet - I figure that can wait a bit till the interface is sorted.
Whilst I have put it into a directory under crypto/, I haven't made an
interface that goes and loads it (analogous to crypto_alloc_skcipher,
say). Instead, you call:
const struct krb5_enctype *crypto_krb5_find_enctype(u32 enctype);
to go and get a handler table and then use a bunch of accessor functions to
jump through the hoops. This is basically the way the sunrpc gsslib does
things. It might be worth making it so you do something like:
struct crypto_mech *ctx = crypto_mech_alloc("krb5(18)");
to get enctype 18, but I'm not sure if it's worth the effort. Also, I'm
not sure if there are any alternatives to kerberos we will need to support.
There are three main interfaces to it:
(*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
These all do in-place crypto, using an sglist to define the buffer
with the data in it. Is it necessary to make it able to take separate
input and output buffers?
(*) PRF+ calculation for key derivation.
(*) Kc, Ke, Ki derivation.
These use krb5_buffer structs to pass objects around. This is akin to
the xdr_netobj, but has a void* instead of a u8* data pointer.
In terms of rxrpc's rxgk, there's another step in key derivation that isn't
part of the kerberos standard, but uses the PRF+ function to generate a key
that is then used to generate Kc, Ke and Ki. Is it worth putting this into
the directory or maybe having a callout to insert an intermediate step in
key derivation?
Note that, for purposes of illustration, I've included some rxrpc patches
that use this interface to implement the rxgk Rx security class. The
branch also is based on some rxrpc patches that are a prerequisite for
this, but the crypto patches don't need it.
---
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=crypto-krb5
David
---
David Howells (18):
crypto/krb5: Implement Kerberos crypto core
crypto/krb5: Add some constants out of sunrpc headers
crypto/krb5: Provide infrastructure and key derivation
crypto/krb5: Implement the Kerberos5 rfc3961 key derivation
crypto/krb5: Implement the Kerberos5 rfc3961 encrypt and decrypt functions
crypto/krb5: Implement the Kerberos5 rfc3961 get_mic and verify_mic
crypto/krb5: Implement the AES enctypes from rfc3962
crypto/krb5: Implement crypto self-testing
crypto/krb5: Implement the AES enctypes from rfc8009
crypto/krb5: Implement the AES encrypt/decrypt from rfc8009
crypto/krb5: Add the AES self-testing data from rfc8009
crypto/krb5: Implement the Camellia enctypes from rfc6803
rxrpc: Add the security index for yfs-rxgk
rxrpc: Add YFS RxGK (GSSAPI) security class
rxrpc: rxgk: Provide infrastructure and key derivation
rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)
rxrpc: rxgk: Implement connection rekeying
rxgk: Support OpenAFS's rxgk implementation
crypto/krb5/Kconfig |9 +
crypto/krb5/Makefile | 11 +-
crypto/krb5/internal.h | 101 +++
crypto/krb5/kdf.c| 223 ++
crypto/krb5/main.c | 190 +
crypto/krb5/rfc3961_simplified.c | 732 ++
crypto/krb5/rfc3962_aes.c| 140
crypto/krb5/rfc6803_camellia.c | 249 ++
crypto/krb5/rfc8009_aes2.c | 440 +++
crypto/krb5/selftest.c | 543 +
crypto/krb5/selftest_data.c | 289 +++
fs/afs/misc.c| 13 +
include/crypto/krb5.h| 100 +++
include/keys/rxrpc-type.h| 17 +
include/trace/events/rxrpc.h |4 +
include/uapi/linux/rxrpc.h | 17 +
net/rxrpc/Kconfig| 10 +
net/rxrpc/Makefile |5 +
net/rxrpc/ar-internal.h | 20 +
net/rxrpc/conn_object.c |2 +
net/rxrpc/key.c | 319
net/rxrpc/rxgk.c | 1232 ++
net/rxrpc/rxgk_app.c | 424 ++
net/rxrpc/rxgk_common.h | 164
net/rxrpc/rxgk_kdf.c | 271 +++
net/rxrpc/security.c |6 +
26 files changed, 5530 insertions(+), 1 deletion(-)
create mode 100644 crypto/krb5/kdf.c
create mode 100644 crypto/krb5/rfc3961_simplified.c
create mode 100644 crypto/krb5/rfc3962_aes.c
create mode 100644 crypto/krb5/rfc6803_camellia.c
create mode 100644 crypto/krb5/rfc8009_aes2.c
create mode 100644 crypto/krb5/selftest.c
create mode 100644 crypto/krb5/selftest_data.c
create mode
