DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Verma, Shally" <Shally.Verma@cavium.com>
To: "Trahe, Fiona" <fiona.trahe@intel.com>,
	"Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	Kanaka Durga Kotamarthy <kkotamarthy@marvell.com>,
	Sunila Sahu <ssahu@marvell.com>,
	"Kotamarthy, Kanaka" <Kanaka.Kotamarthy@cavium.com>,
	"Sahu, Sunila" <Sunila.Sahu@cavium.com>,
	"Cel, TomaszX" <tomaszx.cel@intel.com>,
	"Jozwiak, TomaszX" <tomaszx.jozwiak@intel.com>
Subject: Re: [dpdk-dev] [RFC] cryptodev/asymm: propose changes to modexp and modinv API
Date: Thu, 20 Dec 2018 10:52:45 +0000	[thread overview]
Message-ID: <SN6PR07MB5152209CD18AB77CE423611FF0BF0@SN6PR07MB5152.namprd07.prod.outlook.com> (raw)
In-Reply-To: <348A99DA5F5B7549AA880327E580B435896A4C8E@IRSMSX101.ger.corp.intel.com>



>-----Original Message-----
>From: Trahe, Fiona <fiona.trahe@intel.com>
>Sent: 18 December 2018 21:23
>To: Verma, Shally <Shally.Verma@cavium.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
>Cc: dev@dpdk.org; Doherty, Declan <declan.doherty@intel.com>; Kanaka Durga Kotamarthy <kkotamarthy@marvell.com>; Sunila
>Sahu <ssahu@marvell.com>; Kotamarthy, Kanaka <Kanaka.Kotamarthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Cel,
>TomaszX <tomaszx.cel@intel.com>; Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
>Subject: RE: [RFC] cryptodev/asymm: propose changes to modexp and modinv API
>
>External Email
>
>Hi Shally, Arek,
>
...

>> >>
>> >>               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 [Shally] so these are in-place operation.
>> >> Output will be written back to base param. It also imply length of allocated
>> >> array should be >= modulus length which is passed in session param.
>> >[AK-v2] I would abandon in-place/oop approach at all in asymmetric. For symmetric reason for in-
>> place is that very often structure of
>> >packet is almost intact (macs, ip addresses, ttl etc are changed but structure remains the same, it
>> may differ for IPSec ESP mode etc).
>> >For asymmetric it is mainly used for handshakes (for example in TLS RSA use case client will send
>> 48byte of pre master secret which
>> >server will use to generate master secret after decryption). I generally don't think asymmetric crypto
>> can be used as symmetric
>> >especially that only RSA would be (to some extent) capable of it.
>>
>> [Shally] So you suggest all asym ops should be out of place? Am okay with add that. However would
>> like to ask if anyone has preference to keep in-place option in Asym.
>> If so, then we would need to add Feature flag indicating in-place processing capability.
>[Fiona] I'm ok with dropping all in-place for asymm. As there are multiple inputs and output for various
>algos it would be quite difficult to craft set of capabilities to reflect which field(s) was used for in-place result.
>I don't see a need for in-place, would use out-of-place for all.
>
[Shally] Am okay with that too. So, Arek will you send patches with these changes?

Thanks
Shally

>> >>                              [AK] - Any particular reason modulus and exponent is in
>> >> session? Not saying
>> >>                              it is wrong but is it for DH, RSA use cases only?
>> >> [Shally] no that's not the intent. For RSA and DH respective xforms have been
>> >> defined. It is kept in session envisioning modulus and exponent wont change
>> >> frequently across operation but only base value.
>> >> So once context is loaded with modulus and exponent , app can call modexp
>> >> on different base values.
>> >>
>> >>                              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...
>> >> [Shally] So far RTE_CRYPTO_OP_STATUS_INVALID_PARAM has been
>> >> sufficient for such cases. Do you have any use-cases where you need specific
>> >> error code to indicate asym specific error codes?
>> >There would be many examples, one of which:
>> >[AK-v2] Ok, still to discussion i think though.
>> >>
>> >>               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]?
>> >> [Shally] it should be length of actual data not length of allocated memory to
>> >> an array.
>> >> However it might create bit confusion on modular exponentiation op param
>> >> as that expect length passed should tell actual data length in base array but
>> >> array itself should be allocated upto modulus length.
>> >[AK-v2] - so it is maybe good idea to have allocated data in bytes and actual len in bits here.
>>
>> [Shally] No that will make it complex and breaks compatibility too. I would propose to keep it in bytes
>> which states length of actual data present in array.
>> Any confusion around it will be resolved if we add out of place or proper documentation if in-place is
>> retained.
>>
>> I would suggest you to send a patch with things that we agree or you propose. We can discuss on that
>> further.
>[Fiona] yes, agreed, Arek will send a patch.
>
>> Thanks
>> Shally
>> >>
>> >>                              [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 [Shally] no hard choices
>> >> here though. But size_t would never be less than uint16_t so it guarantee to
>> >> be large enough for any machines
>> >>
>> >>               rte_crypto_asym.h:74, 250, 257, 351
>> >>                              /**< Modular Inverse
>> >>                              [AK] - Modular Multiplicative Inverse
>> >>     [Shally] Ack.
>> >>
>> >> Thanks,
>> >> Arek
>> >>
>> >>

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

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 20:25 Kusztal, ArkadiuszX
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 [this message]
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=SN6PR07MB5152209CD18AB77CE423611FF0BF0@SN6PR07MB5152.namprd07.prod.outlook.com \
    --to=shally.verma@cavium.com \
    --cc=Kanaka.Kotamarthy@cavium.com \
    --cc=Sunila.Sahu@cavium.com \
    --cc=arkadiuszx.kusztal@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=kkotamarthy@marvell.com \
    --cc=ssahu@marvell.com \
    --cc=tomaszx.cel@intel.com \
    --cc=tomaszx.jozwiak@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;
as well as URLs for NNTP newsgroup(s).