linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: dhowells@redhat.com, herbert@gondor.apana.org.au,
	smueller@chronox.de, linux-api@vger.kernel.org,
	marcel@holtmann.org, mathew.j.martineau@linux.intel.com,
	linux-kernel@vger.kernel.org, keyrings@vger.kernel.org,
	linux-crypto@vger.kernel.org, dwmw2@infradead.org,
	davem@davemloft.net
Subject: Re: [PATCH v8 6/6] crypto: AF_ALG - add support for key_id
Date: Wed, 29 Jun 2016 11:43:20 -0700 (PDT)	[thread overview]
Message-ID: <alpine.OSX.2.20.1606291104130.37168@mjmartin-mac01.local> (raw)
In-Reply-To: <146672255872.23101.10938182451423661314.stgit@tstruk-mobl1.ra.intel.com>


Tadeusz,

On Thu, 23 Jun 2016, Tadeusz Struk wrote:

> This patch adds support for asymmetric key type to AF_ALG.
> It will work as follows: A new PF_ALG socket options are
> added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely
> ALG_SET_KEY_ID and ALG_SET_PUBKEY_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 corresponding to the given keyid is found, it is stored
> in the socket context and subsequent crypto operation invoked by the
> user will use the new asymmetric accessor functions instead of akcipher
> api. The asymmetric subtype can internally use akcipher api or
> invoke operations defined by a given subtype, depending on the
> key type.
>
> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> ---
> crypto/af_alg.c             |   10 ++
> crypto/algif_akcipher.c     |  212 ++++++++++++++++++++++++++++++++++++++++++-
> include/crypto/if_alg.h     |    1
> include/uapi/linux/if_alg.h |    2
> 4 files changed, 220 insertions(+), 5 deletions(-)
>
> diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
> index 2b8d37e..106f715 100644
> --- a/crypto/algif_akcipher.c
> +++ b/crypto/algif_akcipher.c
> +static int asym_key_verify(const struct key *key, struct akcipher_request *req)
> +{
> +	struct public_key_signature sig;
> +	char *src = NULL, *in, digest[20];
> +	int ret;
> +
> +	if (!sg_is_last(req->src)) {
> +		src = kmalloc(req->src_len, GFP_KERNEL);
> +		if (!src)
> +			return -ENOMEM;
> +		scatterwalk_map_and_copy(src, req->src, 0, req->src_len, 0);
> +		in = src;
> +	} else {
> +		in = sg_virt(req->src);
> +	}
> +	sig.pkey_algo = "rsa";
> +	sig.encoding = "pkcs1";
> +	/* Need to find a way to pass the hash param */

Comment still needed?

> +	sig.hash_algo = "sha1";
> +	sig.digest_size = sizeof(digest);
> +	sig.digest = digest;
> +	sig.s_size = req->src_len;
> +	sig.s = src;
> +	ret = verify_signature(key, &sig);
> +	if (!ret) {
> +		req->dst_len = sizeof(digest);

I think you fixed the BUG_ON() problem but there's still an issue with the 
handling of the digest. Check the use of sig->digest in 
public_key_verify_signature(), it's an input not an output. Right now it 
looks like 20 uninitialized bytes are compared with the computed digest 
within verify_signature, and then the unintialized bytes are copied to 
req->dst here.

With some modifications to public_key_verify_signature you could get the 
digest you need, but I'm not sure if verification with a hardware key 
(like a key in a TPM) can or can not provide the digest needed. Maybe this 
is why the verify_signature hook in struct asymmetric_key_subtype is 
optional.

> +		scatterwalk_map_and_copy(digest, req->dst, 0, req->dst_len, 1);
> +	}
> +	kfree(src);
> +	return ret;
> +}
> +

--
Mat Martineau
Intel OTC

  parent reply	other threads:[~2016-06-29 18:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-23 22:55 [PATCH v8 0/6] crypto: algif - add akcipher Tadeusz Struk
2016-06-23 22:55 ` [PATCH v8 2/6] crypto: AF_ALG -- add setpubkey setsockopt call Tadeusz Struk
2016-06-23 22:55 ` [PATCH v8 3/6] crypto: AF_ALG -- add asymmetric cipher interface Tadeusz Struk
2016-06-23 22:55 ` [PATCH v8 4/6] crypto: algif_akcipher - enable compilation Tadeusz Struk
     [not found] ` <146672252642.23101.15972023870303797249.stgit-mEAvsCHCuLl9qtVHHdszJa2pdiUAq4bhAL8bYrjMMd8@public.gmane.org>
2016-06-23 22:55   ` [PATCH v8 1/6] crypto: AF_ALG -- add sign/verify API Tadeusz Struk
2016-06-23 22:55   ` [PATCH v8 5/6] crypto: algif_akcipher - add ops_nokey Tadeusz Struk
2016-06-24  6:07   ` [PATCH v8 0/6] crypto: algif - add akcipher Stephan Mueller
2016-06-23 22:55 ` [PATCH v8 6/6] crypto: AF_ALG - add support for key_id Tadeusz Struk
     [not found]   ` <146672255872.23101.10938182451423661314.stgit-mEAvsCHCuLl9qtVHHdszJa2pdiUAq4bhAL8bYrjMMd8@public.gmane.org>
2016-06-24  1:01     ` kbuild test robot
2016-06-29 18:43   ` Mat Martineau [this message]
2016-07-05 20:27     ` Tadeusz Struk
2016-07-06 19:38       ` Mat Martineau
2016-07-08 15:21         ` Tadeusz Struk
2016-07-08 16:38           ` Mat Martineau
2016-07-08 17:26             ` Tadeusz Struk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.OSX.2.20.1606291104130.37168@mjmartin-mac01.local \
    --to=mathew.j.martineau@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=smueller@chronox.de \
    --cc=tadeusz.struk@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).