Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Hi, On 10/26/2015 09:54 PM, Marcel Holtmann wrote: > Hi Stephan, > >> This patch set adds the AF_ALG user space API to externalize the >> asymmetric cipher API recently added to the kernel crypto API. >> >> The patch set is tested with the user space library of libkcapi [1]. >> Use [1] test/test.sh for a full test run. The test covers the >> following scenarios: >> >> * sendmsg of one IOVEC >> >> * sendmsg of 16 IOVECs with non-linear buffer >> >> * vmsplice of one IOVEC >> >> * vmsplice of 15 IOVECs with non-linear buffer >> >> * invoking multiple separate cipher operations with one >>open cipher handle >> >> * encryption with private key (using vector from testmgr.h) >> >> * encryption with public key (using vector from testmgr.h) >> >> * decryption with private key (using vector from testmgr.h) > > after having discussions with David Howells and David Woodhouse, I don't > think we should expose akcipher via AF_ALG at all. I think the akcipher > operations for sign/verify/encrypt/decrypt should operate on asymmetric keys > in the first place. With akcipher you are pretty much bound to public and > private keys and the key is the important part and not the akcipher itself. > Especially since we want to support private keys in hardware (like TPM for > example). > > It seems more appropriate to use keyctl to derive the symmetric session key > from your asymmetric key. And then use the symmetric session key id with > skcipher via AF_ALG. Especially once symmetric key type has been introduced > this seems to be trivial then. > > I am not really in favor of having two userspace facing APIs for asymmetric > cipher usage. And we need to have an API that is capable to work with > hardware keys. If we would have something like this: diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h index f2acd2f..02e6162 100644 --- a/include/uapi/linux/if_alg.h +++ b/include/uapi/linux/if_alg.h @@ -34,9 +34,12 @@ struct af_alg_iv { #define ALG_SET_OP 3 #define ALG_SET_AEAD_ASSOCLEN 4 #define ALG_SET_AEAD_AUTHSIZE 5 +#define ALG_SET_PUBKEY 6 +#define ALG_SET_PUBKEY_ID 7 in case of ALG_SET_PUBKEY the key will be provided by user space and in case of ALG_SET_PUBKEY_ID the PF_ALG layer will retrieve the key from the keyring using the ID provided form user space. Will this be ok with you Marcel and David? Thanks, -- TS -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Mittwoch, 28. Oktober 2015, 11:56:59 schrieb Marcel Holtmann: Hi Marcel, >> >> With all due respect, I would object here. When we say yes to TLS (even if >> it is parts of TLS up to the point where the KDF happens), we invite all >> higher level crypto implementations: IKE, SNMP, SSH -- I would not want to >> go down that path that started by simply supporting accelerated asymmetric >> ciphers. >Reality is that TLS in the kernel is happening. Reality is also that we do This is simply wrong IMHO for anything beyond the key handling. But that is not the topic here, I guess. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Hi Stephan, >> So if a server has public/private key pair, then the first thing that should >> the server do is load this key pair into the kernel and retrieve a key >> serial for it. And then use this key id to derive the session key. That >> session key can then be used with AF_ALG and skcipher for the data >> shoveling. >> >> However that all said, the keys should never leave the kernel. Neither the > > I personally do not fully agree here. For our day-to-day desktops and servers > I would fully and completely agree. But I see other use cases of Linux in > routers or other embedded systems where there may be other checks and > balances > in place where this hard demand is not warranted. actually in embedded devices (especially the tiny IoT stuff I am looking after) I really want keys in a central place and do not have to copy them around all the time. Keeping keys secure is actually a hard job. Doing that multiple places in the kernel and in userspace seems not a good idea. Especially not for an embedded device. The keys subsystem is great since it includes access control to your keys. If you have the right permissions you can get the keys back out if you want to. However if the key is locked down, you will not be able to read it again. I mean the keys subsystem can operate on per user, per process and per thread keys and access rights. So the policy that you are after is already done nicely via the keys subsystem. I really don't think we are limiting anything here. We are actually giving users more choice for policy. > Thus, I feel that this is a policy decision to be made in user space (see my > other email -- please answer on that topic there to keep a single thread). > >> private key nor the session key. There is no point in sending keys through >> userspace. We actually do not want this at all. That is especially >> important if your actual private/public key pair is in hardware. So maybe >> your RSA accelerator might expose secure storage for the keys. Loading them >> over and over again from userspace makes no sense. >> >> As David mentioned, we need to take a deep look at what the userspace API >> for asymmetric cipher suites (and we also have needs for ECDH etc. and not >> just RSA) should look like. Just exposing akcipher via AF_ALG is premature. >> If we expose it now, it is not an API that we can take back. Having two >> userspace APIs for the exactly the same functionality is a bad thing. >> Especially if one is limited to software only keys. > > Do not get me wrong, my patch is shall be there for all to comment. I have no > issues when we find a better solution. And I also do not like multiple > interfaces that would not be needed if we would have thought better. >> >> We also need to look at the larger picture here. And that is TLS support in >> the kernel. Potentially via AF_KCM or something similar. > > With all due respect, I would object here. When we say yes to TLS (even if it > is parts of TLS up to the point where the KDF happens), we invite all higher > level crypto implementations: IKE, SNMP, SSH -- I would not want to go down > that path that started by simply supporting accelerated asymmetric ciphers. Reality is that TLS in the kernel is happening. Reality is also that we do signing and certificate handling in the kernel. How much of the cipher negotiations and key derivation happens in kernel vs userspace is something to be still discussed. And there will be userspace involved for sure. However that does not mean that we keep moving keys through userspace to just load it back into another subsystem. That kind of API really needs to stop. One other note I make is that we are looking at such tiny systems that including OpenSSL or GnuTLS is not an option at all. However we do use secure boot and need to be able to handle certificates and TLS. > Look at user space crypto libs: where is the most fuzz happening? Not in the > cipher implementations, but in the network protocols. Ciphers itself are easy of course. What we are saying here is that we do not have the cipher as the main important input on what to do. We have the key itself. The key decides what options for ciphers or fallback ciphers we have. So let me repeat this, we need to think really hard about supporting hardware keys. We need to see the bigger picture. Just looking at ciphers is not enough. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
On Wed, 2015-10-28 at 02:18 +0100, Stephan Mueller wrote: > > But having a tie between both, the kernel crypto API and the key system, that > cannot be cut any more is something I am not sure about. Both should and > would > work in isolation of each other as both serve different needs. Sure, let people load keys directly without having to instantiate keys and then reference them. My point is that only an API which permits *both* models is acceptable. Otherwise, people build bogus assumptions all the way up the stack. Having both ALG_SET_KEY and ALG_SET_KEY_ID in parallel seems ideal. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Mittwoch, 28. Oktober 2015, 09:46:51 schrieb Marcel Holtmann: Hi Marcel, > So if a server has public/private key pair, then the first thing that should > the server do is load this key pair into the kernel and retrieve a key > serial for it. And then use this key id to derive the session key. That > session key can then be used with AF_ALG and skcipher for the data > shoveling. > > However that all said, the keys should never leave the kernel. Neither the I personally do not fully agree here. For our day-to-day desktops and servers I would fully and completely agree. But I see other use cases of Linux in routers or other embedded systems where there may be other checks and balances in place where this hard demand is not warranted. Thus, I feel that this is a policy decision to be made in user space (see my other email -- please answer on that topic there to keep a single thread). > private key nor the session key. There is no point in sending keys through > userspace. We actually do not want this at all. That is especially > important if your actual private/public key pair is in hardware. So maybe > your RSA accelerator might expose secure storage for the keys. Loading them > over and over again from userspace makes no sense. > > As David mentioned, we need to take a deep look at what the userspace API > for asymmetric cipher suites (and we also have needs for ECDH etc. and not > just RSA) should look like. Just exposing akcipher via AF_ALG is premature. > If we expose it now, it is not an API that we can take back. Having two > userspace APIs for the exactly the same functionality is a bad thing. > Especially if one is limited to software only keys. Do not get me wrong, my patch is shall be there for all to comment. I have no issues when we find a better solution. And I also do not like multiple interfaces that would not be needed if we would have thought better. > > We also need to look at the larger picture here. And that is TLS support in > the kernel. Potentially via AF_KCM or something similar. With all due respect, I would object here. When we say yes to TLS (even if it is parts of TLS up to the point where the KDF happens), we invite all higher level crypto implementations: IKE, SNMP, SSH -- I would not want to go down that path that started by simply supporting accelerated asymmetric ciphers. Look at user space crypto libs: where is the most fuzz happening? Not in the cipher implementations, but in the network protocols. -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Mittwoch, 28. Oktober 2015, 09:37:02 schrieb David Woodhouse: Hi David, > On Wed, 2015-10-28 at 00:47 +0100, Stephan Mueller wrote: > > Ohh, I see. So, you are saying that there should not be a setpub/privkey > > for the akcipher AF_ALG interface?! > > > > If somebody wants to use akcipher, he shall set the key via the keyring > > and > > akcipher shall obtain it from the keyring? > > > > However, for the actual data shoveling, AF_ALG should still be used? > > That might seem ideal, but Herbert doesn't want that — he wants > akcipher to work *only* with its own internal keys, not with keys from > the kernel's key subsystem. > > David has patches (not upstream yet; used for testing) which expose a > verify operation for kernel keys through sys_keyctl(). Adding the other > three operations would be feasible. > > Perhaps if we *really* want this to appear through AF_ALG, the key > subsystem could register its own RSA (and other) implementation(s) with > the crypto subsystem. Then we could find some way that we can pass the > key_serial_t through alg_setkey() instead of the actual key data > without it (or Herbert) noticing that's what we're doing. But... ick. > And I don't think we can select algorithms based on the actual key > rather than the type. We should do it properly, if at all. And define > the API as taking key IDs instead of having it be a nasty special-case > hack for a specific (but really, very generic) algorithm provider. First of all, I personally would not insist on an AF_ALG for pure akcipher externalization. Integrating it with the key subsystem looks like a fine idea. But that would imply that we tie the crypto API quite hard with the key retention system which I guess may not be warranted. Note, I was playing with the idea of using the key retention system for the kernel crypto API myself (hence also my patch to add key wrapping support which has its roots there). But having a tie between both, the kernel crypto API and the key system, that cannot be cut any more is something I am not sure about. Both should and would work in isolation of each other as both serve different needs. But I agree that when having both and the user wants proper key management, the key system should be used. But isn't that already a policy decision of the user/administrator? IIRC, the kernel should not hard-wire policies that may or may not be wanted by user space. Hence, the decision about connecting both systems should rest in user space. And the kernel should support a joint operation of both. -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Hi Stephan, >>> Albeit that all sounds like the crown jewel, how do you propose that shall >>> happen? >>> >>> Assume that you have a web server that has a pub and priv key in its >>> current configuration -- I guess that is the vast majority of configs. >>> >>> Can you please elaborate how the process for such a web server shall >>> really >>> work? >> >> 1. Create a kernel-side key. >> 2. Use it. >> >> That may require adding an API similar to the one you're proposing, but >> working with kernel keys instead of directly with akcipher. Or perhaps >> the key subsystem can already offer what you need in userspace. David? > > Ohh, I see. So, you are saying that there should not be a setpub/privkey for > the akcipher AF_ALG interface?! I tested support for adding ALG_SET_KEY_ID which takes the 32-bit key serial and then using AF_ALG with an skcipher. That works so far so fine. For making this super clean and get it upstream, it needs a symmetric key type (which is planned to be added by David). I can post my current patch as RFC since it is dead simple actually. > If somebody wants to use akcipher, he shall set the key via the keyring and > akcipher shall obtain it from the keyring? > > However, for the actual data shoveling, AF_ALG should still be used? There is no massive data shoveling by an akcipher. All data shoveling for TLS is done via the symmetric session key that is negotiated. Actually with asymmetric ciphers, your keys will be normally larger than your clear text anyway. So if a server has public/private key pair, then the first thing that should the server do is load this key pair into the kernel and retrieve a key serial for it. And then use this key id to derive the session key. That session key can then be used with AF_ALG and skcipher for the data shoveling. However that all said, the keys should never leave the kernel. Neither the private key nor the session key. There is no point in sending keys through userspace. We actually do not want this at all. That is especially important if your actual private/public key pair is in hardware. So maybe your RSA accelerator might expose secure storage for the keys. Loading them over and over again from userspace makes no sense. As David mentioned, we need to take a deep look at what the userspace API for asymmetric cipher suites (and we also have needs for ECDH etc. and not just RSA) should look like. Just exposing akcipher via AF_ALG is premature. If we expose it now, it is not an API that we can take back. Having two userspace APIs for the exactly the same functionality is a bad thing. Especially if one is limited to software only keys. We also need to look at the larger picture here. And that is TLS support in the kernel. Potentially via AF_KCM or something similar. And with TLS in mind, we actually do want to just load the whole X.509 certificate into the key subsystem. It will then allow you retrieve the key id, validate the certificate and use the key. Current kernels already support this kind of functionality and we want to enable this and extend it. Having random pieces in userspace and/or kernel space to extract keys from the containers is a pretty bad idea. We really want this centralized. Here the same goal applies, to not have multiple userspace APIs doing the same thing. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
On Wed, 2015-10-28 at 00:47 +0100, Stephan Mueller wrote: > > Ohh, I see. So, you are saying that there should not be a setpub/privkey for > the akcipher AF_ALG interface?! > > If somebody wants to use akcipher, he shall set the key via the keyring and > akcipher shall obtain it from the keyring? > > However, for the actual data shoveling, AF_ALG should still be used? That might seem ideal, but Herbert doesn't want that — he wants akcipher to work *only* with its own internal keys, not with keys from the kernel's key subsystem. David has patches (not upstream yet; used for testing) which expose a verify operation for kernel keys through sys_keyctl(). Adding the other three operations would be feasible. Perhaps if we *really* want this to appear through AF_ALG, the key subsystem could register its own RSA (and other) implementation(s) with the crypto subsystem. Then we could find some way that we can pass the key_serial_t through alg_setkey() instead of the actual key data without it (or Herbert) noticing that's what we're doing. But... ick. And I don't think we can select algorithms based on the actual key rather than the type. We should do it properly, if at all. And define the API as taking key IDs instead of having it be a nasty special-case hack for a specific (but really, very generic) algorithm provider. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Mittwoch, 28. Oktober 2015, 08:43:16 schrieb David Woodhouse: Hi David, > > Albeit that all sounds like the crown jewel, how do you propose that shall > > happen? > > > > Assume that you have a web server that has a pub and priv key in its > > current configuration -- I guess that is the vast majority of configs. > > > > Can you please elaborate how the process for such a web server shall > > really > > work? > > 1. Create a kernel-side key. > 2. Use it. > > That may require adding an API similar to the one you're proposing, but > working with kernel keys instead of directly with akcipher. Or perhaps > the key subsystem can already offer what you need in userspace. David? Ohh, I see. So, you are saying that there should not be a setpub/privkey for the akcipher AF_ALG interface?! If somebody wants to use akcipher, he shall set the key via the keyring and akcipher shall obtain it from the keyring? However, for the actual data shoveling, AF_ALG should still be used? -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
On Wed, 2015-10-28 at 00:35 +0100, Stephan Mueller wrote: > Am Mittwoch, 28. Oktober 2015, 08:15:16 schrieb David Woodhouse: > > Hi David, > > > > Absolutely. The interface needs to support *both*. > > > > I've spent a lot of time chasing through userspace stacks, fixing > > broken assumptions that we will *always* have the actual key material > > in a file — and making libraries and applications accept PKCS#11 URIs > > referring to keys in hardware as well as filenames. > > > > I am violently opposed to exposing an API from the kernel which makes > > that *same* fundamental mistake, and ties its users to using *only* > > software keys. > > > > FROM THE BEGINNING, users of this new API should be able to cope with > > the fact that they might not *have* the key material, and that they > > might simply be referring to a key which exists elsewhere. Such as in > > the TPM, or within an SGX software enclave. > > Albeit that all sounds like the crown jewel, how do you propose that shall > happen? > > Assume that you have a web server that has a pub and priv key in its current > configuration -- I guess that is the vast majority of configs. > > Can you please elaborate how the process for such a web server shall really > work? 1. Create a kernel-side key. 2. Use it. That may require adding an API similar to the one you're proposing, but working with kernel keys instead of directly with akcipher. Or perhaps the key subsystem can already offer what you need in userspace. David? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Mittwoch, 28. Oktober 2015, 08:15:16 schrieb David Woodhouse: Hi David, > >Absolutely. The interface needs to support *both*. > >I've spent a lot of time chasing through userspace stacks, fixing >broken assumptions that we will *always* have the actual key material >in a file — and making libraries and applications accept PKCS#11 URIs >referring to keys in hardware as well as filenames. > >I am violently opposed to exposing an API from the kernel which makes >that *same* fundamental mistake, and ties its users to using *only* >software keys. > >FROM THE BEGINNING, users of this new API should be able to cope with >the fact that they might not *have* the key material, and that they >might simply be referring to a key which exists elsewhere. Such as in >the TPM, or within an SGX software enclave. Albeit that all sounds like the crown jewel, how do you propose that shall happen? Assume that you have a web server that has a pub and priv key in its current configuration -- I guess that is the vast majority of configs. Can you please elaborate how the process for such a web server shall really work? Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
On Tue, 2015-10-27 at 11:50 +0100, Stephan Mueller wrote: > > >expose that critically limited API to userspace. We need to expose an > >API which supports hardware keys, and basically that means using the > >kernel's key subsystem. > > Agreed. But at the same time, that interface should be able to support the > use > case where the software wants to be in control (just take OpenSSL as the > simple example where you can add an engine for the Linux kernel backed RSA > operation). Absolutely. The interface needs to support *both*. I've spent a lot of time chasing through userspace stacks, fixing broken assumptions that we will *always* have the actual key material in a file — and making libraries and applications accept PKCS#11 URIs referring to keys in hardware as well as filenames. I am violently opposed to exposing an API from the kernel which makes that *same* fundamental mistake, and ties its users to using *only* software keys. FROM THE BEGINNING, users of this new API should be able to cope with the fact that they might not *have* the key material, and that they might simply be referring to a key which exists elsewhere. Such as in the TPM, or within an SGX software enclave. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Hi Marcel, On 10/26/2015 09:54 PM, Marcel Holtmann wrote: > after having discussions with David Howells and David Woodhouse, I don't > think we should expose akcipher via AF_ALG at all. I think the akcipher > operations for sign/verify/encrypt/decrypt should operate on asymmetric keys > in the first place. With akcipher you are pretty much bound to public and > private keys and the key is the important part and not the akcipher itself. > Especially since we want to support private keys in hardware (like TPM for > example). > > It seems more appropriate to use keyctl to derive the symmetric session key > from your asymmetric key. And then use the symmetric session key id with > skcipher via AF_ALG. Especially once symmetric key type has been introduced > this seems to be trivial then. > > I am not really in favor of having two userspace facing APIs for asymmetric > cipher usage. And we need to have an API that is capable to work with > hardware keys. The main use case for algif_akcipher will be to allow a web server, which needs to handle tens of thousand TLS handshakes per second, to offload the RSA operation to a HW accelerator. Do you think we can use keyctl for this? Thanks, T -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Dienstag, 27. Oktober 2015, 18:19:01 schrieb David Woodhouse: Hi David, > >That's largely orthogonal to the point Marcel was making. > >The point is that akcipher is limited to using keys for which we have >the private key material available directly in software. We cannot Agreed. >expose that critically limited API to userspace. We need to expose an >API which supports hardware keys, and basically that means using the >kernel's key subsystem. Agreed. But at the same time, that interface should be able to support the use case where the software wants to be in control (just take OpenSSL as the simple example where you can add an engine for the Linux kernel backed RSA operation). Note, the goal with AF_ALG is simply to expose asymmetric hardware support to user space for unspecified use cases to make user space faster. > >For a key which *happens* to be in software, the key subsystem may end >up *using* akcipher behind the scenes. But the API we expose to >userspace cannot simply be based on akcipher. So, how do you propose that would work? Based on what I understand the suggested logic flow for a simple OpenSSL-like approach would be: 1. OpenSSL opens the interface with the kernel key subsystem and sends the pub/priv key along 2. the key subsystem hooks the key in 3. the key subsystem sees that there is a simple RSA operation to be made 4. the key subsystem initiates an akcipher operation and sends the keys along 5. the akcipher returns the cipher result to the key subsystem 6. the key subsystem sends the data to user space Currently I fail to understand why that key subsystem would help me in that common use case (note, I totally understand to use the key subsystem when you have some key management schema in place). Also, I fail to see that this logic flow would be fast to warrant a detour from user land into kernel land for an RSA operation. Thanks Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
On Tue, 2015-10-27 at 10:12 +0100, Stephan Mueller wrote: > > >after having discussions with David Howells and David Woodhouse, I don't > >think we should expose akcipher via AF_ALG at all. I think the akcipher > >operations for sign/verify/encrypt/decrypt should operate on asymmetric keys > >in the first place. With akcipher you are pretty much bound to public and > >private keys and the key is the important part and not the akcipher itself. > >Especially since we want to support private keys in hardware (like TPM for > >example). > > > >It seems more appropriate to use keyctl to derive the symmetric session key > > Are you saying that you consider importing parts of TLS into the kernel? > Considering the use case where akcipher would be used to speed up network > protocols, I would imply that your comment refers to importing parts of that > network protocol into the kernel. > > The key derivation that you mention here would be: RSA-based key exchange > plus > the TLS KDF. Do we really want to load that into the kernel given that TLS is > one protocol and there are many others? That's largely orthogonal to the point Marcel was making. The point is that akcipher is limited to using keys for which we have the private key material available directly in software. We cannot expose that critically limited API to userspace. We need to expose an API which supports hardware keys, and basically that means using the kernel's key subsystem. For a key which *happens* to be in software, the key subsystem may end up *using* akcipher behind the scenes. But the API we expose to userspace cannot simply be based on akcipher. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Dienstag, 27. Oktober 2015, 13:54:30 schrieb Marcel Holtmann: Hi Marcel, >Hi Stephan, > >> This patch set adds the AF_ALG user space API to externalize the >> asymmetric cipher API recently added to the kernel crypto API. >> >> The patch set is tested with the user space library of libkcapi [1]. >> Use [1] test/test.sh for a full test run. The test covers the >> >> following scenarios: >> * sendmsg of one IOVEC >> >> * sendmsg of 16 IOVECs with non-linear buffer >> >> * vmsplice of one IOVEC >> >> * vmsplice of 15 IOVECs with non-linear buffer >> >> * invoking multiple separate cipher operations with one >> >>open cipher handle >> >> * encryption with private key (using vector from testmgr.h) >> >> * encryption with public key (using vector from testmgr.h) >> >> * decryption with private key (using vector from testmgr.h) > >after having discussions with David Howells and David Woodhouse, I don't >think we should expose akcipher via AF_ALG at all. I think the akcipher >operations for sign/verify/encrypt/decrypt should operate on asymmetric keys >in the first place. With akcipher you are pretty much bound to public and >private keys and the key is the important part and not the akcipher itself. >Especially since we want to support private keys in hardware (like TPM for >example). > >It seems more appropriate to use keyctl to derive the symmetric session key Are you saying that you consider importing parts of TLS into the kernel? Considering the use case where akcipher would be used to speed up network protocols, I would imply that your comment refers to importing parts of that network protocol into the kernel. The key derivation that you mention here would be: RSA-based key exchange plus the TLS KDF. Do we really want to load that into the kernel given that TLS is one protocol and there are many others? >from your asymmetric key. And then use the symmetric session key id with >skcipher via AF_ALG. Especially once symmetric key type has been introduced >this seems to be trivial then. > >I am not really in favor of having two userspace facing APIs for asymmetric >cipher usage. And we need to have an API that is capable to work with >hardware keys. > >Regards > >Marcel > >-- >To unsubscribe from this list: send the line "unsubscribe linux-crypto" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Hi Stephan, > This patch set adds the AF_ALG user space API to externalize the > asymmetric cipher API recently added to the kernel crypto API. > > The patch set is tested with the user space library of libkcapi [1]. > Use [1] test/test.sh for a full test run. The test covers the > following scenarios: > > * sendmsg of one IOVEC > > * sendmsg of 16 IOVECs with non-linear buffer > > * vmsplice of one IOVEC > > * vmsplice of 15 IOVECs with non-linear buffer > > * invoking multiple separate cipher operations with one > open cipher handle > > * encryption with private key (using vector from testmgr.h) > > * encryption with public key (using vector from testmgr.h) > > * decryption with private key (using vector from testmgr.h) after having discussions with David Howells and David Woodhouse, I don't think we should expose akcipher via AF_ALG at all. I think the akcipher operations for sign/verify/encrypt/decrypt should operate on asymmetric keys in the first place. With akcipher you are pretty much bound to public and private keys and the key is the important part and not the akcipher itself. Especially since we want to support private keys in hardware (like TPM for example). It seems more appropriate to use keyctl to derive the symmetric session key from your asymmetric key. And then use the symmetric session key id with skcipher via AF_ALG. Especially once symmetric key type has been introduced this seems to be trivial then. I am not really in favor of having two userspace facing APIs for asymmetric cipher usage. And we need to have an API that is capable to work with hardware keys. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
On Mon, Oct 19, 2015 at 09:14:09AM +0200, Stephan Mueller wrote: > > However, I would suggest that you pull patch 1/5 as this is a bug fix that > may > affect even other users. Sure I'll look into it. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Montag, 19. Oktober 2015, 09:32:30 schrieb Herbert Xu: Hi Herbert, > On Sun, Oct 18, 2015 at 12:44:00PM +0200, Stephan Mueller wrote: > > Hi, > > > > This patch set adds the AF_ALG user space API to externalize the > > asymmetric cipher API recently added to the kernel crypto API. > > > > The patch set is tested with the user space library of libkcapi [1]. > > Use [1] test/test.sh for a full test run. The test covers the > > > following scenarios: > Thanks Stephan. But I would prefer to defer this til after we have > completed the conversion of current in-kernel users. This is because > changing the kernel interface is easy while changing the user-space > interface is not. Sure, let us wait. However, I would suggest that you pull patch 1/5 as this is a bug fix that may affect even other users. -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
On Sun, Oct 18, 2015 at 12:44:00PM +0200, Stephan Mueller wrote: > Hi, > > This patch set adds the AF_ALG user space API to externalize the > asymmetric cipher API recently added to the kernel crypto API. > > The patch set is tested with the user space library of libkcapi [1]. > Use [1] test/test.sh for a full test run. The test covers the > following scenarios: Thanks Stephan. But I would prefer to defer this til after we have completed the conversion of current in-kernel users. This is because changing the kernel interface is easy while changing the user-space interface is not. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] crypto: add algif_akcipher user space API
Hi, This patch set adds the AF_ALG user space API to externalize the asymmetric cipher API recently added to the kernel crypto API. The patch set is tested with the user space library of libkcapi [1]. Use [1] test/test.sh for a full test run. The test covers the following scenarios: * sendmsg of one IOVEC * sendmsg of 16 IOVECs with non-linear buffer * vmsplice of one IOVEC * vmsplice of 15 IOVECs with non-linear buffer * invoking multiple separate cipher operations with one open cipher handle * encryption with private key (using vector from testmgr.h) * encryption with public key (using vector from testmgr.h) * decryption with private key (using vector from testmgr.h) The patch set includes a fix for the MPI parsing that is visible when using SGL members that contain one byte. Changes v2: * use updated SGL-based akcipher API * allow mix-n-match of sendmsg and vmsplice calls [1] http://www.chronox.de/libkcapi.html Stephan Mueller (5): MPI: fix off by one in mpi_read_raw_from_sgl crypto: AF_ALG -- add sign/verify API crypto: AF_ALG -- add setpubkey setsockopt call crypto: AF_ALG -- add asymmetric cipher interface crypto: algif_akcipher - enable compilation crypto/Kconfig | 9 + crypto/Makefile | 1 + crypto/af_alg.c | 14 +- crypto/algif_akcipher.c | 542 include/crypto/if_alg.h | 1 + include/uapi/linux/if_alg.h | 3 + lib/mpi/mpicoder.c | 5 +- 7 files changed, 571 insertions(+), 4 deletions(-) create mode 100644 crypto/algif_akcipher.c -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html