From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
"Trahe, Fiona" <fiona.trahe@intel.com>
Subject: Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM
Date: Wed, 17 Apr 2019 11:38:03 +0000 [thread overview]
Message-ID: <348A99DA5F5B7549AA880327E580B43589743C51@IRSMSX101.ger.corp.intel.com> (raw)
Message-ID: <20190417113803.0QhOvNsbpJLOycj1DeJhrVlTXs7OAOm1KwdwxFvSvLU@z> (raw)
In-Reply-To: <20190417073641.2436-1-arkadiuszx.kusztal@intel.com>
Hi Arek,
> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, April 17, 2019 8:37 AM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH] cryptodev: add an option to support both iv and J0 for GCM
>
> This patch adds an option to support both IV (of all supported sizes)
> and J0 when using Galois Counter Mode of crypto operation.
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
> index c80e90e..126d9f3 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -152,11 +152,6 @@ struct rte_crypto_cipher_xform {
> *
> * - For block ciphers in CTR mode, this is the counter.
> *
> - * - For GCM mode, this is either the IV (if the length
> - * is 96 bits) or J0 (for other sizes), where J0 is as
> - * defined by NIST SP800-38D. Regardless of the IV
> - * length, a full 16 bytes needs to be allocated.
> - *
> * - For CCM mode, the first byte is reserved, and the
> * nonce should be written starting at &iv[1] (to allow
> * space for the implementation to write in the flags
> @@ -184,9 +179,6 @@ struct rte_crypto_cipher_xform {
> * of the counter (which must be the same as the block
> * length of the cipher).
> *
> - * - For GCM mode, this is either 12 (for 96-bit IVs)
> - * or 16, in which case data points to J0.
> - *
> * - For CCM mode, this is the length of the nonce,
> * which can be in the range 7 to 13 inclusive.
> */
> @@ -306,9 +298,10 @@ struct rte_crypto_auth_xform {
> * specified as number of bytes from start of crypto
> * operation (rte_crypto_op).
> *
> - * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
> - * for AES-GMAC, this is the authentication
> - * Initialisation Vector (IV) value.
> + * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
> + * this is the authentication Initialisation Vector
> + * (IV) value. For AES-GMAC IV description please refer
> + * to the field `length` in iv struct.
> *
> * - For KASUMI in F9 mode and other authentication
> * algorithms, this field is not used.
> @@ -325,6 +318,14 @@ struct rte_crypto_auth_xform {
> * - For KASUMI in F9 mode and other authentication
> * algorithms, this field is not used.
> *
> + * - For GMAC mode, this is either:
> + * 1) Number greater or equal to one, which means that IV
> + * is used and J0 will be computed internally, 16 bytes
> + * needs to be allocated.
[Fiona] IVs greater than 16 bytes can be used, right? If so change
to "a minimum of 16 bytes must be allocated". Same below.
> + * 2) Zero, in which case data points to J0. In this case
> + * 16 bytes of J0 should be passed where J0 is defined
> + * by NIST SP800-38D.
> + *
> */
> } iv; /**< Initialisation vector parameters */
>
> @@ -383,11 +384,6 @@ struct rte_crypto_aead_xform {
> * specified as number of bytes from start of crypto
> * operation (rte_crypto_op).
> *
> - * - For GCM mode, this is either the IV (if the length
> - * is 96 bits) or J0 (for other sizes), where J0 is as
> - * defined by NIST SP800-38D. Regardless of the IV
> - * length, a full 16 bytes needs to be allocated.
> - *
> * - For CCM mode, the first byte is reserved, and the
> * nonce should be written starting at &iv[1] (to allow
> * space for the implementation to write in the flags
> @@ -401,8 +397,13 @@ struct rte_crypto_aead_xform {
> uint16_t length;
> /**< Length of valid IV data.
> *
> - * - For GCM mode, this is either 12 (for 96-bit IVs)
> - * or 16, in which case data points to J0.
> + * - For GCM mode, this is either:
> + * 1) Number greater or equal to one, which means that IV
> + * is used and J0 will be computed internally, 16 bytes
> + * needs to be allocated.
> + * 2) Zero, in which case data points to J0. In this case
> + * 16 bytes of J0 should be passed where J0 is defined
> + * by NIST SP800-38D.
> *
> * - For CCM mode, this is the length of the nonce,
> * which can be in the range 7 to 13 inclusive.
> --
> 2.1.0
next prev parent reply other threads:[~2019-04-17 11:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 7:36 Arek Kusztal
2019-04-17 7:36 ` Arek Kusztal
2019-04-17 11:38 ` Trahe, Fiona [this message]
2019-04-17 11:38 ` Trahe, Fiona
2019-04-17 15:38 ` Kusztal, ArkadiuszX
2019-04-17 15:38 ` Kusztal, ArkadiuszX
2019-04-17 11:33 Akhil Goyal
2019-04-17 11:33 ` Akhil Goyal
2019-04-17 13:25 ` Trahe, Fiona
2019-04-17 13:25 ` Trahe, Fiona
2019-06-19 15:04 Akhil Goyal
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=348A99DA5F5B7549AA880327E580B43589743C51@IRSMSX101.ger.corp.intel.com \
--to=fiona.trahe@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=arkadiuszx.kusztal@intel.com \
--cc=dev@dpdk.org \
--cc=pablo.de.lara.guarch@intel.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).