From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
"Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>,
"Griffin, John" <john.griffin@intel.com>,
"Doherty, Declan" <declan.doherty@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Trahe, Fiona" <fiona.trahe@intel.com>
Subject: Re: [dpdk-dev] [PATCH] cryptodev: fix KASUMI F9 expected parameters
Date: Fri, 14 Jul 2017 09:31:24 +0000 [thread overview]
Message-ID: <348A99DA5F5B7549AA880327E580B43589236266@IRSMSX101.ger.corp.intel.com> (raw)
In-Reply-To: <20170713074450.63682-1-pablo.de.lara.guarch@intel.com>
Hi Pablo,
> -----Original Message-----
> From: De Lara Guarch, Pablo
> Sent: Thursday, July 13, 2017 8:45 AM
> To: Trahe, Fiona <fiona.trahe@intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Griffin,
> John <john.griffin@intel.com>; Doherty, Declan <declan.doherty@intel.com>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: [PATCH] cryptodev: fix KASUMI F9 expected parameters
>
> For KASUMI F9 algorithm, COUNT, FRESH and DIRECTION
> input values need to be contiguous with
> the message, as described in the KASUMI and QAT PMD
> documentation.
>
> Before, the COUNT and FRESH values were set
> as part of the AAD (now IV), but always set before
> the beginning of the message.
> Since now the IV is set after the crypto operation,
> it is not possible to have these values in the
> expected location.
>
> Therefore, as these are required to be contiguous,
> cryptodev API will expect these them to be passed
> as a single buffer, already constructed, so
> authentication IV parameters not needed anymore.
>
> Fixes: 681f540da52b ("cryptodev: do not use AAD in wireless algorithms")
>
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> ---
> doc/guides/cryptodevs/kasumi.rst | 19 ++-
> doc/guides/cryptodevs/qat.rst | 18 +++
> drivers/crypto/kasumi/rte_kasumi_pmd.c | 27 +---
> drivers/crypto/kasumi/rte_kasumi_pmd_ops.c | 6 +-
> drivers/crypto/kasumi/rte_kasumi_pmd_private.h | 1 -
> drivers/crypto/qat/qat_crypto.c | 13 +-
> drivers/crypto/qat/qat_crypto_capabilities.h | 6 +-
> lib/librte_cryptodev/rte_crypto_sym.h | 16 +-
> test/test/test_cryptodev.c | 173 +++++++++++++--------
> .../test/test_cryptodev_kasumi_hash_test_vectors.h | 102 +++---------
> test/test/test_cryptodev_kasumi_test_vectors.h | 72 +++++----
> 11 files changed, 226 insertions(+), 227 deletions(-)
>
> diff --git a/doc/guides/cryptodevs/kasumi.rst b/doc/guides/cryptodevs/kasumi.rst
> index bff9321..273ed18 100644
> --- a/doc/guides/cryptodevs/kasumi.rst
> +++ b/doc/guides/cryptodevs/kasumi.rst
> @@ -51,7 +51,7 @@ Limitations
> -----------
>
> * Chained mbufs are not supported.
> -* KASUMI(F9) supported only if hash offset field is byte-aligned.
> +* KASUMI(F9) supported only if hash offset and length field is byte-aligned.
> * In-place bit-level operations for KASUMI(F8) are not supported
> (if length and/or offset of data to be ciphered is not byte-aligned).
>
> @@ -108,3 +108,20 @@ Example:
> .. code-block:: console
>
> ./l2fwd-crypto -l 6 -n 4 --vdev="crypto_kasumi,socket_id=1,max_nb_sessions=128"
> +
> +Extra notes on KASUMI F9
> +------------------------
> +
> +When using KASUMI F9 authentication algorithm, the input buffer must be
> +constructed according to the 3GPP KASUMI specifications (section 4.4, page 13):
> +`<http://cryptome.org/3gpp/35201-900.pdf>`_.
> +Input buffer has to have COUNT (4 bytes), FRESH (4 bytes), MESSAGE and DIRECTION (1 bit)
> +concatenated. After the DIRECTION bit, a single '1' bit is appended, followed by
> +between 0 and 7 '0' bits, so that the total length of the buffer is multiple of 8 bits.
> +Note that the actual message can be any length, specified in bits.
> +
> +Once this buffer is passed this way, when creating the crypto operation,
> +length of data to authenticate (op.sym.auth.data.length) must be the length
> +of all the items described above, including the padding at the end.
> +Also, offset of data to authenticate (op.sym.auth.data.offset)
> +must be such that points at the start of the COUNT bytes.
> diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
> index b2d05e5..21c7f5d 100644
> --- a/doc/guides/cryptodevs/qat.rst
> +++ b/doc/guides/cryptodevs/qat.rst
> @@ -366,3 +366,21 @@ Another way to bind the VFs to the DPDK UIO driver is by using the
>
> cd to the top-level DPDK directory
> ./usertools/dpdk-devbind.py -b igb_uio 0000:03:01.1
> +
> +
> +Extra notes on KASUMI F9
> +------------------------
> +
> +When using KASUMI F9 authentication algorithm, the input buffer must be
> +constructed according to the 3GPP KASUMI specifications (section 4.4, page 13):
> +`<http://cryptome.org/3gpp/35201-900.pdf>`_.
> +Input buffer has to have COUNT (4 bytes), FRESH (4 bytes), MESSAGE and DIRECTION (1 bit)
> +concatenated. After the DIRECTION bit, a single '1' bit is appended, followed by
> +between 0 and 7 '0' bits, so that the total length of the buffer is multiple of 8 bits.
> +Note that the actual message can be any length, specified in bits.
> +
> +Once this buffer is passed this way, when creating the crypto operation,
> +length of data to authenticate (op.sym.auth.data.length) must be the length
> +of all the items described above, including the padding at the end.
> +Also, offset of data to authenticate (op.sym.auth.data.offset)
> +must be such that points at the start of the COUNT bytes.
> diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c b/drivers/crypto/kasumi/rte_kasumi_pmd.c
> index cff40fb..0e12913 100644
> --- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
> +++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
> @@ -142,12 +142,6 @@ kasumi_set_session_parameters(struct kasumi_session *sess,
>
> sess->auth_op = auth_xform->auth.op;
>
> - sess->auth_iv_offset = auth_xform->auth.iv.offset;
> - if (auth_xform->auth.iv.length != KASUMI_IV_LENGTH) {
> - KASUMI_LOG_ERR("Wrong IV length");
> - return -EINVAL;
> - }
> -
> /* Initialize key */
> sso_kasumi_init_f9_key_sched(auth_xform->auth.key.data,
> &sess->pKeySched_hash);
> @@ -274,12 +268,8 @@ process_kasumi_hash_op(struct rte_crypto_op **ops,
> unsigned i;
> uint8_t processed_ops = 0;
> uint8_t *src, *dst;
> - uint8_t *iv_ptr;
> uint32_t length_in_bits;
> uint32_t num_bytes;
> - uint32_t shift_bits;
> - uint64_t iv;
> - uint8_t direction;
>
> for (i = 0; i < num_ops; i++) {
> /* Data must be byte aligned */
> @@ -293,21 +283,15 @@ process_kasumi_hash_op(struct rte_crypto_op **ops,
>
> src = rte_pktmbuf_mtod(ops[i]->sym->m_src, uint8_t *) +
> (ops[i]->sym->auth.data.offset >> 3);
> - iv_ptr = rte_crypto_op_ctod_offset(ops[i], uint8_t *,
> - session->auth_iv_offset);
> - iv = *((uint64_t *)(iv_ptr));
> /* Direction from next bit after end of message */
> - num_bytes = (length_in_bits >> 3) + 1;
> - shift_bits = (BYTE_LEN - 1 - length_in_bits) % BYTE_LEN;
> - direction = (src[num_bytes - 1] >> shift_bits) & 0x01;
> + num_bytes = length_in_bits >> 3;
>
> if (session->auth_op == RTE_CRYPTO_AUTH_OP_VERIFY) {
> dst = (uint8_t *)rte_pktmbuf_append(ops[i]->sym->m_src,
> KASUMI_DIGEST_LENGTH);
> + sso_kasumi_f9_1_buffer(&session->pKeySched_hash, src,
> + num_bytes, dst);
>
> - sso_kasumi_f9_1_buffer_user(&session->pKeySched_hash,
> - iv, src,
> - length_in_bits, dst, direction);
> /* Verify digest. */
> if (memcmp(dst, ops[i]->sym->auth.digest.data,
> KASUMI_DIGEST_LENGTH) != 0)
> @@ -319,9 +303,8 @@ process_kasumi_hash_op(struct rte_crypto_op **ops,
> } else {
> dst = ops[i]->sym->auth.digest.data;
>
> - sso_kasumi_f9_1_buffer_user(&session->pKeySched_hash,
> - iv, src,
> - length_in_bits, dst, direction);
> + sso_kasumi_f9_1_buffer(&session->pKeySched_hash, src,
> + num_bytes, dst);
> }
> processed_ops++;
> }
> diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
> b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
> index 1d9c0fc..569a8de 100644
> --- a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
> +++ b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
> @@ -56,11 +56,7 @@ static const struct rte_cryptodev_capabilities kasumi_pmd_capabilities[] = {
> .max = 4,
> .increment = 0
> },
> - .iv_size = {
> - .min = 8,
> - .max = 8,
> - .increment = 0
> - },
> + .iv_size = { 0 },
> .aad_size = { 0 }
> }, }
> }, }
> diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
> b/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
> index 9315a79..0ce2a2e 100644
> --- a/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
> +++ b/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
> @@ -96,7 +96,6 @@ struct kasumi_session {
> enum kasumi_operation op;
> enum rte_crypto_auth_operation auth_op;
> uint16_t cipher_iv_offset;
> - uint16_t auth_iv_offset;
> } __rte_cache_aligned;
>
>
> diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
> index 7e04f21..a5e16f4 100644
> --- a/drivers/crypto/qat/qat_crypto.c
> +++ b/drivers/crypto/qat/qat_crypto.c
> @@ -1195,18 +1195,7 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t *out_msg,
> auth_ofs = op->sym->auth.data.offset >> 3;
> auth_len = op->sym->auth.data.length >> 3;
>
> - if (ctx->qat_hash_alg ==
> - ICP_QAT_HW_AUTH_ALGO_KASUMI_F9) {
> - if (do_cipher) {
> - auth_len = auth_len + auth_ofs + 1 -
> - ICP_QAT_HW_KASUMI_BLK_SZ;
> - auth_ofs = ICP_QAT_HW_KASUMI_BLK_SZ;
> - } else {
> - auth_len = auth_len + auth_ofs + 1;
> - auth_ofs = 0;
> - }
> - } else
> - auth_param->u1.aad_adr =
> + auth_param->u1.aad_adr =
> rte_crypto_op_ctophys_offset(op,
> ctx->auth_iv.offset);
>
> diff --git a/drivers/crypto/qat/qat_crypto_capabilities.h b/drivers/crypto/qat/qat_crypto_capabilities.h
> index fee8ee1..7f9135d 100644
> --- a/drivers/crypto/qat/qat_crypto_capabilities.h
> +++ b/drivers/crypto/qat/qat_crypto_capabilities.h
> @@ -429,11 +429,7 @@
> .max = 4, \
> .increment = 0 \
> }, \
> - .iv_size = { \
> - .min = 8, \
> - .max = 8, \
> - .increment = 0 \
> - }, \
> + .iv_size = { 0 }, \
> .aad_size = { 0 } \
> }, } \
> }, } \
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
> index f1b2f38..d4b403b 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -343,9 +343,8 @@ struct rte_crypto_auth_xform {
> uint16_t length;
> /**< Length of valid IV data.
> *
> - * - For KASUMI in F9 mode, SNOW3G in UIA2 mode, for
> - * ZUC in EIA3 mode and for AES-GMAC, this is the length
> - * of the IV.
> + * - For SNOW3G in UIA2 mode, for ZUC in EIA3 mode and
> + * for AES-GMAC, this is the length of the IV.
[Fiona] I think it's worth adding here:
For Kasumi in F9 mode the IV field in not used and length should be set to 0.
next prev parent reply other threads:[~2017-07-14 9:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-13 7:44 Pablo de Lara
2017-07-14 7:06 ` [dpdk-dev] [PATCH v2] " Pablo de Lara
2017-07-14 15:47 ` Trahe, Fiona
2017-07-14 16:16 ` Trahe, Fiona
2017-07-16 10:57 ` De Lara Guarch, Pablo
2017-07-14 9:31 ` Trahe, Fiona [this message]
2017-07-14 10:30 ` [dpdk-dev] [PATCH] " De Lara Guarch, Pablo
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=348A99DA5F5B7549AA880327E580B43589236266@IRSMSX101.ger.corp.intel.com \
--to=fiona.trahe@intel.com \
--cc=arkadiuszx.kusztal@intel.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=john.griffin@intel.com \
--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).