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

["Trahe, Fiona" <fiona.trahe@intel.com>]

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