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?
