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" ? > > - 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 (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? > >
