[EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Kusztal, ArkadiuszX]

Hi Anoob,

Sorry, I don't know how I have missed this email!

> -----Original Message-----
> From: Anoob Joseph <anoobj at marvell.com>
> Sent: Wednesday, May 25, 2022 9:06 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal at intel.com>; Akhil Goyal
> <gakhil at marvell.com>; dev at dpdk.org; Kiran Kumar Kokkilagadda
> <kirankumark at marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang at intel.com>; Umesh Kartha
> <ukartha at marvell.com>; Ramkumar Balu <rbalu at marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> Hi Arek, Akhil,
> 
> Please see inline.
> 
> Thanks,
> Anoob
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal at intel.com>
> > Sent: Wednesday, May 25, 2022 12:06 PM
> > To: Akhil Goyal <gakhil at marvell.com>; dev at dpdk.org; Kiran Kumar
> > Kokkilagadda <kirankumark at marvell.com>; Anoob Joseph
> > <anoobj at marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang at intel.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> >
> >
> > > -----Original Message-----
> > > From: Akhil Goyal <gakhil at marvell.com>
> > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal at intel.com>;
> > > dev at dpdk.org; Kiran Kumar Kokkilagadda <kirankumark at marvell.com>;
> > > Anoob Joseph <anoobj at marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang at intel.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > > > > > - removed asymnetric crypto xform next field.
> > > > > > Rationale behind having chaining in symmetric crypto was a
> > > > > > fact that encryption and authentication are usually done on
> > > > > > the same set of data independent of algorithm.
> > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > In asymmetric there is no such relation between algorithms,
> > > > > > therefore next field would be useless.
> > > > > >
> > > > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal at intel.com>
> > > > >
> > > > > Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > Currently supported asymmetric crypto chaining is Diffie-Hellman
> > > > > private key generation followed by public generation.
> > > > [Arek] And why do chaining when this can be done even with one bit flag.
> > > >
> > > I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob
> > > please confirm.
> > >
> > > If we are removing it, then documentation should be in sync.
> > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k' in
> > ecdsa when k.data = NULL.
> > But I do not see any situation for now it will be  useful, it may be
> > dropped later if not application found.
> > >
> > > > Also, currently API does not support chaining of
> > > > > symmetric and asymmetric crypto xforms.
> > > > [Arek] - This is one unlikely scenario to combine symmetric and
> > > > asymmetric. One I can think of was once proposed DH + DSA
> > > > integration for random number. But not much else, although we can
> > > > keep it around for a
> > > while.
> > >
> > > Yes it is highly unlikely to use this combination.
> 
> [Anoob] We may need this support when we add EdDSA support. That would
> involve a asymmetric operation after hash is generated (symmetric).
> https://en.wikipedia.org/wiki/EdDSA#Ed25519
> 
> And, asymmetric chaining may become useful when we have PMDs capable of
> doing more operations together (like the case with EdDSA). So my preference
> would be to retain the 'next' field in asym crypto xform.
[Arek] - that is very good point, however to implement EdDSA as chaining would mean that:
- we need to implement EdDSA internals in DPDK
- and EdDSA (in hash option, where actually picking hash would have sense) is not one hash but multiple hash operation, so we would have to had multiple chaining with operations in between
- and we would have to compute R and S separately.
- If PMD does not support one-pass EdDSA - well this is something that should definitely discuss, but having any crypto internals in DPDK is not probably an option?

> 
> > >
> > > > >
> > > > > > ---
> > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > >  1 file changed, 2 deletions(-)
> > > > > >
> > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa
> > > > > > 100644
> > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > >   * Structure describing asym xforms.
> > > > > >   */
> > > > > >  struct rte_crypto_asym_xform {
> > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > >  	/**< Asymmetric crypto transform */
> > > > > >
> > > > > > --
> > > > > > 2.13.6