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 <[email protected]>; De Lara Guarch, Pablo > <[email protected]>; [email protected]; > [email protected]; Jerin Jacob Kollanukkaran <[email protected]>; > Anoob Joseph <[email protected]>; Zhang, Roy Fan > <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected]; Hemant Agrawal > <[email protected]>; Jay Zhou <[email protected]>; > [email protected] > Cc: Kusztal, ArkadiuszX <[email protected]>; Nowak, DamianX > <[email protected]>; Trahe, Fiona <[email protected]> > 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 <[email protected]>; De Lara Guarch, Pablo > > <[email protected]>; [email protected]; > > [email protected]; Jerin Jacob Kollanukkaran <[email protected]>; > > Anoob Joseph <[email protected]>; Zhang, Roy Fan > > <[email protected]>; [email protected]; [email protected]; > > [email protected]; [email protected]; Hemant Agrawal > > <[email protected]>; Jay Zhou <[email protected]>; > > [email protected] > > Cc: Trahe, Fiona <[email protected]>; Kusztal, ArkadiuszX > > <[email protected]>; Nowak, DamianX > > <[email protected]> > > 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? > >
