Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Tudor - On Mon, 2 Oct 2017, Tudor Ambarus wrote: Hi, all, On 08/10/2017 09:39 AM, Stephan Müller 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. Do we have enough pros and cons so we can decide which interface to use for exporting akcipher/kpp to user-space? I'm willing to invest some time to make this happen. David Howells has a branch implementing asymmetric crypto operations using keyctl: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-asym-keyctl That's based on v4.8-rc1, but I've been merging it with more recent kernels, and it's been working fine: https://git.kernel.org/pub/scm/linux/kernel/git/martineau/linux.git/log/?h=ell-key-crypto As far as I know, these keyctl operations are not upstream yet because there isn't yet a hardware (TPM) asymmetric key subtype that would allow the key subsystem to choose between akcipher or TPM crypto depending on the key subtype in use. I'd like to see the functionality merged even with only akcipher support. The only issue I've had with the existing patch set is that RSA verification can't unpad certain results before comparing because the necessary functionality was removed from rsa-pkcs1pad in the kernel. This isn't a limitation of the keyctl patch set, though. A handful of the people on this thread had agreed to move ahead with the keyctl API because it could handle key material well and choose between crypto engines (including engines that did not support software fallback) - that's when David put together his patches. David, is there help you could use with the hardware asymmetric key subtype or other aspects of keyctl crypto? -- Mat Martineau Intel OTC
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Tudor, >> you still need to get the public key out of the kernel if you want to use it >> from user space. Or feed the remote public key if you plan to use some sort >> of key derivation function. > > The crypto hardware that I'm working on, generates the private key > internally within the device and never reveals it to software and > immediately returns the public key pair. The user can retrieve the > public key from hardware. and don’t we want some sort of access control here. Only the user / process that requested the private key and has access to the public key is allowed to keep using the private key? >> I am saying this again, if you only have a hammer, everything looks like a >> nail. What about actually looking at how this would be used from user space >> in real crypto cases. >> My point is that the usages here are key generation, some sort of >> key-exchange-agreement (aka DH) and key derivation into a symmetric key. >> Frankly the focus with asymmetric ciphers are the keys and the key >> derivation. They are not encryption and decryption of massive amounts of >> data. > > The hardware uses it's own private key and the public key received from > the other end and computes the ecdh shared secret. The hardware computed > shared secret can then be used for key derivation. And that is normally the case. Get your local public key, send it to the other side, get the other sides public key, give it to the hardware and get shared secret. So how is AF_ALG a good fit here? Regards Marcel
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi, Marcel, On 08/30/2017 10:21 AM, Marcel Holtmann wrote: you still need to get the public key out of the kernel if you want to use it from user space. Or feed the remote public key if you plan to use some sort of key derivation function. The crypto hardware that I'm working on, generates the private key internally within the device and never reveals it to software and immediately returns the public key pair. The user can retrieve the public key from hardware. I am saying this again, if you only have a hammer, everything looks like a nail. What about actually looking at how this would be used from user space in real crypto cases. My point is that the usages here are key generation, some sort of key-exchange-agreement (aka DH) and key derivation into a symmetric key. Frankly the focus with asymmetric ciphers are the keys and the key derivation. They are not encryption and decryption of massive amounts of data. The hardware uses it's own private key and the public key received from the other end and computes the ecdh shared secret. The hardware computed shared secret can then be used for key derivation. Cheers, ta
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Tudor, > akcipher can work with its own internal keys, now that we have crypto > accelerators that can generate keys that never leave the hardware. Going > through the kernel's key subsystem seems superfluous in this case. > > I also understand the need of going through the kernel's key subsystem > when the user wants to refer to a key which exists elsewhere, such as in > TPM or within an SGX software enclave, but this seems orthogonal with > crypto accelerators with key generation and retention support. > > How should we interface akcipher/kpp with user-space? you still need to get the public key out of the kernel if you want to use it from user space. Or feed the remote public key if you plan to use some sort of key derivation function. I am saying this again, if you only have a hammer, everything looks like a nail. What about actually looking at how this would be used from user space in real crypto cases. My point is that the usages here are key generation, some sort of key-exchange-agreement (aka DH) and key derivation into a symmetric key. Frankly the focus with asymmetric ciphers are the keys and the key derivation. They are not encryption and decryption of massive amounts of data. Regards Marcel
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi, Herbert, all, akcipher can work with its own internal keys, now that we have crypto accelerators that can generate keys that never leave the hardware. Going through the kernel's key subsystem seems superfluous in this case. I also understand the need of going through the kernel's key subsystem when the user wants to refer to a key which exists elsewhere, such as in TPM or within an SGX software enclave, but this seems orthogonal with crypto accelerators with key generation and retention support. How should we interface akcipher/kpp with user-space? Thanks, ta On 08/17/2017 04:17 PM, Tudor Ambarus wrote: Hi, all, On 08/11/2017 07:05 PM, Marcel Holtmann wrote: Hi Stephan, AF_ALG is best suited for crypto use cases where a socket is set up once and there are lots of reads and writes to justify the setup cost. With asymmetric crypto, the setup cost is high when you might only use the socket for a brief time to do one verify or encrypt operation. To me, the entire AF_ALG purpose is solely to export hardware support to user space. That said, if user space wants an accelerator, a socket would be opened once followed by numerous read/write requests. Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring and I planned to port it to the current implementation. But I thought I offer a small patch focusing on the externalization of the akcipher API first. I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to each other. The statement I made for the KPP AF_ALG RFC applies here too: """ I am aware and in fact supported development of the DH support in the keys subsystem. The question will be raised whether the AF_ALG KPP interface is superfluous in light of the keys DH support. My answer is that AF_ALG KPP is orthogonal to the keys DH support. The keys DH support use case is that the keys are managed inside the kernel and thus has the focus on the key management. Contrary, AF_ALG KPP does not really focus on key management but simply externalizes the DH/ECDH support found in the kernel including hardware acceleration. User space is in full control of the key life cycle. This way, AF_ALG could be used to complement user-space network protocol implementations like TLS or IKE to offload the resource intense DH calculations to accelerators. “"" we do not need two interfaces for doing the same thing. Especially not one that can not handle hardware backed keys. And more important if you can not abstract an accelerator that doesn’t expose the private key at all. I'm working with a crypto accelerator (find it at [1]) that is capable of generating random ecc private keys internally within the device that are never revealed outside of it. The keys can be further used for ECDH and ECDSA. The simplest way to access my device from user-space is to go through af_alg. We can permit the users to provide NULL keys, and if so, we can generate the keys inside the kernel/hardware. If hardware supports key generation and retention, it will use it, else the keys will be generated inside the kernel. Either way it's a win, we don't reveal the private keys to user-space. Going through the keyring subsystem seems superfluous in this case. My use case compared with the one of using keyring subsystem to access keys from TPMs or Intel's sgx enclave seem orthogonal. What do you think? Cheers, ta [1] http://www.microchip.com/wwwproducts/en/ATECC508A The driver can be found in drivers/crypto/atmel-ecc* in Herbert's tree.
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi, all, On 08/11/2017 07:05 PM, Marcel Holtmann wrote: Hi Stephan, AF_ALG is best suited for crypto use cases where a socket is set up once and there are lots of reads and writes to justify the setup cost. With asymmetric crypto, the setup cost is high when you might only use the socket for a brief time to do one verify or encrypt operation. To me, the entire AF_ALG purpose is solely to export hardware support to user space. That said, if user space wants an accelerator, a socket would be opened once followed by numerous read/write requests. Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring and I planned to port it to the current implementation. But I thought I offer a small patch focusing on the externalization of the akcipher API first. I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to each other. The statement I made for the KPP AF_ALG RFC applies here too: """ I am aware and in fact supported development of the DH support in the keys subsystem. The question will be raised whether the AF_ALG KPP interface is superfluous in light of the keys DH support. My answer is that AF_ALG KPP is orthogonal to the keys DH support. The keys DH support use case is that the keys are managed inside the kernel and thus has the focus on the key management. Contrary, AF_ALG KPP does not really focus on key management but simply externalizes the DH/ECDH support found in the kernel including hardware acceleration. User space is in full control of the key life cycle. This way, AF_ALG could be used to complement user-space network protocol implementations like TLS or IKE to offload the resource intense DH calculations to accelerators. “"" we do not need two interfaces for doing the same thing. Especially not one that can not handle hardware backed keys. And more important if you can not abstract an accelerator that doesn’t expose the private key at all. I'm working with a crypto accelerator (find it at [1]) that is capable of generating random ecc private keys internally within the device that are never revealed outside of it. The keys can be further used for ECDH and ECDSA. The simplest way to access my device from user-space is to go through af_alg. We can permit the users to provide NULL keys, and if so, we can generate the keys inside the kernel/hardware. If hardware supports key generation and retention, it will use it, else the keys will be generated inside the kernel. Either way it's a win, we don't reveal the private keys to user-space. Going through the keyring subsystem seems superfluous in this case. My use case compared with the one of using keyring subsystem to access keys from TPMs or Intel's sgx enclave seem orthogonal. What do you think? Cheers, ta [1] http://www.microchip.com/wwwproducts/en/ATECC508A The driver can be found in drivers/crypto/atmel-ecc* in Herbert's tree.
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Stephan, >>> The first part is clearly where AF_ALG fits and keyctl does not. This is >>> provided with the current patch set. As the keyctl API only handles, well, >>> keys, access to the raw ciphers may not be possible through this API. And >>> let us face it, a lot of user space code shall support many different >>> OSes. Thus, if you have a crypto lib in user space who has its own key >>> management (which is a core element of such libraries and thus cannot be >>> put into an architecture-dependent code part), having only the keyctl API >>> on Linux for accelerated asym support may not be helpful. >> >> That argument is just non-sense. > > How interesting. For example, what about NSS with its own key database? a lot of applications create their own key or certificate database. It also means they need to reload and reload them over and over again for each process. A lot of things are possible, but why keep doing things more complicated than they need to be. As I said before, if you only have a hammer .. Regards Marcel
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Am Montag, 14. August 2017, 08:26:22 CEST schrieb Marcel Holtmann: Hi Marcel, > > The first part is clearly where AF_ALG fits and keyctl does not. This is > > provided with the current patch set. As the keyctl API only handles, well, > > keys, access to the raw ciphers may not be possible through this API. And > > let us face it, a lot of user space code shall support many different > > OSes. Thus, if you have a crypto lib in user space who has its own key > > management (which is a core element of such libraries and thus cannot be > > put into an architecture-dependent code part), having only the keyctl API > > on Linux for accelerated asym support may not be helpful. > > That argument is just non-sense. How interesting. For example, what about NSS with its own key database? Ciao Stephan
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Stephan, >> I also would like to have more of those algorithms exposed to userspace, >> and I'd like to make sure the API is a good fit. There was extensive >> discussion of AF_ALG akcipher last year. v8 of the patch set updates the >> implementation but doesn't address the API concerns that kept the previous >> versions from being merged, so we seem to be at just as much of an impasse >> as before. > > During last year's discussion, I think we have concluded (and please correct > me if I miss something), that the export of the asymmetric HW implementations > to user space should > > - allow a streaming mode where the user space uses the kernel as an > accelerator (maybe user space has another way of storing keys) explain to me what a streaming mode with an asymmetric cipher is? They are no good for these kind of operations. If you want streaming mode, then you want a symmetric cipher. The keyring subsystem is actually a good storage for keys. If the keyring subsystem can use hardware storage for the keys, even better. However right now all the certificates and its associated keys are stored perfectly fine in a keyring. > - allow the private key to be retained in kernel space (or even in hardware > only) -- i.e. user space only has a handle to the key for a full asym > operation And that is exactly my point. Even if userspace has the key, let it load into the kernel as a key inside a keyring. We do not need two ways for loading asymmetric keys. They are by nature more complex then any symmetric key. > The first part is clearly where AF_ALG fits and keyctl does not. This is > provided with the current patch set. As the keyctl API only handles, well, > keys, access to the raw ciphers may not be possible through this API. And let > us face it, a lot of user space code shall support many different OSes. Thus, > if you have a crypto lib in user space who has its own key management (which > is a core element of such libraries and thus cannot be put into an > architecture-dependent code part), having only the keyctl API on Linux for > accelerated asym support may not be helpful. That argument is just non-sense. The crypto libraries that run on multiple OSes have already enough abstraction layers to deal with this. And frankly there it would be preferred if hardware backed keys are handled properly. Since that is what is really needed. Also I have to repeat my comment from above. The asymmetric ciphers are really bad for any kind of streaming operation. Using them in that way is almost always going to end badly. David Howells has patches for sign/verify/encrypt/decrypt operation. Keep in mind that all the parameters of the asymmetric keys are really bound to its cipher. So it is pretty obvious that the key itself defines what cipher is used. I do not get the wish for raw access to RSA or ECDH for example. You need the right set of keys and parameters first. Otherwise it is all garbage and not even guaranteed to be cryptographically secure. > The second part is a keyctl domain. I see in-kernel support for this > scenario, > but have not yet seen the kernel/user interface nor the user space support. Actually have you looked at Mat’s kernel tree and the support for it in ELL. > Both options are orthogonal, IMHO. I don’t agree with that. As explained above, asymmetric ciphers are bound to their keys. For me this all feels like a hammer approach. You want to treat things as nails since that is the only thing you have. However that is not the case. We have the keyring subsystem. > Tadeusz Struck provided a patch to link the kernel crypto API / > algif_akcipher > with the keys subsystem to allow the second requirement to be implemented in > algif_akcipher. That patch is on my desk and I plan to integrate it and even > make it generic to allow its use for all different cipher types. I have not > yet integrated it to allow a small patch set to be reviewed. If it is the > will > of the council, I can surely add that code to the initial patch set and > resubmit. For symmetric ciphers this is awesome. For asymmetric ciphers I have no idea on how this would work. Once you provided the key handle, then the crypto subsystem would have to select the cipher. However that is not how it is designed. You are binding a cipher early one. In addition, depending on the key, you would need to choose the right hardware to execute on (in case of hardware bound keys). It is also not designed for this either. So I have no idea how you want to overcome the design limitations / choices of AF_ALG when it comes to supporting assymetric ciphers correctly. Regards Marcel
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Am Freitag, 11. August 2017, 18:02:55 CEST schrieb Marcel Holtmann: Hi Marcel, > > Thanks for the reminder. I have looked at that but I am unsure about > > whether this one covers asym crypto appropriately, too. > > > > The issue is that some hardware may only offer accelerators without a full > > blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others). How do > > you propose to cover raw primitives with keyctl? > > where is such a hardware? Strangely, I see such support all the time in embedded devices where asymmetric acceleration is really necessary. > And what is the usage of it? Look at what we are > using asymmetric crypto for at the moment. It is either for sign and verify > with secure boot etc. Or it is for key exchange purposes. I understand that this is the core purpose of asymmetric ciphers. Yet, asymmetric ciphers are complex and we as kernel developers do not know (or shall not mandate?) where the complexity shall be implemented. By forcing all into the keyctl, we would insist that the entire complexity of the full-blown asym cipher is in the kernel without an option that user space may implement it. What we are currently seemingly discuss is the choice of - keyctl: having all complexity of the entire asym logic including its key handling in the kernel with the benefit of the kernel protection of the private key - algif_akcipher (maybe with a link to keyctl): only exporting the cipher support and allow user space to decide where the complexity lies Just to give you an example: A full blown RSA operation (excluding the hashing part for signatures) consists of padding and the asymmetric operation. For the asymmetric operation, we have sign/verify and encrypt/decrypt (keywrap). There are a gazillion padding types out there: - PKCS1 - OAEP - SP800-56B: RSAEP, RSADP, RSASVE, RSA-OAEP, RSA-KEM-KWS And there may be others. When we talk about encryption/decryption we have to consider the KDFs (SP800-108, RFC5689, SP800-56A). When we consider the KDFs, we have to think of the KDF data styles (ASN.1, concatenation) With keyctl to me it seems that we need to integrate all that logic into the kernel. As all of that is just processing logic, securing it in the kernel may not be the right way as this code does not need the elevated privileges in the kernel for that. Yet, some hardware may provide some/all of this logic. And we want to make that available to user space. > > The asymmetric crypto is a means to an end. If it is not for certification > verification, then it for is creating a symmetric key to be used with a > symmetric cipher. We have the the asymmetric_keys subsystem for > representing the nature of this crypto. Also the list of asymmetric ciphers > is a lot smaller than the symmetric ones. > > What raw primitives? When we are using for example ECDH for Bluetooth where > you need to create a pairwise symmetric key, then what you really want from > the cryptographic primitives is this: > > 1) Create public/private key pair See above, it is my opinion that with asym ciphers, there is a lot of complexity and lots of options. I do not think that the kernel API should be a limiting factor here, because the kernel simply does not implement a specific cipher type. > 2) Give public key to applications and store the private key safely > 3) Retrieve public key from remote side and challenge This assumes that always the Linux kernel is the manager of keys (or the gatekeeper to the key store). Are we sure that this is always the case? Ciao Stephan
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Am Freitag, 11. August 2017, 21:43:15 CEST schrieb Mat Martineau: Hi Mat, > > I also would like to have more of those algorithms exposed to userspace, > and I'd like to make sure the API is a good fit. There was extensive > discussion of AF_ALG akcipher last year. v8 of the patch set updates the > implementation but doesn't address the API concerns that kept the previous > versions from being merged, so we seem to be at just as much of an impasse > as before. During last year's discussion, I think we have concluded (and please correct me if I miss something), that the export of the asymmetric HW implementations to user space should - allow a streaming mode where the user space uses the kernel as an accelerator (maybe user space has another way of storing keys) - allow the private key to be retained in kernel space (or even in hardware only) -- i.e. user space only has a handle to the key for a full asym operation The first part is clearly where AF_ALG fits and keyctl does not. This is provided with the current patch set. As the keyctl API only handles, well, keys, access to the raw ciphers may not be possible through this API. And let us face it, a lot of user space code shall support many different OSes. Thus, if you have a crypto lib in user space who has its own key management (which is a core element of such libraries and thus cannot be put into an architecture-dependent code part), having only the keyctl API on Linux for accelerated asym support may not be helpful. The second part is a keyctl domain. I see in-kernel support for this scenario, but have not yet seen the kernel/user interface nor the user space support. Both options are orthogonal, IMHO. Tadeusz Struck provided a patch to link the kernel crypto API / algif_akcipher with the keys subsystem to allow the second requirement to be implemented in algif_akcipher. That patch is on my desk and I plan to integrate it and even make it generic to allow its use for all different cipher types. I have not yet integrated it to allow a small patch set to be reviewed. If it is the will of the council, I can surely add that code to the initial patch set and resubmit. Ciao Stephan
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Am Sonntag, 13. August 2017, 10:52:00 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > While I don't have anything to contribute to the choice between > keyctl() vs ALG_IF as interfaces for asymmetric cryptography, I would > like to point out that there is both interest and HW support for > private symmetric key operations as well, for example for storage > encryption via DM-Crypt and fscrypt, so I do hope (and will work on) > adding some sort of HW key support the crypto API, community > acceptance withstanding of course. > > So I hope we won't treat the idea of crypto API lack of support for HW > keys as a long standing immutable argument. See the patch set that was offered by Tudor regarding the in-kernel or in- hardware generation of the ECDH private keys. There is nothing that prevents us having such API for akcipher. In fact, it would even be more or less a copy-n-paste job. Exporting that logic to user space could be done as follows: - keyctl API is used to trigger the key generation process and to obtain a handle - AF_ALG to perform the asym operation where the key handle from keyctl is handed into the kernel. I am aware that this link between AF_ALG and keyctl is yet missing. But it on my desk and I am willing to integrate it. The integration should even not be specific to algif_akcipher, but to all cipher types. Ciao Stephan
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
On Fri, Aug 11, 2017 at 7:05 PM, Marcel Holtmannwrote: > Hi Stephan, > >>> AF_ALG is best suited for crypto use cases where a socket is set up once >>> and there are lots of reads and writes to justify the setup cost. With >>> asymmetric crypto, the setup cost is high when you might only use the >>> socket for a brief time to do one verify or encrypt operation. >> >> To me, the entire AF_ALG purpose is solely to export hardware support to user >> space. That said, if user space wants an accelerator, a socket would be >> opened >> once followed by numerous read/write requests. >> >> Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring >> and I planned to port it to the current implementation. But I thought I offer >> a small patch focusing on the externalization of the akcipher API first. >> >> I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to >> each other. The statement I made for the KPP AF_ALG RFC applies here too: >> >> """ >> I am aware and in fact supported development of the DH support in the keys >> subsystem. The question will be raised whether the AF_ALG KPP interface is >> superfluous in light of the keys DH support. My answer is that AF_ALG KPP is >> orthogonal to the keys DH support. The keys DH support use case is that >> the keys are managed inside the kernel and thus has the focus on the >> key management. Contrary, AF_ALG KPP does not really focus on key management >> but simply externalizes the DH/ECDH support found in the kernel including >> hardware acceleration. User space is in full control of the key life cycle. >> This way, AF_ALG could be used to complement user-space network protocol >> implementations like TLS or IKE to offload the resource intense DH >> calculations to accelerators. >> “"" > > we do not need two interfaces for doing the same thing. Especially not one > that can not handle hardware backed keys. And more important if you can not > abstract an accelerator that doesn’t expose the private key at all. While I don't have anything to contribute to the choice between keyctl() vs ALG_IF as interfaces for asymmetric cryptography, I would like to point out that there is both interest and HW support for private symmetric key operations as well, for example for storage encryption via DM-Crypt and fscrypt, so I do hope (and will work on) adding some sort of HW key support the crypto API, community acceptance withstanding of course. So I hope we won't treat the idea of crypto API lack of support for HW keys as a long standing immutable argument. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
On Fri, 11 Aug 2017, Andrew Zaborowski wrote: HI, On 11 August 2017 at 02:48, Mat Martineauwrote: The last round of reviews for AF_ALG akcipher left off at an impasse around a year ago: the consensus was that hardware key support was needed, but that requirement was in conflict with the "always have a software fallback" rule for the crypto subsystem. For example, a private key securely generated by and stored in a TPM could not be copied out for use by a software algorithm. Has anything come about to resolve this impasse? There were some patches around to add keyring support by associating a key ID with an akcipher socket, but that approach ran in to a mismatch between the proposed keyring API for the verify operation and the semantics of AF_ALG verify. AF_ALG is best suited for crypto use cases where a socket is set up once and there are lots of reads and writes to justify the setup cost. With asymmetric crypto, the setup cost is high when you might only use the socket for a brief time to do one verify or encrypt operation. Would that time be shorter when going through the keyctl API? There's a certain amount of work to be done for a one-off crypto operation no matter what the API is: load a key, set up the operation, provide the input, read the output, and clean up. keyctl() handles that "one-off" case with a smaller sequence of system calls, but is not as good for streaming. In any case there will be situations, similar to the lightweight TLS implementation use case, where this isn't a factor. Given the efficiency and hardware key issues, AF_ALG seems to be mismatched with asymmetric crypto. The hardware key support would obviously be a benefit but it's orthogonal to this I believe. That issue is not specific to akcipher either, there will be hardware-only symmetric keys that can't be used with current ALG_IF. The ALG_IF API provides a slightly lower level access to the algorithms listed in /proc/crypto than the keyctl API and I don't see the reason that some of those algorithms should not be available. I also would like to have more of those algorithms exposed to userspace, and I'd like to make sure the API is a good fit. There was extensive discussion of AF_ALG akcipher last year. v8 of the patch set updates the implementation but doesn't address the API concerns that kept the previous versions from being merged, so we seem to be at just as much of an impasse as before. -- Mat Martineau Intel OTC
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Stephan, >> AF_ALG is best suited for crypto use cases where a socket is set up once >> and there are lots of reads and writes to justify the setup cost. With >> asymmetric crypto, the setup cost is high when you might only use the >> socket for a brief time to do one verify or encrypt operation. > > To me, the entire AF_ALG purpose is solely to export hardware support to user > space. That said, if user space wants an accelerator, a socket would be > opened > once followed by numerous read/write requests. > > Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring > and I planned to port it to the current implementation. But I thought I offer > a small patch focusing on the externalization of the akcipher API first. > > I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to > each other. The statement I made for the KPP AF_ALG RFC applies here too: > > """ > I am aware and in fact supported development of the DH support in the keys > subsystem. The question will be raised whether the AF_ALG KPP interface is > superfluous in light of the keys DH support. My answer is that AF_ALG KPP is > orthogonal to the keys DH support. The keys DH support use case is that > the keys are managed inside the kernel and thus has the focus on the > key management. Contrary, AF_ALG KPP does not really focus on key management > but simply externalizes the DH/ECDH support found in the kernel including > hardware acceleration. User space is in full control of the key life cycle. > This way, AF_ALG could be used to complement user-space network protocol > implementations like TLS or IKE to offload the resource intense DH > calculations to accelerators. > “"" we do not need two interfaces for doing the same thing. Especially not one that can not handle hardware backed keys. And more important if you can not abstract an accelerator that doesn’t expose the private key at all. If you only have a hammer, everything looks like a nail. Luckily we have more tools than just a hammer :) Regards Marcel
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Stephan, >>> The last round of reviews for AF_ALG akcipher left off at an impasse >>> around a year ago: the consensus was that hardware key support was >>> needed, but that requirement was in conflict with the "always have a >>> software fallback" rule for the crypto subsystem. For example, a private >>> key securely generated by and stored in a TPM could not be copied out for >>> use by a software algorithm. Has anything come about to resolve this >>> impasse? >>> >>> There were some patches around to add keyring support by associating a key >>> ID with an akcipher socket, but that approach ran in to a mismatch >>> between the proposed keyring API for the verify operation and the >>> semantics of AF_ALG verify. >>> >>> AF_ALG is best suited for crypto use cases where a socket is set up once >>> and there are lots of reads and writes to justify the setup cost. With >>> asymmetric crypto, the setup cost is high when you might only use the >>> socket for a brief time to do one verify or encrypt operation. >>> >>> Given the efficiency and hardware key issues, AF_ALG seems to be >>> mismatched with asymmetric crypto. Have you looked at the proposed >>> keyctl() support for crypto operations? >> we have also seen hardware now where the private key will never leave the >> crypto hardware. They public and private key is only generated for key >> exchange purposes and later on discarded again. Asymmetric ciphers are >> really not a good fit for AF_ALG and they should be solely supported via >> keyctl. > > Thanks for the reminder. I have looked at that but I am unsure about whether > this one covers asym crypto appropriately, too. > > The issue is that some hardware may only offer accelerators without a full > blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others). How do you > propose to cover raw primitives with keyctl? where is such a hardware? And what is the usage of it? Look at what we are using asymmetric crypto for at the moment. It is either for sign and verify with secure boot etc. Or it is for key exchange purposes. The asymmetric crypto is a means to an end. If it is not for certification verification, then it for is creating a symmetric key to be used with a symmetric cipher. We have the the asymmetric_keys subsystem for representing the nature of this crypto. Also the list of asymmetric ciphers is a lot smaller than the symmetric ones. What raw primitives? When we are using for example ECDH for Bluetooth where you need to create a pairwise symmetric key, then what you really want from the cryptographic primitives is this: 1) Create public/private key pair 2) Give public key to applications and store the private key safely 3) Retrieve public key from remote side and challenge 4) Compute key exchange magic (like DH) from remote public key 5) Tell the key generator to throw away the private key So I do not want to load any private key into the kernel. I want the kernel to give me a public key and allow me to feed the key exchange primitive with the remote public key. This is clearly not AF_ALG. We had this discussion during the KPP design and I made it clear multiple times that this is totally different. This is clearly keyctl area of interfaces since the main operation is key generation. I am not saying that keyctl is perfect just yet, but we are working on it. We however have to accept that it is more suitable than AF_ALG. You will never have stream based data feed into an asymmetric cipher. That is what stream ciphers are for. Regards Marcel
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
HI, On 11 August 2017 at 02:48, Mat Martineauwrote: > The last round of reviews for AF_ALG akcipher left off at an impasse around > a year ago: the consensus was that hardware key support was needed, but that > requirement was in conflict with the "always have a software fallback" rule > for the crypto subsystem. For example, a private key securely generated by > and stored in a TPM could not be copied out for use by a software algorithm. > Has anything come about to resolve this impasse? > > There were some patches around to add keyring support by associating a key > ID with an akcipher socket, but that approach ran in to a mismatch between > the proposed keyring API for the verify operation and the semantics of > AF_ALG verify. > > AF_ALG is best suited for crypto use cases where a socket is set up once and > there are lots of reads and writes to justify the setup cost. With > asymmetric crypto, the setup cost is high when you might only use the socket > for a brief time to do one verify or encrypt operation. Would that time be shorter when going through the keyctl API? In any case there will be situations, similar to the lightweight TLS implementation use case, where this isn't a factor. > > Given the efficiency and hardware key issues, AF_ALG seems to be mismatched > with asymmetric crypto. The hardware key support would obviously be a benefit but it's orthogonal to this I believe. That issue is not specific to akcipher either, there will be hardware-only symmetric keys that can't be used with current ALG_IF. The ALG_IF API provides a slightly lower level access to the algorithms listed in /proc/crypto than the keyctl API and I don't see the reason that some of those algorithms should not be available. Best regards
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Am Freitag, 11. August 2017, 02:48:37 CEST schrieb Mat Martineau: Hi Mat, > > AF_ALG is best suited for crypto use cases where a socket is set up once > and there are lots of reads and writes to justify the setup cost. With > asymmetric crypto, the setup cost is high when you might only use the > socket for a brief time to do one verify or encrypt operation. To me, the entire AF_ALG purpose is solely to export hardware support to user space. That said, if user space wants an accelerator, a socket would be opened once followed by numerous read/write requests. Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring and I planned to port it to the current implementation. But I thought I offer a small patch focusing on the externalization of the akcipher API first. I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to each other. The statement I made for the KPP AF_ALG RFC applies here too: """ I am aware and in fact supported development of the DH support in the keys subsystem. The question will be raised whether the AF_ALG KPP interface is superfluous in light of the keys DH support. My answer is that AF_ALG KPP is orthogonal to the keys DH support. The keys DH support use case is that the keys are managed inside the kernel and thus has the focus on the key management. Contrary, AF_ALG KPP does not really focus on key management but simply externalizes the DH/ECDH support found in the kernel including hardware acceleration. User space is in full control of the key life cycle. This way, AF_ALG could be used to complement user-space network protocol implementations like TLS or IKE to offload the resource intense DH calculations to accelerators. """ Ciao Stephan
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Am Freitag, 11. August 2017, 07:13:30 CEST schrieb Marcel Holtmann: Hi Marcel, > > > > The last round of reviews for AF_ALG akcipher left off at an impasse > > around a year ago: the consensus was that hardware key support was > > needed, but that requirement was in conflict with the "always have a > > software fallback" rule for the crypto subsystem. For example, a private > > key securely generated by and stored in a TPM could not be copied out for > > use by a software algorithm. Has anything come about to resolve this > > impasse? > > > > There were some patches around to add keyring support by associating a key > > ID with an akcipher socket, but that approach ran in to a mismatch > > between the proposed keyring API for the verify operation and the > > semantics of AF_ALG verify. > > > > AF_ALG is best suited for crypto use cases where a socket is set up once > > and there are lots of reads and writes to justify the setup cost. With > > asymmetric crypto, the setup cost is high when you might only use the > > socket for a brief time to do one verify or encrypt operation. > > > > Given the efficiency and hardware key issues, AF_ALG seems to be > > mismatched with asymmetric crypto. Have you looked at the proposed > > keyctl() support for crypto operations? > we have also seen hardware now where the private key will never leave the > crypto hardware. They public and private key is only generated for key > exchange purposes and later on discarded again. Asymmetric ciphers are > really not a good fit for AF_ALG and they should be solely supported via > keyctl. Thanks for the reminder. I have looked at that but I am unsure about whether this one covers asym crypto appropriately, too. The issue is that some hardware may only offer accelerators without a full blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others). How do you propose to cover raw primitives with keyctl? Ciao Stephan
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Mat, >> This patch set adds the AF_ALG user space API to externalize the >> asymmetric cipher API recently added to the kernel crypto API. > > ... > >> Changes v8: >> * port to kernel 4.13 >> * port to consolidated AF_ALG code >> >> Stephan Mueller (4): >> crypto: AF_ALG -- add sign/verify API >> crypto: AF_ALG -- add setpubkey setsockopt call >> crypto: AF_ALG -- add asymmetric cipher >> crypto: algif_akcipher - enable compilation >> >> crypto/Kconfig | 9 + >> crypto/Makefile | 1 + >> crypto/af_alg.c | 28 ++- >> crypto/algif_aead.c | 36 ++-- >> crypto/algif_akcipher.c | 466 >> >> crypto/algif_skcipher.c | 26 ++- >> include/crypto/if_alg.h | 7 +- >> include/uapi/linux/if_alg.h | 3 + >> 8 files changed, 543 insertions(+), 33 deletions(-) >> create mode 100644 crypto/algif_akcipher.c >> >> -- >> 2.13.4 > > The last round of reviews for AF_ALG akcipher left off at an impasse around a > year ago: the consensus was that hardware key support was needed, but that > requirement was in conflict with the "always have a software fallback" rule > for the crypto subsystem. For example, a private key securely generated by > and stored in a TPM could not be copied out for use by a software algorithm. > Has anything come about to resolve this impasse? > > There were some patches around to add keyring support by associating a key ID > with an akcipher socket, but that approach ran in to a mismatch between the > proposed keyring API for the verify operation and the semantics of AF_ALG > verify. > > AF_ALG is best suited for crypto use cases where a socket is set up once and > there are lots of reads and writes to justify the setup cost. With asymmetric > crypto, the setup cost is high when you might only use the socket for a brief > time to do one verify or encrypt operation. > > Given the efficiency and hardware key issues, AF_ALG seems to be mismatched > with asymmetric crypto. Have you looked at the proposed keyctl() support for > crypto operations? we have also seen hardware now where the private key will never leave the crypto hardware. They public and private key is only generated for key exchange purposes and later on discarded again. Asymmetric ciphers are really not a good fit for AF_ALG and they should be solely supported via keyctl. Regards Marcel
Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Hi Stephan, On Thu, 10 Aug 2017, Stephan Müller 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. ... Changes v8: * port to kernel 4.13 * port to consolidated AF_ALG code Stephan Mueller (4): crypto: AF_ALG -- add sign/verify API crypto: AF_ALG -- add setpubkey setsockopt call crypto: AF_ALG -- add asymmetric cipher crypto: algif_akcipher - enable compilation crypto/Kconfig | 9 + crypto/Makefile | 1 + crypto/af_alg.c | 28 ++- crypto/algif_aead.c | 36 ++-- crypto/algif_akcipher.c | 466 crypto/algif_skcipher.c | 26 ++- include/crypto/if_alg.h | 7 +- include/uapi/linux/if_alg.h | 3 + 8 files changed, 543 insertions(+), 33 deletions(-) create mode 100644 crypto/algif_akcipher.c -- 2.13.4 The last round of reviews for AF_ALG akcipher left off at an impasse around a year ago: the consensus was that hardware key support was needed, but that requirement was in conflict with the "always have a software fallback" rule for the crypto subsystem. For example, a private key securely generated by and stored in a TPM could not be copied out for use by a software algorithm. Has anything come about to resolve this impasse? There were some patches around to add keyring support by associating a key ID with an akcipher socket, but that approach ran in to a mismatch between the proposed keyring API for the verify operation and the semantics of AF_ALG verify. AF_ALG is best suited for crypto use cases where a socket is set up once and there are lots of reads and writes to justify the setup cost. With asymmetric crypto, the setup cost is high when you might only use the socket for a brief time to do one verify or encrypt operation. Given the efficiency and hardware key issues, AF_ALG seems to be mismatched with asymmetric crypto. Have you looked at the proposed keyctl() support for crypto operations? Thanks, -- Mat Martineau Intel OTC
[PATCH v8 0/4] 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) Note, to enable the test, edit line [2] from "4 99" to "4 13". [1] http://www.chronox.de/libkcapi.html [2] https://github.com/smuellerDD/libkcapi/blob/master/test/test.sh#L1452 Changes v8: * port to kernel 4.13 * port to consolidated AF_ALG code Stephan Mueller (4): crypto: AF_ALG -- add sign/verify API crypto: AF_ALG -- add setpubkey setsockopt call crypto: AF_ALG -- add asymmetric cipher crypto: algif_akcipher - enable compilation crypto/Kconfig | 9 + crypto/Makefile | 1 + crypto/af_alg.c | 28 ++- crypto/algif_aead.c | 36 ++-- crypto/algif_akcipher.c | 466 crypto/algif_skcipher.c | 26 ++- include/crypto/if_alg.h | 7 +- include/uapi/linux/if_alg.h | 3 + 8 files changed, 543 insertions(+), 33 deletions(-) create mode 100644 crypto/algif_akcipher.c -- 2.13.4