From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id B5618A00E6 for ; Thu, 13 Jun 2019 15:56:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3B7BF1D559; Thu, 13 Jun 2019 15:56:28 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 3BB691C49D for ; Thu, 13 Jun 2019 15:56:17 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2019 06:56:16 -0700 X-ExtLoop1: 1 Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga007.jf.intel.com with ESMTP; 13 Jun 2019 06:56:15 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.80]) by IRSMSX107.ger.corp.intel.com ([169.254.10.211]) with mapi id 14.03.0415.000; Thu, 13 Jun 2019 14:56:14 +0100 From: "Trahe, Fiona" To: "Nowak, DamianX" , "dev@dpdk.org" , "De Lara Guarch, Pablo" CC: "Kusztal, ArkadiuszX" , "Trahe, Fiona" , Akhil Goyal Thread-Topic: [PATCH v2 01/10] cryptodev: document usage of digest-appended operations Thread-Index: AQHVHRkdMFjtemz66EKlxt0lpA6RtaaZogrQ Date: Thu, 13 Jun 2019 13:56:14 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B4358978FBD3@IRSMSX101.ger.corp.intel.com> References: <20190603145048.2596-1-damianx.nowak@intel.com> <20190607100608.16212-1-damianx.nowak@intel.com> <20190607100608.16212-2-damianx.nowak@intel.com> In-Reply-To: <20190607100608.16212-2-damianx.nowak@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzYwMGU0YjctZTUxMy00OTIzLWEzMWYtZDhmODk4YTdlYWEzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQkJUNGhyU0hVZk1iXC9PM1wvdW1rVmVMZm9MXC91REhiU3RsWjk3Skx3SjVQVVNwZWl6Rk1GcGc2bFFPaW85NUJJWCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 01/10] cryptodev: document usage of digest-appended operations 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" Hi Damian, > -----Original Message----- > From: Nowak, DamianX > Sent: Friday, June 7, 2019 11:06 AM > To: dev@dpdk.org > Cc: Trahe, Fiona ; Kusztal, ArkadiuszX ; Nowak, > DamianX > Subject: [PATCH v2 01/10] cryptodev: document usage of digest-appended op= erations >=20 > This patch explains what are the conditions > and how to use digest appended for auth-cipher > operations. >=20 > Signed-off-by: Damian Nowak > --- > lib/librte_cryptodev/rte_crypto_sym.h | 43 +++++++++++++++++++++++++++++= ++++++ > 1 file changed, 43 insertions(+) >=20 > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev= /rte_crypto_sym.h > index c80e90e..b211bf5 100644 > --- a/lib/librte_cryptodev/rte_crypto_sym.h > +++ b/lib/librte_cryptodev/rte_crypto_sym.h > @@ -662,6 +662,49 @@ struct rte_crypto_sym_op { > * physically contiguous memory at this > * location. > * > + * @note [Fiona] I suggest adding "Digest-encrypted case." at start of this note.=20 > + * Digest can be generated, appended to > + * the end of raw data and encrypted > + * together using chained digest > + * generation > + * (@ref RTE_CRYPTO_AUTH_OP_GENERATE) > + * and encryption > + * (@ref RTE_CRYPTO_CIPHER_OP_ENCRYPT) > + * xforms. Similarly, authentication > + * of the raw data against appended, > + * decrypted digest, can be performed > + * using decryption > + * (@ref RTE_CRYPTO_CIPHER_OP_DECRYPT) > + * and digest verification > + * (@ref RTE_CRYPTO_AUTH_OP_VERIFY) > + * chained xforms. > + * To perform those operations, a few > + * additional conditions must be met: > + * - caller must allocate at least > + * digest_length of memory at the end of > + * source and (in case of out-of-place > + * operations) destination buffer; those > + * buffers can be linear or split using > + * scatter-gather lists, > + * - digest data pointer must point to > + * the end of source or (in case of > + * out-of-place operations) destination > + * data, which is pointer to the raw > + * data buffer + auth.data.offset + > + * auth.data.length, [Fiona] The word raw is confusing here - better leave it out. i.e. in auth-then-encrypt direction and OOP, the dest buffer doesn't hold r= aw data, it holds encrypted data. Copying Pablo - this is slightly different to what we suggested in RFC - ca= n you review for the aesni-mb PMD please. =20 > + * - cipher.data.offset + > + * cipher.data.length must be greater > + * than auth.data.offset + > + * auth.data.length and is typically > + * equal to auth.data.offset + > + * auth.data.length + digest_length. > + * > + * Note, that for security reasons, it > + * is PMDs' responsibility to not > + * leave an unencrypted digest in any > + * buffer after performing auth-cipher > + * operations. > + * [Fiona] below this is a separate note, which applies to all cases, not just= to digest-encrypted case so better move it back to above the digest-encrypted note > * For digest generation, the digest result > * will overwrite any data at this location. > * > -- > 2.7.4