[dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API

[dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API

[Matan Azrad]

The Key Wrap approach is used by applications in order to protect keys
located in untrusted storage or transmitted over untrusted
communications networks. The constructions are typically built from
standard primitives such as block ciphers and cryptographic hash
functions.

The Key Wrap method and its parameters are a secret between the keys
provider and the device, means that the device is preconfigured for
this method using very secured way.

The key wrap method may change the key length and layout.

Add a description for the cipher transformation key to allow wrapped key
to be forwarded by the same API.

Signed-off-by: Matan Azrad <matan@nvidia.com>
---
 lib/librte_cryptodev/rte_crypto_sym.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 5973e31..6aca2c7 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -200,6 +200,13 @@ struct rte_crypto_cipher_xform {
 		uint16_t length;	/**< key length in bytes */
 	} key;
 	/**< Cipher key
+	 * The original key data may be provided wrapped (encrypted) using a key
+	 * wrap algorithm such as AES key wrap (from rfc3394) or other. In such
+	 * case, the wrapping details is a secret between the key provider and
+	 * the device. Such key wrapping may increase the length of the provided
+	 * key beyond the advertised supported key size. Hence it is the
+	 * responsibility of the driver/device to validate the length of the
+	 * provided key.
 	 *
 	 * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data will
 	 * point to a concatenation of the AES encryption key followed by a
-- 
1.8.3.1

[dpdk-dev] [PATCH v2] cryptodev: formalize key wrap method in API

[Matan Azrad]

The Key Wrap approach is used by applications in order to protect keys
located in untrusted storage or transmitted over untrusted
communications networks. The constructions are typically built from
standard primitives such as block ciphers and cryptographic hash
functions.

The Key Wrap method and its parameters are a secret between the keys
provider and the device, means that the device is preconfigured for
this method using very secured way.

The key wrap method may change the key length and layout.

Add a description for the cipher transformation key to allow wrapped key
to be forwarded by the same API.

Add a new feature flag RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY to be enabled
by PMDs support wrapped key in cipher trasformation.

Signed-off-by: Matan Azrad <matan@nvidia.com>
---

V2:
Address Akhil coment to introduce ne feature flag for wrapped keys.


 doc/guides/cryptodevs/features/default.ini | 1 +
 doc/guides/cryptodevs/overview.rst         | 3 +++
 doc/guides/rel_notes/release_21_05.rst     | 5 +++++
 lib/librte_cryptodev/rte_crypto_sym.h      | 8 ++++++++
 lib/librte_cryptodev/rte_cryptodev.c       | 2 ++
 lib/librte_cryptodev/rte_cryptodev.h       | 2 ++
 6 files changed, 21 insertions(+)

diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 978bb30cc1..c24814de98 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -32,6 +32,7 @@ Symmetric sessionless  =
 Non-Byte aligned data  =
 Sym raw data path API  =
 Cipher multiple data units =
+Cipher wrapped key     =
 
 ;
 ; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index e24e3e1993..47b1231226 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -49,6 +49,9 @@ Supported Feature Flags
    - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support operations
       on multiple data-units message.
 
+   - "CIPHER_WRAPPED_KEY" feature flag means PMD support wrapped key in cipher
+      transformation.
+
 
 Supported Cipher Algorithms
 ---------------------------
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 1537fac4bc..75b2b86c5f 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -132,6 +132,11 @@ New Features
   data-units for AES-XTS algorithm, the data-unit length should be set in the
   transformation. A capability for it was added too.
 
+* **Added feature to support cipher wrapped key on cryptodev library API.**
+
+  The Cryptodev library has been enhanced to allow providing wrapped key in
+  cipher transformation. 
+
 
 Removed Items
 -------------
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 5973e31f30..0e08d2ef9e 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -200,6 +200,14 @@ struct rte_crypto_cipher_xform {
 		uint16_t length;	/**< key length in bytes */
 	} key;
 	/**< Cipher key
+	 * When the device RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY feature is
+	 * enabled, the original key data may be provided wrapped (encrypted)
+	 * using a key wrap algorithm such as AES key wrap (from rfc3394) or
+	 * other. In such case, the wrapping details is a secret between the key
+	 * provider and the device. Such key wrapping may increase the length of
+	 * the provided key beyond the advertised supported key size. Hence it
+	 * is the responsibility of the driver/device to validate the length of
+	 * the provided key.
 	 *
 	 * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data will
 	 * point to a concatenation of the AES encryption key followed by a
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index e02e001325..a84cd745f9 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -619,6 +619,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
 		return "NON_BYTE_ALIGNED_DATA";
 	case RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS:
 		return "CIPHER_MULTIPLE_DATA_UNITS";
+	case RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY:
+		return "CIPHER_WRAPPED_KEY";
 	default:
 		return NULL;
 	}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index c274e208ed..16c20de94c 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -476,6 +476,8 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 /**< Support accelerator specific symmetric raw data-path APIs */
 #define RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS	(1ULL << 25)
 /**< Support operations on multiple data-units message */
+#define RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY		(1ULL << 26)
+/**< Support wrapped key in cipher transformation  */
 
 /**
  * Get the name of a crypto device feature flag
-- 
2.25.1

Re: [dpdk-dev] [EXT] [PATCH v2] cryptodev: formalize key wrap method in API

[Akhil Goyal]

Hi Matan,

> The Key Wrap approach is used by applications in order to protect keys
> located in untrusted storage or transmitted over untrusted
> communications networks. The constructions are typically built from
> standard primitives such as block ciphers and cryptographic hash
> functions.
> 
> The Key Wrap method and its parameters are a secret between the keys
> provider and the device, means that the device is preconfigured for
> this method using very secured way.
> 
> The key wrap method may change the key length and layout.
> 
> Add a description for the cipher transformation key to allow wrapped key
> to be forwarded by the same API.
> 
> Add a new feature flag RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY to be
> enabled
> by PMDs support wrapped key in cipher trasformation.

Spell check

> 
> Signed-off-by: Matan Azrad <matan@nvidia.com>
> ---
> 
> V2:
> Address Akhil coment to introduce ne feature flag for wrapped keys.
> 
> 
>  doc/guides/cryptodevs/features/default.ini | 1 +
>  doc/guides/cryptodevs/overview.rst         | 3 +++
>  doc/guides/rel_notes/release_21_05.rst     | 5 +++++
>  lib/librte_cryptodev/rte_crypto_sym.h      | 8 ++++++++
>  lib/librte_cryptodev/rte_cryptodev.c       | 2 ++
>  lib/librte_cryptodev/rte_cryptodev.h       | 2 ++
>  6 files changed, 21 insertions(+)
> 
> diff --git a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 978bb30cc1..c24814de98 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -32,6 +32,7 @@ Symmetric sessionless  =
>  Non-Byte aligned data  =
>  Sym raw data path API  =
>  Cipher multiple data units =
> +Cipher wrapped key     =
> 
>  ;
>  ; Supported crypto algorithms of a default crypto driver.
> diff --git a/doc/guides/cryptodevs/overview.rst
> b/doc/guides/cryptodevs/overview.rst
> index e24e3e1993..47b1231226 100644
> --- a/doc/guides/cryptodevs/overview.rst
> +++ b/doc/guides/cryptodevs/overview.rst
> @@ -49,6 +49,9 @@ Supported Feature Flags
>     - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support
> operations
>        on multiple data-units message.
> 
> +   - "CIPHER_WRAPPED_KEY" feature flag means PMD support wrapped key
> in cipher
> +      transformation.
> +
> 
>  Supported Cipher Algorithms
>  ---------------------------
> diff --git a/doc/guides/rel_notes/release_21_05.rst
> b/doc/guides/rel_notes/release_21_05.rst
> index 1537fac4bc..75b2b86c5f 100644
> --- a/doc/guides/rel_notes/release_21_05.rst
> +++ b/doc/guides/rel_notes/release_21_05.rst
> @@ -132,6 +132,11 @@ New Features
>    data-units for AES-XTS algorithm, the data-unit length should be set in the
>    transformation. A capability for it was added too.
> 
> +* **Added feature to support cipher wrapped key on cryptodev library
> API.**
> +
> +  The Cryptodev library has been enhanced to allow providing wrapped key
> in
> +  cipher transformation.

Added a crypto PMD feature flag to support cipher wrapped keys

A new feature flag is added to allow application to provide cipher wrapped keys
in session xforms.

> +
> 
>  Removed Items
>  -------------
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> b/lib/librte_cryptodev/rte_crypto_sym.h
> index 5973e31f30..0e08d2ef9e 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -200,6 +200,14 @@ struct rte_crypto_cipher_xform {
>  		uint16_t length;	/**< key length in bytes */
>  	} key;
>  	/**< Cipher key
> +	 * When the device RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY
> feature is
> +	 * enabled, the original key data may be provided wrapped
> (encrypted)
> +	 * using a key wrap algorithm such as AES key wrap (from rfc3394) or
> +	 * other. In such case, the wrapping details is a secret between the
> key
> +	 * provider and the device. Such key wrapping may increase the
> length of
> +	 * the provided key beyond the advertised supported key size. Hence
> it
> +	 * is the responsibility of the driver/device to validate the length of
> +	 * the provided key.

How will the PMD respond if length of the provided key is not correct.
Which API will return error? Session_init? 
It should also be mentioned here.

Also, the application should check the capability key lengths only in case 
FF_CIPHER_WRAPPED_KEY is set. Otherwise it should be checked as it was
Done before.
Please align the l2fwd-crypto patch as per this patch.

You may rephrase it as
"In case the PMD supports RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY,
the original key data provided may be wrapped(encrypted) using key
wrap algorithm such as AES key wrap (rfc3394) and hence length of the
key may increase beyond the PMD advertised supported key size.
PMD shall validate the key length and report error while configuring the
Session and application can skip checking the capability key length in
Such cases."


>  	 *
>  	 * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data
> will
>  	 * point to a concatenation of the AES encryption key followed by a
> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> b/lib/librte_cryptodev/rte_cryptodev.c
> index e02e001325..a84cd745f9 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -619,6 +619,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
>  		return "NON_BYTE_ALIGNED_DATA";
>  	case RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS:
>  		return "CIPHER_MULTIPLE_DATA_UNITS";
> +	case RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY:
> +		return "CIPHER_WRAPPED_KEY";
>  	default:
>  		return NULL;
>  	}
> diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> b/lib/librte_cryptodev/rte_cryptodev.h
> index c274e208ed..16c20de94c 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -476,6 +476,8 @@ rte_cryptodev_asym_get_xform_enum(enum
> rte_crypto_asym_xform_type *xform_enum,
>  /**< Support accelerator specific symmetric raw data-path APIs */
>  #define RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS	(1ULL << 25)
>  /**< Support operations on multiple data-units message */
> +#define RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY		(1ULL << 26)
> +/**< Support wrapped key in cipher transformation  */
> 
>  /**
>   * Get the name of a crypto device feature flag
> --
> 2.25.1

[dpdk-dev] [PATCH v3] cryptodev: formalize key wrap method in API

[Matan Azrad]

The Key Wrap approach is used by applications in order to protect keys
located in untrusted storage or transmitted over untrusted
communications networks. The constructions are typically built from
standard primitives such as block ciphers and cryptographic hash
functions.

The Key Wrap method and its parameters are a secret between the keys
provider and the device, means that the device is preconfigured for
this method using very secured way.

The key wrap method may change the key length and layout.

Add a description for the cipher transformation key to allow wrapped key
to be forwarded by the same API.

Add a new feature flag RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY to be enabled
by PMDs support wrapped key in cipher trasformation.

Signed-off-by: Matan Azrad <matan@nvidia.com>
---

V2:
Address Akhil coment to introduce ne feature flag for wrapped keys.

V3:
Improve descriptions\spelling suggested by Akhil. 

 doc/guides/cryptodevs/features/default.ini | 1 +
 doc/guides/cryptodevs/overview.rst         | 3 +++
 doc/guides/rel_notes/release_21_05.rst     | 5 +++++
 lib/librte_cryptodev/rte_crypto_sym.h      | 8 ++++++++
 lib/librte_cryptodev/rte_cryptodev.c       | 2 ++
 lib/librte_cryptodev/rte_cryptodev.h       | 2 ++
 6 files changed, 21 insertions(+)

diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 978bb30cc1..c24814de98 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -32,6 +32,7 @@ Symmetric sessionless  =
 Non-Byte aligned data  =
 Sym raw data path API  =
 Cipher multiple data units =
+Cipher wrapped key     =
 
 ;
 ; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index e24e3e1993..b87c4c6a27 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -49,6 +49,9 @@ Supported Feature Flags
    - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support operations
       on multiple data-units message.
 
+   - "CIPHER_WRAPPED_KEY" feature flag means PMD support wrapped key in cipher
+      xform.
+
 
 Supported Cipher Algorithms
 ---------------------------
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 1537fac4bc..24b8b28253 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -132,6 +132,11 @@ New Features
   data-units for AES-XTS algorithm, the data-unit length should be set in the
   transformation. A capability for it was added too.
 
+* **Added a crypto PMD feature flag to support cipher wrapped keys.**
+
+  A new feature flag is added to allow application to provide cipher wrapped
+  keys in session xforms.
+
 
 Removed Items
 -------------
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 5973e31f30..a1fb5b0f5c 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -200,6 +200,14 @@ struct rte_crypto_cipher_xform {
 		uint16_t length;	/**< key length in bytes */
 	} key;
 	/**< Cipher key
+	 *
+	 * In case the PMD supports RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY, the
+	 * original key data provided may be wrapped(encrypted) using key wrap
+	 * algorithm such as AES key wrap (rfc3394) and hence length of the key
+	 * may increase beyond the PMD advertised supported key size.
+	 * PMD shall validate the key length and report EMSGSIZE error while
+	 * configuring the session and application can skip checking the
+	 * capability key length in such cases.
 	 *
 	 * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data will
 	 * point to a concatenation of the AES encryption key followed by a
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index e02e001325..a84cd745f9 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -619,6 +619,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
 		return "NON_BYTE_ALIGNED_DATA";
 	case RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS:
 		return "CIPHER_MULTIPLE_DATA_UNITS";
+	case RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY:
+		return "CIPHER_WRAPPED_KEY";
 	default:
 		return NULL;
 	}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index c274e208ed..a823831065 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -476,6 +476,8 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 /**< Support accelerator specific symmetric raw data-path APIs */
 #define RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS	(1ULL << 25)
 /**< Support operations on multiple data-units message */
+#define RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY		(1ULL << 26)
+/**< Support wrapped key in cipher xform  */
 
 /**
  * Get the name of a crypto device feature flag
-- 
2.25.1

Re: [dpdk-dev] [EXT] [PATCH v3] cryptodev: formalize key wrap method in API

[Akhil Goyal]

> The Key Wrap approach is used by applications in order to protect keys
> located in untrusted storage or transmitted over untrusted
> communications networks. The constructions are typically built from
> standard primitives such as block ciphers and cryptographic hash
> functions.
> 
> The Key Wrap method and its parameters are a secret between the keys
> provider and the device, means that the device is preconfigured for
> this method using very secured way.
> 
> The key wrap method may change the key length and layout.
> 
> Add a description for the cipher transformation key to allow wrapped key
> to be forwarded by the same API.
> 
> Add a new feature flag RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY to be
> enabled
> by PMDs support wrapped key in cipher trasformation.
> 
> Signed-off-by: Matan Azrad <matan@nvidia.com>
> ---
Acked-by: Akhil Goyal <gakhil@marvell.com>

I hope crypto mlx5 driver support this feature. Do not forget to add this flag
In that.
> 
> V2:
> Address Akhil coment to introduce ne feature flag for wrapped keys.
> 
> V3:
> Improve descriptions\spelling suggested by Akhil.
> 
>  doc/guides/cryptodevs/features/default.ini | 1 +
>  doc/guides/cryptodevs/overview.rst         | 3 +++
>  doc/guides/rel_notes/release_21_05.rst     | 5 +++++
>  lib/librte_cryptodev/rte_crypto_sym.h      | 8 ++++++++
>  lib/librte_cryptodev/rte_cryptodev.c       | 2 ++
>  lib/librte_cryptodev/rte_cryptodev.h       | 2 ++
>  6 files changed, 21 insertions(+)
> 
> diff --git a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 978bb30cc1..c24814de98 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -32,6 +32,7 @@ Symmetric sessionless  =
>  Non-Byte aligned data  =
>  Sym raw data path API  =
>  Cipher multiple data units =
> +Cipher wrapped key     =
> 
>  ;
>  ; Supported crypto algorithms of a default crypto driver.
> diff --git a/doc/guides/cryptodevs/overview.rst
> b/doc/guides/cryptodevs/overview.rst
> index e24e3e1993..b87c4c6a27 100644
> --- a/doc/guides/cryptodevs/overview.rst
> +++ b/doc/guides/cryptodevs/overview.rst
> @@ -49,6 +49,9 @@ Supported Feature Flags
>     - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support
> operations
>        on multiple data-units message.
> 
> +   - "CIPHER_WRAPPED_KEY" feature flag means PMD support wrapped key
> in cipher
> +      xform.
> +
> 
>  Supported Cipher Algorithms
>  ---------------------------
> diff --git a/doc/guides/rel_notes/release_21_05.rst
> b/doc/guides/rel_notes/release_21_05.rst
> index 1537fac4bc..24b8b28253 100644
> --- a/doc/guides/rel_notes/release_21_05.rst
> +++ b/doc/guides/rel_notes/release_21_05.rst
> @@ -132,6 +132,11 @@ New Features
>    data-units for AES-XTS algorithm, the data-unit length should be set in the
>    transformation. A capability for it was added too.
> 
> +* **Added a crypto PMD feature flag to support cipher wrapped keys.**
> +
> +  A new feature flag is added to allow application to provide cipher wrapped
> +  keys in session xforms.
> +
> 
>  Removed Items
>  -------------
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> b/lib/librte_cryptodev/rte_crypto_sym.h
> index 5973e31f30..a1fb5b0f5c 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -200,6 +200,14 @@ struct rte_crypto_cipher_xform {
>  		uint16_t length;	/**< key length in bytes */
>  	} key;
>  	/**< Cipher key
> +	 *
> +	 * In case the PMD supports
> RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY, the
> +	 * original key data provided may be wrapped(encrypted) using key
> wrap
> +	 * algorithm such as AES key wrap (rfc3394) and hence length of the
> key
> +	 * may increase beyond the PMD advertised supported key size.
> +	 * PMD shall validate the key length and report EMSGSIZE error while
> +	 * configuring the session and application can skip checking the
> +	 * capability key length in such cases.
>  	 *
>  	 * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data
> will
>  	 * point to a concatenation of the AES encryption key followed by a
> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> b/lib/librte_cryptodev/rte_cryptodev.c
> index e02e001325..a84cd745f9 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -619,6 +619,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
>  		return "NON_BYTE_ALIGNED_DATA";
>  	case RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS:
>  		return "CIPHER_MULTIPLE_DATA_UNITS";
> +	case RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY:
> +		return "CIPHER_WRAPPED_KEY";
>  	default:
>  		return NULL;
>  	}
> diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> b/lib/librte_cryptodev/rte_cryptodev.h
> index c274e208ed..a823831065 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -476,6 +476,8 @@ rte_cryptodev_asym_get_xform_enum(enum
> rte_crypto_asym_xform_type *xform_enum,
>  /**< Support accelerator specific symmetric raw data-path APIs */
>  #define RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS	(1ULL << 25)
>  /**< Support operations on multiple data-units message */
> +#define RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY		(1ULL << 26)
> +/**< Support wrapped key in cipher xform  */
> 
>  /**
>   * Get the name of a crypto device feature flag
> --
> 2.25.1

Re: [dpdk-dev] [EXT] [PATCH v3] cryptodev: formalize key wrap method in API

[Akhil Goyal]

> > The Key Wrap approach is used by applications in order to protect keys
> > located in untrusted storage or transmitted over untrusted
> > communications networks. The constructions are typically built from
> > standard primitives such as block ciphers and cryptographic hash
> > functions.
> >
> > The Key Wrap method and its parameters are a secret between the keys
> > provider and the device, means that the device is preconfigured for
> > this method using very secured way.
> >
> > The key wrap method may change the key length and layout.
> >
> > Add a description for the cipher transformation key to allow wrapped key
> > to be forwarded by the same API.
> >
> > Add a new feature flag RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY to be
> > enabled
> > by PMDs support wrapped key in cipher trasformation.
> >
> > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > ---
> Acked-by: Akhil Goyal <gakhil@marvell.com>
> 
> I hope crypto mlx5 driver support this feature. Do not forget to add this flag
> In that.
Applied to dpdk-next-crypto

Thanks.

Re: [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API

[Matan Azrad]

From: Akhil Goyal
> > Hi Akhil
> >
> > From: Akhil Goyal
> > > Hi Matan,
> > >
> > > > The Key Wrap approach is used by applications in order to protect
> > > > keys located in untrusted storage or transmitted over untrusted
> > > > communications networks. The constructions are typically built
> > > > from standard primitives such as block ciphers and cryptographic
> > > > hash functions.
> > > >
> > > > The Key Wrap method and its parameters are a secret between the
> > > > keys provider and the device, means that the device is
> > > > preconfigured for this method using very secured way.
> > > >
> > > > The key wrap method may change the key length and layout.
> > > >
> > > > Add a description for the cipher transformation key to allow
> > > > wrapped key to be forwarded by the same API.
> > > >
> > > > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > > > ---
> > >
> > > How will the driver gets notified whether the key is wrapped or not?
> > > The driver would expect the keys are as per the capabilities exposed.
> > > If it does not check as per the capabilities, how will it identify a
> > > bad Key len
> > and
> > > the wrapped key length?
> >
> > As I wrote, the device is preconfigured to the key wrapping mode in
> > very secured way.
> > No one knows this secret except the device and the key provider
> > (outside the crypto lib and dpdk application).
> > The driver may know something but not necessarily.
> > If the device validation to the key is failed, the driver will return
> > an error to the app.
> >
> Shouldn't this be a capability/feature flag whether it can be supported by the
> underlying Driver or not?

Makes sense to me.

> I am not saying that the driver should know the details of the wrapping mode.
> But it can be asked, whether it support this wrapping mode or not?

It can say that it support key wrapping - no more than that.

What do you think?


> 
> >
> > > >  lib/librte_cryptodev/rte_crypto_sym.h | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > > > b/lib/librte_cryptodev/rte_crypto_sym.h
> > > > index 5973e31..6aca2c7 100644
> > > > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > > > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > > > @@ -200,6 +200,13 @@ struct rte_crypto_cipher_xform {
> > > >               uint16_t length;        /**< key length in bytes */
> > > >       } key;
> > > >       /**< Cipher key
> > > > +      * The original key data may be provided wrapped (encrypted)
> > > > + using
> > > > a key
> > > > +      * wrap algorithm such as AES key wrap (from rfc3394) or other.
> > > > + In
> > > > such
> > > > +      * case, the wrapping details is a secret between the key provider and
> > > > +      * the device. Such key wrapping may increase the length of
> > > > + the
> > > > provided
> > > > +      * key beyond the advertised supported key size. Hence it is the
> > > > +      * responsibility of the driver/device to validate the length of the
> > > > +      * provided key.
> > > >        *
> > > >        * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation,
> > > > key.data will
> > > >        * point to a concatenation of the AES encryption key
> > > > followed by a
> > > > --
> > > > 1.8.3.1

Re: [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API

[Akhil Goyal]

> Hi Akhil
> 
> From: Akhil Goyal
> > Hi Matan,
> >
> > > The Key Wrap approach is used by applications in order to protect keys
> > > located in untrusted storage or transmitted over untrusted
> > > communications networks. The constructions are typically built from
> > > standard primitives such as block ciphers and cryptographic hash
> > > functions.
> > >
> > > The Key Wrap method and its parameters are a secret between the keys
> > > provider and the device, means that the device is preconfigured for
> > > this method using very secured way.
> > >
> > > The key wrap method may change the key length and layout.
> > >
> > > Add a description for the cipher transformation key to allow wrapped
> > > key to be forwarded by the same API.
> > >
> > > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > > ---
> >
> > How will the driver gets notified whether the key is wrapped or not?
> > The driver would expect the keys are as per the capabilities exposed.
> > If it does not check as per the capabilities, how will it identify a bad Key len
> and
> > the wrapped key length?
> 
> As I wrote, the device is preconfigured to the key wrapping mode in very
> secured way.
> No one knows this secret except the device and the key provider (outside the
> crypto lib and dpdk application).
> The driver may know something but not necessarily.
> If the device validation to the key is failed, the driver will return an error to
> the app.
> 
Shouldn't this be a capability/feature flag whether it can be supported by the underlying
Driver or not?

I am not saying that the driver should know the details of the wrapping mode.
But it can be asked, whether it support this wrapping mode or not?


> 
> > >  lib/librte_cryptodev/rte_crypto_sym.h | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > > b/lib/librte_cryptodev/rte_crypto_sym.h
> > > index 5973e31..6aca2c7 100644
> > > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > > @@ -200,6 +200,13 @@ struct rte_crypto_cipher_xform {
> > >               uint16_t length;        /**< key length in bytes */
> > >       } key;
> > >       /**< Cipher key
> > > +      * The original key data may be provided wrapped (encrypted)
> > > + using
> > > a key
> > > +      * wrap algorithm such as AES key wrap (from rfc3394) or other.
> > > + In
> > > such
> > > +      * case, the wrapping details is a secret between the key provider and
> > > +      * the device. Such key wrapping may increase the length of the
> > > provided
> > > +      * key beyond the advertised supported key size. Hence it is the
> > > +      * responsibility of the driver/device to validate the length of the
> > > +      * provided key.
> > >        *
> > >        * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data
> > > will
> > >        * point to a concatenation of the AES encryption key followed
> > > by a
> > > --
> > > 1.8.3.1

Re: [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API

[Matan Azrad]

Hi Akhil

From: Akhil Goyal
> Hi Matan,
> 
> > The Key Wrap approach is used by applications in order to protect keys
> > located in untrusted storage or transmitted over untrusted
> > communications networks. The constructions are typically built from
> > standard primitives such as block ciphers and cryptographic hash
> > functions.
> >
> > The Key Wrap method and its parameters are a secret between the keys
> > provider and the device, means that the device is preconfigured for
> > this method using very secured way.
> >
> > The key wrap method may change the key length and layout.
> >
> > Add a description for the cipher transformation key to allow wrapped
> > key to be forwarded by the same API.
> >
> > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > ---
> 
> How will the driver gets notified whether the key is wrapped or not?
> The driver would expect the keys are as per the capabilities exposed.
> If it does not check as per the capabilities, how will it identify a bad Key len and
> the wrapped key length?

As I wrote, the device is preconfigured to the key wrapping mode in very secured way.
No one knows this secret except the device and the key provider (outside the crypto lib and dpdk application).
The driver may know something but not necessarily.
If the device validation to the key is failed, the driver will return an error to the app.
 

> >  lib/librte_cryptodev/rte_crypto_sym.h | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > b/lib/librte_cryptodev/rte_crypto_sym.h
> > index 5973e31..6aca2c7 100644
> > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > @@ -200,6 +200,13 @@ struct rte_crypto_cipher_xform {
> >               uint16_t length;        /**< key length in bytes */
> >       } key;
> >       /**< Cipher key
> > +      * The original key data may be provided wrapped (encrypted)
> > + using
> > a key
> > +      * wrap algorithm such as AES key wrap (from rfc3394) or other.
> > + In
> > such
> > +      * case, the wrapping details is a secret between the key provider and
> > +      * the device. Such key wrapping may increase the length of the
> > provided
> > +      * key beyond the advertised supported key size. Hence it is the
> > +      * responsibility of the driver/device to validate the length of the
> > +      * provided key.
> >        *
> >        * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data
> > will
> >        * point to a concatenation of the AES encryption key followed
> > by a
> > --
> > 1.8.3.1

Re: [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API

[Akhil Goyal]

Hi Matan,

> The Key Wrap approach is used by applications in order to protect keys
> located in untrusted storage or transmitted over untrusted
> communications networks. The constructions are typically built from
> standard primitives such as block ciphers and cryptographic hash
> functions.
> 
> The Key Wrap method and its parameters are a secret between the keys
> provider and the device, means that the device is preconfigured for
> this method using very secured way.
> 
> The key wrap method may change the key length and layout.
> 
> Add a description for the cipher transformation key to allow wrapped key
> to be forwarded by the same API.
> 
> Signed-off-by: Matan Azrad <matan@nvidia.com>
> ---

How will the driver gets notified whether the key is wrapped or not?
The driver would expect the keys are as per the capabilities exposed.
If it does not check as per the capabilities, how will it identify a bad
Key len and the wrapped key length?

>  lib/librte_cryptodev/rte_crypto_sym.h | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> b/lib/librte_cryptodev/rte_crypto_sym.h
> index 5973e31..6aca2c7 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -200,6 +200,13 @@ struct rte_crypto_cipher_xform {
>  		uint16_t length;	/**< key length in bytes */
>  	} key;
>  	/**< Cipher key
> +	 * The original key data may be provided wrapped (encrypted) using
> a key
> +	 * wrap algorithm such as AES key wrap (from rfc3394) or other. In
> such
> +	 * case, the wrapping details is a secret between the key provider and
> +	 * the device. Such key wrapping may increase the length of the
> provided
> +	 * key beyond the advertised supported key size. Hence it is the
> +	 * responsibility of the driver/device to validate the length of the
> +	 * provided key.
>  	 *
>  	 * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data
> will
>  	 * point to a concatenation of the AES encryption key followed by a
> --
> 1.8.3.1