From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id DAB59239 for ; Tue, 19 Mar 2019 08:47:39 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Mar 2019 00:47:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,497,1544515200"; d="scan'208,217";a="153006016" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga002.fm.intel.com with ESMTP; 19 Mar 2019 00:47:38 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Mar 2019 00:47:38 -0700 Received: from lcsmsx155.ger.corp.intel.com (10.186.165.233) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Mar 2019 00:47:37 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.144]) by LCSMSX155.ger.corp.intel.com ([169.254.12.205]) with mapi id 14.03.0415.000; Tue, 19 Mar 2019 09:47:34 +0200 From: "Kusztal, ArkadiuszX" To: "akhil.goyal@nxp.com" , Shally Verma , Sunila Sahu , "Trahe, Fiona" , "Nowak, DamianX" , "Kanaka Durga Kotamarthy" , Arvind Desai , "De Lara Guarch, Pablo" CC: "dev@dpdk.org" Thread-Topic: [RFC] cryptodev/asymm: propose changes to RSA API Thread-Index: AdTeJpLe1m5vadYeRWyJezCFHVX2HQ== Date: Tue, 19 Mar 2019 07:47:33 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B14B646@hasmsx109.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.104.116.187] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] [RFC] cryptodev/asymm: propose changes to RSA API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 07:47:40 -0000 Hi all, I would like to propose some changes to RSA API, I will put in this mail API comments I initially created and I will try add= itionally to elaborate about some of them too (with [AK]). Any comments, critique or ideas are much appreciated :). 1) Crypto op: @@ -395,9 +414,28 @@ struct rte_crypto_rsa_op_param { /**< * 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. [AK] - some information would be good about behavior when buffer is not big= enough. + */ + + rte_crypto_param cipher; + /**< + * Pointer to data + * - to be decrypted for RSA private decrypt. + * + * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used size in bytes + * of this field need to be equal to the size of corresponding + * RSA key. */ [AK] - Asymmetric nature of RSA suggest cipher/plaintext relation should be= asymmetric too, we don't know how big will be output comparing to the input. [AK] - I miss here some information about len of long number as a separate = field I mentioned in earlier mails, we could then have had size of the buffer (in case it would be reused) and = size of number (removed leading zeroes). For now empty buffer (i.e. message before decryption) length will be the si= ze of the buffer, after decryption it will be size of long number. rte_crypto_param sign; @@ -408,8 +446,85 @@ struct rte_crypto_rsa_op_param { * * Length of the signature data will be equal to the * RSA prime modulus length. + + struct { + enum rte_crypto_rsa_padding_type type; + /**< + * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selec= ted, + * driver will distinguish between block type ba= sing + * on rte_crypto_asym_op_type of the operation. [AK] - So block type 01 for signature, 02 for encryption. I dropped type 00= as it is unsafe and not used anywhere. + * + * Which padding type is supported by the driver= SHALL be + * available in in specific driver guide or capa= bilities. + */ + enum rte_crypto_hash_algorithm hash; + /**< + * - For PKCS1-v1_5 signature (Block typ= e 01) this field + * represents hash function that will be used to= create + * message hash. This hash will be then concaten= ated with + * hash algorithm identifier into DER encoded se= quence. [AK] - I wonder about accepting signatures with BER encoding as it was defined in 2313 rfc to be backward compatible. + * If RTE_CRYPTO_HASH_INVALID is set, driver def= ault will be set. + * If RTE_CRYPTO_HASH_NONE is set, message will = be signed as it is. + * + * - For OAEP this field represents hash= function that will + * be used to produce hash of the optional label= . + * If RTE_CRYPTO_HASH_INVALID or RTE_CRYPTO_HASH= _NONE is set + * driver will use default value. For OAEP usual= ly it is SHA-1. + * + * - For PSS this field represents hash = function that will be used + * to produce hash (mHash) of message M and of M= ' (padding1 | mHash | salt) + * If RTE_CRYPTO_HASH_INVALID or RTE_CRYPTO_HASH= _NONE is set + * driver will use default value. + * + * - If driver supports only one functio= n RTE_CRYPTO_HASH_NONE + * according to aformentioned restrictions shoul= d be used or + * specific function should be set, otherwise on= dequeue the driver + * SHALL set crypto_op_status to RTE_CRYPTO_OP_S= TATUS_INVALID_ARGS. + */ + union { + struct { + enum rte_crypto_has= h_algorithm mgf; + /**< + * Mask genereation = function hash algorithm. + * If this field is = not supported by the driver, + * it should be set = to RTE_CRYPTO_HASH_NONE. + */ + rte_crypto_param la= bel; + /**< + * Optional label, i= f driver does not support + * this option, opti= onal label is just an empty string. + */ + } OAEP; + struct { + enum rte_crypto_has= h_algorithm mgf; + /**< + * Mask genereation = function hash algorithm. + * If this field is = not supported by the driver, + * it should be set = to RTE_CRYPTO_HASH_NONE. + */ + int seed_len; + /**< + * Intended seed len= gth. Nagative number has special + * value as follows: + * -1 : seed len =3D= length of output ot used hash function + * -2 : seed len is = maximized [AK] - It actually is taken from OPENSSL implementation, but looks like goo= d idea tbh. + */ + } PSS; + }; + } padding; + /**< + * Padding type of RSA crypto operation. + * What are random number generator requirements and prerequisi= tes + * SHALL be put in specific driver guide */ + /* All fields below should be deprecated */ enum rte_crypto_rsa_padding_type pad; /**< RSA padding scheme to be used for transform */ 2) Padding: enum rte_crypto_rsa_padding_type { RTE_CRYPTO_RSA_PADDING_NONE =3D 0, - /**< RSA no padding scheme */ + /**< RSA no padding scheme. + * In this case user is responsible for providing and verificat= ion + * of padding. + * In case RTE_CRYPTO_ASYM_OP_VERIFY op type is used if no + * problems in public key 'encryption' detected driver SHALL re= turn + * RTE_CRYPTO_OP_STATUS_SUCCESS, output data should be put in c= ipher data + * of crypto op. + * It is USER RESPONSABILITY to remove padding and verify signa= ture. */ + RTE_CRYPTO_RSA_PADDING_PKCS1, + /**< RSA PKCS#1 PKCS1-v1_5 padding scheme. For signatures bloc= k type 01, + * for encryption block type 02 are used. + * + * In case RTE_CRYPTO_ASYM_OP_VERIFY op type is used crypto op = status + * is set to RTE_CRYPTO_OP_STATUS_SUCCESS when signature is pro= perly + * verified, RTE_CRYPTO_OP_STATUS_ERROR when it failed. + */ + RTE_CRYPTO_RSA_PADDING_OAEP, + /**< RSA PKCS#1 OAEP padding scheme, can be used only for encr= yption/ + * decryption. */ + RTE_CRYPTO_RSA_PADDING_PSS, + /**< RSA PKCS#1 PSS padding scheme, can be used only for signa= tures. + * + * Crypto op status is set to RTE_CRYPTO_OP_STATUS_SUCCESS + * when signature is properly verified, RTE_CRYPTO_OP_STATUS_ER= ROR + * when it failed. [AK] I consider some new flags like STATUS_SIGNATURE_VERIFIED, STATUS_SIGNE= D. + * + */ + RTE_CRYPTO_RSA_PKCS1_V1_5_BT0, - /**< RSA PKCS#1 V1.5 Block Type 0 padding scheme - * as descibed in rfc2313 + /* DEPRECATED */ RTE_CRYPTO_RSA_PKCS1_V1_5_BT1, - /**< RSA PKCS#1 V1.5 Block Type 01 padding scheme - * as descibed in rfc2313 + /* DEPRECATED */ RTE_CRYPTO_RSA_PKCS1_V1_5_BT2, - /**< RSA PKCS#1 V1.5 Block Type 02 padding scheme - * as descibed in rfc2313 + /* DEPRECATED */ }; 3) Hash functions +enum rte_crypto_hash_algorithm { + RTE_CRYPTO_HASH_INVALID, + RTE_CRYPTO_HASH_NONE, + RTE_CRYPTO_HASH_MD5, + RTE_CRYPTO_HASH_SHA1, + RTE_CRYPTO_HASH_SHA244, + RTE_CRYPTO_HASH_SHA256, + RTE_CRYPTO_HASH_SHA384, + RTE_CRYPTO_HASH_SHA512, + RTE_CRYPTO_HASH_SHA512_224, + RTE_CRYPTO_HASH_SHA512_256, +}; [AK] Instead of using auth enum i would just add to symmetric API hash func= tions. [AK] If accepted some, or most of these fields could be somehow reflected i= n capabilities. Regards, Arek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id F0FBBA05FE for ; Tue, 19 Mar 2019 08:47:42 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F27B21DBD; Tue, 19 Mar 2019 08:47:41 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id DAB59239 for ; Tue, 19 Mar 2019 08:47:39 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Mar 2019 00:47:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,497,1544515200"; d="scan'208,217";a="153006016" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga002.fm.intel.com with ESMTP; 19 Mar 2019 00:47:38 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Mar 2019 00:47:38 -0700 Received: from lcsmsx155.ger.corp.intel.com (10.186.165.233) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Mar 2019 00:47:37 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.144]) by LCSMSX155.ger.corp.intel.com ([169.254.12.205]) with mapi id 14.03.0415.000; Tue, 19 Mar 2019 09:47:34 +0200 From: "Kusztal, ArkadiuszX" To: "akhil.goyal@nxp.com" , Shally Verma , Sunila Sahu , "Trahe, Fiona" , "Nowak, DamianX" , "Kanaka Durga Kotamarthy" , Arvind Desai , "De Lara Guarch, Pablo" CC: "dev@dpdk.org" Thread-Topic: [RFC] cryptodev/asymm: propose changes to RSA API Thread-Index: AdTeJpLe1m5vadYeRWyJezCFHVX2HQ== Date: Tue, 19 Mar 2019 07:47:33 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B14B646@hasmsx109.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.104.116.187] MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] [RFC] cryptodev/asymm: propose changes to RSA API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190319074733.FQX2vwLTEPcveEw-iT9bXfuSVO46z3wGQ-JhKhpQt1s@z> Hi all, I would like to propose some changes to RSA API, I will put in this mail API comments I initially created and I will try add= itionally to elaborate about some of them too (with [AK]). Any comments, critique or ideas are much appreciated :). 1) Crypto op: @@ -395,9 +414,28 @@ struct rte_crypto_rsa_op_param { /**< * 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. [AK] - some information would be good about behavior when buffer is not big= enough. + */ + + rte_crypto_param cipher; + /**< + * Pointer to data + * - to be decrypted for RSA private decrypt. + * + * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used size in bytes + * of this field need to be equal to the size of corresponding + * RSA key. */ [AK] - Asymmetric nature of RSA suggest cipher/plaintext relation should be= asymmetric too, we don't know how big will be output comparing to the input. [AK] - I miss here some information about len of long number as a separate = field I mentioned in earlier mails, we could then have had size of the buffer (in case it would be reused) and = size of number (removed leading zeroes). For now empty buffer (i.e. message before decryption) length will be the si= ze of the buffer, after decryption it will be size of long number. rte_crypto_param sign; @@ -408,8 +446,85 @@ struct rte_crypto_rsa_op_param { * * Length of the signature data will be equal to the * RSA prime modulus length. + + struct { + enum rte_crypto_rsa_padding_type type; + /**< + * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selec= ted, + * driver will distinguish between block type ba= sing + * on rte_crypto_asym_op_type of the operation. [AK] - So block type 01 for signature, 02 for encryption. I dropped type 00= as it is unsafe and not used anywhere. + * + * Which padding type is supported by the driver= SHALL be + * available in in specific driver guide or capa= bilities. + */ + enum rte_crypto_hash_algorithm hash; + /**< + * - For PKCS1-v1_5 signature (Block typ= e 01) this field + * represents hash function that will be used to= create + * message hash. This hash will be then concaten= ated with + * hash algorithm identifier into DER encoded se= quence. [AK] - I wonder about accepting signatures with BER encoding as it was defined in 2313 rfc to be backward compatible. + * If RTE_CRYPTO_HASH_INVALID is set, driver def= ault will be set. + * If RTE_CRYPTO_HASH_NONE is set, message will = be signed as it is. + * + * - For OAEP this field represents hash= function that will + * be used to produce hash of the optional label= . + * If RTE_CRYPTO_HASH_INVALID or RTE_CRYPTO_HASH= _NONE is set + * driver will use default value. For OAEP usual= ly it is SHA-1. + * + * - For PSS this field represents hash = function that will be used + * to produce hash (mHash) of message M and of M= ' (padding1 | mHash | salt) + * If RTE_CRYPTO_HASH_INVALID or RTE_CRYPTO_HASH= _NONE is set + * driver will use default value. + * + * - If driver supports only one functio= n RTE_CRYPTO_HASH_NONE + * according to aformentioned restrictions shoul= d be used or + * specific function should be set, otherwise on= dequeue the driver + * SHALL set crypto_op_status to RTE_CRYPTO_OP_S= TATUS_INVALID_ARGS. + */ + union { + struct { + enum rte_crypto_has= h_algorithm mgf; + /**< + * Mask genereation = function hash algorithm. + * If this field is = not supported by the driver, + * it should be set = to RTE_CRYPTO_HASH_NONE. + */ + rte_crypto_param la= bel; + /**< + * Optional label, i= f driver does not support + * this option, opti= onal label is just an empty string. + */ + } OAEP; + struct { + enum rte_crypto_has= h_algorithm mgf; + /**< + * Mask genereation = function hash algorithm. + * If this field is = not supported by the driver, + * it should be set = to RTE_CRYPTO_HASH_NONE. + */ + int seed_len; + /**< + * Intended seed len= gth. Nagative number has special + * value as follows: + * -1 : seed len =3D= length of output ot used hash function + * -2 : seed len is = maximized [AK] - It actually is taken from OPENSSL implementation, but looks like goo= d idea tbh. + */ + } PSS; + }; + } padding; + /**< + * Padding type of RSA crypto operation. + * What are random number generator requirements and prerequisi= tes + * SHALL be put in specific driver guide */ + /* All fields below should be deprecated */ enum rte_crypto_rsa_padding_type pad; /**< RSA padding scheme to be used for transform */ 2) Padding: enum rte_crypto_rsa_padding_type { RTE_CRYPTO_RSA_PADDING_NONE =3D 0, - /**< RSA no padding scheme */ + /**< RSA no padding scheme. + * In this case user is responsible for providing and verificat= ion + * of padding. + * In case RTE_CRYPTO_ASYM_OP_VERIFY op type is used if no + * problems in public key 'encryption' detected driver SHALL re= turn + * RTE_CRYPTO_OP_STATUS_SUCCESS, output data should be put in c= ipher data + * of crypto op. + * It is USER RESPONSABILITY to remove padding and verify signa= ture. */ + RTE_CRYPTO_RSA_PADDING_PKCS1, + /**< RSA PKCS#1 PKCS1-v1_5 padding scheme. For signatures bloc= k type 01, + * for encryption block type 02 are used. + * + * In case RTE_CRYPTO_ASYM_OP_VERIFY op type is used crypto op = status + * is set to RTE_CRYPTO_OP_STATUS_SUCCESS when signature is pro= perly + * verified, RTE_CRYPTO_OP_STATUS_ERROR when it failed. + */ + RTE_CRYPTO_RSA_PADDING_OAEP, + /**< RSA PKCS#1 OAEP padding scheme, can be used only for encr= yption/ + * decryption. */ + RTE_CRYPTO_RSA_PADDING_PSS, + /**< RSA PKCS#1 PSS padding scheme, can be used only for signa= tures. + * + * Crypto op status is set to RTE_CRYPTO_OP_STATUS_SUCCESS + * when signature is properly verified, RTE_CRYPTO_OP_STATUS_ER= ROR + * when it failed. [AK] I consider some new flags like STATUS_SIGNATURE_VERIFIED, STATUS_SIGNE= D. + * + */ + RTE_CRYPTO_RSA_PKCS1_V1_5_BT0, - /**< RSA PKCS#1 V1.5 Block Type 0 padding scheme - * as descibed in rfc2313 + /* DEPRECATED */ RTE_CRYPTO_RSA_PKCS1_V1_5_BT1, - /**< RSA PKCS#1 V1.5 Block Type 01 padding scheme - * as descibed in rfc2313 + /* DEPRECATED */ RTE_CRYPTO_RSA_PKCS1_V1_5_BT2, - /**< RSA PKCS#1 V1.5 Block Type 02 padding scheme - * as descibed in rfc2313 + /* DEPRECATED */ }; 3) Hash functions +enum rte_crypto_hash_algorithm { + RTE_CRYPTO_HASH_INVALID, + RTE_CRYPTO_HASH_NONE, + RTE_CRYPTO_HASH_MD5, + RTE_CRYPTO_HASH_SHA1, + RTE_CRYPTO_HASH_SHA244, + RTE_CRYPTO_HASH_SHA256, + RTE_CRYPTO_HASH_SHA384, + RTE_CRYPTO_HASH_SHA512, + RTE_CRYPTO_HASH_SHA512_224, + RTE_CRYPTO_HASH_SHA512_256, +}; [AK] Instead of using auth enum i would just add to symmetric API hash func= tions. [AK] If accepted some, or most of these fields could be somehow reflected i= n capabilities. Regards, Arek