> > > >  /**
> > > > @@ -383,22 +385,28 @@ struct rte_crypto_dh_op_param {
> > > >         /**<
> > > >          * Output generated private key when op_type is
> > > >          * DH PRIVATE_KEY_GENERATION
> > >
> > > Update with actual enum name for this as well
> > >
> > > > -        * Input when op_type is DH SHARED_SECRET_COMPUTATION.
> > > > -        *
> > > > +        * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > >          */
> > > > -       rte_crypto_uint pub_key;
> > > > +       union {
> > > > +               rte_crypto_uint pub_key;
> > > > +               struct rte_crypto_ec_point pub_point;
> > > > +       };
> > > >         /**<
> > > > -        * Output generated public key when op_type is
> > > > -        * DH PUB_KEY_GENERATION.
> > > > -        * Input peer public key when op_type is DH
> > > > -        * SHARED_SECRET_COMPUTATION
> > > > -        *
> > > > +        * Diffie-Hellman public part
> > > > +        * For DH it is big-endian unsigned integer.
> > > > +        * For ECDH it is a point on the curve.
> > > > +        * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
> > > > +        * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > >          */
> > > > -       rte_crypto_uint shared_secret;
> > > > +       union {
> > > > +               rte_crypto_uint shared_secret;
> > > > +               struct rte_crypto_ec_point shared_point;
> > > > +       };
> > > >         /**<
> > > > -        * Output with calculated shared secret
> > > > -        * when op type is SHARED_SECRET_COMPUTATION.
> > > > -        *
> > > > +        * Diffie-Hellman shared secret
> > > > +        * For DH it is big-endian unsigned integer.
> > > > +        * For ECDH it is a point on the curve.
> > > > +        * Output for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > >          */
> > >
> > > Is it output for others as well?
> > [Arek] - No, it is output for phase2 only.
> [Arek] - additionally there is still an option to split it into DH_PARAM,
> ECDH_PARAM, x25519. For secp and Edwards/Montgomery it should be ok with
> current approach but for SM2 we may need new struct.

I believe we need better documentation for asymmetric cryptography.


Reply via email to