DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <gakhil@marvell.com>
To: Matan Azrad <matan@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
	Declan Doherty <declan.doherty@intel.com>,
	Somalapuram Amaranath <asomalap@amd.com>,
	Ruifeng Wang <ruifeng.wang@arm.com>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Anoob Joseph <anoobj@marvell.com>,
	Fan Zhang <roy.fan.zhang@intel.com>,
	John Griffin <john.griffin@intel.com>,
	Pablo de Lara <pablo.de.lara.guarch@intel.com>,
	Michael Shamis <michaelsh@marvell.com>,
	Nagadheeraj Rottela <rnagadheeraj@marvell.com>,
	Ankur Dwivedi <adwivedi@marvell.com>,
	Gagandeep Singh <g.singh@nxp.com>,
	Jay Zhou <jianjay.zhou@huawei.com>,
	ArkadiuszX Kusztal <arkadiuszx.kusztal@intel.com>,
	"sashakot@nvidia.com" <sashakot@nvidia.com>,
	"oren@nvidia.com" <oren@nvidia.com>,
	Shiri Kuzin <shirik@nvidia.com>
Subject: Re: [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API
Date: Mon, 5 Apr 2021 19:11:29 +0000	[thread overview]
Message-ID: <MW2PR18MB228464DAFEFBF9E712B80995D8779@MW2PR18MB2284.namprd18.prod.outlook.com> (raw)

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


             reply	other threads:[~2021-04-05 19:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05 19:11 Akhil Goyal [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MW2PR18MB228464DAFEFBF9E712B80995D8779@MW2PR18MB2284.namprd18.prod.outlook.com \
    --to=gakhil@marvell.com \
    --cc=adwivedi@marvell.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=akhil.goyal@nxp.com \
    --cc=anoobj@marvell.com \
    --cc=arkadiuszx.kusztal@intel.com \
    --cc=asomalap@amd.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=g.singh@nxp.com \
    --cc=jianjay.zhou@huawei.com \
    --cc=john.griffin@intel.com \
    --cc=matan@nvidia.com \
    --cc=michaelsh@marvell.com \
    --cc=oren@nvidia.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=rnagadheeraj@marvell.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=ruifeng.wang@arm.com \
    --cc=sashakot@nvidia.com \
    --cc=shirik@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).