[PATCH v1] virtio-crypto: add ECDSA op parameters

[PATCH v1] virtio-crypto: add ECDSA op parameters

[Gowrishankar Muthukrishnan]

In ECDSA SIGN operation, a random scalar 'k' is used to generate
one part of signature. As this value SHOULD be randomly secure,
the application might supply it through secure RNG rather than
relying on SIGN implementation.

Another parameter is prehash algorithm to hash source data before
SIGN operation on it.

Current data queue struct for AKCIPHER do not hold any option
to input algorithm specific parameter. Hence, in this patch
new fields are introduced in data queue struct for AKCIPHER to
support additional parameters.

Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
---
 device-types/crypto/description.tex | 55 ++++++++++++++++++++++++++---
 1 file changed, 51 insertions(+), 4 deletions(-)

diff --git a/device-types/crypto/description.tex b/device-types/crypto/description.tex
index 5705e26..6ad20b8 100644
--- a/device-types/crypto/description.tex
+++ b/device-types/crypto/description.tex
@@ -1742,11 +1742,36 @@ \subsubsection{AEAD Service Operation}\label{sec:Device Types / Crypto Device /
 \end{itemize*}
 
 \subsubsection{AKCIPHER Service Operation}\label{sec:Device Types / Crypto Device / Device Operation / AKCIPHER Service Operation}
+An input for AKCIPHER operation contains one or more parameters that \field{algo} (in virtio_crypto_op_header structure) may need along with source data.
+
+ECDSA algorithm accepts the following parameters:
+
+\begin{lstlisting}
+    struct virtio_crypto_ecdsa_param_flf {
+        /* Prehash algorithm */
+        le32 prehash_algo;
+
+        /* Length of secret scalar */
+        le32 secret_scalar_len;
+    };
+
+    struct virtio_crypto_ecdsa_param_vlf {
+        /* Secret scalar */
+        u8 secret_scalar[secret_scalar_len];
+    };
+\end{lstlisting}
+
+\field{prehash_algo} is the prehash algorithm used in the ECDSA SIGN and VERIFY operations. Refer VIRTIO_CRYPTO_AKCIPHER* for the supported algorithms.
+
+\field{secret_scalar} is the secret scalar used in the ECDSA SIGN operation. The length of the secret scalar is specified in \field{secret_scalar_len}.
 
 Session mode AKCIPHER requests are as follows:
 
 \begin{lstlisting}
 struct virtio_crypto_akcipher_data_flf {
+    /* Algorithm parameters in fixed length */
+    #define VIRTIO_CRYPTO_AKCIPHER_ALGO_PARAM_SIZE 8
+    u8 algo_param_flf[VIRTIO_CRYPTO_AKCIPHER_ALGO_PARAM_SIZE];
     /* length of source data */
     le32 src_data_len;
     /* length of dst data */
@@ -1755,6 +1780,9 @@ \subsubsection{AKCIPHER Service Operation}\label{sec:Device Types / Crypto Devic
 
 struct virtio_crypto_akcipher_data_vlf {
     /* Device read only portion */
+    /* Algorithm parameters in variable length */
+    u8 algo_param_vlf[algo_param_len];
+
     /* Source data */
     u8 src_data[src_data_len];
 
@@ -1764,15 +1792,29 @@ \subsubsection{AKCIPHER Service Operation}\label{sec:Device Types / Crypto Devic
 };
 \end{lstlisting}
 
-Each data request uses the virtio_crypto_akcipher_flf structure and the virtio_crypto_akcipher_data_vlf
+Each data request uses the virtio_crypto_akcipher_data_flf structure and the virtio_crypto_akcipher_data_vlf
 structure to store information used to run the AKCIPHER operations.
 
+\field{algo_param_flf} is the \field{algo} specific fixed parameters, it MUST be one of the following structures:
+\begin{itemize*}
+    \item struct virtio_crypto_ecdsa_param_flf
+\end{itemize*}
+
+The length of the \field{algo_param_flf} is fixed to 8 bytes, the data of unused part (if has) will be ignored.
+
+\field{algo_param_vlf} is the algorithm specific variable parameters, it MUST be one of the following structures:
+\begin{itemize*}
+    \item struct virtio_crypto_ecdsa_param_vlf
+\end{itemize*}
+
+\field{algo_param_len} is the size of the specific structure used in \field{algo_param_vlf}.
+
 For encryption, decryption, and signing:
 \field{src_data} is the source data that will be processed, note that for signing operations,
 src_data stores the data to be signed, which usually is the digest of some data rather than the
 data itself.
 \field{src_data_len} is the length of source data.
-\field{dst_result} is the result data and \field{dst_data_len} is the length of it. Note that the
+\field{dst_data} is the result data and \field{dst_data_len} is the length of it. Note that the
 length of the result is not always exactly equal to dst_data_len, the driver needs to check how
 many bytes the device has written and calculate the actual length of the result.
 
@@ -1802,7 +1844,7 @@ \subsubsection{AKCIPHER Service Operation}\label{sec:Device Types / Crypto Devic
 \begin{lstlisting}
 struct virtio_crypto_akcipher_data_flf_stateless {
     struct {
-        /* See VIRTIO_CYRPTO_AKCIPHER* above */
+        /* See VIRTIO_CRYPTO_AKCIPHER* above */
         le32 algo;
         /* See VIRTIO_CRYPTO_AKCIPHER_KEY_TYPE_* above */
         le32 key_type;
@@ -1816,6 +1858,8 @@ \subsubsection{AKCIPHER Service Operation}\label{sec:Device Types / Crypto Devic
         } u;
     } sess_para;
 
+    /* Algorithm parameters in fixed length */
+    u8 algo_param_flf[VIRTIO_CRYPTO_AKCIPHER_ALGO_PARAM_SIZE];
     /* length of source data */
     le32 src_data_len;
     /* length of destination data */
@@ -1826,6 +1870,9 @@ \subsubsection{AKCIPHER Service Operation}\label{sec:Device Types / Crypto Devic
     /* Device read only portion */
     u8 akcipher_key[key_len];
 
+    /* Algorithm parameters in variable length */
+    u8 algo_param_vlf[algo_param_len];
+
     /* Source data */
     u8 src_data[src_data_len];
 
@@ -1834,7 +1881,7 @@ \subsubsection{AKCIPHER Service Operation}\label{sec:Device Types / Crypto Devic
 };
 \end{lstlisting}
 
-In stateless mode, the format of key and signature, the meaning of src_data and dst_data, are all the same
+In stateless mode, the format of key and signature, the meaning of src_data and dst_data, algorithm specific additional parameters are all the same
 with session mode.
 
 \drivernormative{\paragraph}{AKCIPHER Service Operation}{Device Types / Crypto Device / Device Operation / AKCIPHER Service Operation}
-- 
2.25.1

RE: [PATCH v1] virtio-crypto: add ECDSA op parameters

[Gowrishankar Muthukrishnan]

> 
> In ECDSA SIGN operation, a random scalar 'k' is used to generate one part of
> signature. As this value SHOULD be randomly secure, the application might
> supply it through secure RNG rather than relying on SIGN implementation.
> 
> Another parameter is prehash algorithm to hash source data before SIGN
> operation on it.
> 
> Current data queue struct for AKCIPHER do not hold any option to input
> algorithm specific parameter. Hence, in this patch new fields are introduced in
> data queue struct for AKCIPHER to support additional parameters.
> 
> Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>

Ping ?.

Regards,
Gowrishankar

RE: [PATCH v1] virtio-crypto: add ECDSA op parameters

[Gowrishankar Muthukrishnan]

Hi,
Since it has been more than a month without a review, I would like to check if there is any information missing or any comments needed. Please help. Additionally, we need to capture this feature in the specifications to support SM2 and EDDSA in a similar way.

Also opened new ticket https://github.com/oasis-tcs/virtio-spec/issues/203 if it can help us.

Thanks,
Gowrishankar

> 
> >
> > In ECDSA SIGN operation, a random scalar 'k' is used to generate one
> > part of signature. As this value SHOULD be randomly secure, the
> > application might supply it through secure RNG rather than relying on SIGN
> implementation.
> >
> > Another parameter is prehash algorithm to hash source data before SIGN
> > operation on it.
> >
> > Current data queue struct for AKCIPHER do not hold any option to input
> > algorithm specific parameter. Hence, in this patch new fields are
> > introduced in data queue struct for AKCIPHER to support additional
> parameters.
> >
> > Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> 
> Ping ?.
> 
> Regards,
> Gowrishankar

Re: [PATCH v1] virtio-crypto: add ECDSA op parameters

[Michael S. Tsirkin]

I suggest you follow
https://github.com/oasis-tcs/virtio-spec/blob/master/README.md#use-of-github-issues
to request a vote.



On Thu, Sep 05, 2024 at 12:16:44PM +0000, Gowrishankar Muthukrishnan wrote:
> Hi,
> Since it has been more than a month without a review, I would like to check if there is any information missing or any comments needed. Please help. Additionally, we need to capture this feature in the specifications to support SM2 and EDDSA in a similar way.
> 
> Also opened new ticket https://github.com/oasis-tcs/virtio-spec/issues/203 if it can help us.
> 
> Thanks,
> Gowrishankar
> 
> > 
> > >
> > > In ECDSA SIGN operation, a random scalar 'k' is used to generate one
> > > part of signature. As this value SHOULD be randomly secure, the
> > > application might supply it through secure RNG rather than relying on SIGN
> > implementation.
> > >
> > > Another parameter is prehash algorithm to hash source data before SIGN
> > > operation on it.
> > >
> > > Current data queue struct for AKCIPHER do not hold any option to input
> > > algorithm specific parameter. Hence, in this patch new fields are
> > > introduced in data queue struct for AKCIPHER to support additional
> > parameters.
> > >
> > > Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> > 
> > Ping ?.
> > 
> > Regards,
> > Gowrishankar