Hi Arek, > -----Original Message----- > From: Kusztal, ArkadiuszX > Sent: Wednesday, May 15, 2019 1:51 AM > To: Trahe, Fiona <fiona.tr...@intel.com>; Doherty, Declan > <declan.dohe...@intel.com>; De Lara Guarch, > Pablo <pablo.de.lara.gua...@intel.com>; akhil.go...@nxp.com; > ravi1.ku...@amd.com; Jerin Jacob > Kollanukkaran <jer...@marvell.com>; Anoob Joseph <ano...@marvell.com>; Zhang, > Roy Fan > <roy.fan.zh...@intel.com>; t...@semihalf.com; lir...@marvell.com; > wa...@marvell.com; > g.si...@nxp.com; Hemant Agrawal <hemant.agra...@nxp.com>; Jay Zhou > <jianjay.z...@huawei.com>; dev@dpdk.org > Cc: Nowak, DamianX <damianx.no...@intel.com> > Subject: RE: [RFC] crypto: handling of encrypted digest > > 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 <declan.dohe...@intel.com>; De Lara Guarch, Pablo > > <pablo.de.lara.gua...@intel.com>; akhil.go...@nxp.com; > > ravi1.ku...@amd.com; Jerin Jacob Kollanukkaran <jer...@marvell.com>; > > Anoob Joseph <ano...@marvell.com>; Zhang, Roy Fan > > <roy.fan.zh...@intel.com>; t...@semihalf.com; lir...@marvell.com; > > wa...@marvell.com; g.si...@nxp.com; Hemant Agrawal > > <hemant.agra...@nxp.com>; Jay Zhou <jianjay.z...@huawei.com>; > > dev@dpdk.org > > Cc: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>; Nowak, DamianX > > <damianx.no...@intel.com>; Trahe, Fiona <fiona.tr...@intel.com> > > 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 > > publish > > 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 <declan.dohe...@intel.com>; De Lara Guarch, Pablo > > > <pablo.de.lara.gua...@intel.com>; akhil.go...@nxp.com; > > > ravi1.ku...@amd.com; Jerin Jacob Kollanukkaran <jer...@marvell.com>; > > > Anoob Joseph <ano...@marvell.com>; Zhang, Roy Fan > > > <roy.fan.zh...@intel.com>; t...@semihalf.com; lir...@marvell.com; > > > wa...@marvell.com; g.si...@nxp.com; Hemant Agrawal > > > <hemant.agra...@nxp.com>; Jay Zhou <jianjay.z...@huawei.com>; > > > dev@dpdk.org > > > Cc: Trahe, Fiona <fiona.tr...@intel.com>; Kusztal, ArkadiuszX > > > <arkadiuszx.kusz...@intel.com>; Nowak, DamianX > > > <damianx.no...@intel.com> > > > 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 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 then > > cipher encrypt > > > - In decrypt direction, xform chain must specify cipher decrypt then > > > auth > > verify > > > - digest ptr must point to where the unencrypted digest will be > > > stored, > > 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. > > [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 len". The +1 is not needed. > > > - 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 >= auth length + digest length > > [AK] for sure you meant this but to specify bit more : > cipher offset + cipher length >= auth offset + auth len + digest length [Fiona] Yes, that's better. But still doesn't answer the following question re partial digest encryption. So in case that's needed, and not to prevent it, how about: (cipher offset + cipher length) must be greater than (auth offset + auth len) and is typically (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 > > > 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. 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 > > notice. > > > > > > Opinions? > > >
