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

Trahe, Fiona fiona.trahe at intel.com
Tue May 14 15:59:00 CEST 2019

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

More information about the dev mailing list