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
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
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
> 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
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