From: Stephan Mueller <smueller@chronox.de>
To: Gary R Hook <ghook@amd.com>
Cc: Tadeusz Struk <tadeusz.struk@intel.com>, linux-crypto@vger.kernel.org
Subject: Re: Typos and RSA
Date: Wed, 18 May 2016 00:56:29 +0200 [thread overview]
Message-ID: <6203568.4quGhfsc99@positron.chronox.de> (raw)
In-Reply-To: <573B9F54.7050006@amd.com>
Am Dienstag, 17. Mai 2016, 17:46:44 schrieb Gary R Hook:
Hi Gary,
> Thanks so much.
>
> There are exactly 3 references to that symbol (in my freshly pulled copy
> of cryptodev-2.6).
> testmgr.c precipitates my questions, and public_key.c doesn't actually
> provide any content
> in the source input buffer, neither modulus nor plaintext. Thus, it
> doesn't clarify things
> either.
>
> But I truly appreciate your attention.
>
> So I'll go ahead and ask, because I did look at the two areas mentioned
> by Stephan, but
> neither seem to clarify (to my admittedly ignorant eyes... I'm a real
> newbie on crypto here)
> usage.
Here is an example from a current code of mine (all kccavs symbols are private
to my code):
tfm = crypto_alloc_akcipher(kccavs_test->name, 0, 0);
if (IS_ERR(tfm)) {
pr_info("could not allocate akcipher handle for %s %ld\n",
kccavs_test->name, PTR_ERR(tfm));
return PTR_ERR(tfm);
}
req = akcipher_request_alloc(tfm, GFP_KERNEL);
if (!req)
goto err;
if (crypto_akcipher_maxsize(tfm) > MAXDATALEN) {
err = -ENOMEM;
pr_info("output datasize is too big\n");
goto err;
}
err = crypto_akcipher_set_pub_key(tfm, key->data, key->len);
if (err)
goto err;
err = kccavs_akcipher_hashdata();
if (err)
goto err;
rsa.tfm = tfm;
rsa.req = req;
init_completion(&rsa.result.completion);
sg_init_one(&src, rsa_sig->data, rsa_sig->len);
akcipher_request_set_crypt(req, &src, &src, rsa_sig->len,
crypto_akcipher_maxsize(tfm));
err = crypto_akcipher_verify(req);
kccavs_akcipher_wait(&rsa, err);
dbg("RSA signature verification result %d\n", err);
rsa_sig->len = min_t(u64, rsa_sig->len, data->len);
if (!err) {
/* sig ver passed */
if (data->len == rsa_sig->len &&
!memcmp(rsa_sig->data, data->data, rsa_sig->len)) {
dbg("sig ver op passed, good data");
memcpy(kccavs_test->data.data, "\xbe\xef\xbe\xef", 4);
} else {
dbg("sig ver op passed, wrong data");
memcpy(kccavs_test->data.data, "\xde\xad\xbe\xef", 4);
}
} else {
/*
* Signature verify failed
* Note, the CAVS vectors may sometimes even provide wrong
* input data that do not comply with some requirements. In
* this case, the kernel returns errors other than EBADMSG.
*/
memcpy(kccavs_test->data.data, "\xde\xad\xbe\xef", 4);
}
>
> Here's my question:
>
> The source input (as set via akcipher_request_set_crypt()) to akcipher
> is supposed to be
> the modulus + plaintext. testmgr hands this in via a scatterlist with 2
> elements, wherein
> the first is the modulus, the second the payload. The source length
> however, appears to
> be the aggregate length of these two elements. Okay, good enough.
>
> Since the API provides no information about the modulus length, one
crypto_akcipher_maxsize(tfm)?
> might guess that the
> only way to ascertain the separate lengths of the two parts is to read
> the values from
> the scatterlist structures. I get that the key (exponent) length is what
> really matters,
> but the source input fields are clearly of arbitrary and unequal length.
Depending on what type of RSA operation you use (raw or pkcs1) or the
operation type (siggen/ver), the input is not just the modulus.
So, to help you, you need to give a bit more information about what type of
RSA operation you want to perform.
>
> So please forgive my ignorance, but I'm not seeing it: how do we
> decompose the two parts
> of src and get their lengths? What can we expect on the receiving end of
> the encrypt
> function with respect to the source data structure? A two-element
> scatterlist? Or...?
> What can we conclude from the calls made in do_test_rsa() in testmgr.c,
> vs the call in
> public_key_verify_signature() in public_key.c re: invocation and
> provided data.
>
> Any clarification is greatly appreciated.
>
> Gary
>
> On 05/17/2016 05:18 PM, Tadeusz Struk wrote:
> > On 05/17/2016 03:16 PM, Stephan Mueller wrote:
> >>> I am working on hooking up RSA functionality to the akcipher API. It
> >>> appears>>>
> >>>> that no other code, to date, uses this API. Can anyone confirm or deny
> >>>> that
> >>>> conclusion?
> >>
> >> This is not correct. The asymmetric key API uses that code. So does the
> >> module signing code.
> >
> > Also you can have a look at testmgr.c for examples.
> > "git grep crypto_alloc_akcipher" is also useful.
> >
> > Thanks,
Ciao
Stephan
next prev parent reply other threads:[~2016-05-17 22:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-17 21:22 Typos and RSA Gary R Hook
2016-05-17 22:16 ` Stephan Mueller
2016-05-17 22:18 ` Tadeusz Struk
2016-05-17 22:46 ` Gary R Hook
2016-05-17 22:56 ` Stephan Mueller [this message]
2016-05-18 15:57 ` Gary R Hook
2016-05-18 16:01 ` 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=6203568.4quGhfsc99@positron.chronox.de \
--to=smueller@chronox.de \
--cc=ghook@amd.com \
--cc=linux-crypto@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.