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

[Trahe, Fiona]

Hi Arek,

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