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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html