Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

[Mat Martineau]

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

[Marcel Holtmann]

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

[Tudor Ambarus]

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

[Marcel Holtmann]

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

[Tudor Ambarus]

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

[Tudor Ambarus]

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

[Marcel Holtmann]

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

[Stephan Mueller]

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

[Marcel Holtmann]

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

[Stephan Mueller]

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

[Stephan Mueller]

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

[Stephan Mueller]

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

[Gilad Ben-Yossef]

On Fri, Aug 11, 2017 at 7: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.

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

[Mat Martineau]

On Fri, 11 Aug 2017, Andrew Zaborowski wrote:


HI,

On 11 August 2017 at 02:48, Mat Martineau
 wrote:

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

[Marcel Holtmann]

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

[Marcel Holtmann]

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

[Andrew Zaborowski]

HI,

On 11 August 2017 at 02:48, Mat Martineau
 wrote:
> 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

[Stephan Mueller]

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

[Stephan Müller]

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

[Marcel Holtmann]

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

[Mat Martineau]

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