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

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

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?