RE: [PATCH v6 1/6] cryptodev: add EDDSA asymmetric crypto algorithm

[Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>]

> > > > > +/**
> > > > > + * EdDSA operation params
> > > > > + */
> > > > > +struct rte_crypto_eddsa_op_param {
> > > > > +	enum rte_crypto_asym_op_type op_type;
> > > > > +	/**< Signature generation or verification */
> > > > > +
> > > > > +	rte_crypto_param message;
> > > > > +	/**< Input message digest to be signed or verified */
> > > > HashEdDSA will require a message digest; pure EdDSA will require
> > > > the message itself. For HW it will be more complicated.
> >
> > Do you mean some hardware may not have HashEdDSA support ?
> Not in full. For example: ECDSA in QAT and Octeon accepts a digest, not a
> message. So it does not support the full process, but EdDSA is more
> complicated than that because of the two hash rounds, similar to the SM2.
> 
> For now we have only OpenSSL PMD that supports it, and it accepts a
> message not a digest, so this should be changed to "message to be signed".
> 
Ack.

<cut>
> > > > All instances are using the same curve, where they differ is the
> > > > way of handling input message.
> > > > And I think this should be a session variable -> new xform for the EdDSA.
> >
> > Based on prehash and context string, these instances are listed in RFC.
> > A context string per operation helps ensure each signature is uniquely
> > tied to its specific context, thereby preventing reuse of signatures
> > across different contexts or operations.
> > Prehashing adds additional security by ensuring new prehash is
> > computed from the message.
> > Therefor it is more appropriate to treat both of these as operational
> variables.
> 
> Different 'instance' are basically different algorithms.
> 
> About the 'context' I am not sure, as not any major protocol specifies its usage
> (TLS and IKEv2 forbids PH though), But from RFC8032, it looks like it was
> defined to be used per protocol basis, or some subprotocol routine. But about
> this I am not sure.
> 
> Yet, EdDSA should not be delayed really; it is basically a network standard for
> quite a time.
> These changes may be discussed later.
> 

Sure Arkadiusz.

Regards,
Gowrishankar