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 73801A00E6 for ; Tue, 14 May 2019 15:59:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A82CF5F1A; Tue, 14 May 2019 15:59:06 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 8648E5F13 for ; Tue, 14 May 2019 15:59:05 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2019 06:59:04 -0700 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga004.jf.intel.com with ESMTP; 14 May 2019 06:59:01 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.10]) by IRSMSX103.ger.corp.intel.com ([169.254.3.133]) with mapi id 14.03.0415.000; Tue, 14 May 2019 14:59:00 +0100 From: "Trahe, Fiona" To: "Doherty, Declan" , "De Lara Guarch, Pablo" , "akhil.goyal@nxp.com" , "ravi1.kumar@amd.com" , "Jerin Jacob Kollanukkaran" , Anoob Joseph , "Zhang, Roy Fan" , "tdu@semihalf.com" , "lironh@marvell.com" , "walan@marvell.com" , "g.singh@nxp.com" , Hemant Agrawal , Jay Zhou , "dev@dpdk.org" CC: "Kusztal, ArkadiuszX" , "Nowak, DamianX" , "Trahe, Fiona" Thread-Topic: [RFC] crypto: handling of encrypted digest Thread-Index: AdUFtU8i7TKAnBkoS4yLoFp4QeD9/gEp0Dbg Date: Tue, 14 May 2019 13:59:00 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43589767D15@IRSMSX101.ger.corp.intel.com> References: <348A99DA5F5B7549AA880327E580B435897562CC@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B435897562CC@IRSMSX101.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjdlMGFlMzMtYmNkOS00YmE1LTliMjctZDdiZDkzZGE1MzVkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYkNwME1Ca0xVS1ZkdDRvdHpCcW9DZWpGSzRST1wva1pjd2l4dW1YZ2E1RG5wVDdiY0p3MzFYZ1FCMktWbkpRQ1UifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] crypto: handling of encrypted digest 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" Message-ID: <20190514135900.YY22S1gDcs22Xg3R1NpQVUkNYWTMu-ETH60VBVk0c6g@z> After discussions with Pablo and Fan we plan to go with option 1 below and add a feature flag to capabilities, so by default existing PMDs won't p= ublish support for it. We plan to push this in 19.08. > -----Original Message----- > From: Trahe, Fiona > Sent: Wednesday, May 8, 2019 6:39 PM > To: Doherty, Declan ; De Lara Guarch, Pablo > ; akhil.goyal@nxp.com; ravi1.kumar@amd.co= m; Jerin Jacob > Kollanukkaran ; Anoob Joseph ; Zh= ang, Roy Fan > ; tdu@semihalf.com; lironh@marvell.com; walan@ma= rvell.com; > g.singh@nxp.com; Hemant Agrawal ; Jay Zhou ; > dev@dpdk.org > Cc: Trahe, Fiona ; Kusztal, ArkadiuszX ; Nowak, > DamianX > Subject: [RFC] crypto: handling of encrypted digest >=20 > Hi all crypto PMD maintainers, >=20 > We're getting requests to handle the following case on symmetric crypto A= PI, needed for 5G security: > Generate digest, append to end of raw data, then encrypt the raw data= plus digest. > In opposite direction decryption returns raw data plus digest, authen= ticate > the raw data against that decrypted digest. >=20 > It's not clearly described on the cryptodev API whether this case is expe= cted to be supported or not. > Tests are throwing up some issues - specifically > - In out-of-place generate-auth-then-encrypt operations, it's necessary t= o provide space at the end of both > the source AND the destination buffer for the digest. Which should the op= .auth.digest.data refer to? > - The unencrypted digest must be just stored temporarily until finished w= ith, then zeroed, for proper > security. >=20 > I see two options for handling this: > 1. Use existing API - Document in comment under rte_crypto_sym_op.auth.di= gest.data that for encrypted > digest cases > - In encrypt direction, xform chain must specify auth generate then c= ipher encrypt > - In decrypt direction, xform chain must specify cipher decrypt then = auth verify > - digest ptr must point to where the unencrypted digest will be store= d, i.e. > end of raw data+1 in m_dst for out-of-place operation in the decr= ypt direction > end of raw data+1 in m_src for all other operations. > - for out-of-place operation there must be space for digest at end of= both m_src and m_dst > - as for any unencrypted data, the unencrypted digest will be cleared= by the PMD once no longer > needed > - cipher length >=3D auth length + digest length (Is it overkill to s= ay this? might someone want partial > digest encryption?) >=20 > 2. Extend the API with an explicit encrypted_digest flag in rte_crypto_au= th_xform. > Document usage in comment - almost same as above. EXCEPT digest ptr = should not be set, instead > PMD will assume its location as above. >=20 > Regardless of which option, should this be considered a specific feature = - with a feature capability flag? Or > are all PMDs expected to handle it and so treat as a bug or document as a= limitation if they don't? >=20 > Pros/cons: > (1) could be considered as just a clarification and no deprecation notice= needed. Test cases may work > against some existing PMDs. However the 2 PMDs we've tested so far - QAT = and aesni_mb - need patches > to work so are affected anyway. > (2) is more explicit - but may affect more PMDs - needs a deprecation not= ice. >=20 > Opinions? >=20