From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id E489D2BBD for ; Wed, 15 May 2019 02:51:01 +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 orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2019 17:51:00 -0700 X-ExtLoop1: 1 Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga004.jf.intel.com with ESMTP; 14 May 2019 17:51:00 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 14 May 2019 17:50:59 -0700 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 14 May 2019 17:50:59 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.177]) by HASMSX110.ger.corp.intel.com ([169.254.6.92]) with mapi id 14.03.0415.000; Wed, 15 May 2019 03:50:56 +0300 From: "Kusztal, ArkadiuszX" To: "Trahe, Fiona" , "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: "Nowak, DamianX" Thread-Topic: [RFC] crypto: handling of encrypted digest Thread-Index: AdUFtU8i7TKAnBkoS4yLoFp4QeD9/gEp0DbgABWdGTA= Date: Wed, 15 May 2019 00:50:56 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B16DBAC@hasmsx109.ger.corp.intel.com> References: <348A99DA5F5B7549AA880327E580B435897562CC@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B43589767D15@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B43589767D15@IRSMSX101.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.104.116.167] Content-Type: text/plain; charset="us-ascii" 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: , X-List-Received-Date: Wed, 15 May 2019 00:51:02 -0000 Hi Fiona, Two small things to clarify bit more. > -----Original Message----- > From: Trahe, Fiona > Sent: Tuesday, May 14, 2019 3:59 PM > 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 > Subject: RE: [RFC] crypto: handling of encrypted digest >=20 > After discussions with Pablo and Fan we plan to go with option 1 below an= d > add a feature flag to capabilities, so by default existing PMDs won't pub= lish > support for it. > We plan to push this in 19.08. >=20 > > -----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.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: Trahe, Fiona ; Kusztal, ArkadiuszX > > ; Nowak, DamianX > > > > Subject: [RFC] crypto: handling of encrypted digest > > > > Hi all crypto PMD maintainers, > > > > We're getting requests to handle the following case on symmetric crypto > API, needed for 5G security: > > Generate digest, append to end of raw data, then encrypt the raw da= ta > plus digest. > > In opposite direction decryption returns raw data plus digest, > authenticate > > the raw data against that decrypted digest. > > > > It's not clearly described on the cryptodev API whether this case is ex= pected > to be supported or not. > > Tests are throwing up some issues - specifically > > - In out-of-place generate-auth-then-encrypt operations, it's > > necessary to provide space at the end of both the source AND the > destination buffer for the digest. Which should the op.auth.digest.data r= efer > to? > > - The unencrypted digest must be just stored temporarily until > > finished with, then zeroed, for proper security. > > > > I see two options for handling this: > > 1. Use existing API - Document in comment under > > rte_crypto_sym_op.auth.digest.data that for encrypted digest cases > > - In encrypt direction, xform chain must specify auth generate then > cipher encrypt > > - In decrypt direction, xform chain must specify cipher decrypt the= n auth > verify > > - digest ptr must point to where the unencrypted digest will be sto= red, > i.e. > > end of raw data+1 in m_dst for out-of-place operation in the de= crypt > direction > > end of raw data+1 in m_src for all other operations. [AK] - By "raw data + 1" you mean "buffer ptr + auth offset + auth len +1" = ? > > - 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=20 [AK] for sure you meant this but to specify bit more : cipher offset + cipher length >=3D auth offset + auth len + digest length (Is it overkill to > > say this? might someone want partial digest encryption?) > > > > 2. Extend the API with an explicit encrypted_digest flag in > rte_crypto_auth_xform. > > Document usage in comment - almost same as above. EXCEPT digest > > ptr should not be set, instead PMD will assume its location as above. > > > > Regardless of which option, should this be considered a specific > > feature - with a feature capability flag? Or are all PMDs expected to h= andle > it and so treat as a bug or document as a limitation if they don't? > > > > 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 wor= k > so are affected anyway. > > (2) is more explicit - but may affect more PMDs - needs a deprecation > notice. > > > > Opinions? > > 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 DF4CAA00E6 for ; Wed, 15 May 2019 02:51:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C54FA4CA7; Wed, 15 May 2019 02:51:03 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id E489D2BBD for ; Wed, 15 May 2019 02:51:01 +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 orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2019 17:51:00 -0700 X-ExtLoop1: 1 Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga004.jf.intel.com with ESMTP; 14 May 2019 17:51:00 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 14 May 2019 17:50:59 -0700 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 14 May 2019 17:50:59 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.177]) by HASMSX110.ger.corp.intel.com ([169.254.6.92]) with mapi id 14.03.0415.000; Wed, 15 May 2019 03:50:56 +0300 From: "Kusztal, ArkadiuszX" To: "Trahe, Fiona" , "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: "Nowak, DamianX" Thread-Topic: [RFC] crypto: handling of encrypted digest Thread-Index: AdUFtU8i7TKAnBkoS4yLoFp4QeD9/gEp0DbgABWdGTA= Date: Wed, 15 May 2019 00:50:56 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B16DBAC@hasmsx109.ger.corp.intel.com> References: <348A99DA5F5B7549AA880327E580B435897562CC@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B43589767D15@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B43589767D15@IRSMSX101.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.104.116.167] 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: <20190515005056.cc3jP3vfhRaMD8PsVc9U3WpnYiq9bRlH29-oXyfW-kE@z> Hi Fiona, Two small things to clarify bit more. > -----Original Message----- > From: Trahe, Fiona > Sent: Tuesday, May 14, 2019 3:59 PM > 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 > Subject: RE: [RFC] crypto: handling of encrypted digest >=20 > After discussions with Pablo and Fan we plan to go with option 1 below an= d > add a feature flag to capabilities, so by default existing PMDs won't pub= lish > support for it. > We plan to push this in 19.08. >=20 > > -----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.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: Trahe, Fiona ; Kusztal, ArkadiuszX > > ; Nowak, DamianX > > > > Subject: [RFC] crypto: handling of encrypted digest > > > > Hi all crypto PMD maintainers, > > > > We're getting requests to handle the following case on symmetric crypto > API, needed for 5G security: > > Generate digest, append to end of raw data, then encrypt the raw da= ta > plus digest. > > In opposite direction decryption returns raw data plus digest, > authenticate > > the raw data against that decrypted digest. > > > > It's not clearly described on the cryptodev API whether this case is ex= pected > to be supported or not. > > Tests are throwing up some issues - specifically > > - In out-of-place generate-auth-then-encrypt operations, it's > > necessary to provide space at the end of both the source AND the > destination buffer for the digest. Which should the op.auth.digest.data r= efer > to? > > - The unencrypted digest must be just stored temporarily until > > finished with, then zeroed, for proper security. > > > > I see two options for handling this: > > 1. Use existing API - Document in comment under > > rte_crypto_sym_op.auth.digest.data that for encrypted digest cases > > - In encrypt direction, xform chain must specify auth generate then > cipher encrypt > > - In decrypt direction, xform chain must specify cipher decrypt the= n auth > verify > > - digest ptr must point to where the unencrypted digest will be sto= red, > i.e. > > end of raw data+1 in m_dst for out-of-place operation in the de= crypt > direction > > end of raw data+1 in m_src for all other operations. [AK] - By "raw data + 1" you mean "buffer ptr + auth offset + auth len +1" = ? > > - 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=20 [AK] for sure you meant this but to specify bit more : cipher offset + cipher length >=3D auth offset + auth len + digest length (Is it overkill to > > say this? might someone want partial digest encryption?) > > > > 2. Extend the API with an explicit encrypted_digest flag in > rte_crypto_auth_xform. > > Document usage in comment - almost same as above. EXCEPT digest > > ptr should not be set, instead PMD will assume its location as above. > > > > Regardless of which option, should this be considered a specific > > feature - with a feature capability flag? Or are all PMDs expected to h= andle > it and so treat as a bug or document as a limitation if they don't? > > > > 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 wor= k > so are affected anyway. > > (2) is more explicit - but may affect more PMDs - needs a deprecation > notice. > > > > Opinions? > >