From patchwork Thu Sep 21 13:11:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "De Lara Guarch, Pablo" X-Patchwork-Id: 29073 X-Patchwork-Delegate: pablo.de.lara.guarch@intel.com Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9592F1B19B; Thu, 21 Sep 2017 23:11:45 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 0FC8C1AEF4 for ; Thu, 21 Sep 2017 23:11:43 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 14:11:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,426,1500966000"; d="scan'208";a="902703254" Received: from silpixa00399464.ir.intel.com (HELO silpixa00399464.ger.corp.intel.com) ([10.237.222.157]) by FMSMGA003.fm.intel.com with ESMTP; 21 Sep 2017 14:11:40 -0700 From: Pablo de Lara To: declan.doherty@intel.com, fiona.trahe@intel.com, deepak.k.jain@intel.com, john.griffin@intel.com Cc: dev@dpdk.org, Pablo de Lara Date: Thu, 21 Sep 2017 14:11:14 +0100 Message-Id: <20170921131123.16513-2-pablo.de.lara.guarch@intel.com> X-Mailer: git-send-email 2.9.4 In-Reply-To: <20170921131123.16513-1-pablo.de.lara.guarch@intel.com> References: <20170818080728.43248-1-pablo.de.lara.guarch@intel.com> <20170921131123.16513-1-pablo.de.lara.guarch@intel.com> Subject: [dpdk-dev] [PATCH v2 1/9] cryptodev: clarify API for AES-CCM X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" AES-CCM algorithm has some restrictions when handling nonce (IV) and AAD information. As the API stated, the nonce needs to be place 1 byte after the start of the IV field. This field needs to be 16 bytes long, regardless the length of the nonce, but it is important to clarify that the first byte and the padding added after the nonce may be modified by the PMDs using this algorithm. Same happens with the AAD. It needs to be placed 18 bytes after the start of the AAD field. The field also needs to be multiple of 16 bytes long and all memory reserved (the first bytes and the padding (may be modified by the PMDs). Lastly, nonce is not needed to be placed in the first 16 bytes of the AAD, as the API stated, as that depends on the PMD used, so the comment has been removed. Signed-off-by: Pablo de Lara Acked-by: Fiona Trahe --- lib/librte_cryptodev/rte_crypto_sym.h | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h index 0ceaa91..5f859ec 100644 --- a/lib/librte_cryptodev/rte_crypto_sym.h +++ b/lib/librte_cryptodev/rte_crypto_sym.h @@ -196,7 +196,9 @@ struct rte_crypto_cipher_xform { * space for the implementation to write in the flags * in the first byte). Note that a full 16 bytes should * be allocated, even though the length field will - * have a value less than this. + * have a value less than this. Note that the PMDs may + * modify the memory reserved (the first byte and the + * final padding) * * - For AES-XTS, this is the 128bit tweak, i, from * IEEE Std 1619-2007. @@ -555,20 +557,19 @@ struct rte_crypto_sym_op { * Specifically for CCM (@ref RTE_CRYPTO_AEAD_AES_CCM), * the caller should setup this field as follows: * - * - the nonce should be written starting at an offset - * of one byte into the array, leaving room for the - * implementation to write in the flags to the first - * byte. - * - * - the additional authentication data itself should + * - the additional authentication data itself should * be written starting at an offset of 18 bytes into - * the array, leaving room for the length encoding in - * the first two bytes of the second block. + * the array, leaving room for the first block (16 bytes) + * and the length encoding in the first two bytes of the + * second block. * * - the array should be big enough to hold the above - * fields, plus any padding to round this up to the - * nearest multiple of the block size (16 bytes). - * Padding will be added by the implementation. + * fields, plus any padding to round this up to the + * nearest multiple of the block size (16 bytes). + * Padding will be added by the implementation. + * + * - Note that PMDs may modify the memory reserved + * (first 18 bytes and the final padding). * * Finally, for GCM (@ref RTE_CRYPTO_AEAD_AES_GCM), the * caller should setup this field as follows: