Thread (11 messages) 11 messages, 4 authors, 2016-01-16

Re: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type

From: Tadeusz Struk <hidden>
Date: 2016-01-12 05:59:56
Also in: linux-api, lkml

Hi David, David and Marcel,
On 12/26/2015 07:50 AM, Tadeusz Struk wrote:
From: Tadeusz Struk <redacted>

Created on top of patchset from Stephan Mueller [off-list ref]
https://patchwork.kernel.org/patch/7877921/
https://patchwork.kernel.org/patch/7877971/
https://patchwork.kernel.org/patch/7877961/

This patch adds support for asymmetric key type to AF_ALG.
It will work as follows: A new PF_ALG socket options will be
added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely
ALG_SET_PUBKEY_ID and ALG_SET_KEY_ID for setting public and
private keys respectively. When these new options will be used
the user instead of providing the key material, will provide a
key id and the key itself will be obtained from kernel keyring
subsystem. The user will use the standard tools (keyctl tool
or the keyctl syscall) for key instantiation and to obtain the
key id. The key id can also be obtained by reading the
/proc/keys file.

When a key will be found, the request_key() function will
return a requested key. Next the asymmetric key subtype will be
used to obtain the public_key, which can be either a public key
or a private key from the cryptographic point of view, and the
key payload will be passed to the akcipher pf_alg subtype.
Pf_alg code will then call crypto API functions, either the
crypto_akcipher_set_priv_key or the crypto_akcipher_set_pub_key,
depending on the used option. Subsequently the asymmetric key
will be freed and return code returned back to the user.

Currently the interface will be restricted only to asymmetric
ciphers, but it can be extended later to work with symmetric
ciphers if required.

The assumption is that access rights for a given user will be
verified by the key subsystem so the pf_alg interface can call
the request_key() without checking if the user has appropriate
rights (Please verify this assumption).

Changes in v2:
Separate logic for setkey and setkey_id into two separate
functions as proposed by Stephan.

Signed-off-by: Tadeusz Struk <redacted>
---
 crypto/af_alg.c             |   49 +++++++++++++++++++++++++++++++++++++++----
 include/uapi/linux/if_alg.h |    2 ++
 2 files changed, 47 insertions(+), 4 deletions(-)
Do you have any comments on this?
Based on your feedback after Stephan sent the v2 algif_akcipher patches
the conclusion was that having both setkey and setkey_id will be acceptable.
This is exactly what this patch does, so will the algif_akcipher patches
with this one on top work for you?
Thanks,
-- 
TS
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help