>-----Original Message-----
>From: Trahe, Fiona <fiona.tr...@intel.com>
>Sent: 18 December 2018 21:23
>To: Verma, Shally <shally.ve...@cavium.com>; Kusztal, ArkadiuszX
><arkadiuszx.kusz...@intel.com>
>Cc: dev@dpdk.org; Doherty, Declan <declan.dohe...@intel.com>; Kanaka Durga
>Kotamarthy <kkotamar...@marvell.com>; Sunila
>Sahu <ss...@marvell.com>; Kotamarthy, Kanaka <kanaka.kotamar...@cavium.com>;
>Sahu, Sunila <sunila.s...@cavium.com>; Cel,
>TomaszX <tomaszx....@intel.com>; Jozwiak, TomaszX <tomaszx.jozw...@intel.com>;
>Trahe, Fiona <fiona.tr...@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
>> >>
>> >>
