From: Gary R Hook <ghook@amd.com>
To: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: Stephan Mueller <smueller@chronox.de>, <linux-crypto@vger.kernel.org>
Subject: Re: Typos and RSA
Date: Tue, 17 May 2016 17:46:44 -0500 [thread overview]
Message-ID: <573B9F54.7050006@amd.com> (raw)
In-Reply-To: <ae33e745-feca-c588-015d-bf2b4ca461f0@intel.com>
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'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
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.
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,
next prev parent reply other threads:[~2016-05-17 22:46 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 [this message]
2016-05-17 22:56 ` Stephan Mueller
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=573B9F54.7050006@amd.com \
--to=ghook@amd.com \
--cc=linux-crypto@vger.kernel.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 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.