Hi Arek, > -----Original Message----- > From: Kusztal, ArkadiuszX > Sent: Wednesday, May 15, 2019 1:51 AM > To: Trahe, Fiona <[email protected]>; 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: Nowak, DamianX <[email protected]> > Subject: RE: [RFC] crypto: handling of encrypted digest > > 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" ? [Fiona] Almost. Actually, I suppose it's "buffer ptr + auth offset + auth len". The +1 is not needed. > > > - 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 [Fiona] Yes, that's better. But still doesn't answer the following question re partial digest encryption. So in case that's needed, and not to prevent it, how about: (cipher offset + cipher length) must be greater than (auth offset + auth len) and is typically (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? > > >
