We should also take into account Barry's earlier RFC for adding public key support. See http://patches.opendataplane.org/patch/4985/ as this is closely related to this RFC.
On Thu, Apr 6, 2017 at 7:31 AM, Kartha, Umesh <umesh.kar...@cavium.com> wrote: > Thanks for comments, please go through my replies. > > Regards, > Umesh > > From: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org> > Sent: Thursday, April 6, 2017 4:11 PM > To: Kartha, Umesh; lng-odp@lists.linaro.org > Cc: Manoharan, Balasubramanian; Murthy, Nidadavolu; Manapragada, Ram Kumar > Subject: Re: [lng-odp] [RFC][PATCH] added asymmetric crypto algorithm support. > > On 05.04.2017 13:02, Umesh Kartha wrote: >> Asymmetric crypto algorithms are essential in protocols such as SSL/TLS. >> As the current ODP crypto library lacks support for asymmetric crypto >> algorithms, this RFC is an attempt to address it and add support for the >> same. > > If you target TLS, you should probably also include FFDH support as a > first grade citizen. Is this API sufficient and efficient to produce > working TLS server? > [Umesh]>> Assuming FFDH is finite field Diffie Hellman, we were planning to > achieve the > DH operation through modexp operation. > > Did you consider having separate interfaces for symmetric and for public > key crypto? > [Umesh]>> We had an internal discussion about having a separate interface for > public key > crypto, the comment we received was if we were to implement new interfaces for > public key, we would also require a totally different session for asymmetric > algorithms. > This means we will need to create additional session and operation struct > then we need to > add similar functions for odp_crypto_session_create() and > odp_crypto_operation(). > >> The asymmetric algorithms featured in this version are >> >> 1 RSA >> - RSA Sign >> - RSA Verify >> - RSA Public Encrypt >> - RSA Private Decrypt >> >> Padding schemes supported for RSA operations are >> * RSA PKCS#1 BT1 >> * RSA PKCS#1 BT2 >> * RSA PKCS#1 OAEP >> * RSA PKCS#1 PSS >> >> 2 ECDSA >> - ECDSA Sign >> - ECDSA Verify >> >> Curves supported for ECDSA operations are >> * Prime192v1 >> * Secp224k1 >> * Prime256v1 >> * Secp384r1 >> * Secp521r1 > > What about EdDSA? > [Umesh]>> This is an intial draft and not the final list of EC curves. This > will be added > future draft. > >> >> 3 MODEXP >> >> 4 FUNDAMENTAL ECC >> - Point Addition >> - Point Multiplication >> - Point Doubling >> >> Curves supported for fundamental ECC operations are same as that of >> ECDSA operations. >> >> >> >> Signed-off-by: Umesh Kartha <umesh.kar...@caviumnetworks.com> >> --- >> include/odp/api/spec/crypto.h | 570 >> +++++++++++++++++++++++++++++++++++++++++- >> 1 file changed, 569 insertions(+), 1 deletion(-) >> >> diff --git include/odp/api/spec/crypto.h include/odp/api/spec/crypto.h >> index d30f050..4cd5a3d 100644 >> --- include/odp/api/spec/crypto.h >> +++ include/odp/api/spec/crypto.h >> @@ -57,6 +57,14 @@ typedef enum { >> ODP_CRYPTO_OP_ENCODE, >> /** Decrypt and/or verify authentication ICV */ >> ODP_CRYPTO_OP_DECODE, >> + /** Perform asymmetric crypto RSA operation */ >> + ODP_CRYPTO_OP_RSA, >> + /** Perform asymmetric crypto modex operation */ >> + ODP_CRYPTO_OP_MODEX, >> + /** Perform asymmetric crypto ECDSA operation */ >> + ODP_CRYPTO_OP_ECDSA, >> + /** Perform asymmetric crypto ECC point operation */ >> + ODP_CRYPTO_OP_FECC, > > This looks like a bad abstraction for me. RSA and ECDSA also follow the > encode/decode and sign/verify scheme, so my first impression would be > that they should also fall into OP_ENCODE/OP_DECODE, exact operation > being selected by other parameters. > > Also I ain't sure why do you exactly need modexp and ecc point operation. > [Umesh]>> encode/decode modes are meant for symmetric operations. The > encodeing and > decoding required for RSA/ECDSA SIGN/VERIFY operations are handled internally > based > odp_crypto_rsa_op_t and odp_crypto_ecdsa_op_t respectively. > >> } odp_crypto_op_t; >> >> /** >> @@ -213,6 +221,202 @@ typedef union odp_crypto_auth_algos_t { >> } odp_crypto_auth_algos_t; >> >> /** >> + * Asymmetric crypto algorithms >> + */ >> +typedef enum { >> + /** RSA asymmetric key algorithm */ >> + ODP_ASYM_ALG_RSA, >> + >> + /** Modular exponentiation algorithm */ >> + ODP_ASYM_ALG_MODEXP, >> + >> + /** ECDSA authentication algorithm */ >> + ODP_ASYM_ALG_ECDSA, >> + >> + /** Fundamental ECC algorithm */ >> + ODP_ASYM_ALG_FECC > > What is Fundamental? > [Umesh]>> Basic EC curve operations used as part of ECDH and ECDSA, > that addition, doubling, point multiplication. > >> +} odp_asym_alg_t; >> + >> +/** >> + * Asymmetric algorithms in a bit field structure >> + */ >> +typedef union odp_crypto_asym_algos_t { >> + /** Asymmetric algorithms */ >> + struct { >> + /** ODP_ASYM_ALG_RSA_PKCS */ >> + uint16_t alg_rsa_pkcs :1; >> + >> + /** ODP_ASYM_ALG_MODEXP */ >> + uint16_t alg_modexp :1; >> + >> + /** ODP_ASYM_ALG_ECDSA */ >> + uint16_t alg_ecdsa :1; >> + >> + /** ODP_ASYM_FECC */ >> + uint16_t alg_fecc :1; >> + } bit; >> + /** All bits of the bit field structure >> + * >> + * This field can be used to set/clear all flags, or bitwise >> + * operations over the entire structure. >> + */ >> + uint16_t all_bits; >> +} odp_crypto_asym_algos_t; >> + >> +/** >> + * Asymmetric Crypto RSA PKCS operation type >> + */ >> +typedef enum { >> + /** Encrypt with PKCS RSA public key */ >> + ODP_CRYPTO_RSA_OP_PUBLIC_ENCRYPT, >> + >> + /** Decrypt with PKCS RSA private key */ >> + ODP_CRYPTO_RSA_OP_PRIVATE_DECRYPT, >> + >> + /** Sign with RSA private key*/ >> + ODP_CRYPTO_RSA_OP_SIGN, >> + >> + /** Verify with RSA public key */ >> + ODP_CRYPTO_RSA_OP_VERIFY, >> + >> +} odp_crypto_rsa_op_t; >> + >> +/** >> + * Asymmetric Crypto RSA PKCS padding type >> + */ >> +typedef enum { >> + /** RSA padding type none */ >> + ODP_CRYPTO_RSA_PADDING_NONE, >> + >> + /** RSA padding type PKCS#1 BT1*/ >> + ODP_CRYPTO_RSA_PADDING_BT1, >> + >> + /** RSA padding type PKCS#1 BT2*/ >> + ODP_CRYPTO_RSA_PADDING_BT2, >> + >> + /** RSA padding type PKCS#1OAEP */ >> + ODP_CRYPTO_RSA_PADDING_OAEP, >> + >> + /** RSA padding type PKCS#1 PSS */ >> + ODP_CRYPTO_RSA_PADDING_PSS, >> + >> +} odp_crypto_rsa_padding_t; >> + >> +/** >> + * RSA padding types in a bitfield structure. >> + */ >> +typedef union odp_crypto_rsa_pad_bits_t { >> + /** RSA padding type */ >> + struct { >> + /** ODP_CRYPTO_RSA_PADDING_NONE */ >> + uint16_t rsa_pad_none :1; >> + >> + /** ODP_CRYPTO_RSA_PADDING_BT1*/ >> + uint16_t rsa_pad_bt1 :1; >> + >> + /** ODP_CRYPTO_RSA_PADDING_BT2*/ >> + uint16_t rsa_pad_bt2 :1; >> + >> + /** ODP_CRYPTO_RSA_PADDING_OAEP*/ >> + uint16_t rsa_pad_oaep :1; >> + >> + /** ODP_CRYPTO_RSA_PADDING_PSS */ >> + uint16_t rsa_pad_pss :1; >> + } bit; >> + /** All bits of the bit field structure >> + * >> + * This field can be used to set/clear all flags, or bitwise >> + * operations over the entire structure. >> + */ >> + uint16_t all_bits; >> +} odp_crypto_rsa_pad_bits_t; >> + >> +typedef enum { >> + /** MODEX operation not specified */ >> + ODP_CRYPTO_MODEX_OP_NULL, >> + >> + /** MODEX operation modular exponentation */ >> + ODP_CRYPTO_MODEX_OP_MODEX, >> + >> +} odp_crypto_modex_op_t; >> + >> +/** >> + * Asymmetric Crypto ECDSA operation type >> + */ >> +typedef enum { >> + /** Compute ECDSA signature with ECDSA private key */ >> + ODP_CRYPTO_ECDSA_OP_SIGN, >> + >> + /** Verify ECDSA signature with ECDSA public key */ >> + ODP_CRYPTO_ECDSA_OP_VERIFY, >> + >> +} odp_crypto_ecdsa_op_t; > > What about ECDH/ECDHE? > [Umesh]>> For ECDH/ECDHE, the plan was to use point > multiplication. What is your opinion on having a separate operation > for FFDH and ECDH? Do you think this is required? > >> + >> +/** >> + * Asymmetric Crypto FECC operation type >> + */ >> +typedef enum { >> + /** Perform ECC point addition operation */ >> + ODP_CRYPTO_FECC_OP_P_ADD, >> + >> + /** Perform ECC point doubling operation */ >> + ODP_CRYPTO_FECC_OP_P_DBL, >> + >> + /** Perform ECC point multiplication */ >> + ODP_CRYPTO_FECC_OP_P_MUL, >> + >> +} odp_crypto_fecc_op_t; > > Is there any reason to intermix low level and high level abstractions in > the same layer? In the end, we do not have `XOR' and `BIT SHIFT' > operations in crypto layer. > [Umesh]>> There are custom hws which can accelerate these EC operations. > OpenSSL exposes these APIs to application layer. On adding ECDH, we might > not require. Your comments ? > > >> + >> +/** >> + * Asymmetric Crypto ECC curves with h/w acceleration >> + */ >> +typedef enum { >> + /** NIST/X9.62/SECG curve over a 192 bit prime field */ >> + ODP_CRYPTO_CURVE_P192, >> + >> + /** NIST/SECG curve over a 224 bit prime field */ >> + ODP_CRYPTO_CURVE_P224, >> + >> + /** X9.62/SECG curve over a 256 bit prime field */ >> + ODP_CRYPTO_CURVE_P256, >> + >> + /** NIST/SECG curve over a 384 bit prime field */ >> + ODP_CRYPTO_CURVE_P384, >> + >> + /** NIST/SECG curve over a 521 bit prime field */ >> + ODP_CRYPTO_CURVE_P521, > > Curve25519? > [Umesh]>> Will be added in the future. >> +} odp_crypto_ecc_curves_t; >> + >> +/** >> + * ECC curves in a bitfield structure. >> + */ >> +typedef union odp_crypto_ecc_bits_t { >> + /** ECC curves */ >> + struct { >> + /** ODP_CRYPTO_CURVE_P192*/ >> + uint32_t ecc_curve_p192 :1; >> + >> + /** ODP_CRYPTO_CURVE_P224*/ >> + uint32_t ecc_curve_p224 :1; >> + >> + /** ODP_CRYPTO_CURVE_P256*/ >> + uint32_t ecc_curve_p256 :1; >> + >> + /** ODP_CRYPTO_CURVE_P384*/ >> + uint32_t ecc_curve_p384 :1; >> + >> + /** ODP_CRYPTO_CURVE_P521*/ >> + uint32_t ecc_curve_p521 :1; >> + } bit; >> + /** All bits of the bit field structure >> + * >> + * This field can be used to set/clear all flags, or bitwise >> + * operations over the entire structure. >> + */ >> + uint32_t all_bits; >> +} odp_crypto_ecc_bits_t; >> + >> +/** >> * Crypto API key structure >> */ >> typedef struct odp_crypto_key { >> @@ -236,6 +440,118 @@ typedef struct odp_crypto_iv { >> >> } odp_crypto_iv_t; >> >> +typedef struct odp_crypto_asym_key { >> + union { > > Any plans to differentiate private and public keys? > [Umesh]>>Not as of now. > >> + struct { >> + /**< PKCS RSA operation parameters*/ >> + >> + /** RSA prime modulus (n) */ >> + odp_crypto_key_t n; >> + >> + /** RSA public key component (e) */ >> + odp_crypto_key_t e; >> + >> + /** RSA private key component (d)*/ >> + odp_crypto_key_t d; >> + >> + /** RSA private key CRT component (p)*/ >> + odp_crypto_key_t p; >> + >> + /** RSA private key CRT component (q)*/ >> + odp_crypto_key_t q; >> + >> + /** RSA private key CRT component (dmp1 = d%(p-1))*/ >> + odp_crypto_key_t dmp1; >> + >> + /** RSA private key CRT component (dmq1 = d%(q-1))*/ >> + odp_crypto_key_t dmq1; >> + >> + /** RSA private key CRT component >> + * (iqmp = q^(-1 mod p)) >> + */ >> + odp_crypto_key_t iqmp; >> + >> + /** RSA modulus length */ >> + int rsa_modlen; >> + >> + } rsa; >> + struct { >> + /**< Modular Exponentation parameters */ >> + >> + /** ModEx prime modulus (n) */ >> + odp_crypto_key_t n; >> + >> + /** ModEx exponent component (e) */ >> + odp_crypto_key_t e; >> + >> + /** Exponent CRT component (p)*/ >> + odp_crypto_key_t p; >> + >> + /** Exponent CRT component (q)*/ >> + odp_crypto_key_t q; >> + >> + /** Exponent CRT component (Ep = e%(p-1))*/ >> + odp_crypto_key_t Ep; >> + >> + /** Exponent CRT component (Eq = e%(q-1))*/ >> + odp_crypto_key_t Eq; >> + >> + /** Exponent CRT component (iqmp = q^(-1 mod p))*/ >> + odp_crypto_key_t iqmp; >> + >> + /** ModEx modulus length */ >> + int modex_modlen; >> + >> + } modex; > > What is the difference between modex and rsa then? > [Umesh]>> I will remove the CRT comopnents of MODEXP, CRT components > were not meant to be mandatory for the operation. > > Also if one would like to implement DSA/DH using your modex, he won't > have all those parameters. > [Umesh]>> The idea was to decide on doing CRT or NON CRT method > depending on the availablity of the parameters and not meant to be > mandatory. > >> + struct { >> + /**< ECDSA operation parameters */ >> + >> + /** ECDSA curve order */ >> + odp_crypto_key_t order; >> + >> + /** ECDSA prime modulus */ >> + odp_crypto_key_t prime; >> + >> + /** ECDSA private key */ >> + odp_crypto_key_t priv_key; >> + >> + /** ECDSA curve generator X co-ordinate */ >> + odp_crypto_key_t Gx; >> + >> + /** ECDSA curve generator Y co-ordinate */ >> + odp_crypto_key_t Gy; >> + >> + /** ECDSA public key :X co-ordinate of ECPOINT */ >> + odp_crypto_key_t qx; >> + >> + /** ECDSA public key :Y co-ordinate of ECPOINT */ >> + odp_crypto_key_t qy; >> + >> + /** ECDSA curve ID */ >> + odp_crypto_ecc_curves_t curve_id; >> + >> + } ecdsa; >> + struct { >> + /** ECDSA curve order */ >> + odp_crypto_key_t order; >> + >> + /** ECDSA curve generator X co-ordinate */ >> + odp_crypto_key_t Gx; >> + >> + /** ECDSA curve generator Y co-ordinate */ >> + odp_crypto_key_t Gy; >> + >> + /** F-ECC prime modulus */ >> + odp_crypto_key_t prime; >> + >> + /** F-ECC curve ID */ >> + odp_crypto_ecc_curves_t curve_id; >> + >> + } fecc; >> + }; >> +} odp_crypto_asym_key_t; >> + >> /** >> * Crypto API data range specifier >> */ >> @@ -252,7 +568,7 @@ typedef struct odp_crypto_data_range { >> * Crypto API session creation parameters >> */ >> typedef struct odp_crypto_session_param_t { >> - /** Encode vs. decode operation */ >> + /** Type of operation */ >> odp_crypto_op_t op; >> >> /** Authenticate cipher vs. plain text >> @@ -298,6 +614,15 @@ typedef struct odp_crypto_session_param_t { >> */ >> odp_crypto_key_t auth_key; >> >> + /** Asymmetric crypto operation keys >> + * When the cryptographic operation to be performed is any of the >> + * asymmetric crypto algorithms: cipher_alg, cipher_key, iv, and >> + * auth alg are invalid or inconsequential. All immutable parameters >> + * for the asymmetric crypto operation is expected in the asym_key >> + * structure. >> + */ >> + odp_crypto_asym_key_t asym_key; >> + >> /** Async mode completion event queue >> * >> * When odp_crypto_operation() is asynchronous, the completion queue >> is >> @@ -320,6 +645,145 @@ typedef struct odp_crypto_session_param_t { >> typedef odp_crypto_session_param_t odp_crypto_session_params_t; >> >> /** >> + * Asymmetric crypto API per packet operation parameters. >> + */ >> +typedef struct asym_param_offset { >> + union { >> + struct { >> + /** Data range of RSA signature >> + * When asymmetric crypto operation to be performed >> + * is @c ODP_CRYPTO_RSA_OP_SIGN, the signature >> + * generated will be written at specified offset in >> + * the output pkt buffer. If operation type is @c >> + * ODP_CRYPTO_RSA_OP_VERIFY, signature to be verified >> + * is expected at the specified offset in the input pkt >> + * buffer. >> + */ >> + odp_crypto_data_range_t signature; >> + >> + /** RSA operation type */ >> + odp_crypto_rsa_op_t op; >> + >> + /** RSA sign padding type >> + * RSA padding type to be used for RSA signature >> + * generation or signature verification @c >> + * odp_crypto_rsa_padding_t. >> + */ >> + odp_crypto_rsa_padding_t padding; >> + >> + /** RSA data hash type for OAEP/PSS padding */ >> + odp_auth_alg_t md; >> + >> + /** mask generating function for PSS padding*/ >> + odp_auth_alg_t mgf1md; >> + >> + } rsa; >> + struct { >> + /** MODEX operation type */ >> + odp_crypto_modex_op_t op; >> + } modex; >> + struct { >> + /** r-component of ECDSA sign >> + * When asymmetric crypto operation to be performed is >> + * @c ODP_CRYPTO_ECDSA_OP_SIGN, the 'r' component of >> + * ECDSA signature to be generated is written at >> + * specified offset in the output pkt. When asymmetric >> + * crypto operation to be performed is @c >> + * ODP_CRYPTO_ECDSA_OP_VERIFY, the 'r' component of >> + * signature to be verfied is read from the specified >> + * offset in input pkt buffer. >> + */ >> + odp_crypto_data_range_t sign_r; >> + >> + /** s-component of ECDSA sign >> + * When asymmetric crypto operation to be performed >> + * is @c ODP_CRYPTO_ECDSA_OP_SIGN, the 's' component of >> + * ECDSA signature to be generated is written at >> + * specified offset in the output pkt. When asymmetric >> + * crypto operation to be performed is @c >> + * ODP_CRYPTO_ECDSA_OP_VERIFY, the 's' component of >> + * signature to be verfied is read from the specified >> + * offset in input pkt buffer. >> + */ >> + odp_crypto_data_range_t sign_s; >> + >> + /** Scalar multiplicant for ECDSA sign >> + * When asymmetric crypto operation is @c >> + * ODP_CRYPTO_ECDSA_OP_SIGN, the scalar multiplicant >> + * used to generate signature is read from the >> + * specified offset from input pkt buffer. >> + */ >> + odp_crypto_data_range_t k; > > Ohh. I have really, really bad feeling about this. k is a very precious > thing. If Mallory can deduce k, he can recover private key. If there are > two signatures with the same k, Mallory can recover private key. I would > expect that k generation should be handled by the strong code part -- by > crypto engine/driver itself. > [Umesh]>> Just to be clear here, are you suggesting that the library create a > random > number internally and not take it as a part of input parameters? Current > libcrypto > library takes K as an explicit input. > >> + >> + /** ECDSA operation type */ >> + odp_crypto_ecdsa_op_t ecdsa_op; >> + >> + } ecdsa; >> + struct { >> + /** X co-ord of point operand I >> + * X co-ordinate of primary ECC curve point is read >> + * from the specified offset from input pkt buffer >> + * when crypto operation to be performed is @c >> + * ODP_CRYPTO_OP_FECC. >> + */ >> + odp_crypto_data_range_t px; >> + >> + /** Y co-ord of point operand I >> + * Y co-ordinate of primary ECC curve point is read >> + * from the specified offset from input pkt buffer >> + * when crypto operation to be performed is @c >> + * ODP_CRYPTO_OP_FECC. >> + */ >> + odp_crypto_data_range_t py; >> + >> + /** X co-ord of point operand II >> + * X co-ordinate of secondary ECC curve point is read >> + * from the specified offset from input pkt buffer when >> + * crypto operation to be performed is point addition >> + * @c ODP_CRYPTO_FECC_OP_P_ADD. >> + */ >> + odp_crypto_data_range_t qx; >> + >> + /** Y co-ord of point operand II >> + * Y co-ordinate of secondary ECC curve point is read >> + * from the specified offset from input pkt buffer when >> + * crypto operation to be performed is point addition >> + * @c ODP_CRYPTO_FECC_OP_P_ADD. >> + */ >> + odp_crypto_data_range_t qy; >> + >> + /** X co-ord of result point >> + * X co-ordinate of result ECC curve point is written >> + * at the specified offset in output packet buffer when >> + * crypto operation to be performed is @c >> + * ODP_CRYPTO_OP_FECC. >> + */ >> + odp_crypto_data_range_t rx; >> + >> + /** Y co-ord of result point >> + * Y co-ordinate of result ECC curve point is written >> + * at the specified offset in output packet buffer >> + * when crypto operation to be performed is @c >> + * ODP_CRYPTO_OP_FECC. >> + */ >> + odp_crypto_data_range_t ry; >> + >> + /** Scalar multiplicant >> + * When crypto operation to be performed is @c >> + * ODP_CRYPTO_FECC_OP_P_MUL, the scalar multiplicant >> + * for point multiplication is read from specified >> + * offset in input packet buffer. >> + */ >> + odp_crypto_data_range_t k; >> + >> + /** F-ECC operation type */ >> + odp_crypto_fecc_op_t fecc_op; >> + >> + } fecc; >> + }; >> +} asym_param_offset_t; >> + >> +/** >> * Crypto API per packet operation parameters >> */ >> typedef struct odp_crypto_op_param_t { >> @@ -364,12 +828,36 @@ typedef struct odp_crypto_op_param_t { >> */ >> uint32_t hash_result_offset; >> >> + struct asym_param_offset asym_offset; >> + >> /** Data range to apply cipher */ >> odp_crypto_data_range_t cipher_range; >> >> /** Data range to authenticate */ >> odp_crypto_data_range_t auth_range; >> >> + /** Data range for asymmetric operation >> + * >> + * If asymmetric operation is any of RSA public encrypt or private >> + * decrypt, asym_data_range specifies the length and offset of data to >> + * be encrypted or decrypted respectively. Length of data cannot exceed >> + * modulus length prime modulus length for encryption and should be >> + * equal to prime modulus length for decryption. >> + * >> + * If asymmetric operation is any of RSA sign, RSA verify, ECDSA >> + * sign or ECDSA verify, asym_data_range specifies the data for which >> + * signature is to be generated or verified. Length of data for RSA >> + * sign or verify depends on the type of RSA padding to be used and >> + * less than prime modulus length. Only leftmost prime modulus length >> + * bytes of data are used for ECDSA sign generation or verification. >> + * >> + * If asymmetric operation is modexp, asym_data_range specifies the >> + * base for modular exponentiation. Length of data is expected to be >> + * than prime modulus length. >> + * >> + */ >> + odp_crypto_data_range_t asym_data_range; >> + >> } odp_crypto_op_param_t; >> >> /** @deprecated Use odp_crypto_op_param_t instead */ >> @@ -403,6 +891,20 @@ typedef enum { >> ODP_CRYPTO_ALG_ERR_ICV_CHECK, >> /** IV value not specified */ >> ODP_CRYPTO_ALG_ERR_IV_INVALID, >> + /** Invalid parameter length */ >> + ODP_CRYPTO_ALG_ERR_INVALID_PARAM_LEN, >> + /** Data too large for RSA encrypt */ >> + ODP_CRYPTO_ALG_RSA_DATA_TOO_LARGE, >> + /** Invalid PKCS padding */ >> + ODP_CRYPTO_ALG_RSA_ERR_DECRYPT, > > If the error is about invalid padding, why did you name it > RSA_ERR_DECRYPT instead of RSA_ERR_PADDING? > [Umesh]>> We will change the comment, we do not want to differentiate > between various RSA decrypt errors. > >> + /** RSA signature verification failed */ >> + ODP_CRYPTO_ALG_RSA_SIGN_MISMATCH, >> + /** Invalid ECDSA signature */ >> + ODP_CRYPTO_ALG_ECDSA_ERR_INVALID_SIGN, >> + /** ECDSA signature verify failure */ >> + ODP_CRYPTO_ALG_ECDSA_ERR_SIGN_MISMATCH, >> + /** Fundamental ECC error Point at Infinity */ >> + ODP_CRYPTO_ALG_FECC_POINT_AT_INFINITY, >> } odp_crypto_alg_err_t; >> >> /** >> @@ -448,6 +950,9 @@ typedef struct odp_crypto_op_result { >> /** Authentication status */ >> odp_crypto_compl_status_t auth_status; >> >> + /** Asymmetric operation status */ >> + odp_crypto_compl_status_t asym_status; >> + >> } odp_crypto_op_result_t; >> >> /** >> @@ -469,6 +974,12 @@ typedef struct odp_crypto_capability_t { >> /** Authentication algorithms implemented with HW offload */ >> odp_crypto_auth_algos_t hw_auths; >> >> + /** Supported Asymmetric algorithms */ >> + odp_crypto_asym_algos_t asym_algs; >> + >> + /** Asymmetric algorithms implemented with HW offload */ >> + odp_crypto_asym_algos_t hw_asym_algs; >> + >> } odp_crypto_capability_t; >> >> /** >> @@ -509,6 +1020,46 @@ typedef struct odp_crypto_auth_capability_t { >> } odp_crypto_auth_capability_t; >> >> /** >> + * Asymmetric algorithm capabilities >> + */ >> +typedef struct odp_crypto_asym_capability_t { >> + union { >> + struct { >> + /** Maximum prime modulus length for RSA */ >> + uint32_t max_modlen; >> + >> + /** Minimum prime modulus length for RSA */ >> + uint32_t min_modlen; >> + >> + /** Supported RSA padding schemes */ >> + odp_crypto_rsa_pad_bits_t padding; >> + } rsa; >> + >> + struct { >> + /** Maximum prime modulus length for modular >> + * exponentiation >> + */ >> + uint32_t max_modlen; >> + >> + /** Minimum prime modulus length for modular >> + * exponentiation >> + */ >> + uint32_t min_modlen; >> + } modex; >> + >> + struct { >> + /** Support ECC curves for ECDSA Operation */ >> + odp_crypto_ecc_bits_t curve_list; >> + } ecdsa; >> + >> + struct { >> + /** Support ECC curves for Fundamental ECC Operation */ >> + odp_crypto_ecc_bits_t curve_list; >> + } fecc; >> + }; >> +} odp_crypto_asym_capability_t; >> + >> +/** >> * Query crypto capabilities >> * >> * Outputs crypto capabilities on success. >> @@ -560,6 +1111,23 @@ int odp_crypto_auth_capability(odp_auth_alg_t auth, >> odp_crypto_auth_capability_t capa[], int num); >> >> /** >> + * Query supported asymmetric algorithm capabilities >> + * >> + * Outputs all supported configuration options for asymmetric algorithm. >> + * >> + * @param asym Asymmetric algorithm >> + * @param[out] capa Array of capability structures for output >> + * @param num Maximum number of capability structures to >> output >> + * >> + * @return Number of capability structures for the algorithm. If this is >> larger >> + * than 'num', only 'num' first structures were output and >> application >> + * may call the function again with a larger value of 'num'. >> + * @retval <0 on failure >> + */ >> +int odp_crypto_asym_capability(odp_asym_alg_t asym, >> + odp_crypto_asym_capability_t capa[], int num); >> + >> +/** >> * Crypto session creation >> * >> * Create a crypto session according to the session parameters. Use >> > > > -- > With best wishes > Dmitry >