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