DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>
To: "sverma@caviumnetworks.com" <sverma@caviumnetworks.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Trahe, Fiona" <fiona.trahe@intel.com>,
	"Doherty, Declan" <declan.doherty@intel.com>
Subject: [dpdk-dev] [RFC] cryptodev/asymm: propose changes to modexp and modinv API
Date: Wed, 12 Dec 2018 20:25:37 +0000	[thread overview]
Message-ID: <06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.ger.corp.intel.com> (raw)

Hi Shally,

I'm implementing a crypto asymmetric PMD and have some concerns about the API which I
will work through over the next few months. Starting with modexp and modinv I have
the following questions / suggestions:

              rte_crypto_asym.h:233
                             rte_crypto_param modulus;
                             /**< modulus
                             * Prime modulus of the modexp transform operation in octet-string
                             * network byte order format.
                             */
                             [AK] - Why prime? RSA for example use semi-prime or "RSA multi-prime".
                             It should be just any positive integer.
                             [AK] - If session API layer should check if it is non-zero and set flag accordingly.

              rte_crypto_asym.h:253
                             rte_crypto_param modulus;
                             /**<
                             * Pointer to the prime modulus data for modular
                             * inverse operation in octet-string network byte
                             * order format.
                             */
                             [AK] - Same situation as for mod exp. Just any number.
                             For example when using with RSA Carmichael and Euler Totient function will even
                             have composite factors.

              rte_crypto_asym.h:323
                             struct rte_crypto_mod_op_param {
                             [AK] - There should be a result field. It size should be equal to the size
                             of modulus. Same apply to mod mult inverse. It should be driver responsability to check if result
                             will not overflow
                             [AK] - Any particular reason modulus and exponent is in session? Not saying
                             it is wrong but is it for DH, RSA use cases only?

                             rte_crypto.h:39
                             enum rte_crypto_op_status {
                             [AK] - There will be many more status options in asymmetric,
                             could we probably create new one for asymmetric crypto? Even if asymmetric and symmetric
                             overlap?
                             For mod exp, mod inv potentially it will be:
                            DIVIDING_BY_ZERO_ERROR, INVERSE_NOT_EXISTS_ERROR...

              rte_crypto_asym.h:33
                             size_t length;
                             /**< length of data in bytes */
                             [AK] - Is it guaranteed to be length of actual data, not allocated memory (i mean no leading 0ed bytes), so the most significant bit will be in data[0]?
                             [AK] - could it be uint16/32_t instead as size_t can have different sizes in different implementations, uint16_t should be enough
                             for all algorithms big integer sizes

              rte_crypto_asym.h:74, 250, 257, 351
                             /**< Modular Inverse
                             [AK] - Modular Multiplicative Inverse


Thanks,
Arek

             reply	other threads:[~2018-12-12 20:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 20:25 Kusztal, ArkadiuszX [this message]
2018-12-17  5:44 ` Verma, Shally
2018-12-17 14:24   ` Kusztal, ArkadiuszX
2018-12-17 18:34     ` Trahe, Fiona
2018-12-18 13:53     ` Verma, Shally
2018-12-18 15:53       ` Trahe, Fiona
2018-12-20 10:52         ` Verma, Shally
2018-12-20 11:07           ` Kusztal, ArkadiuszX

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=06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.ger.corp.intel.com \
    --to=arkadiuszx.kusztal@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=sverma@caviumnetworks.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;
as well as URLs for NNTP newsgroup(s).