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
next prev 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).