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 992F94C9D for ; Wed, 15 May 2019 12:59:28 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2019 03:59:27 -0700 X-ExtLoop1: 1 Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga005.jf.intel.com with ESMTP; 15 May 2019 03:59:25 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.10]) by IRSMSX106.ger.corp.intel.com ([169.254.8.166]) with mapi id 14.03.0415.000; Wed, 15 May 2019 11:58:57 +0100 From: "Trahe, Fiona" To: "Kusztal, ArkadiuszX" , "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" , "Trahe, Fiona" Thread-Topic: [RFC] crypto: handling of encrypted digest Thread-Index: AdUFtU8i7TKAnBkoS4yLoFp4QeD9/gEp0DbgABWdGTAAFkYpoA== Date: Wed, 15 May 2019 10:58:56 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B4358976880D@IRSMSX101.ger.corp.intel.com> References: <348A99DA5F5B7549AA880327E580B435897562CC@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B43589767D15@IRSMSX101.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B16DBAC@hasmsx109.ger.corp.intel.com> In-Reply-To: <06EE24DD0B19E248B53F6DC8657831551B16DBAC@hasmsx109.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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2QwNTJmOGYtN2ZlMi00Nzc2LThlNmEtNjQ1OTgwYmMxZDE0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZXVyN2hMb1NFUUpjSlQwZDJyVFdTSVQ4TkRUWWlQbThDWGtUQ2F0NXVWeXlRR21HNHJpRUpjTFwvbEg1STdQVTgifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.182] 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 10:59:29 -0000 Hi Arek, > -----Original Message----- > From: Kusztal, ArkadiuszX > Sent: Wednesday, May 15, 2019 1:51 AM > To: Trahe, Fiona ; Doherty, Declan ; De Lara Guarch, > Pablo ; akhil.goyal@nxp.com; ravi1.kumar@= amd.com; 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: Nowak, DamianX > Subject: RE: [RFC] crypto: handling of encrypted digest >=20 > Hi Fiona, >=20 > Two small things to clarify bit more. >=20 > > -----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 > > > > 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.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 cryp= to > > API, 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, > > authenticate > > > the raw data against that decrypted digest. > > > > > > It's not clearly described on the cryptodev API whether this case is = expected > > 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= refer > > 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 th= en > > cipher encrypt > > > - In decrypt direction, xform chain must specify cipher decrypt t= hen auth > > verify > > > - digest ptr must point to where the unencrypted digest will be s= tored, > > i.e. > > > end of raw data+1 in m_dst for out-of-place operation in the = decrypt > > direction > > > end of raw data+1 in m_src for all other operations. >=20 > [AK] - By "raw data + 1" you mean "buffer ptr + auth offset + auth len +1= " ? [Fiona] Almost. Actually, I suppose it's "buffer ptr + auth offset + auth l= en". The +1 is not needed. =20 > > > - for out-of-place operation there must be space for digest at en= d 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 [Fiona] Yes, that's better. But still doesn't answer the following question re partial digest encryptio= n. So in case that's needed, and not to prevent it, how about: (cipher offset + cipher length) must be greater than (auth offset + auth le= n) and is typically (auth offset + auth len + digest length) > (Is it overkill to > > > say this? might someone want partial digest encryption?) >=20 > > > > > > 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= handle > > 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. Howeve= r > > > the 2 PMDs we've tested so far - QAT and aesni_mb - need patches to w= ork > > 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 761A1A00E6 for ; Wed, 15 May 2019 12:59:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 962835B2A; Wed, 15 May 2019 12:59:30 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 992F94C9D for ; Wed, 15 May 2019 12:59:28 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2019 03:59:27 -0700 X-ExtLoop1: 1 Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga005.jf.intel.com with ESMTP; 15 May 2019 03:59:25 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.10]) by IRSMSX106.ger.corp.intel.com ([169.254.8.166]) with mapi id 14.03.0415.000; Wed, 15 May 2019 11:58:57 +0100 From: "Trahe, Fiona" To: "Kusztal, ArkadiuszX" , "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" , "Trahe, Fiona" Thread-Topic: [RFC] crypto: handling of encrypted digest Thread-Index: AdUFtU8i7TKAnBkoS4yLoFp4QeD9/gEp0DbgABWdGTAAFkYpoA== Date: Wed, 15 May 2019 10:58:56 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B4358976880D@IRSMSX101.ger.corp.intel.com> References: <348A99DA5F5B7549AA880327E580B435897562CC@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B43589767D15@IRSMSX101.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B16DBAC@hasmsx109.ger.corp.intel.com> In-Reply-To: <06EE24DD0B19E248B53F6DC8657831551B16DBAC@hasmsx109.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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2QwNTJmOGYtN2ZlMi00Nzc2LThlNmEtNjQ1OTgwYmMxZDE0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZXVyN2hMb1NFUUpjSlQwZDJyVFdTSVQ4TkRUWWlQbThDWGtUQ2F0NXVWeXlRR21HNHJpRUpjTFwvbEg1STdQVTgifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.182] 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: <20190515105856.8FMFEA4qwp84hDBwNC0z55NPlbnl6SqL4a8-6OoLXiE@z> Hi Arek, > -----Original Message----- > From: Kusztal, ArkadiuszX > Sent: Wednesday, May 15, 2019 1:51 AM > To: Trahe, Fiona ; Doherty, Declan ; De Lara Guarch, > Pablo ; akhil.goyal@nxp.com; ravi1.kumar@= amd.com; 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: Nowak, DamianX > Subject: RE: [RFC] crypto: handling of encrypted digest >=20 > Hi Fiona, >=20 > Two small things to clarify bit more. >=20 > > -----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 > > > > 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.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 cryp= to > > API, 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, > > authenticate > > > the raw data against that decrypted digest. > > > > > > It's not clearly described on the cryptodev API whether this case is = expected > > 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= refer > > 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 th= en > > cipher encrypt > > > - In decrypt direction, xform chain must specify cipher decrypt t= hen auth > > verify > > > - digest ptr must point to where the unencrypted digest will be s= tored, > > i.e. > > > end of raw data+1 in m_dst for out-of-place operation in the = decrypt > > direction > > > end of raw data+1 in m_src for all other operations. >=20 > [AK] - By "raw data + 1" you mean "buffer ptr + auth offset + auth len +1= " ? [Fiona] Almost. Actually, I suppose it's "buffer ptr + auth offset + auth l= en". The +1 is not needed. =20 > > > - for out-of-place operation there must be space for digest at en= d 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 [Fiona] Yes, that's better. But still doesn't answer the following question re partial digest encryptio= n. So in case that's needed, and not to prevent it, how about: (cipher offset + cipher length) must be greater than (auth offset + auth le= n) and is typically (auth offset + auth len + digest length) > (Is it overkill to > > > say this? might someone want partial digest encryption?) >=20 > > > > > > 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= handle > > 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. Howeve= r > > > the 2 PMDs we've tested so far - QAT and aesni_mb - need patches to w= ork > > so are affected anyway. > > > (2) is more explicit - but may affect more PMDs - needs a deprecation > > notice. > > > > > > Opinions? > > >