DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>
To: "Trahe, Fiona" <fiona.trahe@intel.com>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
	"akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
	"ravi1.kumar@amd.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" <tdu@semihalf.com>,
	"lironh@marvell.com" <lironh@marvell.com>,
	"walan@marvell.com" <walan@marvell.com>,
	"g.singh@nxp.com" <g.singh@nxp.com>,
	 Hemant Agrawal <hemant.agrawal@nxp.com>,
	Jay Zhou <jianjay.zhou@huawei.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Nowak, DamianX" <damianx.nowak@intel.com>
Subject: Re: [dpdk-dev] [RFC] crypto: handling of encrypted digest
Date: Wed, 15 May 2019 00:50:56 +0000	[thread overview]
Message-ID: <06EE24DD0B19E248B53F6DC8657831551B16DBAC@hasmsx109.ger.corp.intel.com> (raw)
Message-ID: <20190515005056.cc3jP3vfhRaMD8PsVc9U3WpnYiq9bRlH29-oXyfW-kE@z> (raw)
In-Reply-To: <348A99DA5F5B7549AA880327E580B43589767D15@IRSMSX101.ger.corp.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?
> >


  parent reply	other threads:[~2019-05-15  0:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-08 17:38 Trahe, Fiona
2019-05-08 17:38 ` Trahe, Fiona
2019-05-14 13:59 ` Trahe, Fiona
2019-05-14 13:59   ` Trahe, Fiona
2019-05-15  0:50   ` Kusztal, ArkadiuszX [this message]
2019-05-15  0:50     ` Kusztal, ArkadiuszX
2019-05-15 10:58     ` Trahe, Fiona
2019-05-15 10:58       ` Trahe, Fiona

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=06EE24DD0B19E248B53F6DC8657831551B16DBAC@hasmsx109.ger.corp.intel.com \
    --to=arkadiuszx.kusztal@intel.com \
    --cc=akhil.goyal@nxp.com \
    --cc=anoobj@marvell.com \
    --cc=damianx.nowak@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=g.singh@nxp.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=jianjay.zhou@huawei.com \
    --cc=lironh@marvell.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=ravi1.kumar@amd.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=tdu@semihalf.com \
    --cc=walan@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).