Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Tadeusz Struk]

Hi,
On 10/26/2015 09:54 PM, Marcel Holtmann wrote:
> Hi Stephan,
> 
>> This patch set adds the AF_ALG user space API to externalize the
>> asymmetric cipher API recently added to the kernel crypto API.
>>
>> The patch set is tested with the user space library of libkcapi [1].
>> Use [1] test/test.sh for a full test run. The test covers the
>> following scenarios:
>>
>>  * sendmsg of one IOVEC
>>
>>  * sendmsg of 16 IOVECs with non-linear buffer
>>
>>  * vmsplice of one IOVEC
>>
>>  * vmsplice of 15 IOVECs with non-linear buffer
>>
>>  * invoking multiple separate cipher operations with one
>>open cipher handle
>>
>>  * encryption with private key (using vector from testmgr.h)
>>
>>  * encryption with public key (using vector from testmgr.h)
>>
>>  * decryption with private key (using vector from testmgr.h)
> 
> after having discussions with David Howells and David Woodhouse, I don't 
> think we should expose akcipher via AF_ALG at all. I think the akcipher 
> operations for sign/verify/encrypt/decrypt should operate on asymmetric keys 
> in the first place. With akcipher you are pretty much bound to public and 
> private keys and the key is the important part and not the akcipher itself. 
> Especially since we want to support private keys in hardware (like TPM for 
> example).
> 
> It seems more appropriate to use keyctl to derive the symmetric session key 
> from your asymmetric key. And then use the symmetric session key id with 
> skcipher via AF_ALG. Especially once symmetric key type has been introduced 
> this seems to be trivial then.
> 
> I am not really in favor of having two userspace facing APIs for asymmetric 
> cipher usage. And we need to have an API that is capable to work with 
> hardware keys.

If we would have something like this:

diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index f2acd2f..02e6162 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -34,9 +34,12 @@ struct af_alg_iv {
 #define ALG_SET_OP 3
 #define ALG_SET_AEAD_ASSOCLEN  4
 #define ALG_SET_AEAD_AUTHSIZE  5
+#define ALG_SET_PUBKEY 6
+#define ALG_SET_PUBKEY_ID  7

in case of ALG_SET_PUBKEY the key will be provided by user space
and in case of ALG_SET_PUBKEY_ID the PF_ALG layer will retrieve the
key from the keyring using the ID provided form user space.
Will this be ok with you Marcel and David?
Thanks,

-- 
TS
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

Am Dienstag, 27. Oktober 2015, 18:19:01 schrieb David Woodhouse:

Hi David,
>
>That's largely orthogonal to the point Marcel was making.
>
>The point is that akcipher is limited to using keys for which we have
>the private key material available directly in software. We cannot

Agreed.

>expose that critically limited API to userspace. We need to expose an
>API which supports hardware keys, and basically that means using the
>kernel's key subsystem.

Agreed. But at the same time, that interface should be able to support the use 
case where the software wants to be in control (just take OpenSSL as the 
simple example where you can add an engine for the Linux kernel backed RSA 
operation).

Note, the goal with AF_ALG is simply to expose asymmetric hardware support to 
user space for unspecified use cases to make user space faster.
>
>For a key which *happens* to be in software, the key subsystem may end
>up *using* akcipher behind the scenes. But the API we expose to
>userspace cannot simply be based on akcipher.

So, how do you propose that would work? Based on what I understand the 
suggested logic flow for a simple OpenSSL-like approach would be:

1. OpenSSL opens the interface with the kernel key subsystem and sends the 
pub/priv key along
 
2. the key subsystem hooks the key in

3. the key subsystem sees that there is a simple RSA operation to be made

4. the key subsystem initiates an akcipher operation and sends the keys along

5. the akcipher returns the cipher result to the key subsystem

6. the key subsystem sends the data to user space

Currently I fail to understand why that key subsystem would help me in that 
common use case (note, I totally understand to use the key subsystem when you 
have some key management schema in place).

Also, I fail to see that this logic flow would be fast to warrant a detour 
from user land into kernel land for an RSA operation.

Thanks
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Tadeusz Struk]

Hi Marcel,
On 10/26/2015 09:54 PM, Marcel Holtmann wrote:
> after having discussions with David Howells and David Woodhouse, I don't 
> think we should expose akcipher via AF_ALG at all. I think the akcipher 
> operations for sign/verify/encrypt/decrypt should operate on asymmetric keys 
> in the first place. With akcipher you are pretty much bound to public and 
> private keys and the key is the important part and not the akcipher itself. 
> Especially since we want to support private keys in hardware (like TPM for 
> example).
> 
> It seems more appropriate to use keyctl to derive the symmetric session key 
> from your asymmetric key. And then use the symmetric session key id with 
> skcipher via AF_ALG. Especially once symmetric key type has been introduced 
> this seems to be trivial then.
> 
> I am not really in favor of having two userspace facing APIs for asymmetric 
> cipher usage. And we need to have an API that is capable to work with 
> hardware keys.

The main use case for algif_akcipher will be to allow a web server, which needs 
to handle
tens of thousand TLS handshakes per second, to offload the RSA operation to a 
HW accelerator.
Do you think we can use keyctl for this?
Thanks,
T
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[David Woodhouse]

On Tue, 2015-10-27 at 11:50 +0100, Stephan Mueller wrote:
> 
> >expose that critically limited API to userspace. We need to expose an
> >API which supports hardware keys, and basically that means using the
> >kernel's key subsystem.
> 
> Agreed. But at the same time, that interface should be able to support the 
> use 
> case where the software wants to be in control (just take OpenSSL as the 
> simple example where you can add an engine for the Linux kernel backed RSA 
> operation).

Absolutely. The interface needs to support *both*.

I've spent a lot of time chasing through userspace stacks, fixing
broken assumptions that we will *always* have the actual key material
in a file — and making libraries and applications accept PKCS#11 URIs
referring to keys in hardware as well as filenames.

I am violently opposed to exposing an API from the kernel which makes
that *same* fundamental mistake, and ties its users to using *only*
software keys.

FROM THE BEGINNING, users of this new API should be able to cope with
the fact that they might not *have* the key material, and that they
might simply be referring to a key which exists elsewhere. Such as in
the TPM, or within an SGX software enclave.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

Am Mittwoch, 28. Oktober 2015, 08:15:16 schrieb David Woodhouse:

Hi David,
>
>Absolutely. The interface needs to support *both*.
>
>I've spent a lot of time chasing through userspace stacks, fixing
>broken assumptions that we will *always* have the actual key material
>in a file — and making libraries and applications accept PKCS#11 URIs
>referring to keys in hardware as well as filenames.
>
>I am violently opposed to exposing an API from the kernel which makes
>that *same* fundamental mistake, and ties its users to using *only*
>software keys.
>
>FROM THE BEGINNING, users of this new API should be able to cope with
>the fact that they might not *have* the key material, and that they
>might simply be referring to a key which exists elsewhere. Such as in
>the TPM, or within an SGX software enclave.

Albeit that all sounds like the crown jewel, how do you propose that shall 
happen?

Assume that you have a web server that has a pub and priv key in its current 
configuration -- I guess that is the vast majority of configs.

Can you please elaborate how the process for such a web server shall really 
work?


Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

Am Mittwoch, 28. Oktober 2015, 08:43:16 schrieb David Woodhouse:

Hi David,

> > Albeit that all sounds like the crown jewel, how do you propose that shall
> > happen?
> > 
> > Assume that you have a web server that has a pub and priv key in its
> > current configuration -- I guess that is the vast majority of configs.
> > 
> > Can you please elaborate how the process for such a web server shall
> > really
> > work?
> 
> 1. Create a kernel-side key.
> 2. Use it.
> 
> That may require adding an API similar to the one you're proposing, but
> working with kernel keys instead of directly with akcipher. Or perhaps
> the key subsystem can already offer what you need in userspace. David?

Ohh, I see. So, you are saying that there should not be a setpub/privkey for 
the akcipher AF_ALG interface?!

If somebody wants to use akcipher, he shall set the key via the keyring and 
akcipher shall obtain it from the keyring?

However, for the actual data shoveling, AF_ALG should still be used?


-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Marcel Holtmann]

Hi Stephan,

>>> Albeit that all sounds like the crown jewel, how do you propose that shall
>>> happen?
>>> 
>>> Assume that you have a web server that has a pub and priv key in its
>>> current configuration -- I guess that is the vast majority of configs.
>>> 
>>> Can you please elaborate how the process for such a web server shall
>>> really
>>> work?
>> 
>> 1. Create a kernel-side key.
>> 2. Use it.
>> 
>> That may require adding an API similar to the one you're proposing, but
>> working with kernel keys instead of directly with akcipher. Or perhaps
>> the key subsystem can already offer what you need in userspace. David?
> 
> Ohh, I see. So, you are saying that there should not be a setpub/privkey for 
> the akcipher AF_ALG interface?!

I tested support for adding ALG_SET_KEY_ID which takes the 32-bit key serial 
and then using AF_ALG with an skcipher. That works so far so fine. For making 
this super clean and get it upstream, it needs a symmetric key type (which is 
planned to be added by David). I can post my current patch as RFC since it is 
dead simple actually.

> If somebody wants to use akcipher, he shall set the key via the keyring and 
> akcipher shall obtain it from the keyring?
> 
> However, for the actual data shoveling, AF_ALG should still be used?

There is no massive data shoveling by an akcipher. All data shoveling for TLS 
is done via the symmetric session key that is negotiated. Actually with 
asymmetric ciphers, your keys will be normally larger than your clear text 
anyway.

So if a server has public/private key pair, then the first thing that should 
the server do is load this key pair into the kernel and retrieve a key serial 
for it. And then use this key id to derive the session key. That session key 
can then be used with AF_ALG and skcipher for the data shoveling.

However that all said, the keys should never leave the kernel. Neither the 
private key nor the session key. There is no point in sending keys through 
userspace. We actually do not want this at all. That is especially important if 
your actual private/public key pair is in hardware. So maybe your RSA 
accelerator might expose secure storage for the keys. Loading them over and 
over again from userspace makes no sense.

As David mentioned, we need to take a deep look at what the userspace API for 
asymmetric cipher suites (and we also have needs for ECDH etc. and not just 
RSA) should look like. Just exposing akcipher via AF_ALG is premature. If we 
expose it now, it is not an API that we can take back. Having two userspace 
APIs for the exactly the same functionality is a bad thing. Especially if one 
is limited to software only keys.

We also need to look at the larger picture here. And that is TLS support in the 
kernel. Potentially via AF_KCM or something similar.

And with TLS in mind, we actually do want to just load the whole X.509 
certificate into the key subsystem. It will then allow you retrieve the key id, 
validate the certificate and use the key. Current kernels already support this 
kind of functionality and we want to enable this and extend it. Having random 
pieces in userspace and/or kernel space to extract keys from the containers is 
a pretty bad idea. We really want this centralized. Here the same goal applies, 
to not have multiple userspace APIs doing the same thing.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

Am Mittwoch, 28. Oktober 2015, 09:37:02 schrieb David Woodhouse:

Hi David,

> On Wed, 2015-10-28 at 00:47 +0100, Stephan Mueller wrote:
> > Ohh, I see. So, you are saying that there should not be a setpub/privkey
> > for the akcipher AF_ALG interface?!
> > 
> > If somebody wants to use akcipher, he shall set the key via the keyring
> > and
> > akcipher shall obtain it from the keyring?
> > 
> > However, for the actual data shoveling, AF_ALG should still be used?
> 
> That might seem ideal, but Herbert doesn't want that — he wants
> akcipher to work *only* with its own internal keys, not with keys from
> the kernel's key subsystem.
> 
> David has patches (not upstream yet; used for testing) which expose a
> verify operation for kernel keys through sys_keyctl(). Adding the other
> three operations would be feasible.
> 
> Perhaps if we *really* want this to appear through AF_ALG, the key
> subsystem could register its own RSA (and other) implementation(s) with
> the crypto subsystem. Then we could find some way that we can pass the
> key_serial_t through alg_setkey() instead of the actual key data
> without it (or Herbert) noticing that's what we're doing. But... ick.
> And I don't think we can select algorithms based on the actual key
> rather than the type. We should do it properly, if at all. And define
> the API as taking key IDs instead of having it be a nasty special-case
> hack for a specific (but really, very generic) algorithm provider.

First of all, I personally would not insist on an AF_ALG for pure akcipher 
externalization. Integrating it with the key subsystem looks like a fine idea.

But that would imply that we tie the crypto API quite hard with the key 
retention system which I guess may not be warranted.

Note, I was playing with the idea of using the key retention system for the 
kernel crypto API myself (hence also my patch to add key wrapping support 
which has its roots there).

But having a tie between both, the kernel crypto API and the key system, that 
cannot be cut any more is something I am not sure about. Both should and would 
work in isolation of each other as both serve different needs.

But I agree that when having both and the user wants proper key management, 
the key system should be used. But isn't that already a policy decision of the 
user/administrator? IIRC, the kernel should not hard-wire policies that may or 
may not be wanted by user space. Hence, the decision about connecting both 
systems should rest in user space. And the kernel should support a joint 
operation of both.


-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

Am Mittwoch, 28. Oktober 2015, 09:46:51 schrieb Marcel Holtmann:

Hi Marcel,

> So if a server has public/private key pair, then the first thing that should
> the server do is load this key pair into the kernel and retrieve a key
> serial for it. And then use this key id to derive the session key. That
> session key can then be used with AF_ALG and skcipher for the data
> shoveling.
> 
> However that all said, the keys should never leave the kernel. Neither the

I personally do not fully agree here. For our day-to-day desktops and servers 
I would fully and completely agree. But I see other use cases of Linux in 
routers or other embedded systems where there may be other checks and balances 
in place where this hard demand is not warranted.

Thus, I feel that this is a policy decision to be made in user space (see my 
other email -- please answer on that topic there to keep a single thread).

> private key nor the session key. There is no point in sending keys through
> userspace. We actually do not want this at all. That is especially
> important if your actual private/public key pair is in hardware. So maybe
> your RSA accelerator might expose secure storage for the keys. Loading them
> over and over again from userspace makes no sense.
> 
> As David mentioned, we need to take a deep look at what the userspace API
> for asymmetric cipher suites (and we also have needs for ECDH etc. and not
> just RSA) should look like. Just exposing akcipher via AF_ALG is premature.
> If we expose it now, it is not an API that we can take back. Having two
> userspace APIs for the exactly the same functionality is a bad thing.
> Especially if one is limited to software only keys.

Do not get me wrong, my patch is shall be there for all to comment. I have no 
issues when we find a better solution. And I also do not like multiple 
interfaces that would not be needed if we would have thought better.
> 
> We also need to look at the larger picture here. And that is TLS support in
> the kernel. Potentially via AF_KCM or something similar.

With all due respect, I would object here. When we say yes to TLS (even if it 
is parts of TLS up to the point where the KDF happens), we invite all higher 
level crypto implementations: IKE, SNMP, SSH -- I would not want to go down 
that path that started by simply supporting accelerated asymmetric ciphers.

Look at user space crypto libs: where is the most fuzz happening? Not in the 
cipher implementations, but in the network protocols.


-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[David Woodhouse]

On Wed, 2015-10-28 at 00:35 +0100, Stephan Mueller wrote:
> Am Mittwoch, 28. Oktober 2015, 08:15:16 schrieb David Woodhouse:
> 
> Hi David,
> > 
> > Absolutely. The interface needs to support *both*.
> > 
> > I've spent a lot of time chasing through userspace stacks, fixing
> > broken assumptions that we will *always* have the actual key material
> > in a file — and making libraries and applications accept PKCS#11 URIs
> > referring to keys in hardware as well as filenames.
> > 
> > I am violently opposed to exposing an API from the kernel which makes
> > that *same* fundamental mistake, and ties its users to using *only*
> > software keys.
> > 
> > FROM THE BEGINNING, users of this new API should be able to cope with
> > the fact that they might not *have* the key material, and that they
> > might simply be referring to a key which exists elsewhere. Such as in
> > the TPM, or within an SGX software enclave.
> 
> Albeit that all sounds like the crown jewel, how do you propose that shall 
> happen?
> 
> Assume that you have a web server that has a pub and priv key in its current 
> configuration -- I guess that is the vast majority of configs.
> 
> Can you please elaborate how the process for such a web server shall really 
> work?

1. Create a kernel-side key.
2. Use it.

That may require adding an API similar to the one you're proposing, but
working with kernel keys instead of directly with akcipher. Or perhaps
the key subsystem can already offer what you need in userspace. David?

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[David Woodhouse]

On Wed, 2015-10-28 at 00:47 +0100, Stephan Mueller wrote:
> 
> Ohh, I see. So, you are saying that there should not be a setpub/privkey for 
> the akcipher AF_ALG interface?!
> 
> If somebody wants to use akcipher, he shall set the key via the keyring and 
> akcipher shall obtain it from the keyring?
> 
> However, for the actual data shoveling, AF_ALG should still be used?

That might seem ideal, but Herbert doesn't want that — he wants
akcipher to work *only* with its own internal keys, not with keys from
the kernel's key subsystem.

David has patches (not upstream yet; used for testing) which expose a
verify operation for kernel keys through sys_keyctl(). Adding the other
three operations would be feasible.

Perhaps if we *really* want this to appear through AF_ALG, the key
subsystem could register its own RSA (and other) implementation(s) with
the crypto subsystem. Then we could find some way that we can pass the
key_serial_t through alg_setkey() instead of the actual key data
without it (or Herbert) noticing that's what we're doing. But... ick.
And I don't think we can select algorithms based on the actual key
rather than the type. We should do it properly, if at all. And define
the API as taking key IDs instead of having it be a nasty special-case
hack for a specific (but really, very generic) algorithm provider.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[David Woodhouse]

On Wed, 2015-10-28 at 02:18 +0100, Stephan Mueller wrote:
> 
> But having a tie between both, the kernel crypto API and the key system, that 
> cannot be cut any more is something I am not sure about. Both should and 
> would 
> work in isolation of each other as both serve different needs.

Sure, let people load keys directly without having to instantiate keys
and then reference them. My point is that only an API which permits
*both* models is acceptable. Otherwise, people build bogus assumptions
all the way up the stack.

Having both ALG_SET_KEY and ALG_SET_KEY_ID in parallel seems ideal.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Marcel Holtmann]

Hi Stephan,

> This patch set adds the AF_ALG user space API to externalize the
> asymmetric cipher API recently added to the kernel crypto API.
> 
> The patch set is tested with the user space library of libkcapi [1].
> Use [1] test/test.sh for a full test run. The test covers the
> following scenarios:
> 
>   * sendmsg of one IOVEC
> 
>   * sendmsg of 16 IOVECs with non-linear buffer
> 
>   * vmsplice of one IOVEC
> 
>   * vmsplice of 15 IOVECs with non-linear buffer
> 
>   * invoking multiple separate cipher operations with one
> open cipher handle
> 
>   * encryption with private key (using vector from testmgr.h)
> 
>   * encryption with public key (using vector from testmgr.h)
> 
>   * decryption with private key (using vector from testmgr.h)

after having discussions with David Howells and David Woodhouse, I don't think 
we should expose akcipher via AF_ALG at all. I think the akcipher operations 
for sign/verify/encrypt/decrypt should operate on asymmetric keys in the first 
place. With akcipher you are pretty much bound to public and private keys and 
the key is the important part and not the akcipher itself. Especially since we 
want to support private keys in hardware (like TPM for example).

It seems more appropriate to use keyctl to derive the symmetric session key 
from your asymmetric key. And then use the symmetric session key id with 
skcipher via AF_ALG. Especially once symmetric key type has been introduced 
this seems to be trivial then.

I am not really in favor of having two userspace facing APIs for asymmetric 
cipher usage. And we need to have an API that is capable to work with hardware 
keys.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Herbert Xu]

On Mon, Oct 19, 2015 at 09:14:09AM +0200, Stephan Mueller wrote:
>
> However, I would suggest that you pull patch 1/5 as this is a bug fix that 
> may 
> affect even other users.

Sure I'll look into it.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

Am Montag, 19. Oktober 2015, 09:32:30 schrieb Herbert Xu:

Hi Herbert,

> On Sun, Oct 18, 2015 at 12:44:00PM +0200, Stephan Mueller wrote:
> > Hi,
> > 
> > This patch set adds the AF_ALG user space API to externalize the
> > asymmetric cipher API recently added to the kernel crypto API.
> > 
> > The patch set is tested with the user space library of libkcapi [1].
> > Use [1] test/test.sh for a full test run. The test covers the
> 
> > following scenarios:
> Thanks Stephan.  But I would prefer to defer this til after we have
> completed the conversion of current in-kernel users.  This is because
> changing the kernel interface is easy while changing the user-space
> interface is not.

Sure, let us wait.

However, I would suggest that you pull patch 1/5 as this is a bug fix that may 
affect even other users.

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

Hi,

This patch set adds the AF_ALG user space API to externalize the
asymmetric cipher API recently added to the kernel crypto API.

The patch set is tested with the user space library of libkcapi [1].
Use [1] test/test.sh for a full test run. The test covers the
following scenarios:

* sendmsg of one IOVEC

* sendmsg of 16 IOVECs with non-linear buffer

* vmsplice of one IOVEC

* vmsplice of 15 IOVECs with non-linear buffer

* invoking multiple separate cipher operations with one
  open cipher handle

* encryption with private key (using vector from testmgr.h)

* encryption with public key (using vector from testmgr.h)

* decryption with private key (using vector from testmgr.h)

The patch set includes a fix for the MPI parsing that is visible when
using SGL members that contain one byte.

Changes v2:
 * use updated SGL-based akcipher API
 * allow mix-n-match of sendmsg and vmsplice calls

[1] http://www.chronox.de/libkcapi.html

Stephan Mueller (5):
  MPI: fix off by one in mpi_read_raw_from_sgl
  crypto: AF_ALG -- add sign/verify API
  crypto: AF_ALG -- add setpubkey setsockopt call
  crypto: AF_ALG -- add asymmetric cipher interface
  crypto: algif_akcipher - enable compilation

 crypto/Kconfig  |   9 +
 crypto/Makefile |   1 +
 crypto/af_alg.c |  14 +-
 crypto/algif_akcipher.c | 542 
 include/crypto/if_alg.h |   1 +
 include/uapi/linux/if_alg.h |   3 +
 lib/mpi/mpicoder.c  |   5 +-
 7 files changed, 571 insertions(+), 4 deletions(-)
 create mode 100644 crypto/algif_akcipher.c

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Herbert Xu]

On Sun, Oct 18, 2015 at 12:44:00PM +0200, Stephan Mueller wrote:
> Hi,
> 
> This patch set adds the AF_ALG user space API to externalize the
> asymmetric cipher API recently added to the kernel crypto API.
> 
> The patch set is tested with the user space library of libkcapi [1].
> Use [1] test/test.sh for a full test run. The test covers the
> following scenarios:

Thanks Stephan.  But I would prefer to defer this til after we have
completed the conversion of current in-kernel users.  This is because
changing the kernel interface is easy while changing the user-space
interface is not.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html