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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Jan 2016 21:56:13 -0800
From:	Tadeusz Struk <tadeusz.struk@...el.com>
To:	Tadeusz Struk <tstruk@...il.com>, herbert@...dor.apana.org.au,
	marcel@...tmann.org, dhowells@...hat.com, dwmw2@...radead.org
Cc:	smueller@...onox.de, linux-api@...r.kernel.org,
	linux-kernel@...r.kernel.org, keyrings@...r.kernel.org,
	linux-crypto@...r.kernel.org, zohar@...ux.vnet.ibm.com
Subject: Re: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type

Hi David, David and Marcel,
On 12/26/2015 07:50 AM, Tadeusz Struk wrote:
> From: Tadeusz Struk <tadeusz.struk@...el.com>
> 
> Created on top of patchset from Stephan Mueller <smueller@...onox.de>
> 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 <tadeusz.struk@...el.com>
> ---
>  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