> -----Original Message-----
> From: Anoob Joseph <ano...@marvell.com>
> Sent: Friday, May 27, 2022 9:28 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>; Akhil Goyal
> <gak...@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> <kirankum...@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zh...@intel.com>; Umesh Kartha
> <ukar...@marvell.com>; Ramkumar Balu <rb...@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
>
> Hi Arek,
>
> Please see inline.
>
> Thanks,
> Anoob
>
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>
> > Sent: Friday, May 27, 2022 12:26 PM
> > To: Anoob Joseph <ano...@marvell.com>; Akhil Goyal
> > <gak...@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > <kirankum...@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zh...@intel.com>; Umesh Kartha
> > <ukar...@marvell.com>; Ramkumar Balu <rb...@marvell.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> >
> >
> > > -----Original Message-----
> > > From: Kusztal, ArkadiuszX
> > > Sent: Friday, May 27, 2022 8:40 AM
> > > To: Anoob Joseph <ano...@marvell.com>; Akhil Goyal
> > > <gak...@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > <kirankum...@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zh...@intel.com>; Umesh Kartha
> > > <ukar...@marvell.com>; Ramkumar Balu <rb...@marvell.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Kusztal, ArkadiuszX
> > > > Sent: Friday, May 27, 2022 8:31 AM
> > > > To: Anoob Joseph <ano...@marvell.com>; Akhil Goyal
> > > > <gak...@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > <kirankum...@marvell.com>
> > > > Cc: Zhang, Roy Fan <roy.fan.zh...@intel.com>; Umesh Kartha
> > > > <ukar...@marvell.com>; Ramkumar Balu <rb...@marvell.com>
> > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > next xform
> > > >
> > > > Hi Anoob,
> > > >
> > > > Sorry, I don't know how I have missed this email!
> > > >
> > > > > -----Original Message-----
> > > > > From: Anoob Joseph <ano...@marvell.com>
> > > > > Sent: Wednesday, May 25, 2022 9:06 AM
> > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>; Akhil
> > > > > Goyal <gak...@marvell.com>; dev@dpdk.org; Kiran Kumar
> > > > > Kokkilagadda <kirankum...@marvell.com>
> > > > > Cc: Zhang, Roy Fan <roy.fan.zh...@intel.com>; Umesh Kartha
> > > > > <ukar...@marvell.com>; Ramkumar Balu <rb...@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.kusz...@intel.com>
> > > > > > Sent: Wednesday, May 25, 2022 12:06 PM
> > > > > > To: Akhil Goyal <gak...@marvell.com>; dev@dpdk.org; Kiran
> > > > > > Kumar Kokkilagadda <kirankum...@marvell.com>; Anoob Joseph
> > > > > > <ano...@marvell.com>
> > > > > > Cc: Zhang, Roy Fan <roy.fan.zh...@intel.com>
> > > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > > next xform
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Akhil Goyal <gak...@marvell.com>
> > > > > > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>;
> > > > > > > dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > > > > <kirankum...@marvell.com>; Anoob Joseph <ano...@marvell.com>
> > > > > > > Cc: Zhang, Roy Fan <roy.fan.zh...@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.kusz...@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://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.
> > > > > org_wiki_EdDSA-
> > 23Ed25519&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8
> > > > > rwwviRSxyLWs2n6B-
> > WYLn1v9SyTMrT5EQqh2TU&m=bddkY8ZMMGGHjFFvgGsyhfgWB
> > > > > fuX0hpwqTdpgCAo_ngHINhO6zwLB-
> > mUxNU8xu6p&s=3vFaBffulofGlfAPsjnaaUZa
> > > > > V01o6k8XWzwNFWHQzvY&e=
> > > > >
> > > > > 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?
> > > [Arek] - but, I have kept 'next' in later changes.
> > [Arek] - additionally if EdDSAhash one-pass used it is enough to have
> > field with hash, an that's all - only information needed.
> > Normally EdDSA hash is fixed to SHA256 or BLAKE but for EdDSAhash
> > option there is one additional hash - so enum in Ed struct should be enough.
>
> [Anoob] I'm also not clear about what would be the right abstraction. As you
> described for EdDSA, it can be just a flag. But we may need to revisit this
> when
> we add such kind of algos. So my suggestion was to not remove 'next' field
> just
> yet. We can revisit this sometime later.
>
> Thanks for agreeing to the suggestion and keeping the field.
[Arek] - I considered few Ed options:
- or to have
Ed25519_op, Ed448_op,
- or
EdDSA with
Curve_is = curve25519 (29) | curve448 (30)
By default hash algorithms are SHA2-56 and BLAKE accordingly.
But for preHash Ed there would be hash field:
Hash = [ rte_crypto_auth ]
/* When preHash (PH(M)) used this field is obligatory etc... */
>
> > > >
> > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > > 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
