Re: [dpdk-dev] [RFC] crypto: handling of encrypted digest

["Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>]

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.doherty@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; akhil.goyal@nxp.com;
> ravi1.kumar@amd.com; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; tdu@semihalf.com; lironh@marvell.com;
> walan@marvell.com; g.singh@nxp.com; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Jay Zhou <jianjay.zhou@huawei.com>;
> dev@dpdk.org
> Cc: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Nowak, DamianX
> <damianx.nowak@intel.com>; Trahe, Fiona <fiona.trahe@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.doherty@intel.com>; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>; akhil.goyal@nxp.com;
> > ravi1.kumar@amd.com; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> > Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> > <roy.fan.zhang@intel.com>; tdu@semihalf.com; lironh@marvell.com;
> > walan@marvell.com; g.singh@nxp.com; Hemant Agrawal
> > <hemant.agrawal@nxp.com>; Jay Zhou <jianjay.zhou@huawei.com>;
> > dev@dpdk.org
> > Cc: Trahe, Fiona <fiona.trahe@intel.com>; Kusztal, ArkadiuszX
> > <arkadiuszx.kusztal@intel.com>; Nowak, DamianX
> > <damianx.nowak@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?
> >