DPDK patches and discussions
 help / color / mirror / Atom feed
* Re: [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API
@ 2021-04-05 19:11 Akhil Goyal
  2021-04-06  6:20 ` Matan Azrad
  0 siblings, 1 reply; 5+ messages in thread
From: Akhil Goyal @ 2021-04-05 19:11 UTC (permalink / raw)
  To: Matan Azrad, dev
  Cc: akhil.goyal, Declan Doherty, Somalapuram Amaranath, Ruifeng Wang,
	Ajit Khaparde, Anoob Joseph, Fan Zhang, John Griffin,
	Pablo de Lara, Michael Shamis, Nagadheeraj Rottela,
	Ankur Dwivedi, Gagandeep Singh, Jay Zhou, ArkadiuszX Kusztal,
	sashakot, oren, Shiri Kuzin

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API
  2021-04-05 19:11 [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API Akhil Goyal
@ 2021-04-06  6:20 ` Matan Azrad
  2021-04-06  8:08   ` Akhil Goyal
  0 siblings, 1 reply; 5+ messages in thread
From: Matan Azrad @ 2021-04-06  6:20 UTC (permalink / raw)
  To: Akhil Goyal, dev
  Cc: akhil.goyal, Declan Doherty, Somalapuram Amaranath, Ruifeng Wang,
	Ajit Khaparde, Anoob Joseph, Fan Zhang, John Griffin,
	Pablo de Lara, Michael Shamis, Nagadheeraj Rottela,
	Ankur Dwivedi, Gagandeep Singh, Jay Zhou, ArkadiuszX Kusztal,
	Sasha Kotchubievsky, Oren Duer, Shiri Kuzin

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API
  2021-04-06  6:20 ` Matan Azrad
@ 2021-04-06  8:08   ` Akhil Goyal
  2021-04-06 10:49     ` Matan Azrad
  0 siblings, 1 reply; 5+ messages in thread
From: Akhil Goyal @ 2021-04-06  8:08 UTC (permalink / raw)
  To: Matan Azrad, dev
  Cc: akhil.goyal, Declan Doherty, Somalapuram Amaranath, Ruifeng Wang,
	Ajit Khaparde, Anoob Joseph, Fan Zhang, John Griffin,
	Pablo de Lara, Michael Shamis, Nagadheeraj Rottela,
	Ankur Dwivedi, Gagandeep Singh, Jay Zhou, ArkadiuszX Kusztal,
	Sasha Kotchubievsky, Oren Duer, Shiri Kuzin

> 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API
  2021-04-06  8:08   ` Akhil Goyal
@ 2021-04-06 10:49     ` Matan Azrad
  0 siblings, 0 replies; 5+ messages in thread
From: Matan Azrad @ 2021-04-06 10:49 UTC (permalink / raw)
  To: Akhil Goyal, dev
  Cc: akhil.goyal, Declan Doherty, Somalapuram Amaranath, Ruifeng Wang,
	Ajit Khaparde, Anoob Joseph, Fan Zhang, John Griffin,
	Pablo de Lara, Michael Shamis, Nagadheeraj Rottela,
	Ankur Dwivedi, Gagandeep Singh, Jay Zhou, ArkadiuszX Kusztal,
	Sasha Kotchubievsky, Oren Duer, Shiri Kuzin



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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API
@ 2021-03-16  6:51 Matan Azrad
  0 siblings, 0 replies; 5+ messages in thread
From: Matan Azrad @ 2021-03-16  6:51 UTC (permalink / raw)
  To: dev
  Cc: akhil.goyal, Declan Doherty, Somalapuram Amaranath, Ruifeng Wang,
	Ajit Khaparde, Anoob Joseph, Fan Zhang, John Griffin,
	Pablo de Lara, Michael Shamis, Nagadheeraj Rottela,
	Ankur Dwivedi, Gagandeep Singh, Jay Zhou, ArkadiuszX Kusztal,
	sashakot, oren, Shiri Kuzin

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-04-06 10:49 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-05 19:11 [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API Akhil Goyal
2021-04-06  6:20 ` Matan Azrad
2021-04-06  8:08   ` Akhil Goyal
2021-04-06 10:49     ` Matan Azrad
  -- strict thread matches above, loose matches on Subject: below --
2021-03-16  6:51 Matan Azrad

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).