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?
I have questions about invoking akcipher transform functions, and can
find no
information about specifics that vex me. If there is other code to look
at, I'm
happy to. Otherwise, I can embarrass myself here with a display of
ignorance.
Gary
Am Dienstag, 17. Mai 2016, 16:22:43 schrieb Gary R Hook:
Hi Gary,
> 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.
>
> I have questions about invoking akcipher transform functions, and can
> find no
> information about specifics that vex me. If there is other code to look
> at, I'm
> happy to. Otherwise, I can embarrass myself here with a display of
> ignorance.
>
> Gary
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ciao
Stephan
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,
--
TS
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,
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
Ah.... enlightenment can be such an uncomfortable thing...
On 05/17/2016 05:56 PM, Stephan Mueller wrote:
> 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):
Yes, thank you. After spending more time wandering through rsa.c &
rsa_helper.c
I have come to realize that I have been laboring under a paradigm imposed by
my implementation requirements. Now that I have that cleared up, the
answer to
my question it self-evident.Although I'm still not clear on why testmgr
feels
the need to create a SGL table with an empty second element (for the
existing
tests), rather than a single SGL. But that's neither here nor there.
As I said, I'm a newbie with lots to learn about this stuff. Thanks for your
patience.
On 05/18/2016 08:57 AM, Gary R Hook wrote:
> Yes, thank you. After spending more time wandering through rsa.c & rsa_helper.c
> I have come to realize that I have been laboring under a paradigm imposed by
> my implementation requirements. Now that I have that cleared up, the answer to
> my question it self-evident.Although I'm still not clear on why testmgr feels
> the need to create a SGL table with an empty second element (for the existing
> tests), rather than a single SGL.
Because the role of testmgr is to test different scenarios like more than one
entry in an sgl, etc.
Thanks,
--
TS