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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox