[v6,1/6] cryptodev: add EDDSA asymmetric crypto algorithm
Checks
Commit Message
Add support for asymmetric EDDSA in cryptodev, as referenced in RFC:
https://datatracker.ietf.org/doc/html/rfc8032
Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
---
doc/guides/cryptodevs/features/default.ini | 1 +
doc/guides/prog_guide/cryptodev_lib.rst | 2 +-
lib/cryptodev/rte_crypto_asym.h | 47 ++++++++++++++++++++++
3 files changed, 49 insertions(+), 1 deletion(-)
Comments
Hi Gowrishankar,
I like the idea of adding EdDSA, but I have several comments.
> -----Original Message-----
> From: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> Sent: Friday, October 4, 2024 10:26 AM
> To: dev@dpdk.org; Akhil Goyal <gakhil@marvell.com>; Fan Zhang
> <fanzhang.oss@gmail.com>
> Cc: Anoob Joseph <anoobj@marvell.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; jerinj@marvell.com; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>; Ji, Kai <kai.ji@intel.com>; jack.bond-
> preston@foss.arm.com; Marchand, David <david.marchand@redhat.com>;
> hemant.agrawal@nxp.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>;
> Doherty, Declan <declan.doherty@intel.com>; matan@nvidia.com;
> ruifeng.wang@arm.com; Gowrishankar Muthukrishnan
> <gmuthukrishn@marvell.com>
> Subject: [PATCH v6 1/6] cryptodev: add EDDSA asymmetric crypto algorithm
>
> Add support for asymmetric EDDSA in cryptodev, as referenced in RFC:
> https://datatracker.ietf.org/doc/html/rfc8032
>
> Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> ---
> doc/guides/cryptodevs/features/default.ini | 1 +
> doc/guides/prog_guide/cryptodev_lib.rst | 2 +-
> lib/cryptodev/rte_crypto_asym.h | 47 ++++++++++++++++++++++
> 3 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index f411d4bab7..3073753911 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -130,6 +130,7 @@ ECDSA =
> ECPM =
> ECDH =
> SM2 =
> +EDDSA =
>
> ;
> ; Supported Operating systems of a default crypto driver.
> diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
> b/doc/guides/prog_guide/cryptodev_lib.rst
> index 2b513bbf82..dd636ba5ef 100644
> --- a/doc/guides/prog_guide/cryptodev_lib.rst
> +++ b/doc/guides/prog_guide/cryptodev_lib.rst
> @@ -927,7 +927,7 @@ Asymmetric Cryptography The cryptodev library
> currently provides support for the following asymmetric Crypto operations;
> RSA, Modular exponentiation and inversion, Diffie-Hellman and Elliptic Curve
> Diffie-Hellman public and/or private key generation and shared -secret compute,
> DSA Signature generation and verification.
> +secret compute, DSA and EdDSA Signature generation and verification.
>
> Session and Session Management
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 39d3da3952..fe4194c184 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -49,6 +49,10 @@ rte_crypto_asym_op_strings[];
> * and if the flag is not set, shared secret will be padded to the left with
> * zeros to the size of the underlying algorithm (default)
> */
> +#define RTE_CRYPTO_ASYM_FLAG_PUB_KEY_COMPRESSED
> RTE_BIT32(2)
> +/**<
> + * Flag to denote public key will be returned in compressed form */
>
> /**
> * List of elliptic curves. This enum aligns with @@ -65,9 +69,22 @@ enum
> rte_crypto_curve_id {
> RTE_CRYPTO_EC_GROUP_SECP256R1 = 23,
> RTE_CRYPTO_EC_GROUP_SECP384R1 = 24,
> RTE_CRYPTO_EC_GROUP_SECP521R1 = 25,
> + RTE_CRYPTO_EC_GROUP_ED25519 = 29,
> + RTE_CRYPTO_EC_GROUP_ED448 = 30,
> RTE_CRYPTO_EC_GROUP_SM2 = 41,
> };
>
> +/**
> + * List of Edwards curve instances as per RFC 8032 (Section 5).
> + */
> +enum rte_crypto_edward_instance {
> + RTE_CRYPTO_EDCURVE_25519,
> + RTE_CRYPTO_EDCURVE_25519CTX,
> + RTE_CRYPTO_EDCURVE_25519PH,
> + RTE_CRYPTO_EDCURVE_448,
> + RTE_CRYPTO_EDCURVE_448PH
> +};
> +
> /**
> * Asymmetric crypto transformation types.
> * Each xform type maps to one asymmetric algorithm @@ -119,6 +136,10 @@
> enum rte_crypto_asym_xform_type {
> * Performs Encrypt, Decrypt, Sign and Verify.
> * Refer to rte_crypto_asym_op_type.
> */
> + RTE_CRYPTO_ASYM_XFORM_EDDSA,
> + /**< Edwards Curve Digital Signature Algorithm
> + * Perform Signature Generation and Verification.
> + */
> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> /**< End of list */
> };
> @@ -585,6 +606,31 @@ struct rte_crypto_ecdsa_op_param {
> */
> };
>
> +/**
> + * EdDSA operation params
> + */
> +struct rte_crypto_eddsa_op_param {
> + enum rte_crypto_asym_op_type op_type;
> + /**< Signature generation or verification */
> +
> + rte_crypto_param message;
> + /**< Input message digest to be signed or verified */
HashEdDSA will require a message digest; pure EdDSA will require the message itself. For HW it will be more complicated.
> +
> + rte_crypto_param context;
> + /**< Context value for the sign op.
> + * Must not be empty for Ed25519ctx instance.
> + */
> +
> + enum rte_crypto_edward_instance instance;
> + /**< Type of Edwards curve. */
All instances are using the same curve, where they differ is the way of handling input message.
And I think this should be a session variable -> new xform for the EdDSA.
> +
> + rte_crypto_uint sign;
> + /**< Edward curve signature
> + * output : for signature generation
> + * input : for signature verification
> + */
> +};
> +
> /**
> * Structure for EC point multiplication operation param
> */
> @@ -720,6 +766,7 @@ struct rte_crypto_asym_op {
> struct rte_crypto_ecdsa_op_param ecdsa;
> struct rte_crypto_ecpm_op_param ecpm;
> struct rte_crypto_sm2_op_param sm2;
> + struct rte_crypto_eddsa_op_param eddsa;
> };
> uint16_t flags;
> /**<
> --
> 2.21.0
Acked-by: Arkadiusz Kusztal <arkadiuszx.kusztal@intel.com>
> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Monday, October 7, 2024 6:04 PM
> To: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>;
> dev@dpdk.org; Akhil Goyal <gakhil@marvell.com>; Fan Zhang
> <fanzhang.oss@gmail.com>
> Cc: Anoob Joseph <anoobj@marvell.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; jerinj@marvell.com; Ji, Kai <kai.ji@intel.com>;
> jack.bond-preston@foss.arm.com; Marchand, David
> <david.marchand@redhat.com>; hemant.agrawal@nxp.com; De Lara Guarch,
> Pablo <pablo.de.lara.guarch@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>;
> matan@nvidia.com; ruifeng.wang@arm.com
> Subject: RE: [PATCH v6 1/6] cryptodev: add EDDSA asymmetric crypto algorithm
>
> Hi Gowrishankar,
>
> I like the idea of adding EdDSA, but I have several comments.
>
> > -----Original Message-----
> > From: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> > Sent: Friday, October 4, 2024 10:26 AM
> > To: dev@dpdk.org; Akhil Goyal <gakhil@marvell.com>; Fan Zhang
> > <fanzhang.oss@gmail.com>
> > Cc: Anoob Joseph <anoobj@marvell.com>; Richardson, Bruce
> > <bruce.richardson@intel.com>; jerinj@marvell.com; Kusztal, ArkadiuszX
> > <arkadiuszx.kusztal@intel.com>; Ji, Kai <kai.ji@intel.com>; jack.bond-
> > preston@foss.arm.com; Marchand, David <david.marchand@redhat.com>;
> > hemant.agrawal@nxp.com; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona
> > <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>;
> > matan@nvidia.com; ruifeng.wang@arm.com; Gowrishankar Muthukrishnan
> > <gmuthukrishn@marvell.com>
> > Subject: [PATCH v6 1/6] cryptodev: add EDDSA asymmetric crypto
> > algorithm
> >
> > Add support for asymmetric EDDSA in cryptodev, as referenced in RFC:
> > https://datatracker.ietf.org/doc/html/rfc8032
> >
> > Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> > ---
> > doc/guides/cryptodevs/features/default.ini | 1 +
> > doc/guides/prog_guide/cryptodev_lib.rst | 2 +-
> > lib/cryptodev/rte_crypto_asym.h | 47 ++++++++++++++++++++++
> > 3 files changed, 49 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/cryptodevs/features/default.ini
> > b/doc/guides/cryptodevs/features/default.ini
> > index f411d4bab7..3073753911 100644
> > --- a/doc/guides/cryptodevs/features/default.ini
> > +++ b/doc/guides/cryptodevs/features/default.ini
> > @@ -130,6 +130,7 @@ ECDSA =
> > ECPM =
> > ECDH =
> > SM2 =
> > +EDDSA =
> >
> > ;
> > ; Supported Operating systems of a default crypto driver.
> > diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
> > b/doc/guides/prog_guide/cryptodev_lib.rst
> > index 2b513bbf82..dd636ba5ef 100644
> > --- a/doc/guides/prog_guide/cryptodev_lib.rst
> > +++ b/doc/guides/prog_guide/cryptodev_lib.rst
> > @@ -927,7 +927,7 @@ Asymmetric Cryptography The cryptodev library
> > currently provides support for the following asymmetric Crypto
> > operations; RSA, Modular exponentiation and inversion, Diffie-Hellman
> > and Elliptic Curve Diffie-Hellman public and/or private key
> > generation and shared -secret compute, DSA Signature generation and
> verification.
> > +secret compute, DSA and EdDSA Signature generation and verification.
> >
> > Session and Session Management
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index 39d3da3952..fe4194c184 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -49,6 +49,10 @@ rte_crypto_asym_op_strings[];
> > * and if the flag is not set, shared secret will be padded to the left with
> > * zeros to the size of the underlying algorithm (default)
> > */
> > +#define RTE_CRYPTO_ASYM_FLAG_PUB_KEY_COMPRESSED
> > RTE_BIT32(2)
> > +/**<
> > + * Flag to denote public key will be returned in compressed form */
> >
> > /**
> > * List of elliptic curves. This enum aligns with @@ -65,9 +69,22 @@
> > enum rte_crypto_curve_id {
> > RTE_CRYPTO_EC_GROUP_SECP256R1 = 23,
> > RTE_CRYPTO_EC_GROUP_SECP384R1 = 24,
> > RTE_CRYPTO_EC_GROUP_SECP521R1 = 25,
> > + RTE_CRYPTO_EC_GROUP_ED25519 = 29,
> > + RTE_CRYPTO_EC_GROUP_ED448 = 30,
> > RTE_CRYPTO_EC_GROUP_SM2 = 41,
> > };
> >
> > +/**
> > + * List of Edwards curve instances as per RFC 8032 (Section 5).
> > + */
> > +enum rte_crypto_edward_instance {
> > + RTE_CRYPTO_EDCURVE_25519,
> > + RTE_CRYPTO_EDCURVE_25519CTX,
> > + RTE_CRYPTO_EDCURVE_25519PH,
> > + RTE_CRYPTO_EDCURVE_448,
> > + RTE_CRYPTO_EDCURVE_448PH
> > +};
> > +
> > /**
> > * Asymmetric crypto transformation types.
> > * Each xform type maps to one asymmetric algorithm @@ -119,6 +136,10
> > @@ enum rte_crypto_asym_xform_type {
> > * Performs Encrypt, Decrypt, Sign and Verify.
> > * Refer to rte_crypto_asym_op_type.
> > */
> > + RTE_CRYPTO_ASYM_XFORM_EDDSA,
> > + /**< Edwards Curve Digital Signature Algorithm
> > + * Perform Signature Generation and Verification.
> > + */
> > RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > /**< End of list */
> > };
> > @@ -585,6 +606,31 @@ struct rte_crypto_ecdsa_op_param {
> > */
> > };
> >
> > +/**
> > + * EdDSA operation params
> > + */
> > +struct rte_crypto_eddsa_op_param {
> > + enum rte_crypto_asym_op_type op_type;
> > + /**< Signature generation or verification */
> > +
> > + rte_crypto_param message;
> > + /**< Input message digest to be signed or verified */
> HashEdDSA will require a message digest; pure EdDSA will require the message
> itself. For HW it will be more complicated.
> > +
> > + rte_crypto_param context;
> > + /**< Context value for the sign op.
> > + * Must not be empty for Ed25519ctx instance.
> > + */
> > +
> > + enum rte_crypto_edward_instance instance;
> > + /**< Type of Edwards curve. */
> All instances are using the same curve, where they differ is the way of handling
> input message.
> And I think this should be a session variable -> new xform for the EdDSA.
> > +
> > + rte_crypto_uint sign;
> > + /**< Edward curve signature
> > + * output : for signature generation
> > + * input : for signature verification
> > + */
> > +};
> > +
> > /**
> > * Structure for EC point multiplication operation param
> > */
> > @@ -720,6 +766,7 @@ struct rte_crypto_asym_op {
> > struct rte_crypto_ecdsa_op_param ecdsa;
> > struct rte_crypto_ecpm_op_param ecpm;
> > struct rte_crypto_sm2_op_param sm2;
> > + struct rte_crypto_eddsa_op_param eddsa;
> > };
> > uint16_t flags;
> > /**<
> > --
> > 2.21.0
> Acked-by: Arkadiusz Kusztal <arkadiuszx. kusztal@ intel. com
Thanks Arkadiusz.
> > Hi Gowrishankar,
> >
> > I like the idea of adding EdDSA, but I have several comments.
> >
<cut>
> > > +/**
> > > + * EdDSA operation params
> > > + */
> > > +struct rte_crypto_eddsa_op_param {
> > > + enum rte_crypto_asym_op_type op_type;
> > > + /**< Signature generation or verification */
> > > +
> > > + rte_crypto_param message;
> > > + /**< Input message digest to be signed or verified */
> > HashEdDSA will require a message digest; pure EdDSA will require the
> > message itself. For HW it will be more complicated.
Do you mean some hardware may not have HashEdDSA support ?
If so, I think it can be addressed as an operation capability in EdDSA xform itself as proposed in another patch:
https://patches.dpdk.org/project/dpdk/patch/20241004181255.916-1-gmuthukrishn@marvell.com/
> > > +
> > > + rte_crypto_param context;
> > > + /**< Context value for the sign op.
> > > + * Must not be empty for Ed25519ctx instance.
> > > + */
> > > +
> > > + enum rte_crypto_edward_instance instance;
> > > + /**< Type of Edwards curve. */
> > All instances are using the same curve, where they differ is the way
> > of handling input message.
> > And I think this should be a session variable -> new xform for the EdDSA.
Based on prehash and context string, these instances are listed in RFC.
A context string per operation helps ensure each signature is uniquely tied to its specific context, thereby preventing reuse of signatures across different contexts or operations.
Prehashing adds additional security by ensuring new prehash is computed from the message.
Therefor it is more appropriate to treat both of these as operational variables.
Thanks,
Gowrishankar
> > > +
> > > + rte_crypto_uint sign;
> > > + /**< Edward curve signature
> > > + * output : for signature generation
> > > + * input : for signature verification
> > > + */
> > > +};
> > > +
> > > /**
> > > * Structure for EC point multiplication operation param
> > > */
> > > @@ -720,6 +766,7 @@ struct rte_crypto_asym_op {
> > > struct rte_crypto_ecdsa_op_param ecdsa;
> > > struct rte_crypto_ecpm_op_param ecpm;
> > > struct rte_crypto_sm2_op_param sm2;
> > > + struct rte_crypto_eddsa_op_param eddsa;
> > > };
> > > uint16_t flags;
> > > /**<
> > > --
> > > 2.21.0
> -----Original Message-----
> From: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> Sent: Tuesday, October 8, 2024 11:32 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org; Akhil
> Goyal <gakhil@marvell.com>; Fan Zhang <fanzhang.oss@gmail.com>
> Cc: Anoob Joseph <anoobj@marvell.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Jerin Jacob <jerinj@marvell.com>; Ji, Kai
> <kai.ji@intel.com>; jack.bond-preston@foss.arm.com; Marchand, David
> <david.marchand@redhat.com>; hemant.agrawal@nxp.com; De Lara Guarch,
> Pablo <pablo.de.lara.guarch@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>;
> matan@nvidia.com; ruifeng.wang@arm.com
> Subject: RE: [PATCH v6 1/6] cryptodev: add EDDSA asymmetric crypto algorithm
>
> > Acked-by: Arkadiusz Kusztal <arkadiuszx. kusztal@ intel. com
>
> Thanks Arkadiusz.
>
> > > Hi Gowrishankar,
> > >
> > > I like the idea of adding EdDSA, but I have several comments.
> > >
> <cut>
> > > > +/**
> > > > + * EdDSA operation params
> > > > + */
> > > > +struct rte_crypto_eddsa_op_param {
> > > > + enum rte_crypto_asym_op_type op_type;
> > > > + /**< Signature generation or verification */
> > > > +
> > > > + rte_crypto_param message;
> > > > + /**< Input message digest to be signed or verified */
> > > HashEdDSA will require a message digest; pure EdDSA will require the
> > > message itself. For HW it will be more complicated.
>
> Do you mean some hardware may not have HashEdDSA support ?
Not in full. For example: ECDSA in QAT and Octeon accepts a digest, not a message. So it does not support the full process, but EdDSA is more complicated than that because of the two hash rounds, similar to the SM2.
For now we have only OpenSSL PMD that supports it, and it accepts a message not a digest, so this should be changed to "message to be signed".
> If so, I think it can be addressed as an operation capability in EdDSA xform itself
> as proposed in another patch:
> https://patches.dpdk.org/project/dpdk/patch/20241004181255.916-1-
> gmuthukrishn@marvell.com/
I have not yet reviewed this patch, but it looks that possibly yes.
>
> > > > +
> > > > + rte_crypto_param context;
> > > > + /**< Context value for the sign op.
> > > > + * Must not be empty for Ed25519ctx instance.
> > > > + */
> > > > +
> > > > + enum rte_crypto_edward_instance instance;
> > > > + /**< Type of Edwards curve. */
> > > All instances are using the same curve, where they differ is the way
> > > of handling input message.
> > > And I think this should be a session variable -> new xform for the EdDSA.
>
> Based on prehash and context string, these instances are listed in RFC.
> A context string per operation helps ensure each signature is uniquely tied to its
> specific context, thereby preventing reuse of signatures across different
> contexts or operations.
> Prehashing adds additional security by ensuring new prehash is computed from
> the message.
> Therefor it is more appropriate to treat both of these as operational variables.
Different 'instance' are basically different algorithms.
About the 'context' I am not sure, as not any major protocol specifies its usage (TLS and IKEv2 forbids PH though),
But from RFC8032, it looks like it was defined to be used per protocol basis, or some subprotocol routine. But about this I am not sure.
Yet, EdDSA should not be delayed really; it is basically a network standard for quite a time.
These changes may be discussed later.
>
> Thanks,
> Gowrishankar
> > > > +
> > > > + rte_crypto_uint sign;
> > > > + /**< Edward curve signature
> > > > + * output : for signature generation
> > > > + * input : for signature verification
> > > > + */
> > > > +};
> > > > +
> > > > /**
> > > > * Structure for EC point multiplication operation param
> > > > */
> > > > @@ -720,6 +766,7 @@ struct rte_crypto_asym_op {
> > > > struct rte_crypto_ecdsa_op_param ecdsa;
> > > > struct rte_crypto_ecpm_op_param ecpm;
> > > > struct rte_crypto_sm2_op_param sm2;
> > > > + struct rte_crypto_eddsa_op_param eddsa;
> > > > };
> > > > uint16_t flags;
> > > > /**<
> > > > --
> > > > 2.21.0
> > > > > +/**
> > > > > + * EdDSA operation params
> > > > > + */
> > > > > +struct rte_crypto_eddsa_op_param {
> > > > > + enum rte_crypto_asym_op_type op_type;
> > > > > + /**< Signature generation or verification */
> > > > > +
> > > > > + rte_crypto_param message;
> > > > > + /**< Input message digest to be signed or verified */
> > > > HashEdDSA will require a message digest; pure EdDSA will require
> > > > the message itself. For HW it will be more complicated.
> >
> > Do you mean some hardware may not have HashEdDSA support ?
> Not in full. For example: ECDSA in QAT and Octeon accepts a digest, not a
> message. So it does not support the full process, but EdDSA is more
> complicated than that because of the two hash rounds, similar to the SM2.
>
> For now we have only OpenSSL PMD that supports it, and it accepts a
> message not a digest, so this should be changed to "message to be signed".
>
Ack.
<cut>
> > > > All instances are using the same curve, where they differ is the
> > > > way of handling input message.
> > > > And I think this should be a session variable -> new xform for the EdDSA.
> >
> > Based on prehash and context string, these instances are listed in RFC.
> > A context string per operation helps ensure each signature is uniquely
> > tied to its specific context, thereby preventing reuse of signatures
> > across different contexts or operations.
> > Prehashing adds additional security by ensuring new prehash is
> > computed from the message.
> > Therefor it is more appropriate to treat both of these as operational
> variables.
>
> Different 'instance' are basically different algorithms.
>
> About the 'context' I am not sure, as not any major protocol specifies its usage
> (TLS and IKEv2 forbids PH though), But from RFC8032, it looks like it was
> defined to be used per protocol basis, or some subprotocol routine. But about
> this I am not sure.
>
> Yet, EdDSA should not be delayed really; it is basically a network standard for
> quite a time.
> These changes may be discussed later.
>
Sure Arkadiusz.
Regards,
Gowrishankar
> > Subject: RE: [PATCH v6 1/6] cryptodev: add EDDSA asymmetric crypto algorithm
> >
> > > Acked-by: Arkadiusz Kusztal <arkadiuszx. kusztal@ intel. com
Series Acked-by: Akhil Goyal <gakhil@marvell.com>
Series Applied to dpdk-next-crypto
Thanks.
Updated release notes and removed deprecation notices for EDDSA.
@@ -130,6 +130,7 @@ ECDSA =
ECPM =
ECDH =
SM2 =
+EDDSA =
;
; Supported Operating systems of a default crypto driver.
@@ -927,7 +927,7 @@ Asymmetric Cryptography
The cryptodev library currently provides support for the following asymmetric
Crypto operations; RSA, Modular exponentiation and inversion, Diffie-Hellman and
Elliptic Curve Diffie-Hellman public and/or private key generation and shared
-secret compute, DSA Signature generation and verification.
+secret compute, DSA and EdDSA Signature generation and verification.
Session and Session Management
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -49,6 +49,10 @@ rte_crypto_asym_op_strings[];
* and if the flag is not set, shared secret will be padded to the left with
* zeros to the size of the underlying algorithm (default)
*/
+#define RTE_CRYPTO_ASYM_FLAG_PUB_KEY_COMPRESSED RTE_BIT32(2)
+/**<
+ * Flag to denote public key will be returned in compressed form
+ */
/**
* List of elliptic curves. This enum aligns with
@@ -65,9 +69,22 @@ enum rte_crypto_curve_id {
RTE_CRYPTO_EC_GROUP_SECP256R1 = 23,
RTE_CRYPTO_EC_GROUP_SECP384R1 = 24,
RTE_CRYPTO_EC_GROUP_SECP521R1 = 25,
+ RTE_CRYPTO_EC_GROUP_ED25519 = 29,
+ RTE_CRYPTO_EC_GROUP_ED448 = 30,
RTE_CRYPTO_EC_GROUP_SM2 = 41,
};
+/**
+ * List of Edwards curve instances as per RFC 8032 (Section 5).
+ */
+enum rte_crypto_edward_instance {
+ RTE_CRYPTO_EDCURVE_25519,
+ RTE_CRYPTO_EDCURVE_25519CTX,
+ RTE_CRYPTO_EDCURVE_25519PH,
+ RTE_CRYPTO_EDCURVE_448,
+ RTE_CRYPTO_EDCURVE_448PH
+};
+
/**
* Asymmetric crypto transformation types.
* Each xform type maps to one asymmetric algorithm
@@ -119,6 +136,10 @@ enum rte_crypto_asym_xform_type {
* Performs Encrypt, Decrypt, Sign and Verify.
* Refer to rte_crypto_asym_op_type.
*/
+ RTE_CRYPTO_ASYM_XFORM_EDDSA,
+ /**< Edwards Curve Digital Signature Algorithm
+ * Perform Signature Generation and Verification.
+ */
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
/**< End of list */
};
@@ -585,6 +606,31 @@ struct rte_crypto_ecdsa_op_param {
*/
};
+/**
+ * EdDSA operation params
+ */
+struct rte_crypto_eddsa_op_param {
+ enum rte_crypto_asym_op_type op_type;
+ /**< Signature generation or verification */
+
+ rte_crypto_param message;
+ /**< Input message digest to be signed or verified */
+
+ rte_crypto_param context;
+ /**< Context value for the sign op.
+ * Must not be empty for Ed25519ctx instance.
+ */
+
+ enum rte_crypto_edward_instance instance;
+ /**< Type of Edwards curve. */
+
+ rte_crypto_uint sign;
+ /**< Edward curve signature
+ * output : for signature generation
+ * input : for signature verification
+ */
+};
+
/**
* Structure for EC point multiplication operation param
*/
@@ -720,6 +766,7 @@ struct rte_crypto_asym_op {
struct rte_crypto_ecdsa_op_param ecdsa;
struct rte_crypto_ecpm_op_param ecpm;
struct rte_crypto_sm2_op_param sm2;
+ struct rte_crypto_eddsa_op_param eddsa;
};
uint16_t flags;
/**<