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

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

[Trahe, Fiona]

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?

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

[Trahe, Fiona]

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?

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

[Trahe, Fiona]

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

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

[Trahe, Fiona]

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

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

[Kusztal, ArkadiuszX]

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

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

[Kusztal, ArkadiuszX]

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

Re: [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@intel.com>; 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: Nowak, DamianX <damianx.nowak@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@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" ?
[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?
> > >

Re: [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@intel.com>; 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: Nowak, DamianX <damianx.nowak@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@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" ?
[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?
> > >