[v4,1/4] lib/cryptodev: add asymmetric algos in cryptodev
Checks
Commit Message
Add rte_crypto_asym.h with supported xfrms
and associated op structures and APIs
API currently supports:
- RSA Encrypt, Decrypt, Sign and Verify
- Modular Exponentiation and Inversion
- DSA Sign and Verify
- Deffie-hellman private key exchange
- Deffie-hellman public key exchange
- Deffie-hellman shared secret compute
- Deffie-hellman public/private key pair generation
using xform chain
Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
---
lib/librte_cryptodev/Makefile | 1 +
lib/librte_cryptodev/meson.build | 3 +-
lib/librte_cryptodev/rte_crypto_asym.h | 496 +++++++++++++++++++++++++++++++++
3 files changed, 499 insertions(+), 1 deletion(-)
Comments
Hey Shally,
just a few things inline below mainly concerned with the need to be able
to support session-less operations in future PMDs. I think with a few
minor changes to the API now it should allow session-less to be
supported later without the need for a major rework of the APIs, I don't
think this should cause any major rework to your PMD just the adoption
of some new more explicit op types.
Thanks
Declan
On 03/07/2018 4:24 PM, Shally Verma wrote:
> Add rte_crypto_asym.h with supported xfrms
> and associated op structures and APIs
>
> API currently supports:
> - RSA Encrypt, Decrypt, Sign and Verify
> - Modular Exponentiation and Inversion
> - DSA Sign and Verify
> - Deffie-hellman private key exchange
> - Deffie-hellman public key exchange
> - Deffie-hellman shared secret compute
> - Deffie-hellman public/private key pair generation
> using xform chain
>
> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
> Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
> ---
> lib/librte_cryptodev/Makefile | 1 +
> lib/librte_cryptodev/meson.build | 3 +-
> lib/librte_cryptodev/rte_crypto_asym.h | 496 +++++++++++++++++++++++++++++++++
> 3 files changed, 499 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cr
...
> +typedef struct rte_crypto_param_t {
> + uint8_t *data;
> + /**< pointer to buffer holding data */
> + rte_iova_t iova;
> + /**< IO address of data buffer */
> + size_t length;
> + /**< length of data in bytes */
> +} rte_crypto_param;
What is the intended way for this memory to be allocated, it seems like
there might be a more general requirement in DPDK for IO addressable
memory (compression? other hardware acceleators implemented on FPGAs)
than just asymmetric crypto, will we end up needing to support features
like scatter gather lists in this structure? btw I think this is
probably fine for the moment as it will be expermential but I think it
will need to be addressed before the removal of the expermential tag.
> +
> +/** asym xform type name strings */
> +extern const char *
> +rte_crypto_asym_xform_strings[];
> +
> +/** asym operations type name strings */
> +extern const char *
> +rte_crypto_asym_op_strings[];
> +
> +/**
> + * Asymmetric crypto transformation types.
> + * Each xform type maps to one asymmetric algorithm
> + * performing specific operation
> + *
> + */
> +enum rte_crypto_asym_xform_type {
> + RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED = 0,
> + /**< Invalid xform. */
> + RTE_CRYPTO_ASYM_XFORM_NONE,
> + /**< Xform type None.
> + * May be supported by PMD to support
> + * passthrough op for debugging purpose.
> + * if xform_type none , op_type is disregarded.
> + */
> + RTE_CRYPTO_ASYM_XFORM_RSA,
> + /**< RSA. Performs Encrypt, Decrypt, Sign and Verify.
> + * Refer to rte_crypto_asym_op_type
> + */
> + RTE_CRYPTO_ASYM_XFORM_DH,
> + /**< Deffie-Hellman.
> + * Performs Key Generate and Shared Secret Compute.
> + * Refer to rte_crypto_asym_op_type
> + */
> + RTE_CRYPTO_ASYM_XFORM_DSA,
> + /**< Digital Signature Algorithm
> + * Performs Signature Generation and Verification.
> + * Refer to rte_crypto_asym_op_type
> + */
> + RTE_CRYPTO_ASYM_XFORM_MODINV,
Would prefer if this was _MOD_INV :)
> + /**< Modular Inverse
> + * Perform Modulus inverse b^(-1) mod n
> + */
> + RTE_CRYPTO_ASYM_XFORM_MODEX,
any this was _MOD_EX :)
> + /**< Modular Exponentiation
> + * Perform Modular Exponentiation b^e mod n
> + */
> + RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> + /**< End of list */
> +};
> +
> +/**
> + * Asymmetric crypto operation type variants
> + */
> +enum rte_crypto_asym_op_type {
> + RTE_CRYPTO_ASYM_OP_ENCRYPT,
> + /**< Asymmetric Encrypt operation */
> + RTE_CRYPTO_ASYM_OP_DECRYPT,
> + /**< Asymmetric Decrypt operation */
> + RTE_CRYPTO_ASYM_OP_SIGN,
> + /**< Signature Generation operation */
> + RTE_CRYPTO_ASYM_OP_VERIFY,
> + /**< Signature Verification operation */
> + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
> + /**< DH Private Key generation operation */
> + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
> + /**< DH Public Key generation operation */
> + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> + /**< DH Shared Secret compute operation */
> + RTE_CRYPTO_ASYM_OP_LIST_END
> +};
> +
I think that having generic operation types which may or may not apply
to all of the defined xforms is confusing from a user perspective and in
the longer term will make it impossible to support session-less
asymmetric operations. If we instead do something like
RTE_CRYPTO_ASYM_OP_RSA_ENCRYPT,
RTE_CRYPTO_ASYM_OP_RSA_DECRYPT,
RTE_CRYPTO_ASYM_OP_RSA_SIGN,
RTE_CRYPTO_ASYM_OP_RSA_VERIFY,
RTE_CRYPTO_ASYM_OP_DH_KEY_GENERATE,
RTE_CRYPTO_ASYM_OP_DH_SHARED_SECRET_COMPUTE,
etc...
Then the op type becomes very explicit and will allow session-less
operations to be supported by PMDs. This shouldn't have any impact on
your current implementation other than updating the op type.
> +/**
....
> + */
> +struct rte_crypto_dh_xform {
> + enum rte_crypto_asym_op_type type;
> + /**< Setup xform for key generate or shared secret compute */
> +
there is an inconsistency here in terms of were the op_type is defined,
in this case it is in the xform but it other cases RSA, DSA it is
defined in the operation information itself. I don't know of any reason
why it is needed in the xform but I think it must be consistent across
all operations/xforms. Ideally from my perspective it would be in the
rte_crypto_asym_op structure, see below, as this would allow
session/session-less operations to be supported seamlessly.
> + rte_crypto_param p;
...
> +struct rte_crypto_rsa_op_param {
> + enum rte_crypto_asym_op_type op_type;
> + /**< Type of RSA operation for transform */;
> +
see previous comment above
...
> +
> +/**
> + * DSA Operations params
> + *
> + */
> +struct rte_crypto_dsa_op_param {
> + enum rte_crypto_asym_op_type op_type;
> + /**< Signature Generation or Verification */
see previous comment above
...
> +/**
> + * Asymmetric Cryptographic Operation.
> + *
> + * Structure describing asymmetric crypto operation params.
> + *
> + */
> +struct rte_crypto_asym_op {
> + struct rte_cryptodev_asym_session *session;
> + /**< Handle for the initialised session context */
> +
> + __extension__
> + union {
> + struct rte_crypto_rsa_op_param rsa;
> + struct rte_crypto_mod_op_param modex;
> + struct rte_crypto_mod_op_param modinv;
> + struct rte_crypto_dh_op_param dh;
> + struct rte_crypto_dsa_op_param dsa;
> + };
> +} __rte_cache_aligned;
> +
Relating to my comment on position of the op_type and the minor change
of having an union of session/xform in the rte_crypto_asym_op structure
would then enable sessionless support to be added seamless in the future
with minimal effect to the current proposal.
struct rte_crypto_asym_op {
- struct rte_cryptodev_asym_session *session;
- /**< Handle for the initialised session context */
+ enum rte_crypto_asym_op_type op_type;
+
+ union {
+ struct rte_cryptodev_asym_session *session;
+ /**< Handle for the initialised session context */
+ struct rte_crypto_asym_xform *xform;
+ };
__extension__
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* _RTE_CRYPTO_ASYM_H_ */
>
Hi Declan
>-----Original Message-----
>From: Doherty, Declan [mailto:declan.doherty@intel.com]
>Sent: 05 July 2018 20:24
>To: Verma, Shally <Shally.Verma@cavium.com>; pablo.de.lara.guarch@intel.com
>Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
><Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha,
>Umesh <Umesh.Kartha@cavium.com>
>Subject: Re: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>
>External Email
>
>Hey Shally,
>
>just a few things inline below mainly concerned with the need to be able
>to support session-less operations in future PMDs. I think with a few
>minor changes to the API now it should allow session-less to be
>supported later without the need for a major rework of the APIs, I don't
>think this should cause any major rework to your PMD just the adoption
>of some new more explicit op types.
>
>Thanks
>Declan
>
>On 03/07/2018 4:24 PM, Shally Verma wrote:
>> Add rte_crypto_asym.h with supported xfrms
>> and associated op structures and APIs
>>
>> API currently supports:
>> - RSA Encrypt, Decrypt, Sign and Verify
>> - Modular Exponentiation and Inversion
>> - DSA Sign and Verify
>> - Deffie-hellman private key exchange
>> - Deffie-hellman public key exchange
>> - Deffie-hellman shared secret compute
>> - Deffie-hellman public/private key pair generation
>> using xform chain
>>
>> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
>> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>> Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
>> ---
>> lib/librte_cryptodev/Makefile | 1 +
>> lib/librte_cryptodev/meson.build | 3 +-
>> lib/librte_cryptodev/rte_crypto_asym.h | 496 +++++++++++++++++++++++++++++++++
>> 3 files changed, 499 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cr
>
>...
>
>> +typedef struct rte_crypto_param_t {
>> + uint8_t *data;
>> + /**< pointer to buffer holding data */
>> + rte_iova_t iova;
>> + /**< IO address of data buffer */
>> + size_t length;
>> + /**< length of data in bytes */
>> +} rte_crypto_param;
>
>What is the intended way for this memory to be allocated,
[Shally] It should be pointer to flat buffers and added only to input/output data to/from
asymmetric crypto engine.
> it seems like
>there might be a more general requirement in DPDK for IO addressable
>memory (compression? other hardware acceleators implemented on FPGAs)
>than just asymmetric crypto, will we end up needing to support features
>like scatter gather lists in this structure?
[Shally] I don’t anticipate that we would need to support scatter-gather data buffers as far as it is used for asymmetric.
And I'm not aware if we have requirement to support it for asymmetric processing since data size is usually small for
such operations. Thus, app is expected to send linear buffers for input/output.
Does that answer your question? Or did I miss anything?
>btw I think this is
>probably fine for the moment as it will be expermential but I think it
>will need to be addressed before the removal of the expermential tag.
>
...
>> + RTE_CRYPTO_ASYM_XFORM_MODINV,
>
>Would prefer if this was _MOD_INV :)
>
>> + /**< Modular Inverse
>> + * Perform Modulus inverse b^(-1) mod n
>> + */
>> + RTE_CRYPTO_ASYM_XFORM_MODEX,
>
>any this was _MOD_EX :)
[Shally] fine will do name change.
>
>> + /**< Modular Exponentiation
>> + * Perform Modular Exponentiation b^e mod n
>> + */
>> + RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>> + /**< End of list */
>> +};
>> +
>> +/**
>> + * Asymmetric crypto operation type variants
>> + */
>> +enum rte_crypto_asym_op_type {
>> + RTE_CRYPTO_ASYM_OP_ENCRYPT,
>> + /**< Asymmetric Encrypt operation */
>> + RTE_CRYPTO_ASYM_OP_DECRYPT,
>> + /**< Asymmetric Decrypt operation */
>> + RTE_CRYPTO_ASYM_OP_SIGN,
>> + /**< Signature Generation operation */
>> + RTE_CRYPTO_ASYM_OP_VERIFY,
>> + /**< Signature Verification operation */
>> + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
>> + /**< DH Private Key generation operation */
>> + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
>> + /**< DH Public Key generation operation */
>> + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
>> + /**< DH Shared Secret compute operation */
>> + RTE_CRYPTO_ASYM_OP_LIST_END
>> +};
>> +
>
>I think that having generic operation types which may or may not apply
>to all of the defined xforms is confusing from a user perspective and in
>the longer term will make it impossible to support session-less
>asymmetric operations. If we instead do something like
>
> RTE_CRYPTO_ASYM_OP_RSA_ENCRYPT,
> RTE_CRYPTO_ASYM_OP_RSA_DECRYPT,
> RTE_CRYPTO_ASYM_OP_RSA_SIGN,
> RTE_CRYPTO_ASYM_OP_RSA_VERIFY,
> RTE_CRYPTO_ASYM_OP_DH_KEY_GENERATE,
> RTE_CRYPTO_ASYM_OP_DH_SHARED_SECRET_COMPUTE,
> etc...
>
>Then the op type becomes very explicit and will allow session-less
>operations to be supported by PMDs. This shouldn't have any impact on
>your current implementation other than updating the op type.
>
[Shally] Ok, so you suggest to merge xform and op_type (including keeping op_type in one place) for simplicity sake.
If we take this change, then I will prefer to keep it as xforms rather than op_types, such as,
enum rte_crypto_asym_xform_types {
RTE_CRYPTO_ASYM_XFORM_RSA_ENCRYPT,
RTE_CRYPTO_ASYM_XFORM_RSA_SIGN,
RTE_CRYPTO_ASYM_XFORM_DSA_SIGN,
RTE_CRYPTO_ASYM_XFORM_DSA_VERIFY,
RTE_CRYPTO_ASYM_XFORM_DH_PRIV_KEY_GENERATE,
RTE_CRYPTO_ASYM_XFORM_DH_PUB_KEY_GENERATE,
RTE_CRYPTO_ASYM_XFORM_DH_SHARED_SECRET_COMPUTE, .... and so on..
}
These, when set on a rte_crypto_asym_xform , will work seamlessly for both session and session-less.
I also see advantage here to support xform chaining. In this case, op_type in rte_crypto_asym_xx_op_params isn't needed and will be removed.
It will add bit of repetition though, like RSA_SIGN / DSA_SIGN, but that would occur in any case, if we are merging two types.
Does that sound okay?
We were about to submit Openssl PMD with asym support today. But I would hold back till we align on this.
...
>....
>
>
>> + */
>> +struct rte_crypto_dh_xform {
>> + enum rte_crypto_asym_op_type type;
>> + /**< Setup xform for key generate or shared secret compute */
>> +
>
>there is an inconsistency here in terms of were the op_type is defined,
>in this case it is in the xform but it other cases RSA, DSA it is
>defined in the operation information itself. I don't know of any reason
>why it is needed in the xform but I think it must be consistent across
>all operations/xforms. Ideally from my perspective it would be in the
>rte_crypto_asym_op structure, see below, as this would allow
>session/session-less operations to be supported seamlessly.
>
[Shally] Reason was xform chaining. As per Fiona feedback, we identified requirement to break DH Key pair
generation in to two : PRIV_KEY_GENERATION and PUB_KEY_GENERATION, so I had to move this param around.
But this will be addressed once we change xform_types as per suggestion above.
...
>
>...
>
>> +/**
>> + * Asymmetric Cryptographic Operation.
>> + *
>> + * Structure describing asymmetric crypto operation params.
>> + *
>> + */
>> +struct rte_crypto_asym_op {
>> + struct rte_cryptodev_asym_session *session;
>> + /**< Handle for the initialised session context */
>> +
>> + __extension__
>> + union {
>> + struct rte_crypto_rsa_op_param rsa;
>> + struct rte_crypto_mod_op_param modex;
>> + struct rte_crypto_mod_op_param modinv;
>> + struct rte_crypto_dh_op_param dh;
>> + struct rte_crypto_dsa_op_param dsa;
>> + };
>> +} __rte_cache_aligned;
>> +
>Relating to my comment on position of the op_type and the minor change
>of having an union of session/xform in the rte_crypto_asym_op structure
>would then enable sessionless support to be added seamless in the future
>with minimal effect to the current proposal.
[Shally] Again, this will also be resolved with change to xform_types
>
>struct rte_crypto_asym_op {
>- struct rte_cryptodev_asym_session *session;
>- /**< Handle for the initialised session context */
>+ enum rte_crypto_asym_op_type op_type;
>+
>+ union {
>+ struct rte_cryptodev_asym_session *session;
>+ /**< Handle for the initialised session context */
>+ struct rte_crypto_asym_xform *xform;
>+ };
>
[Shally] Ok. Will add this change. But then I'll have to check if crypto PMD has support to reflect which type of mode it supports?
Thanks for review.
Shally
> __extension__
>
>
>> +#ifdef __cplusplus
>> +}
>> +#endif
>> +
>> +#endif /* _RTE_CRYPTO_ASYM_H_ */
>>
HI Declan, Pablo
Could we please close on this asap?
Thanks
Shally
>-----Original Message-----
>From: Verma, Shally
>Sent: 06 July 2018 19:59
>To: 'Doherty, Declan' <declan.doherty@intel.com>; pablo.de.lara.guarch@intel.com
>Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
><Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha,
>Umesh <Umesh.Kartha@cavium.com>
>Subject: RE: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>
>Hi Declan
>
>>-----Original Message-----
>>From: Doherty, Declan [mailto:declan.doherty@intel.com]
>>Sent: 05 July 2018 20:24
>>To: Verma, Shally <Shally.Verma@cavium.com>; pablo.de.lara.guarch@intel.com
>>Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
>><Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha,
>>Umesh <Umesh.Kartha@cavium.com>
>>Subject: Re: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>>
>>External Email
>>
>>Hey Shally,
>>
>>just a few things inline below mainly concerned with the need to be able
>>to support session-less operations in future PMDs. I think with a few
>>minor changes to the API now it should allow session-less to be
>>supported later without the need for a major rework of the APIs, I don't
>>think this should cause any major rework to your PMD just the adoption
>>of some new more explicit op types.
>>
>>Thanks
>>Declan
>>
>>On 03/07/2018 4:24 PM, Shally Verma wrote:
>>> Add rte_crypto_asym.h with supported xfrms
>>> and associated op structures and APIs
>>>
>>> API currently supports:
>>> - RSA Encrypt, Decrypt, Sign and Verify
>>> - Modular Exponentiation and Inversion
>>> - DSA Sign and Verify
>>> - Deffie-hellman private key exchange
>>> - Deffie-hellman public key exchange
>>> - Deffie-hellman shared secret compute
>>> - Deffie-hellman public/private key pair generation
>>> using xform chain
>>>
>>> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
>>> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>>> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>>> Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
>>> ---
>>> lib/librte_cryptodev/Makefile | 1 +
>>> lib/librte_cryptodev/meson.build | 3 +-
>>> lib/librte_cryptodev/rte_crypto_asym.h | 496 +++++++++++++++++++++++++++++++++
>>> 3 files changed, 499 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cr
>>
>>...
>>
>>> +typedef struct rte_crypto_param_t {
>>> + uint8_t *data;
>>> + /**< pointer to buffer holding data */
>>> + rte_iova_t iova;
>>> + /**< IO address of data buffer */
>>> + size_t length;
>>> + /**< length of data in bytes */
>>> +} rte_crypto_param;
>>
>>What is the intended way for this memory to be allocated,
>
>[Shally] It should be pointer to flat buffers and added only to input/output data to/from
>asymmetric crypto engine.
>
>> it seems like
>>there might be a more general requirement in DPDK for IO addressable
>>memory (compression? other hardware acceleators implemented on FPGAs)
>>than just asymmetric crypto, will we end up needing to support features
>>like scatter gather lists in this structure?
>
>[Shally] I don’t anticipate that we would need to support scatter-gather data buffers as far as it is used for asymmetric.
>And I'm not aware if we have requirement to support it for asymmetric processing since data size is usually small for
>such operations. Thus, app is expected to send linear buffers for input/output.
>
>Does that answer your question? Or did I miss anything?
>
>
>>btw I think this is
>>probably fine for the moment as it will be expermential but I think it
>>will need to be addressed before the removal of the expermential tag.
>>
>
>...
>
>>> + RTE_CRYPTO_ASYM_XFORM_MODINV,
>>
>>Would prefer if this was _MOD_INV :)
>>
>>> + /**< Modular Inverse
>>> + * Perform Modulus inverse b^(-1) mod n
>>> + */
>>> + RTE_CRYPTO_ASYM_XFORM_MODEX,
>>
>>any this was _MOD_EX :)
>
>[Shally] fine will do name change.
>
>>
>>> + /**< Modular Exponentiation
>>> + * Perform Modular Exponentiation b^e mod n
>>> + */
>>> + RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>>> + /**< End of list */
>>> +};
>>> +
>>> +/**
>>> + * Asymmetric crypto operation type variants
>>> + */
>>> +enum rte_crypto_asym_op_type {
>>> + RTE_CRYPTO_ASYM_OP_ENCRYPT,
>>> + /**< Asymmetric Encrypt operation */
>>> + RTE_CRYPTO_ASYM_OP_DECRYPT,
>>> + /**< Asymmetric Decrypt operation */
>>> + RTE_CRYPTO_ASYM_OP_SIGN,
>>> + /**< Signature Generation operation */
>>> + RTE_CRYPTO_ASYM_OP_VERIFY,
>>> + /**< Signature Verification operation */
>>> + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
>>> + /**< DH Private Key generation operation */
>>> + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
>>> + /**< DH Public Key generation operation */
>>> + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
>>> + /**< DH Shared Secret compute operation */
>>> + RTE_CRYPTO_ASYM_OP_LIST_END
>>> +};
>>> +
>>
>>I think that having generic operation types which may or may not apply
>>to all of the defined xforms is confusing from a user perspective and in
>>the longer term will make it impossible to support session-less
>>asymmetric operations. If we instead do something like
>>
>> RTE_CRYPTO_ASYM_OP_RSA_ENCRYPT,
>> RTE_CRYPTO_ASYM_OP_RSA_DECRYPT,
>> RTE_CRYPTO_ASYM_OP_RSA_SIGN,
>> RTE_CRYPTO_ASYM_OP_RSA_VERIFY,
>> RTE_CRYPTO_ASYM_OP_DH_KEY_GENERATE,
>> RTE_CRYPTO_ASYM_OP_DH_SHARED_SECRET_COMPUTE,
>> etc...
>>
>>Then the op type becomes very explicit and will allow session-less
>>operations to be supported by PMDs. This shouldn't have any impact on
>>your current implementation other than updating the op type.
>>
>
>[Shally] Ok, so you suggest to merge xform and op_type (including keeping op_type in one place) for simplicity sake.
>
>If we take this change, then I will prefer to keep it as xforms rather than op_types, such as,
>
>enum rte_crypto_asym_xform_types {
>RTE_CRYPTO_ASYM_XFORM_RSA_ENCRYPT,
>RTE_CRYPTO_ASYM_XFORM_RSA_SIGN,
>RTE_CRYPTO_ASYM_XFORM_DSA_SIGN,
>RTE_CRYPTO_ASYM_XFORM_DSA_VERIFY,
>RTE_CRYPTO_ASYM_XFORM_DH_PRIV_KEY_GENERATE,
>RTE_CRYPTO_ASYM_XFORM_DH_PUB_KEY_GENERATE,
>RTE_CRYPTO_ASYM_XFORM_DH_SHARED_SECRET_COMPUTE, .... and so on..
>}
>
>These, when set on a rte_crypto_asym_xform , will work seamlessly for both session and session-less.
>I also see advantage here to support xform chaining. In this case, op_type in rte_crypto_asym_xx_op_params isn't needed and will be
>removed.
>It will add bit of repetition though, like RSA_SIGN / DSA_SIGN, but that would occur in any case, if we are merging two types.
>Does that sound okay?
>
>We were about to submit Openssl PMD with asym support today. But I would hold back till we align on this.
>...
>
>>....
>>
>>
>>> + */
>>> +struct rte_crypto_dh_xform {
>>> + enum rte_crypto_asym_op_type type;
>>> + /**< Setup xform for key generate or shared secret compute */
>>> +
>>
>>there is an inconsistency here in terms of were the op_type is defined,
>>in this case it is in the xform but it other cases RSA, DSA it is
>>defined in the operation information itself. I don't know of any reason
>>why it is needed in the xform but I think it must be consistent across
>>all operations/xforms. Ideally from my perspective it would be in the
>>rte_crypto_asym_op structure, see below, as this would allow
>>session/session-less operations to be supported seamlessly.
>>
>
>[Shally] Reason was xform chaining. As per Fiona feedback, we identified requirement to break DH Key pair
>generation in to two : PRIV_KEY_GENERATION and PUB_KEY_GENERATION, so I had to move this param around.
>But this will be addressed once we change xform_types as per suggestion above.
>
>...
>
>>
>>...
>>
>>> +/**
>>> + * Asymmetric Cryptographic Operation.
>>> + *
>>> + * Structure describing asymmetric crypto operation params.
>>> + *
>>> + */
>>> +struct rte_crypto_asym_op {
>>> + struct rte_cryptodev_asym_session *session;
>>> + /**< Handle for the initialised session context */
>>> +
>>> + __extension__
>>> + union {
>>> + struct rte_crypto_rsa_op_param rsa;
>>> + struct rte_crypto_mod_op_param modex;
>>> + struct rte_crypto_mod_op_param modinv;
>>> + struct rte_crypto_dh_op_param dh;
>>> + struct rte_crypto_dsa_op_param dsa;
>>> + };
>>> +} __rte_cache_aligned;
>>> +
>>Relating to my comment on position of the op_type and the minor change
>>of having an union of session/xform in the rte_crypto_asym_op structure
>>would then enable sessionless support to be added seamless in the future
>>with minimal effect to the current proposal.
>
>[Shally] Again, this will also be resolved with change to xform_types
>
>>
>>struct rte_crypto_asym_op {
>>- struct rte_cryptodev_asym_session *session;
>>- /**< Handle for the initialised session context */
>>+ enum rte_crypto_asym_op_type op_type;
>>+
>>+ union {
>>+ struct rte_cryptodev_asym_session *session;
>>+ /**< Handle for the initialised session context */
>>+ struct rte_crypto_asym_xform *xform;
>>+ };
>>
>[Shally] Ok. Will add this change. But then I'll have to check if crypto PMD has support to reflect which type of mode it supports?
>
>Thanks for review.
>Shally
>
>> __extension__
>>
>>
>>> +#ifdef __cplusplus
>>> +}
>>> +#endif
>>> +
>>> +#endif /* _RTE_CRYPTO_ASYM_H_ */
>>>
On 06/07/2018 3:28 PM, Verma, Shally wrote:
> Hi Declan
>
>> -----Original Message-----
>> From: Doherty, Declan [mailto:declan.doherty@intel.com]
>> Sent: 05 July 2018 20:24
>> To: Verma, Shally <Shally.Verma@cavium.com>; pablo.de.lara.guarch@intel.com
>> Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
>> <Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha,
>> Umesh <Umesh.Kartha@cavium.com>
>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>>
>> External Email
>>
>> Hey Shally,
>>
>> just a few things inline below mainly concerned with the need to be able
>> to support session-less operations in future PMDs. I think with a few
>> minor changes to the API now it should allow session-less to be
>> supported later without the need for a major rework of the APIs, I don't
>> think this should cause any major rework to your PMD just the adoption
>> of some new more explicit op types.
>>
>> Thanks
>> Declan
>>
>> On 03/07/2018 4:24 PM, Shally Verma wrote:
>>> Add rte_crypto_asym.h with supported xfrms
>>> and associated op structures and APIs
>>>
>>> API currently supports:
>>> - RSA Encrypt, Decrypt, Sign and Verify
>>> - Modular Exponentiation and Inversion
>>> - DSA Sign and Verify
>>> - Deffie-hellman private key exchange
>>> - Deffie-hellman public key exchange
>>> - Deffie-hellman shared secret compute
>>> - Deffie-hellman public/private key pair generation
>>> using xform chain
>>>
>>> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
>>> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>>> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>>> Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
>>> ---
>>> lib/librte_cryptodev/Makefile | 1 +
>>> lib/librte_cryptodev/meson.build | 3 +-
>>> lib/librte_cryptodev/rte_crypto_asym.h | 496 +++++++++++++++++++++++++++++++++
>>> 3 files changed, 499 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cr
>>
>> ...
>>
>>> +typedef struct rte_crypto_param_t {
>>> + uint8_t *data;
>>> + /**< pointer to buffer holding data */
>>> + rte_iova_t iova;
>>> + /**< IO address of data buffer */
>>> + size_t length;
>>> + /**< length of data in bytes */
>>> +} rte_crypto_param;
>>
>> What is the intended way for this memory to be allocated,
>
> [Shally] It should be pointer to flat buffers and added only to input/output data to/from
> asymmetric crypto engine.
>
>> it seems like
>> there might be a more general requirement in DPDK for IO addressable
>> memory (compression? other hardware acceleators implemented on FPGAs)
>> than just asymmetric crypto, will we end up needing to support features
>> like scatter gather lists in this structure?
>
> [Shally] I don’t anticipate that we would need to support scatter-gather data buffers as far as it is used for asymmetric.
> And I'm not aware if we have requirement to support it for asymmetric processing since data size is usually small for
> such operations. Thus, app is expected to send linear buffers for input/output.
>
> Does that answer your question? Or did I miss anything?
>
Sure I understand the rationale.
>
>> btw I think this is
>> probably fine for the moment as it will be expermential but I think it
>> will need to be addressed before the removal of the expermential tag.
>>
>
> ...
>
>>> + RTE_CRYPTO_ASYM_XFORM_MODINV,
>>
>> Would prefer if this was _MOD_INV :)
>>
>>> + /**< Modular Inverse
>>> + * Perform Modulus inverse b^(-1) mod n
>>> + */
>>> + RTE_CRYPTO_ASYM_XFORM_MODEX,
>>
>> any this was _MOD_EX :)
>
> [Shally] fine will do name change.
>
>>
>>> + /**< Modular Exponentiation
>>> + * Perform Modular Exponentiation b^e mod n
>>> + */
>>> + RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>>> + /**< End of list */
>>> +};
>>> +
>>> +/**
>>> + * Asymmetric crypto operation type variants
>>> + */
>>> +enum rte_crypto_asym_op_type {
>>> + RTE_CRYPTO_ASYM_OP_ENCRYPT,
>>> + /**< Asymmetric Encrypt operation */
>>> + RTE_CRYPTO_ASYM_OP_DECRYPT,
>>> + /**< Asymmetric Decrypt operation */
>>> + RTE_CRYPTO_ASYM_OP_SIGN,
>>> + /**< Signature Generation operation */
>>> + RTE_CRYPTO_ASYM_OP_VERIFY,
>>> + /**< Signature Verification operation */
>>> + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
>>> + /**< DH Private Key generation operation */
>>> + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
>>> + /**< DH Public Key generation operation */
>>> + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
>>> + /**< DH Shared Secret compute operation */
>>> + RTE_CRYPTO_ASYM_OP_LIST_END
>>> +};
>>> +
>>
>> I think that having generic operation types which may or may not apply
>> to all of the defined xforms is confusing from a user perspective and in
>> the longer term will make it impossible to support session-less
>> asymmetric operations. If we instead do something like
>>
>> RTE_CRYPTO_ASYM_OP_RSA_ENCRYPT,
>> RTE_CRYPTO_ASYM_OP_RSA_DECRYPT,
>> RTE_CRYPTO_ASYM_OP_RSA_SIGN,
>> RTE_CRYPTO_ASYM_OP_RSA_VERIFY,
>> RTE_CRYPTO_ASYM_OP_DH_KEY_GENERATE,
>> RTE_CRYPTO_ASYM_OP_DH_SHARED_SECRET_COMPUTE,
>> etc...
>>
>> Then the op type becomes very explicit and will allow session-less
>> operations to be supported by PMDs. This shouldn't have any impact on
>> your current implementation other than updating the op type.
>>
>
> [Shally] Ok, so you suggest to merge xform and op_type (including keeping op_type in one place) for simplicity sake.
>
> If we take this change, then I will prefer to keep it as xforms rather than op_types, such as,
>
> enum rte_crypto_asym_xform_types {
> RTE_CRYPTO_ASYM_XFORM_RSA_ENCRYPT,
> RTE_CRYPTO_ASYM_XFORM_RSA_SIGN,
> RTE_CRYPTO_ASYM_XFORM_DSA_SIGN,
> RTE_CRYPTO_ASYM_XFORM_DSA_VERIFY,
> RTE_CRYPTO_ASYM_XFORM_DH_PRIV_KEY_GENERATE,
> RTE_CRYPTO_ASYM_XFORM_DH_PUB_KEY_GENERATE,
> RTE_CRYPTO_ASYM_XFORM_DH_SHARED_SECRET_COMPUTE, .... and so on..
> }
>
> These, when set on a rte_crypto_asym_xform , will work seamlessly for both session and session-less.
> I also see advantage here to support xform chaining. In this case, op_type in rte_crypto_asym_xx_op_params isn't needed and will be removed.
> It will add bit of repetition though, like RSA_SIGN / DSA_SIGN, but that would occur in any case, if we are merging two types.
> Does that sound okay?
I would be a bit concerned with dropping the
rte_crypto_asym_xx_op_params as if we are following the symmetric model,
the xform should only specify the immutable data in relation to a
transform and the operation should provide the mutable input data. I'm
not sure how this would look like for the different asymmetric
operations but if there are transforms that don't have immutable data
then it would make more sense not to have a specific xform data
structure for that and pass the data through that transformations
operation structure.
>
> We were about to submit Openssl PMD with asym support today. But I would hold back till we align on this.
> ...
>
Ok, I think I had missed part of the complexity of the chained used
case. I think if we are to follow the symmetric crypto model we end up
with something along the lines of a fundamental op types - dh, dsa, mod,
rsa etc.
enum rte_crypto_asym_op_types {
RTE_CRYPTO_ASYM_OP_DH,
RTE_CRYPTO_ASYM_OP_DSA,
RTE_CRYPTO_ASYM_OP_MOD,
RTE_CRYPTO_ASYM_OP_RSA,
};
with a corresponding asym_op as follows.
struct rte_crypto_asym_op {
union {
struct rte_cryptodev_asym_session *session;
/**< Handle for the initialized session context */
struct rte_crypto_asym_xform *xform;
};
union {
struct rte_crypto_asym_dh_op_data dh;
struct rte_crypto_asym_dsa_op_data dsa;
struct rte_crypto_asyn_mod_op_data mod;
struct rte_crypto_asym_rsa_op_data rsa;
} op_data;
};
In terms of the xform definitions I'm not sure that we should have all
the different transforms defined in the same enum. If we take the below
approach, all the specifics of each transform could be split out into
separate headers, giving a cleaner API. This would see a xform types
enum which would mirror the operation types:
enum rte_crypto_asym_xform_types {
RTE_CRYPTO_ASYM_XFORM_DH,
RTE_CRYPTO_ASYM_XFORM_DSA,
RTE_CRYPTO_ASYM_XFORM_MOD,
RTE_CRYPTO_ASYM_XFORM_RSA,
}
with corresponding xforms structures
struct rte_crypto_asym_xform dh;
struct rte_crypto_asym_xform dsa;
struct rte_crypto_asym_xform modlus;
struct rte_crypto_asym_xform rsa;
then within the xforms would define the sub-type of that xform and have
definitions of the relevant session data which is required, with the
rsa it might look like something like this:
enum rte_crypto_asym_xform_rsa_types {
RTE_CRYPTO_ASYM_XFORM_RSA_ENCRYPT,
RTE_CRYPTO_ASYM_XFORM_RSA_DECRYPT,
RTE_CRYPTO_ASYM_XFORM_RSA_SIGN,
RTE_CRYPTO_ASYM_XFORM_RSA_VERIFY,
}
struct rte_crypto_asym_xform rsa {
enum rte_crypto_asym_op_rsa_types type;
union {
struct rte_crypto_asym_xform_rsa_encrypt_data encrypt;
struct rte_crypto_asym_xform_rsa_decrypt_data decrypt;
etc...
} data;
};
The need for xform sub-type data structure would be dependent on whether
there was immutable data associated with a particular transform. Also if
we take this approach it would allow each operation type to be separated
out into there own headers.
>> ....
>>
>>
>>> + */
>>> +struct rte_crypto_dh_xform {
>>> + enum rte_crypto_asym_op_type type;
>>> + /**< Setup xform for key generate or shared secret compute */
>>> +
>>
>> there is an inconsistency here in terms of were the op_type is defined,
>> in this case it is in the xform but it other cases RSA, DSA it is
>> defined in the operation information itself. I don't know of any reason
>> why it is needed in the xform but I think it must be consistent across
>> all operations/xforms. Ideally from my perspective it would be in the
>> rte_crypto_asym_op structure, see below, as this would allow
>> session/session-less operations to be supported seamlessly.
>>
>
> [Shally] Reason was xform chaining. As per Fiona feedback, we identified requirement to break DH Key pair
> generation in to two : PRIV_KEY_GENERATION and PUB_KEY_GENERATION, so I had to move this param around.
> But this will be addressed once we change xform_types as per suggestion above.
>
> ...
>
>>
>> ...
>>
>>> +/**
>>> + * Asymmetric Cryptographic Operation.
>>> + *
>>> + * Structure describing asymmetric crypto operation params.
>>> + *
>>> + */
>>> +struct rte_crypto_asym_op {
>>> + struct rte_cryptodev_asym_session *session;
>>> + /**< Handle for the initialised session context */
>>> +
>>> + __extension__
>>> + union {
>>> + struct rte_crypto_rsa_op_param rsa;
>>> + struct rte_crypto_mod_op_param modex;
>>> + struct rte_crypto_mod_op_param modinv;
>>> + struct rte_crypto_dh_op_param dh;
>>> + struct rte_crypto_dsa_op_param dsa;
>>> + };
>>> +} __rte_cache_aligned;
>>> +
>> Relating to my comment on position of the op_type and the minor change
>> of having an union of session/xform in the rte_crypto_asym_op structure
>> would then enable sessionless support to be added seamless in the future
>> with minimal effect to the current proposal.
>
> [Shally] Again, this will also be resolved with change to xform_types
>
>>
>> struct rte_crypto_asym_op {
>> - struct rte_cryptodev_asym_session *session;
>> - /**< Handle for the initialised session context */
>> + enum rte_crypto_asym_op_type op_type;
>> +
>> + union {
>> + struct rte_cryptodev_asym_session *session;
>> + /**< Handle for the initialised session context */
>> + struct rte_crypto_asym_xform *xform;
>> + };
>>
> [Shally] Ok. Will add this change. But then I'll have to check if crypto PMD has support to reflect which type of mode it supports?
>
The sess_type=RTE_CRYPTO_OP_WITH_SESSION/RTE_CRYPTO_OP_SESSIONLESS
should be set in the outer crypto_op struct, so if the PMD doesn't
support the selected sess_type, it should just fail the enqueue and
possibly log an error.
> Thanks for review.
> Shally
>
>> __extension__
>>
>>
>>> +#ifdef __cplusplus
>>> +}
>>> +#endif
>>> +
>>> +#endif /* _RTE_CRYPTO_ASYM_H_ */
>>>
>
Hi Shally, Declan, Pablo,
I'm concerned about rushing in significant last-minute changes, but would like to see this API in 18.08.
So I suggest the patchset is applied with the caveat that it is experimental and will continue to be so
for the next release, in which the remaining open issues should be addressed.
The main areas of concern are:
- the structures for xforms and ops and rework needed to cater for sessionless
- capabilities
Regards,
Fiona
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Doherty, Declan
> Sent: Monday, July 9, 2018 3:55 PM
> To: Verma, Shally <Shally.Verma@cavium.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy,
> Nidadavolu <Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta,
> Ashish <Ashish.Gupta@cavium.com>; Kartha, Umesh <Umesh.Kartha@cavium.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>
> On 06/07/2018 3:28 PM, Verma, Shally wrote:
> > Hi Declan
> >
> >> -----Original Message-----
> >> From: Doherty, Declan [mailto:declan.doherty@intel.com]
> >> Sent: 05 July 2018 20:24
> >> To: Verma, Shally <Shally.Verma@cavium.com>; pablo.de.lara.guarch@intel.com
> >> Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy,
> Nidadavolu
> >> <Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish
> <Ashish.Gupta@cavium.com>; Kartha,
> >> Umesh <Umesh.Kartha@cavium.com>
> >> Subject: Re: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
> >>
> >> External Email
> >>
> >> Hey Shally,
> >>
> >> just a few things inline below mainly concerned with the need to be able
> >> to support session-less operations in future PMDs. I think with a few
> >> minor changes to the API now it should allow session-less to be
> >> supported later without the need for a major rework of the APIs, I don't
> >> think this should cause any major rework to your PMD just the adoption
> >> of some new more explicit op types.
> >>
> >> Thanks
> >> Declan
> >>
> >> On 03/07/2018 4:24 PM, Shally Verma wrote:
> >>> Add rte_crypto_asym.h with supported xfrms
> >>> and associated op structures and APIs
> >>>
> >>> API currently supports:
> >>> - RSA Encrypt, Decrypt, Sign and Verify
> >>> - Modular Exponentiation and Inversion
> >>> - DSA Sign and Verify
> >>> - Deffie-hellman private key exchange
> >>> - Deffie-hellman public key exchange
> >>> - Deffie-hellman shared secret compute
> >>> - Deffie-hellman public/private key pair generation
> >>> using xform chain
> >>>
> >>> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> >>> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> >>> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
> >>> Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
> >>> ---
> >>> lib/librte_cryptodev/Makefile | 1 +
> >>> lib/librte_cryptodev/meson.build | 3 +-
> >>> lib/librte_cryptodev/rte_crypto_asym.h | 496 +++++++++++++++++++++++++++++++++
> >>> 3 files changed, 499 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cr
> >>
> >> ...
> >>
> >>> +typedef struct rte_crypto_param_t {
> >>> + uint8_t *data;
> >>> + /**< pointer to buffer holding data */
> >>> + rte_iova_t iova;
> >>> + /**< IO address of data buffer */
> >>> + size_t length;
> >>> + /**< length of data in bytes */
> >>> +} rte_crypto_param;
> >>
> >> What is the intended way for this memory to be allocated,
> >
> > [Shally] It should be pointer to flat buffers and added only to input/output data to/from
> > asymmetric crypto engine.
> >
> >> it seems like
> >> there might be a more general requirement in DPDK for IO addressable
> >> memory (compression? other hardware acceleators implemented on FPGAs)
> >> than just asymmetric crypto, will we end up needing to support features
> >> like scatter gather lists in this structure?
> >
> > [Shally] I don’t anticipate that we would need to support scatter-gather data buffers as far as it is used
> for asymmetric.
> > And I'm not aware if we have requirement to support it for asymmetric processing since data size is
> usually small for
> > such operations. Thus, app is expected to send linear buffers for input/output.
> >
> > Does that answer your question? Or did I miss anything?
> >
>
> Sure I understand the rationale.
>
> >
> >> btw I think this is
> >> probably fine for the moment as it will be expermential but I think it
> >> will need to be addressed before the removal of the expermential tag.
> >>
> >
> > ...
> >
> >>> + RTE_CRYPTO_ASYM_XFORM_MODINV,
> >>
> >> Would prefer if this was _MOD_INV :)
> >>
> >>> + /**< Modular Inverse
> >>> + * Perform Modulus inverse b^(-1) mod n
> >>> + */
> >>> + RTE_CRYPTO_ASYM_XFORM_MODEX,
> >>
> >> any this was _MOD_EX :)
> >
> > [Shally] fine will do name change.
> >
> >>
> >>> + /**< Modular Exponentiation
> >>> + * Perform Modular Exponentiation b^e mod n
> >>> + */
> >>> + RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> >>> + /**< End of list */
> >>> +};
> >>> +
> >>> +/**
> >>> + * Asymmetric crypto operation type variants
> >>> + */
> >>> +enum rte_crypto_asym_op_type {
> >>> + RTE_CRYPTO_ASYM_OP_ENCRYPT,
> >>> + /**< Asymmetric Encrypt operation */
> >>> + RTE_CRYPTO_ASYM_OP_DECRYPT,
> >>> + /**< Asymmetric Decrypt operation */
> >>> + RTE_CRYPTO_ASYM_OP_SIGN,
> >>> + /**< Signature Generation operation */
> >>> + RTE_CRYPTO_ASYM_OP_VERIFY,
> >>> + /**< Signature Verification operation */
> >>> + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
> >>> + /**< DH Private Key generation operation */
> >>> + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
> >>> + /**< DH Public Key generation operation */
> >>> + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> >>> + /**< DH Shared Secret compute operation */
> >>> + RTE_CRYPTO_ASYM_OP_LIST_END
> >>> +};
> >>> +
> >>
> >> I think that having generic operation types which may or may not apply
> >> to all of the defined xforms is confusing from a user perspective and in
> >> the longer term will make it impossible to support session-less
> >> asymmetric operations. If we instead do something like
> >>
> >> RTE_CRYPTO_ASYM_OP_RSA_ENCRYPT,
> >> RTE_CRYPTO_ASYM_OP_RSA_DECRYPT,
> >> RTE_CRYPTO_ASYM_OP_RSA_SIGN,
> >> RTE_CRYPTO_ASYM_OP_RSA_VERIFY,
> >> RTE_CRYPTO_ASYM_OP_DH_KEY_GENERATE,
> >> RTE_CRYPTO_ASYM_OP_DH_SHARED_SECRET_COMPUTE,
> >> etc...
> >>
> >> Then the op type becomes very explicit and will allow session-less
> >> operations to be supported by PMDs. This shouldn't have any impact on
> >> your current implementation other than updating the op type.
> >>
> >
> > [Shally] Ok, so you suggest to merge xform and op_type (including keeping op_type in one place) for
> simplicity sake.
> >
> > If we take this change, then I will prefer to keep it as xforms rather than op_types, such as,
> >
> > enum rte_crypto_asym_xform_types {
> > RTE_CRYPTO_ASYM_XFORM_RSA_ENCRYPT,
> > RTE_CRYPTO_ASYM_XFORM_RSA_SIGN,
> > RTE_CRYPTO_ASYM_XFORM_DSA_SIGN,
> > RTE_CRYPTO_ASYM_XFORM_DSA_VERIFY,
> > RTE_CRYPTO_ASYM_XFORM_DH_PRIV_KEY_GENERATE,
> > RTE_CRYPTO_ASYM_XFORM_DH_PUB_KEY_GENERATE,
> > RTE_CRYPTO_ASYM_XFORM_DH_SHARED_SECRET_COMPUTE, .... and so on..
> > }
> >
> > These, when set on a rte_crypto_asym_xform , will work seamlessly for both session and session-less.
> > I also see advantage here to support xform chaining. In this case, op_type in
> rte_crypto_asym_xx_op_params isn't needed and will be removed.
> > It will add bit of repetition though, like RSA_SIGN / DSA_SIGN, but that would occur in any case, if we
> are merging two types.
> > Does that sound okay?
>
> I would be a bit concerned with dropping the
> rte_crypto_asym_xx_op_params as if we are following the symmetric model,
> the xform should only specify the immutable data in relation to a
> transform and the operation should provide the mutable input data. I'm
> not sure how this would look like for the different asymmetric
> operations but if there are transforms that don't have immutable data
> then it would make more sense not to have a specific xform data
> structure for that and pass the data through that transformations
> operation structure.
>
> >
> > We were about to submit Openssl PMD with asym support today. But I would hold back till we align on
> this.
> > ...
> >
>
> Ok, I think I had missed part of the complexity of the chained used
> case. I think if we are to follow the symmetric crypto model we end up
> with something along the lines of a fundamental op types - dh, dsa, mod,
> rsa etc.
>
> enum rte_crypto_asym_op_types {
> RTE_CRYPTO_ASYM_OP_DH,
> RTE_CRYPTO_ASYM_OP_DSA,
> RTE_CRYPTO_ASYM_OP_MOD,
> RTE_CRYPTO_ASYM_OP_RSA,
> };
>
> with a corresponding asym_op as follows.
>
> struct rte_crypto_asym_op {
> union {
> struct rte_cryptodev_asym_session *session;
> /**< Handle for the initialized session context */
> struct rte_crypto_asym_xform *xform;
> };
>
> union {
> struct rte_crypto_asym_dh_op_data dh;
> struct rte_crypto_asym_dsa_op_data dsa;
> struct rte_crypto_asyn_mod_op_data mod;
> struct rte_crypto_asym_rsa_op_data rsa;
> } op_data;
> };
>
>
> In terms of the xform definitions I'm not sure that we should have all
> the different transforms defined in the same enum. If we take the below
> approach, all the specifics of each transform could be split out into
> separate headers, giving a cleaner API. This would see a xform types
> enum which would mirror the operation types:
>
> enum rte_crypto_asym_xform_types {
> RTE_CRYPTO_ASYM_XFORM_DH,
> RTE_CRYPTO_ASYM_XFORM_DSA,
> RTE_CRYPTO_ASYM_XFORM_MOD,
> RTE_CRYPTO_ASYM_XFORM_RSA,
> }
>
> with corresponding xforms structures
>
> struct rte_crypto_asym_xform dh;
> struct rte_crypto_asym_xform dsa;
> struct rte_crypto_asym_xform modlus;
> struct rte_crypto_asym_xform rsa;
>
> then within the xforms would define the sub-type of that xform and have
> definitions of the relevant session data which is required, with the
> rsa it might look like something like this:
>
> enum rte_crypto_asym_xform_rsa_types {
> RTE_CRYPTO_ASYM_XFORM_RSA_ENCRYPT,
> RTE_CRYPTO_ASYM_XFORM_RSA_DECRYPT,
> RTE_CRYPTO_ASYM_XFORM_RSA_SIGN,
> RTE_CRYPTO_ASYM_XFORM_RSA_VERIFY,
> }
>
> struct rte_crypto_asym_xform rsa {
> enum rte_crypto_asym_op_rsa_types type;
> union {
> struct rte_crypto_asym_xform_rsa_encrypt_data encrypt;
> struct rte_crypto_asym_xform_rsa_decrypt_data decrypt;
> etc...
> } data;
> };
>
> The need for xform sub-type data structure would be dependent on whether
> there was immutable data associated with a particular transform. Also if
> we take this approach it would allow each operation type to be separated
> out into there own headers.
>
> >> ....
> >>
> >>
> >>> + */
> >>> +struct rte_crypto_dh_xform {
> >>> + enum rte_crypto_asym_op_type type;
> >>> + /**< Setup xform for key generate or shared secret compute */
> >>> +
> >>
> >> there is an inconsistency here in terms of were the op_type is defined,
> >> in this case it is in the xform but it other cases RSA, DSA it is
> >> defined in the operation information itself. I don't know of any reason
> >> why it is needed in the xform but I think it must be consistent across
> >> all operations/xforms. Ideally from my perspective it would be in the
> >> rte_crypto_asym_op structure, see below, as this would allow
> >> session/session-less operations to be supported seamlessly.
> >>
> >
> > [Shally] Reason was xform chaining. As per Fiona feedback, we identified requirement to break DH Key
> pair
> > generation in to two : PRIV_KEY_GENERATION and PUB_KEY_GENERATION, so I had to move this
> param around.
> > But this will be addressed once we change xform_types as per suggestion above.
> >
> > ...
> >
> >>
> >> ...
> >>
> >>> +/**
> >>> + * Asymmetric Cryptographic Operation.
> >>> + *
> >>> + * Structure describing asymmetric crypto operation params.
> >>> + *
> >>> + */
> >>> +struct rte_crypto_asym_op {
> >>> + struct rte_cryptodev_asym_session *session;
> >>> + /**< Handle for the initialised session context */
> >>> +
> >>> + __extension__
> >>> + union {
> >>> + struct rte_crypto_rsa_op_param rsa;
> >>> + struct rte_crypto_mod_op_param modex;
> >>> + struct rte_crypto_mod_op_param modinv;
> >>> + struct rte_crypto_dh_op_param dh;
> >>> + struct rte_crypto_dsa_op_param dsa;
> >>> + };
> >>> +} __rte_cache_aligned;
> >>> +
> >> Relating to my comment on position of the op_type and the minor change
> >> of having an union of session/xform in the rte_crypto_asym_op structure
> >> would then enable sessionless support to be added seamless in the future
> >> with minimal effect to the current proposal.
> >
> > [Shally] Again, this will also be resolved with change to xform_types
> >
> >>
> >> struct rte_crypto_asym_op {
> >> - struct rte_cryptodev_asym_session *session;
> >> - /**< Handle for the initialised session context */
> >> + enum rte_crypto_asym_op_type op_type;
> >> +
> >> + union {
> >> + struct rte_cryptodev_asym_session *session;
> >> + /**< Handle for the initialised session context */
> >> + struct rte_crypto_asym_xform *xform;
> >> + };
> >>
> > [Shally] Ok. Will add this change. But then I'll have to check if crypto PMD has support to reflect which
> type of mode it supports?
> >
> The sess_type=RTE_CRYPTO_OP_WITH_SESSION/RTE_CRYPTO_OP_SESSIONLESS
> should be set in the outer crypto_op struct, so if the PMD doesn't
> support the selected sess_type, it should just fail the enqueue and
> possibly log an error.
>
> > Thanks for review.
> > Shally
> >
> >> __extension__
> >>
> >>
> >>> +#ifdef __cplusplus
> >>> +}
> >>> +#endif
> >>> +
> >>> +#endif /* _RTE_CRYPTO_ASYM_H_ */
> >>>
> >
>-----Original Message-----
>From: Trahe, Fiona [mailto:fiona.trahe@intel.com]
>Sent: 09 July 2018 22:15
>To: Doherty, Declan <declan.doherty@intel.com>; Verma, Shally <Shally.Verma@cavium.com>; De Lara Guarch, Pablo
><pablo.de.lara.guarch@intel.com>
>Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
><Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha,
>Umesh <Umesh.Kartha@cavium.com>; Trahe, Fiona <fiona.trahe@intel.com>
>Subject: RE: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>
>External Email
>
>Hi Shally, Declan, Pablo,
>
>I'm concerned about rushing in significant last-minute changes, but would like to see this API in 18.08.
>So I suggest the patchset is applied with the caveat that it is experimental and will continue to be so
>for the next release, in which the remaining open issues should be addressed.
>The main areas of concern are:
> - the structures for xforms and ops and rework needed to cater for sessionless
> - capabilities
>
Sounds good to me. If that’s fine with everyone, I will send current openssl PMD patch. Please confirm.
Thanks
Shally
>
>Regards,
>Fiona
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Doherty, Declan
>> Sent: Monday, July 9, 2018 3:55 PM
>> To: Verma, Shally <Shally.Verma@cavium.com>; De Lara Guarch, Pablo
>> <pablo.de.lara.guarch@intel.com>
>> Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy,
>> Nidadavolu <Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta,
>> Ashish <Ashish.Gupta@cavium.com>; Kartha, Umesh <Umesh.Kartha@cavium.com>
>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>>
>> On 06/07/2018 3:28 PM, Verma, Shally wrote:
>> > Hi Declan
>> >
>> >> -----Original Message-----
>> >> From: Doherty, Declan [mailto:declan.doherty@intel.com]
>> >> Sent: 05 July 2018 20:24
>> >> To: Verma, Shally <Shally.Verma@cavium.com>; pablo.de.lara.guarch@intel.com
>> >> Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy,
>> Nidadavolu
>> >> <Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish
>> <Ashish.Gupta@cavium.com>; Kartha,
>> >> Umesh <Umesh.Kartha@cavium.com>
>> >> Subject: Re: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>> >>
>> >> External Email
>> >>
>> >> Hey Shally,
>> >>
>> >> just a few things inline below mainly concerned with the need to be able
>> >> to support session-less operations in future PMDs. I think with a few
>> >> minor changes to the API now it should allow session-less to be
>> >> supported later without the need for a major rework of the APIs, I don't
>> >> think this should cause any major rework to your PMD just the adoption
>> >> of some new more explicit op types.
>> >>
>> >> Thanks
>> >> Declan
>> >>
>> >> On 03/07/2018 4:24 PM, Shally Verma wrote:
>> >>> Add rte_crypto_asym.h with supported xfrms
>> >>> and associated op structures and APIs
>> >>>
>> >>> API currently supports:
>> >>> - RSA Encrypt, Decrypt, Sign and Verify
>> >>> - Modular Exponentiation and Inversion
>> >>> - DSA Sign and Verify
>> >>> - Deffie-hellman private key exchange
>> >>> - Deffie-hellman public key exchange
>> >>> - Deffie-hellman shared secret compute
>> >>> - Deffie-hellman public/private key pair generation
>> >>> using xform chain
>> >>>
>> >>> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
>> >>> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>> >>> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>> >>> Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
>> >>> ---
>> >>> lib/librte_cryptodev/Makefile | 1 +
>> >>> lib/librte_cryptodev/meson.build | 3 +-
>> >>> lib/librte_cryptodev/rte_crypto_asym.h | 496 +++++++++++++++++++++++++++++++++
>> >>> 3 files changed, 499 insertions(+), 1 deletion(-)
>> >>>
>> >>> diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cr
>> >>
>> >> ...
>> >>
>> >>> +typedef struct rte_crypto_param_t {
>> >>> + uint8_t *data;
>> >>> + /**< pointer to buffer holding data */
>> >>> + rte_iova_t iova;
>> >>> + /**< IO address of data buffer */
>> >>> + size_t length;
>> >>> + /**< length of data in bytes */
>> >>> +} rte_crypto_param;
>> >>
>> >> What is the intended way for this memory to be allocated,
>> >
>> > [Shally] It should be pointer to flat buffers and added only to input/output data to/from
>> > asymmetric crypto engine.
>> >
>> >> it seems like
>> >> there might be a more general requirement in DPDK for IO addressable
>> >> memory (compression? other hardware acceleators implemented on FPGAs)
>> >> than just asymmetric crypto, will we end up needing to support features
>> >> like scatter gather lists in this structure?
>> >
>> > [Shally] I don’t anticipate that we would need to support scatter-gather data buffers as far as it is used
>> for asymmetric.
>> > And I'm not aware if we have requirement to support it for asymmetric processing since data size is
>> usually small for
>> > such operations. Thus, app is expected to send linear buffers for input/output.
>> >
>> > Does that answer your question? Or did I miss anything?
>> >
>>
>> Sure I understand the rationale.
>>
>> >
>> >> btw I think this is
>> >> probably fine for the moment as it will be expermential but I think it
>> >> will need to be addressed before the removal of the expermential tag.
>> >>
>> >
>> > ...
>> >
>> >>> + RTE_CRYPTO_ASYM_XFORM_MODINV,
>> >>
>> >> Would prefer if this was _MOD_INV :)
>> >>
>> >>> + /**< Modular Inverse
>> >>> + * Perform Modulus inverse b^(-1) mod n
>> >>> + */
>> >>> + RTE_CRYPTO_ASYM_XFORM_MODEX,
>> >>
>> >> any this was _MOD_EX :)
>> >
>> > [Shally] fine will do name change.
>> >
>> >>
>> >>> + /**< Modular Exponentiation
>> >>> + * Perform Modular Exponentiation b^e mod n
>> >>> + */
>> >>> + RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>> >>> + /**< End of list */
>> >>> +};
>> >>> +
>> >>> +/**
>> >>> + * Asymmetric crypto operation type variants
>> >>> + */
>> >>> +enum rte_crypto_asym_op_type {
>> >>> + RTE_CRYPTO_ASYM_OP_ENCRYPT,
>> >>> + /**< Asymmetric Encrypt operation */
>> >>> + RTE_CRYPTO_ASYM_OP_DECRYPT,
>> >>> + /**< Asymmetric Decrypt operation */
>> >>> + RTE_CRYPTO_ASYM_OP_SIGN,
>> >>> + /**< Signature Generation operation */
>> >>> + RTE_CRYPTO_ASYM_OP_VERIFY,
>> >>> + /**< Signature Verification operation */
>> >>> + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
>> >>> + /**< DH Private Key generation operation */
>> >>> + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
>> >>> + /**< DH Public Key generation operation */
>> >>> + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
>> >>> + /**< DH Shared Secret compute operation */
>> >>> + RTE_CRYPTO_ASYM_OP_LIST_END
>> >>> +};
>> >>> +
>> >>
>> >> I think that having generic operation types which may or may not apply
>> >> to all of the defined xforms is confusing from a user perspective and in
>> >> the longer term will make it impossible to support session-less
>> >> asymmetric operations. If we instead do something like
>> >>
>> >> RTE_CRYPTO_ASYM_OP_RSA_ENCRYPT,
>> >> RTE_CRYPTO_ASYM_OP_RSA_DECRYPT,
>> >> RTE_CRYPTO_ASYM_OP_RSA_SIGN,
>> >> RTE_CRYPTO_ASYM_OP_RSA_VERIFY,
>> >> RTE_CRYPTO_ASYM_OP_DH_KEY_GENERATE,
>> >> RTE_CRYPTO_ASYM_OP_DH_SHARED_SECRET_COMPUTE,
>> >> etc...
>> >>
>> >> Then the op type becomes very explicit and will allow session-less
>> >> operations to be supported by PMDs. This shouldn't have any impact on
>> >> your current implementation other than updating the op type.
>> >>
>> >
>> > [Shally] Ok, so you suggest to merge xform and op_type (including keeping op_type in one place) for
>> simplicity sake.
>> >
>> > If we take this change, then I will prefer to keep it as xforms rather than op_types, such as,
>> >
>> > enum rte_crypto_asym_xform_types {
>> > RTE_CRYPTO_ASYM_XFORM_RSA_ENCRYPT,
>> > RTE_CRYPTO_ASYM_XFORM_RSA_SIGN,
>> > RTE_CRYPTO_ASYM_XFORM_DSA_SIGN,
>> > RTE_CRYPTO_ASYM_XFORM_DSA_VERIFY,
>> > RTE_CRYPTO_ASYM_XFORM_DH_PRIV_KEY_GENERATE,
>> > RTE_CRYPTO_ASYM_XFORM_DH_PUB_KEY_GENERATE,
>> > RTE_CRYPTO_ASYM_XFORM_DH_SHARED_SECRET_COMPUTE, .... and so on..
>> > }
>> >
>> > These, when set on a rte_crypto_asym_xform , will work seamlessly for both session and session-less.
>> > I also see advantage here to support xform chaining. In this case, op_type in
>> rte_crypto_asym_xx_op_params isn't needed and will be removed.
>> > It will add bit of repetition though, like RSA_SIGN / DSA_SIGN, but that would occur in any case, if we
>> are merging two types.
>> > Does that sound okay?
>>
>> I would be a bit concerned with dropping the
>> rte_crypto_asym_xx_op_params as if we are following the symmetric model,
>> the xform should only specify the immutable data in relation to a
>> transform and the operation should provide the mutable input data. I'm
>> not sure how this would look like for the different asymmetric
>> operations but if there are transforms that don't have immutable data
>> then it would make more sense not to have a specific xform data
>> structure for that and pass the data through that transformations
>> operation structure.
>>
>> >
>> > We were about to submit Openssl PMD with asym support today. But I would hold back till we align on
>> this.
>> > ...
>> >
>>
>> Ok, I think I had missed part of the complexity of the chained used
>> case. I think if we are to follow the symmetric crypto model we end up
>> with something along the lines of a fundamental op types - dh, dsa, mod,
>> rsa etc.
>>
>> enum rte_crypto_asym_op_types {
>> RTE_CRYPTO_ASYM_OP_DH,
>> RTE_CRYPTO_ASYM_OP_DSA,
>> RTE_CRYPTO_ASYM_OP_MOD,
>> RTE_CRYPTO_ASYM_OP_RSA,
>> };
>>
>> with a corresponding asym_op as follows.
>>
>> struct rte_crypto_asym_op {
>> union {
>> struct rte_cryptodev_asym_session *session;
>> /**< Handle for the initialized session context */
>> struct rte_crypto_asym_xform *xform;
>> };
>>
>> union {
>> struct rte_crypto_asym_dh_op_data dh;
>> struct rte_crypto_asym_dsa_op_data dsa;
>> struct rte_crypto_asyn_mod_op_data mod;
>> struct rte_crypto_asym_rsa_op_data rsa;
>> } op_data;
>> };
>>
>>
>> In terms of the xform definitions I'm not sure that we should have all
>> the different transforms defined in the same enum. If we take the below
>> approach, all the specifics of each transform could be split out into
>> separate headers, giving a cleaner API. This would see a xform types
>> enum which would mirror the operation types:
>>
>> enum rte_crypto_asym_xform_types {
>> RTE_CRYPTO_ASYM_XFORM_DH,
>> RTE_CRYPTO_ASYM_XFORM_DSA,
>> RTE_CRYPTO_ASYM_XFORM_MOD,
>> RTE_CRYPTO_ASYM_XFORM_RSA,
>> }
>>
>> with corresponding xforms structures
>>
>> struct rte_crypto_asym_xform dh;
>> struct rte_crypto_asym_xform dsa;
>> struct rte_crypto_asym_xform modlus;
>> struct rte_crypto_asym_xform rsa;
>>
>> then within the xforms would define the sub-type of that xform and have
>> definitions of the relevant session data which is required, with the
>> rsa it might look like something like this:
>>
>> enum rte_crypto_asym_xform_rsa_types {
>> RTE_CRYPTO_ASYM_XFORM_RSA_ENCRYPT,
>> RTE_CRYPTO_ASYM_XFORM_RSA_DECRYPT,
>> RTE_CRYPTO_ASYM_XFORM_RSA_SIGN,
>> RTE_CRYPTO_ASYM_XFORM_RSA_VERIFY,
>> }
>>
>> struct rte_crypto_asym_xform rsa {
>> enum rte_crypto_asym_op_rsa_types type;
>> union {
>> struct rte_crypto_asym_xform_rsa_encrypt_data encrypt;
>> struct rte_crypto_asym_xform_rsa_decrypt_data decrypt;
>> etc...
>> } data;
>> };
>>
>> The need for xform sub-type data structure would be dependent on whether
>> there was immutable data associated with a particular transform. Also if
>> we take this approach it would allow each operation type to be separated
>> out into there own headers.
>>
>> >> ....
>> >>
>> >>
>> >>> + */
>> >>> +struct rte_crypto_dh_xform {
>> >>> + enum rte_crypto_asym_op_type type;
>> >>> + /**< Setup xform for key generate or shared secret compute */
>> >>> +
>> >>
>> >> there is an inconsistency here in terms of were the op_type is defined,
>> >> in this case it is in the xform but it other cases RSA, DSA it is
>> >> defined in the operation information itself. I don't know of any reason
>> >> why it is needed in the xform but I think it must be consistent across
>> >> all operations/xforms. Ideally from my perspective it would be in the
>> >> rte_crypto_asym_op structure, see below, as this would allow
>> >> session/session-less operations to be supported seamlessly.
>> >>
>> >
>> > [Shally] Reason was xform chaining. As per Fiona feedback, we identified requirement to break DH Key
>> pair
>> > generation in to two : PRIV_KEY_GENERATION and PUB_KEY_GENERATION, so I had to move this
>> param around.
>> > But this will be addressed once we change xform_types as per suggestion above.
>> >
>> > ...
>> >
>> >>
>> >> ...
>> >>
>> >>> +/**
>> >>> + * Asymmetric Cryptographic Operation.
>> >>> + *
>> >>> + * Structure describing asymmetric crypto operation params.
>> >>> + *
>> >>> + */
>> >>> +struct rte_crypto_asym_op {
>> >>> + struct rte_cryptodev_asym_session *session;
>> >>> + /**< Handle for the initialised session context */
>> >>> +
>> >>> + __extension__
>> >>> + union {
>> >>> + struct rte_crypto_rsa_op_param rsa;
>> >>> + struct rte_crypto_mod_op_param modex;
>> >>> + struct rte_crypto_mod_op_param modinv;
>> >>> + struct rte_crypto_dh_op_param dh;
>> >>> + struct rte_crypto_dsa_op_param dsa;
>> >>> + };
>> >>> +} __rte_cache_aligned;
>> >>> +
>> >> Relating to my comment on position of the op_type and the minor change
>> >> of having an union of session/xform in the rte_crypto_asym_op structure
>> >> would then enable sessionless support to be added seamless in the future
>> >> with minimal effect to the current proposal.
>> >
>> > [Shally] Again, this will also be resolved with change to xform_types
>> >
>> >>
>> >> struct rte_crypto_asym_op {
>> >> - struct rte_cryptodev_asym_session *session;
>> >> - /**< Handle for the initialised session context */
>> >> + enum rte_crypto_asym_op_type op_type;
>> >> +
>> >> + union {
>> >> + struct rte_cryptodev_asym_session *session;
>> >> + /**< Handle for the initialised session context */
>> >> + struct rte_crypto_asym_xform *xform;
>> >> + };
>> >>
>> > [Shally] Ok. Will add this change. But then I'll have to check if crypto PMD has support to reflect which
>> type of mode it supports?
>> >
>> The sess_type=RTE_CRYPTO_OP_WITH_SESSION/RTE_CRYPTO_OP_SESSIONLESS
>> should be set in the outer crypto_op struct, so if the PMD doesn't
>> support the selected sess_type, it should just fail the enqueue and
>> possibly log an error.
>>
>> > Thanks for review.
>> > Shally
>> >
>> >> __extension__
>> >>
>> >>
>> >>> +#ifdef __cplusplus
>> >>> +}
>> >>> +#endif
>> >>> +
>> >>> +#endif /* _RTE_CRYPTO_ASYM_H_ */
>> >>>
>> >
Hi Shally,
> -----Original Message-----
> From: Verma, Shally [mailto:Shally.Verma@cavium.com]
> Sent: Monday, July 9, 2018 6:12 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; Doherty, Declan
> <declan.doherty@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; Athreya, Narayana Prasad
> <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
> <Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
> Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha, Umesh
> <Umesh.Kartha@cavium.com>
> Subject: RE: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in
> cryptodev
>
>
>
> >-----Original Message-----
> >From: Trahe, Fiona [mailto:fiona.trahe@intel.com]
> >Sent: 09 July 2018 22:15
> >To: Doherty, Declan <declan.doherty@intel.com>; Verma, Shally
> ><Shally.Verma@cavium.com>; De Lara Guarch, Pablo
> ><pablo.de.lara.guarch@intel.com>
> >Cc: dev@dpdk.org; Athreya, Narayana Prasad
> ><NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
> ><Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
> >Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha, Umesh
> ><Umesh.Kartha@cavium.com>; Trahe, Fiona <fiona.trahe@intel.com>
> >Subject: RE: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric
> >algos in cryptodev
> >
> >External Email
> >
> >Hi Shally, Declan, Pablo,
> >
> >I'm concerned about rushing in significant last-minute changes, but would like
> to see this API in 18.08.
> >So I suggest the patchset is applied with the caveat that it is
> >experimental and will continue to be so for the next release, in which the
> remaining open issues should be addressed.
> >The main areas of concern are:
> > - the structures for xforms and ops and rework needed to cater for
> >sessionless
> > - capabilities
> >
> Sounds good to me. If that’s fine with everyone, I will send current openssl PMD
> patch. Please confirm.
>
I agree with Fiona. This was postponed one release, so it is fair that it makes it into 18.08,
knowing that there will be substantial changes in the next release.
About OpenSSL, please make sure that it works on 1.1.0.
Thanks,
Pablo
> Thanks
> Shally
> >
> >Regards,
> >Fiona
> >
> >
>-----Original Message-----
>From: De Lara Guarch, Pablo [mailto:pablo.de.lara.guarch@intel.com]
>Sent: 09 July 2018 22:46
>To: Verma, Shally <Shally.Verma@cavium.com>; Trahe, Fiona <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>
>Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
><Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha,
>Umesh <Umesh.Kartha@cavium.com>
>Subject: RE: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>
>External Email
>
>Hi Shally,
>
>> -----Original Message-----
>> From: Verma, Shally [mailto:Shally.Verma@cavium.com]
>> Sent: Monday, July 9, 2018 6:12 PM
>> To: Trahe, Fiona <fiona.trahe@intel.com>; Doherty, Declan
>> <declan.doherty@intel.com>; De Lara Guarch, Pablo
>> <pablo.de.lara.guarch@intel.com>
>> Cc: dev@dpdk.org; Athreya, Narayana Prasad
>> <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
>> <Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
>> Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha, Umesh
>> <Umesh.Kartha@cavium.com>
>> Subject: RE: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in
>> cryptodev
>>
>>
>>
>> >-----Original Message-----
>> >From: Trahe, Fiona [mailto:fiona.trahe@intel.com]
>> >Sent: 09 July 2018 22:15
>> >To: Doherty, Declan <declan.doherty@intel.com>; Verma, Shally
>> ><Shally.Verma@cavium.com>; De Lara Guarch, Pablo
>> ><pablo.de.lara.guarch@intel.com>
>> >Cc: dev@dpdk.org; Athreya, Narayana Prasad
>> ><NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
>> ><Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
>> >Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha, Umesh
>> ><Umesh.Kartha@cavium.com>; Trahe, Fiona <fiona.trahe@intel.com>
>> >Subject: RE: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric
>> >algos in cryptodev
>> >
>> >External Email
>> >
>> >Hi Shally, Declan, Pablo,
>> >
>> >I'm concerned about rushing in significant last-minute changes, but would like
>> to see this API in 18.08.
>> >So I suggest the patchset is applied with the caveat that it is
>> >experimental and will continue to be so for the next release, in which the
>> remaining open issues should be addressed.
>> >The main areas of concern are:
>> > - the structures for xforms and ops and rework needed to cater for
>> >sessionless
>> > - capabilities
>> >
>> Sounds good to me. If that’s fine with everyone, I will send current openssl PMD
>> patch. Please confirm.
>>
>
>I agree with Fiona. This was postponed one release, so it is fair that it makes it into 18.08,
>knowing that there will be substantial changes in the next release.
>
We will continue to discuss through open items to find level of change.
>About OpenSSL, please make sure that it works on 1.1.0.
Yup. It will support 1.1.0 with compatibility to 1.0.2
Thanks
Shally
>
>Thanks,
>Pablo
>
>> Thanks
>> Shally
>> >
>> >Regards,
>> >Fiona
>> >
>> >
Hi Shally,
A few minor comments:
> -----Original Message-----
> From: Shally Verma [mailto:shally.verma@caviumnetworks.com]
> Sent: Tuesday, July 3, 2018 4:24 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
> nmurthy@caviumnetworks.com; Sunila Sahu
> <sunila.sahu@caviumnetworks.com>; Ashish Gupta
> <ashish.gupta@caviumnetworks.com>; Umesh Kartha
> <umesh.kartha@caviumnetworks.com>
> Subject: [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>
Change title to: "cryptodev: add basic asymmetric structures"?
At least, don't use lib, and cryptodev twice.
> Add rte_crypto_asym.h with supported xfrms and associated op structures and
> APIs
>
> API currently supports:
> - RSA Encrypt, Decrypt, Sign and Verify
> - Modular Exponentiation and Inversion
> - DSA Sign and Verify
> - Deffie-hellman private key exchange
Diffie-Hellman
> - Deffie-hellman public key exchange
> - Deffie-hellman shared secret compute
> - Deffie-hellman public/private key pair generation using xform chain
>
> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
> Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
> -----Original Message-----
> From: Shally Verma [mailto:shally.verma@caviumnetworks.com]
> Sent: Tuesday, July 3, 2018 4:24 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
> nmurthy@caviumnetworks.com; Sunila Sahu
> <sunila.sahu@caviumnetworks.com>; Ashish Gupta
> <ashish.gupta@caviumnetworks.com>; Umesh Kartha
> <umesh.kartha@caviumnetworks.com>
> Subject: [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>
> Add rte_crypto_asym.h with supported xfrms and associated op structures and
> APIs
One more comment that I missed.
> +++ b/lib/librte_cryptodev/rte_crypto_asym.h
...
> +struct rte_crypto_rsa_op_param {
...
> + rte_crypto_param sign;
> + /**<
> + * Pointer to RSA signature data. If operation is RSA
> + * sign @ref RTE_CRYPTO_RSA_OP_SIGN, buffer will be
> + * over-written with generated signature.
There is an error when building the API documentation here:
lib/librte_cryptodev/rte_crypto_asym.h:383: warning:
unable to resolve reference to `RTE_CRYPTO_RSA_OP_SIGN' for \ref command
Hi Pablo
>-----Original Message-----
>From: De Lara Guarch, Pablo [mailto:pablo.de.lara.guarch@intel.com]
>Sent: 10 July 2018 03:54
>To: Verma, Shally <Shally.Verma@cavium.com>
>Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
><Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha,
>Umesh <Umesh.Kartha@cavium.com>
>Subject: RE: [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>
>External Email
>
>Hi Shally,
>
>A few minor comments:
>
>> -----Original Message-----
>> From: Shally Verma [mailto:shally.verma@caviumnetworks.com]
>> Sent: Tuesday, July 3, 2018 4:24 PM
>> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
>> nmurthy@caviumnetworks.com; Sunila Sahu
>> <sunila.sahu@caviumnetworks.com>; Ashish Gupta
>> <ashish.gupta@caviumnetworks.com>; Umesh Kartha
>> <umesh.kartha@caviumnetworks.com>
>> Subject: [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>>
>
>Change title to: "cryptodev: add basic asymmetric structures"?
>At least, don't use lib, and cryptodev twice.
So what's convention for all patches? Just cryptodev: <actual title> ?
Thanks
Shally
>
>> Add rte_crypto_asym.h with supported xfrms and associated op structures and
>> APIs
>>
>> API currently supports:
>> - RSA Encrypt, Decrypt, Sign and Verify
>> - Modular Exponentiation and Inversion
>> - DSA Sign and Verify
>> - Deffie-hellman private key exchange
>
>Diffie-Hellman
>
>> - Deffie-hellman public key exchange
>> - Deffie-hellman shared secret compute
>> - Deffie-hellman public/private key pair generation using xform chain
>>
>> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
>> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>> Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
>
> -----Original Message-----
> From: Verma, Shally [mailto:Shally.Verma@cavium.com]
> Sent: Tuesday, July 10, 2018 6:22 AM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; Athreya, Narayana Prasad
> <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
> <Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
> Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha, Umesh
> <Umesh.Kartha@cavium.com>
> Subject: RE: [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>
> Hi Pablo
>
> >-----Original Message-----
> >From: De Lara Guarch, Pablo [mailto:pablo.de.lara.guarch@intel.com]
> >Sent: 10 July 2018 03:54
> >To: Verma, Shally <Shally.Verma@cavium.com>
> >Cc: dev@dpdk.org; Athreya, Narayana Prasad
> ><NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
> ><Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
> >Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha, Umesh
> ><Umesh.Kartha@cavium.com>
> >Subject: RE: [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in
> >cryptodev
> >
> >External Email
> >
> >Hi Shally,
> >
> >A few minor comments:
> >
> >> -----Original Message-----
> >> From: Shally Verma [mailto:shally.verma@caviumnetworks.com]
> >> Sent: Tuesday, July 3, 2018 4:24 PM
> >> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> >> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
> >> nmurthy@caviumnetworks.com; Sunila Sahu
> >> <sunila.sahu@caviumnetworks.com>; Ashish Gupta
> >> <ashish.gupta@caviumnetworks.com>; Umesh Kartha
> >> <umesh.kartha@caviumnetworks.com>
> >> Subject: [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in
> >> cryptodev
> >>
> >
> >Change title to: "cryptodev: add basic asymmetric structures"?
> >At least, don't use lib, and cryptodev twice.
>
> So what's convention for all patches? Just cryptodev: <actual title> ?
Correct. For libraries, title prefix should be just the name of the library.
For other components, we usually need two names, the folder where the belong and the component name.
For example, for drivers, we use the folder where they belong and their name (e.g. crypto/openssl).
Pablo
>
> Thanks
> Shally
>
> >
> >> Add rte_crypto_asym.h with supported xfrms and associated op
> >> structures and APIs
> >>
> >> API currently supports:
> >> - RSA Encrypt, Decrypt, Sign and Verify
> >> - Modular Exponentiation and Inversion
> >> - DSA Sign and Verify
> >> - Deffie-hellman private key exchange
> >
> >Diffie-Hellman
> >
> >> - Deffie-hellman public key exchange
> >> - Deffie-hellman shared secret compute
> >> - Deffie-hellman public/private key pair generation using xform chain
> >>
> >> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> >> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> >> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
> >> Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
> >
HI Declan
>-----Original Message-----
>From: Doherty, Declan [mailto:declan.doherty@intel.com]
>Sent: 09 July 2018 20:25
>To: Verma, Shally <Shally.Verma@cavium.com>; pablo.de.lara.guarch@intel.com
>Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
><Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Kartha,
>Umesh <Umesh.Kartha@cavium.com>
>Subject: Re: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>
>External Email
>
>On 06/07/2018 3:28 PM, Verma, Shally wrote:
>> Hi Declan
>>
>>> -----Original Message-----
>>> From: Doherty, Declan [mailto:declan.doherty@intel.com]
>>> Sent: 05 July 2018 20:24
>>> To: Verma, Shally <Shally.Verma@cavium.com>; pablo.de.lara.guarch@intel.com
>>> Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Murthy, Nidadavolu
>>> <Nidadavolu.Murthy@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>;
>Kartha,
>>> Umesh <Umesh.Kartha@cavium.com>
>>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] lib/cryptodev: add asymmetric algos in cryptodev
>>>
>>> External Email
>>>
>>> Hey Shally,
>>>
>>> just a few things inline below mainly concerned with the need to be able
>>> to support session-less operations in future PMDs. I think with a few
>>> minor changes to the API now it should allow session-less to be
>>> supported later without the need for a major rework of the APIs, I don't
>>> think this should cause any major rework to your PMD just the adoption
>>> of some new more explicit op types.
>>>
>>> Thanks
>>> Declan
>>>
>>> On 03/07/2018 4:24 PM, Shally Verma wrote:
>>>> Add rte_crypto_asym.h with supported xfrms
>>>> and associated op structures and APIs
>>>>
>>>> API currently supports:
>>>> - RSA Encrypt, Decrypt, Sign and Verify
>>>> - Modular Exponentiation and Inversion
>>>> - DSA Sign and Verify
>>>> - Deffie-hellman private key exchange
>>>> - Deffie-hellman public key exchange
>>>> - Deffie-hellman shared secret compute
>>>> - Deffie-hellman public/private key pair generation
>>>> using xform chain
>>>>
>>>> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
>>>> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>>>> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>>>> Signed-off-by: Umesh Kartha <umesh.kartha@caviumnetworks.com>
>>>> ---
>>>> lib/librte_cryptodev/Makefile | 1 +
>>>> lib/librte_cryptodev/meson.build | 3 +-
>>>> lib/librte_cryptodev/rte_crypto_asym.h | 496 +++++++++++++++++++++++++++++++++
>>>> 3 files changed, 499 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cr
>>>
>>> ...
>>>
>>>> +typedef struct rte_crypto_param_t {
>>>> + uint8_t *data;
>>>> + /**< pointer to buffer holding data */
>>>> + rte_iova_t iova;
>>>> + /**< IO address of data buffer */
>>>> + size_t length;
>>>> + /**< length of data in bytes */
>>>> +} rte_crypto_param;
>>>
>>> What is the intended way for this memory to be allocated,
>>
>> [Shally] It should be pointer to flat buffers and added only to input/output data to/from
>> asymmetric crypto engine.
>>
>>> it seems like
>>> there might be a more general requirement in DPDK for IO addressable
>>> memory (compression? other hardware acceleators implemented on FPGAs)
>>> than just asymmetric crypto, will we end up needing to support features
>>> like scatter gather lists in this structure?
>>
>> [Shally] I don’t anticipate that we would need to support scatter-gather data buffers as far as it is used for asymmetric.
>> And I'm not aware if we have requirement to support it for asymmetric processing since data size is usually small for
>> such operations. Thus, app is expected to send linear buffers for input/output.
>>
>> Does that answer your question? Or did I miss anything?
>>
>
>Sure I understand the rationale.
>
>>
>>> btw I think this is
>>> probably fine for the moment as it will be expermential but I think it
>>> will need to be addressed before the removal of the expermential tag.
>>>
>>
>> ...
>>
>>>> + RTE_CRYPTO_ASYM_XFORM_MODINV,
>>>
>>> Would prefer if this was _MOD_INV :)
>>>
>>>> + /**< Modular Inverse
>>>> + * Perform Modulus inverse b^(-1) mod n
>>>> + */
>>>> + RTE_CRYPTO_ASYM_XFORM_MODEX,
>>>
>>> any this was _MOD_EX :)
>>
>> [Shally] fine will do name change.
>>
>>>
>>>> + /**< Modular Exponentiation
>>>> + * Perform Modular Exponentiation b^e mod n
>>>> + */
>>>> + RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>>>> + /**< End of list */
>>>> +};
>>>> +
>>>> +/**
>>>> + * Asymmetric crypto operation type variants
>>>> + */
>>>> +enum rte_crypto_asym_op_type {
>>>> + RTE_CRYPTO_ASYM_OP_ENCRYPT,
>>>> + /**< Asymmetric Encrypt operation */
>>>> + RTE_CRYPTO_ASYM_OP_DECRYPT,
>>>> + /**< Asymmetric Decrypt operation */
>>>> + RTE_CRYPTO_ASYM_OP_SIGN,
>>>> + /**< Signature Generation operation */
>>>> + RTE_CRYPTO_ASYM_OP_VERIFY,
>>>> + /**< Signature Verification operation */
>>>> + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
>>>> + /**< DH Private Key generation operation */
>>>> + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
>>>> + /**< DH Public Key generation operation */
>>>> + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
>>>> + /**< DH Shared Secret compute operation */
>>>> + RTE_CRYPTO_ASYM_OP_LIST_END
>>>> +};
>>>> +
>>>
>>> I think that having generic operation types which may or may not apply
>>> to all of the defined xforms is confusing from a user perspective and in
>>> the longer term will make it impossible to support session-less
>>> asymmetric operations. If we instead do something like
>>>
>>> RTE_CRYPTO_ASYM_OP_RSA_ENCRYPT,
>>> RTE_CRYPTO_ASYM_OP_RSA_DECRYPT,
>>> RTE_CRYPTO_ASYM_OP_RSA_SIGN,
>>> RTE_CRYPTO_ASYM_OP_RSA_VERIFY,
>>> RTE_CRYPTO_ASYM_OP_DH_KEY_GENERATE,
>>> RTE_CRYPTO_ASYM_OP_DH_SHARED_SECRET_COMPUTE,
>>> etc...
>>>
>>> Then the op type becomes very explicit and will allow session-less
>>> operations to be supported by PMDs. This shouldn't have any impact on
>>> your current implementation other than updating the op type.
>>>
>>
>> [Shally] Ok, so you suggest to merge xform and op_type (including keeping op_type in one place) for simplicity sake.
>>
>> If we take this change, then I will prefer to keep it as xforms rather than op_types, such as,
>>
>> enum rte_crypto_asym_xform_types {
>> RTE_CRYPTO_ASYM_XFORM_RSA_ENCRYPT,
>> RTE_CRYPTO_ASYM_XFORM_RSA_SIGN,
>> RTE_CRYPTO_ASYM_XFORM_DSA_SIGN,
>> RTE_CRYPTO_ASYM_XFORM_DSA_VERIFY,
>> RTE_CRYPTO_ASYM_XFORM_DH_PRIV_KEY_GENERATE,
>> RTE_CRYPTO_ASYM_XFORM_DH_PUB_KEY_GENERATE,
>> RTE_CRYPTO_ASYM_XFORM_DH_SHARED_SECRET_COMPUTE, .... and so on..
>> }
>>
>> These, when set on a rte_crypto_asym_xform , will work seamlessly for both session and session-less.
>> I also see advantage here to support xform chaining. In this case, op_type in rte_crypto_asym_xx_op_params isn't needed and will
>be removed.
>> It will add bit of repetition though, like RSA_SIGN / DSA_SIGN, but that would occur in any case, if we are merging two types.
>> Does that sound okay?
>
>I would be a bit concerned with dropping the
>rte_crypto_asym_xx_op_params as if we are following the symmetric model,
>the xform should only specify the immutable data in relation to a
>transform and the operation should provide the mutable input data. I'm
>not sure how this would look like for the different asymmetric
>operations but if there are transforms that don't have immutable data
>then it would make more sense not to have a specific xform data
>structure for that and pass the data through that transformations
>operation structure.
[Shally] Believe there's some misunderstanding here. My suggestion was not to drop asym_xx_op_params, but just an op_type field from op_params if xform types are redefined as suggested above. However, I see below you have another proposal so I will clarify more there.
As a side note, Asym works on similar principle as symmetric i.e. immutable data in xform and mutable in op_params. So, op_params definitely will be there.
>
>>
>> We were about to submit Openssl PMD with asym support today. But I would hold back till we align on this.
>> ...
>>
>
>Ok, I think I had missed part of the complexity of the chained used
>case. I think if we are to follow the symmetric crypto model we end up
>with something along the lines of a fundamental op types - dh, dsa, mod,
>rsa etc.
>
>enum rte_crypto_asym_op_types {
> RTE_CRYPTO_ASYM_OP_DH,
> RTE_CRYPTO_ASYM_OP_DSA,
> RTE_CRYPTO_ASYM_OP_MOD,
> RTE_CRYPTO_ASYM_OP_RSA,
>};
>
>with a corresponding asym_op as follows.
>
>struct rte_crypto_asym_op {
> union {
> struct rte_cryptodev_asym_session *session;
> /**< Handle for the initialized session context */
> struct rte_crypto_asym_xform *xform;
> };
>
> union {
> struct rte_crypto_asym_dh_op_data dh;
> struct rte_crypto_asym_dsa_op_data dsa;
> struct rte_crypto_asyn_mod_op_data mod;
> struct rte_crypto_asym_rsa_op_data rsa;
> } op_data;
>};
>
>
>In terms of the xform definitions I'm not sure that we should have all
>the different transforms defined in the same enum. If we take the below
>approach, all the specifics of each transform could be split out into
>separate headers, giving a cleaner API. This would see a xform types
>enum which would mirror the operation types:
>
>enum rte_crypto_asym_xform_types {
> RTE_CRYPTO_ASYM_XFORM_DH,
> RTE_CRYPTO_ASYM_XFORM_DSA,
> RTE_CRYPTO_ASYM_XFORM_MOD,
> RTE_CRYPTO_ASYM_XFORM_RSA,
>}
>
>with corresponding xforms structures
>
>struct rte_crypto_asym_xform dh;
>struct rte_crypto_asym_xform dsa;
>struct rte_crypto_asym_xform modlus;
>struct rte_crypto_asym_xform rsa;
>
>then within the xforms would define the sub-type of that xform and have
>definitions of the relevant session data which is required, with the
>rsa it might look like something like this:
>
>enum rte_crypto_asym_xform_rsa_types {
> RTE_CRYPTO_ASYM_XFORM_RSA_ENCRYPT,
> RTE_CRYPTO_ASYM_XFORM_RSA_DECRYPT,
> RTE_CRYPTO_ASYM_XFORM_RSA_SIGN,
> RTE_CRYPTO_ASYM_XFORM_RSA_VERIFY,
>}
>
>struct rte_crypto_asym_xform rsa {
> enum rte_crypto_asym_op_rsa_types type;
> union {
> struct rte_crypto_asym_xform_rsa_encrypt_data encrypt;
> struct rte_crypto_asym_xform_rsa_decrypt_data decrypt;
> etc...
> } data;
>};
>
>The need for xform sub-type data structure would be dependent on whether
>there was immutable data associated with a particular transform. Also if
>we take this approach it would allow each operation type to be separated
>out into there own headers.
>
[Shally] I'm assuming you are not suggesting any changes to existing fundamental rte_crypto_asym_op and rte_crypto_asym_xform structures here, as they're
defined the way you mentioned. Only change I see having a new xform sub-type in per-xform struct.
Since we already have an enum rte_crypto_asym_op_type {
RTE_CRYPTO_ASYM_OP_ENCRYPT,
RTE_CRYPTO_ASYM_OP_SIGN
RTE_CRYPTO_ASYM_OP_VERIFY
RTE_CRYPTO_ASYM_OP_KEY_PAIR_GENERATE and so on...
}
So, we can use existing one into asym_xx_xform structure so every rte_crypto_asym_xx_xform struct would look like:
struct rte_crypto_xxx_xform {
enum rte_crypto_asym_op_type;
/**< Sign/Verify/Encrypt/Decrypt/key generate/ */
/* other xform params such as public and private key */
}
Since every xform returns bitmask of op_types supported in capability structure. So, app would know which op types are supported on xform.
Also, I don’t see a need a new define such as OP_RSA/OP_DSA as every op come associated with session/xform with same information, so relevant xform op params will be referenced based on that.
Thanks
Shally
>>> ....
>>>
>>>
>>>> + */
>>>> +struct rte_crypto_dh_xform {
>>>> + enum rte_crypto_asym_op_type type;
>>>> + /**< Setup xform for key generate or shared secret compute */
>>>> +
>>>
>>> there is an inconsistency here in terms of were the op_type is defined,
>>> in this case it is in the xform but it other cases RSA, DSA it is
>>> defined in the operation information itself. I don't know of any reason
>>> why it is needed in the xform but I think it must be consistent across
>>> all operations/xforms. Ideally from my perspective it would be in the
>>> rte_crypto_asym_op structure, see below, as this would allow
>>> session/session-less operations to be supported seamlessly.
>>>
>>
>> [Shally] Reason was xform chaining. As per Fiona feedback, we identified requirement to break DH Key pair
>> generation in to two : PRIV_KEY_GENERATION and PUB_KEY_GENERATION, so I had to move this param around.
>> But this will be addressed once we change xform_types as per suggestion above.
>>
>> ...
>>
>>>
>>> ...
>>>
>>>> +/**
>>>> + * Asymmetric Cryptographic Operation.
>>>> + *
>>>> + * Structure describing asymmetric crypto operation params.
>>>> + *
>>>> + */
>>>> +struct rte_crypto_asym_op {
>>>> + struct rte_cryptodev_asym_session *session;
>>>> + /**< Handle for the initialised session context */
>>>> +
>>>> + __extension__
>>>> + union {
>>>> + struct rte_crypto_rsa_op_param rsa;
>>>> + struct rte_crypto_mod_op_param modex;
>>>> + struct rte_crypto_mod_op_param modinv;
>>>> + struct rte_crypto_dh_op_param dh;
>>>> + struct rte_crypto_dsa_op_param dsa;
>>>> + };
>>>> +} __rte_cache_aligned;
>>>> +
>>> Relating to my comment on position of the op_type and the minor change
>>> of having an union of session/xform in the rte_crypto_asym_op structure
>>> would then enable sessionless support to be added seamless in the future
>>> with minimal effect to the current proposal.
>>
>> [Shally] Again, this will also be resolved with change to xform_types
>>
>>>
>>> struct rte_crypto_asym_op {
>>> - struct rte_cryptodev_asym_session *session;
>>> - /**< Handle for the initialised session context */
>>> + enum rte_crypto_asym_op_type op_type;
>>> +
>>> + union {
>>> + struct rte_cryptodev_asym_session *session;
>>> + /**< Handle for the initialised session context */
>>> + struct rte_crypto_asym_xform *xform;
>>> + };
>>>
>> [Shally] Ok. Will add this change. But then I'll have to check if crypto PMD has support to reflect which type of mode it supports?
>>
>The sess_type=RTE_CRYPTO_OP_WITH_SESSION/RTE_CRYPTO_OP_SESSIONLESS
>should be set in the outer crypto_op struct, so if the PMD doesn't
>support the selected sess_type, it should just fail the enqueue and
>possibly log an error.
>
>> Thanks for review.
>> Shally
>>
>>> __extension__
>>>
>>>
>>>> +#ifdef __cplusplus
>>>> +}
>>>> +#endif
>>>> +
>>>> +#endif /* _RTE_CRYPTO_ASYM_H_ */
>>>>
>>
@@ -23,6 +23,7 @@ SYMLINK-y-include += rte_crypto.h
SYMLINK-y-include += rte_crypto_sym.h
SYMLINK-y-include += rte_cryptodev.h
SYMLINK-y-include += rte_cryptodev_pmd.h
+SYMLINK-y-include += rte_crypto_asym.h
# versioning export map
EXPORT_MAP := rte_cryptodev_version.map
@@ -6,5 +6,6 @@ sources = files('rte_cryptodev.c', 'rte_cryptodev_pmd.c')
headers = files('rte_cryptodev.h',
'rte_cryptodev_pmd.h',
'rte_crypto.h',
- 'rte_crypto_sym.h')
+ 'rte_crypto_sym.h',
+ 'rte_crypto_asym.h')
deps += ['kvargs', 'mbuf']
new file mode 100644
@@ -0,0 +1,496 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Cavium Networks
+ */
+
+#ifndef _RTE_CRYPTO_ASYM_H_
+#define _RTE_CRYPTO_ASYM_H_
+
+/**
+ * @file rte_crypto_asym.h
+ *
+ * RTE Definitions for Asymmetric Cryptography
+ *
+ * Defines asymmetric algorithms and modes, as well as supported
+ * asymmetric crypto operations.
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <string.h>
+#include <stdint.h>
+
+#include <rte_memory.h>
+#include <rte_mempool.h>
+#include <rte_common.h>
+
+typedef struct rte_crypto_param_t {
+ uint8_t *data;
+ /**< pointer to buffer holding data */
+ rte_iova_t iova;
+ /**< IO address of data buffer */
+ size_t length;
+ /**< length of data in bytes */
+} rte_crypto_param;
+
+/** asym xform type name strings */
+extern const char *
+rte_crypto_asym_xform_strings[];
+
+/** asym operations type name strings */
+extern const char *
+rte_crypto_asym_op_strings[];
+
+/**
+ * Asymmetric crypto transformation types.
+ * Each xform type maps to one asymmetric algorithm
+ * performing specific operation
+ *
+ */
+enum rte_crypto_asym_xform_type {
+ RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED = 0,
+ /**< Invalid xform. */
+ RTE_CRYPTO_ASYM_XFORM_NONE,
+ /**< Xform type None.
+ * May be supported by PMD to support
+ * passthrough op for debugging purpose.
+ * if xform_type none , op_type is disregarded.
+ */
+ RTE_CRYPTO_ASYM_XFORM_RSA,
+ /**< RSA. Performs Encrypt, Decrypt, Sign and Verify.
+ * Refer to rte_crypto_asym_op_type
+ */
+ RTE_CRYPTO_ASYM_XFORM_DH,
+ /**< Deffie-Hellman.
+ * Performs Key Generate and Shared Secret Compute.
+ * Refer to rte_crypto_asym_op_type
+ */
+ RTE_CRYPTO_ASYM_XFORM_DSA,
+ /**< Digital Signature Algorithm
+ * Performs Signature Generation and Verification.
+ * Refer to rte_crypto_asym_op_type
+ */
+ RTE_CRYPTO_ASYM_XFORM_MODINV,
+ /**< Modular Inverse
+ * Perform Modulus inverse b^(-1) mod n
+ */
+ RTE_CRYPTO_ASYM_XFORM_MODEX,
+ /**< Modular Exponentiation
+ * Perform Modular Exponentiation b^e mod n
+ */
+ RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
+ /**< End of list */
+};
+
+/**
+ * Asymmetric crypto operation type variants
+ */
+enum rte_crypto_asym_op_type {
+ RTE_CRYPTO_ASYM_OP_ENCRYPT,
+ /**< Asymmetric Encrypt operation */
+ RTE_CRYPTO_ASYM_OP_DECRYPT,
+ /**< Asymmetric Decrypt operation */
+ RTE_CRYPTO_ASYM_OP_SIGN,
+ /**< Signature Generation operation */
+ RTE_CRYPTO_ASYM_OP_VERIFY,
+ /**< Signature Verification operation */
+ RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
+ /**< DH Private Key generation operation */
+ RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
+ /**< DH Public Key generation operation */
+ RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
+ /**< DH Shared Secret compute operation */
+ RTE_CRYPTO_ASYM_OP_LIST_END
+};
+
+/**
+ * Padding types for RSA signature.
+ */
+enum rte_crypto_rsa_padding_type {
+ RTE_CRYPTO_RSA_PADDING_NONE = 0,
+ /**< RSA no padding scheme */
+ RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
+ /**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
+ * as descibed in rfc2313
+ */
+ RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
+ /**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
+ * as descibed in rfc2313
+ */
+ RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
+ /**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
+ * as descibed in rfc2313
+ */
+ RTE_CRYPTO_RSA_PADDING_OAEP,
+ /**< RSA PKCS#1 OAEP padding scheme */
+ RTE_CRYPTO_RSA_PADDING_PSS,
+ /**< RSA PKCS#1 PSS padding scheme */
+ RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
+};
+
+/**
+ * RSA private key type enumeration
+ *
+ * enumerates private key format required to perform RSA crypto
+ * transform.
+ *
+ */
+enum rte_crypto_rsa_priv_key_type {
+ RTE_RSA_KEY_TYPE_EXP,
+ /**< RSA private key is an exponent */
+ RTE_RSA_KET_TYPE_QT,
+ /**< RSA private key is in quintuple format
+ * See rte_crypto_rsa_priv_key_qt
+ */
+};
+
+/**
+ * Structure describing RSA private key in quintuple format.
+ * See PKCS V1.5 RSA Cryptography Standard.
+ */
+struct rte_crypto_rsa_priv_key_qt {
+ rte_crypto_param p;
+ /**< p - Private key component P
+ * Private key component of RSA parameter required for CRT method
+ * of private key operations in Octet-string network byte order
+ * format.
+ */
+
+ rte_crypto_param q;
+ /**< q - Private key component Q
+ * Private key component of RSA parameter required for CRT method
+ * of private key operations in Octet-string network byte order
+ * format.
+ */
+
+ rte_crypto_param dP;
+ /**< dP - Private CRT component
+ * Private CRT component of RSA parameter required for CRT method
+ * RSA private key operations in Octet-string network byte order
+ * format.
+ * dP = d mod ( p - 1 )
+ */
+
+ rte_crypto_param dQ;
+ /**< dQ - Private CRT component
+ * Private CRT component of RSA parameter required for CRT method
+ * RSA private key operations in Octet-string network byte order
+ * format.
+ * dQ = d mod ( q - 1 )
+ */
+
+ rte_crypto_param qInv;
+ /**< qInv - Private CRT component
+ * Private CRT component of RSA parameter required for CRT method
+ * RSA private key operations in Octet-string network byte order
+ * format.
+ * qInv = inv q mod p
+ */
+};
+
+/**
+ * Asymmetric RSA transform data
+ *
+ * Structure describing RSA xform params
+ *
+ */
+struct rte_crypto_rsa_xform {
+ rte_crypto_param n;
+ /**< n - Prime modulus
+ * Prime modulus data of RSA operation in Octet-string network
+ * byte order format.
+ */
+
+ rte_crypto_param e;
+ /**< e - Public key exponent
+ * Public key exponent used for RSA public key operations in Octet-
+ * string network byte order format.
+ */
+
+ enum rte_crypto_rsa_priv_key_type key_type;
+
+ __extension__
+ union {
+ rte_crypto_param d;
+ /**< d - Private key exponent
+ * Private key exponent used for RSA
+ * private key operations in
+ * Octet-string network byte order format.
+ */
+
+ struct rte_crypto_rsa_priv_key_qt qt;
+ /**< qt - Private key in quintuple format */
+ };
+};
+
+/**
+ * Asymmetric Modular exponentiation transform data
+ *
+ * Structure describing modular exponentation xform param
+ *
+ */
+struct rte_crypto_modex_xform {
+ rte_crypto_param modulus;
+ /**< modulus
+ * Prime modulus of the modexp transform operation in octet-string
+ * network byte order format.
+ */
+
+ rte_crypto_param exponent;
+ /**< exponent
+ * Private exponent of the modexp transform operation in
+ * octet-string network byte order format.
+ */
+};
+
+/**
+ * Asymmetric modular inverse transform operation
+ *
+ * Structure describing modulus inverse xform params
+ *
+ */
+struct rte_crypto_modinv_xform {
+ rte_crypto_param modulus;
+ /**<
+ * Pointer to the prime modulus data for modular
+ * inverse operation in octet-string network byte
+ * order format.
+ */
+};
+
+/**
+ * Asymmetric DH transform data
+ *
+ * Structure describing deffie-hellman xform params
+ *
+ */
+struct rte_crypto_dh_xform {
+ enum rte_crypto_asym_op_type type;
+ /**< Setup xform for key generate or shared secret compute */
+
+ rte_crypto_param p;
+ /**< p : Prime modulus data
+ * DH prime modulous data in octet-string network byte order format.
+ *
+ */
+
+ rte_crypto_param g;
+ /**< g : Generator
+ * DH group generator data in octet-string network byte order
+ * format.
+ *
+ */
+};
+
+/**
+ * Asymmetric Digital Signature transform operation
+ *
+ * Structure describing DSA xform params
+ *
+ */
+struct rte_crypto_dsa_xform {
+ rte_crypto_param p;
+ /**< p - Prime modulus
+ * Prime modulus data for DSA operation in Octet-string network byte
+ * order format.
+ */
+ rte_crypto_param q;
+ /**< q : Order of the subgroup.
+ * Order of the subgroup data in Octet-string network byte order
+ * format.
+ * (p-1) % q = 0
+ */
+ rte_crypto_param g;
+ /**< g: Generator of the subgroup
+ * Generator data in Octet-string network byte order format.
+ */
+ rte_crypto_param x;
+ /**< x: Private key of the signer in octet-string network
+ * byte order format.
+ * Used when app has pre-defined private key.
+ * Valid only when xform chain is DSA ONLY.
+ * if xform chain is DH private key generate + DSA, then DSA sign
+ * compute will use internally generated key.
+ */
+};
+
+/**
+ * Operations params for modular operations:
+ * exponentiation and invert
+ *
+ */
+struct rte_crypto_mod_op_param {
+ rte_crypto_param base;
+ /**<
+ * Pointer to base of modular exponentiation/inversion data in
+ * Octet-string network byte order format.
+ */
+};
+
+/**
+ * Asymmetric crypto transform data
+ *
+ * Structure describing asym xforms.
+ */
+struct rte_crypto_asym_xform {
+ struct rte_crypto_asym_xform *next;
+ /**< Pointer to next xform to set up xform chain.*/
+ enum rte_crypto_asym_xform_type xform_type;
+ /**< Asymmetric crypto transform */
+
+ __extension__
+ union {
+ struct rte_crypto_rsa_xform rsa;
+ /**< RSA xform parameters */
+
+ struct rte_crypto_modex_xform modex;
+ /**< Modular Exponentiation xform parameters */
+
+ struct rte_crypto_modinv_xform modinv;
+ /**< Modulus Inverse xform parameters */
+
+ struct rte_crypto_dh_xform dh;
+ /**< DH xform parameters */
+
+ struct rte_crypto_dsa_xform dsa;
+ /**< DSA xform parameters */
+ };
+};
+
+struct rte_cryptodev_asym_session;
+
+/**
+ * RSA operation params
+ *
+ */
+struct rte_crypto_rsa_op_param {
+ enum rte_crypto_asym_op_type op_type;
+ /**< Type of RSA operation for transform */;
+
+ rte_crypto_param message;
+ /**<
+ * Pointer to data
+ * - to be encrypted for RSA public encrypt.
+ * - to be decrypted for RSA private decrypt.
+ * - to be signed for RSA sign generation.
+ * - to be authenticated for RSA sign verification.
+ */
+
+ rte_crypto_param sign;
+ /**<
+ * Pointer to RSA signature data. If operation is RSA
+ * sign @ref RTE_CRYPTO_RSA_OP_SIGN, buffer will be
+ * over-written with generated signature.
+ *
+ * Length of the signature data will be equal to the
+ * RSA prime modulus length.
+ */
+
+ enum rte_crypto_rsa_padding_type pad;
+ /**< RSA padding scheme to be used for transform */
+
+ enum rte_crypto_auth_algorithm md;
+ /**< Hash algorithm to be used for data hash if padding
+ * scheme is either OAEP or PSS. Valid hash algorithms
+ * are:
+ * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
+ */
+
+ enum rte_crypto_auth_algorithm mgf1md;
+ /**<
+ * Hash algorithm to be used for mask generation if
+ * padding scheme is either OAEP or PSS. If padding
+ * scheme is unspecified data hash algorithm is used
+ * for mask generation. Valid hash algorithms are:
+ * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
+ */
+};
+
+/**
+ * Deffie-Hellman Operations params.
+ * @note:
+ */
+struct rte_crypto_dh_op_param {
+ rte_crypto_param pub_key;
+ /**<
+ * Output generated public key when xform type is
+ * DH PUB_KEY_GENERATION.
+ * Input peer public key when xform type is DH
+ * SHARED_SECRET_COMPUTATION
+ * pub_key is in octet-string network byte order format.
+ *
+ */
+
+ rte_crypto_param priv_key;
+ /**<
+ * Output generated private key if xform type is
+ * DH PRIVATE_KEY_GENERATION
+ * Input when xform type is DH SHARED_SECRET_COMPUTATION.
+ * priv_key is in octet-string network byte order format.
+ *
+ */
+
+ rte_crypto_param shared_secret;
+ /**<
+ * Output with calculated shared secret
+ * when dh xform set up with op type = SHARED_SECRET_COMPUTATION.
+ * shared_secret is an octet-string network byte order format.
+ *
+ */
+};
+
+/**
+ * DSA Operations params
+ *
+ */
+struct rte_crypto_dsa_op_param {
+ enum rte_crypto_asym_op_type op_type;
+ /**< Signature Generation or Verification */
+ rte_crypto_param message;
+ /**< input message to be signed or verified */
+ rte_crypto_param r;
+ /**< dsa sign component 'r' value
+ *
+ * output if op_type = sign generate,
+ * input if op_type = sign verify
+ */
+ rte_crypto_param s;
+ /**< dsa sign component 's' value
+ *
+ * output if op_type = sign generate,
+ * input if op_type = sign verify
+ */
+ rte_crypto_param y;
+ /**< y : Public key of the signer.
+ * Public key data of the signer in Octet-string network byte order
+ * format.
+ * y = g^x mod p
+ */
+};
+
+/**
+ * Asymmetric Cryptographic Operation.
+ *
+ * Structure describing asymmetric crypto operation params.
+ *
+ */
+struct rte_crypto_asym_op {
+ struct rte_cryptodev_asym_session *session;
+ /**< Handle for the initialised session context */
+
+ __extension__
+ union {
+ struct rte_crypto_rsa_op_param rsa;
+ struct rte_crypto_mod_op_param modex;
+ struct rte_crypto_mod_op_param modinv;
+ struct rte_crypto_dh_op_param dh;
+ struct rte_crypto_dsa_op_param dsa;
+ };
+} __rte_cache_aligned;
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_CRYPTO_ASYM_H_ */