[V0,1/1] virtio crypto device specification: asymmetric crypto service

Commit Message

Xin Zeng Sept. 21, 2016, 5:15 a.m. UTC

This patch introduces asymmetric crypto service into virtio crypto
device. The asymmetric crypto service can be referred as signature,
verification, encryption, decryption, key generation and key exchange.
This patch depends on another virtio crypto device spec patch:
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04563.html.

Signed-off-by: Xin Zeng <[e-mail]>
---
 virtio-crypto.tex | 932 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 931 insertions(+), 1 deletion(-)

Comments

Gonglei (Arei) Sept. 21, 2016, 7:03 a.m. UTC | #1

Hi Xin,

Here you go. ;)

> -----Original Message-----
> From: Xin Zeng [mailto:[e-mail]]
> Sent: Wednesday, September 21, 2016 1:15 PM
> To: [e-mail]; [e-mail]; Gonglei (Arei)
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Huangweidong (C); Xin Zeng
> Subject: [V0 1/1] virtio crypto device specification: asymmetric crypto service
> 
> This patch introduces asymmetric crypto service into virtio crypto
> device. The asymmetric crypto service can be referred as signature,
> verification, encryption, decryption, key generation and key exchange.
> This patch depends on another virtio crypto device spec patch:
> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04563.html.
> 
> Signed-off-by: Xin Zeng <[e-mail]>
> ---
>  virtio-crypto.tex | 932
> +++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 931 insertions(+), 1 deletion(-)
> 
> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> index c3554e3..699d8dc 100644
> --- a/virtio-crypto.tex
> +++ b/virtio-crypto.tex
> @@ -46,6 +46,7 @@ struct virtio_crypto_config {
>      le32 kdf_algo;
>      le32 aead_algo;
>      le32 primitive_algo;
> +    le32 rsa_padding;

The structure doesn't 64-bit aligned now. Please add a padding.

>  };
>  \end{lstlisting}
> 
> @@ -67,6 +68,7 @@ The following services are defined:
>  #define VIRTIO_CRYPTO_SERVICE_HASH   (1) /* HASH service */
>  #define VIRTIO_CRYPTO_SERVICE_MAC    (2) /* MAC (Message
> Authentication Codes) service */
>  #define VIRTIO_CRYPTO_SERVICE_AEAD   (3) /* AEAD (Authenticated
> Encryption with Associated Data) service */
> +#define VIRTIO_CRYPTO_SERVICE_ASYM  (4) /* Asymmetric crypto service*/
>  \end{lstlisting}
> 
>  The last driver-read-only fields specify detailed algorithms masks
> @@ -140,6 +142,28 @@ The following AEAD algorithms are defined:
>  #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3
>  \end{lstlisting}
> 
> +The following asymmetric algorithms are defined:
> +
> +\begin{lstlisting}
> +#define VIRTIO_CRYPTO_ASYM_NONE        0
> +#define VIRTIO_CRYPTO_ASYM_RSA         1
> +#define VIRTIO_CRYPTO_ASYM_DSA         2
> +#define VIRTIO_CRYPTO_ASYM_DH          3
> +#define VIRTIO_CRYPTO_ASYM_ECDSA       4
> +#define VIRTIO_CRYPTO_ASYM_ECDH	       5
> +\end{lstlisting}
> +
> +The following rsa padding capabilities are defined:
> +
> +\begin{lstlisting}
> +#define VIRTIO_CRYPTO_RSA_NO_PADDING         0
> +#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING      1
> +#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING     2
> +#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING 3
> +#define VIRTIO_CRYPTO_RSA_X931_PADDING       4
> +#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING  5
> +\end{lstlisting}
> +
>  \begin{note}
>  More algorithms will be defined in the future.
>  \end{note}
> @@ -238,6 +262,18 @@ struct virtio_crypto_op_header {
>      VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
>  #define VIRTIO_CRYPTO_AEAD_DECRYPT \
>      VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> +#define VIRTIO_CRYPTO_ASYM_SIGN    \
> +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x00)
> +#define VIRTIO_CRYPTO_ASYM_VERIFY \
> +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x01)
> +#define VIRTIO_CRYPTO_ASYM_ENCRYPT  \
> +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x02)
> +#define VIRTIO_CRYPTO_ASYM_DECRYPT  \
> +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x03)
> +#define VIRTIO_CRYPTO_ASYM_KEY_GEN  \
> +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x04)
> +#define VIRTIO_CRYPTO_ASYM_KEY_EXCHG \
> +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x05)
>      le32 opcode;
>      /* algo should be service-specific algorithms */
>      le32 algo;
> @@ -540,6 +576,26 @@ struct virtio_crypto_op_data_req {
>          struct virtio_crypto_hash_data_req  hash_req;
>          struct virtio_crypto_mac_data_req   mac_req;
>          struct virtio_crypto_aead_data_req  aead_req;
> +        struct virtio_crypto_ecdsa_sign_req ecdsa_sign_req;
> +        struct virtio_crypto_dsa_sign_req dsa_sign_req;
> +        struct virtio_crypto_rsa_sign_req rsa_sign_req;
> +
> +        struct virtio_crypto_ecdsa_verify_req ecdsa_verify_req;
> +        struct virtio_crypto_dsa_verify_req dsa_verify_req;
> +        struct virtio_crypto_rsa_verify_req rsa_verify_req;
> +
> +        struct virtio_crypto_rsa_enc_req rsa_enc_req
> +        struct virtio_crypto_rsa_dec_req rsa_dec_req;
> +
> +        struct virtio_crypto_rsa_keygen_req rsa_keygen_req;
> +        struct virtio_crypto_dsa_keygen_req dsa_keygen_req;
> +        struct virtio_crypto_ec_keygen_req ec_keygen_req;
> +
> +        struct virtio_crypto_dh_keyexchg_param_gen_req
> dh_keyexchg_param_gen_req;
> +        struct virtio_crypto_dh_keyexchg_key_gen_req
> dh_keyexchg_key_gen_req;
> +        struct virtio_crypto_dh_keyexchg_key_compute_req
> dh_keyexchg_key_compute_req;
> +        struct virtio_crypto_ecdh_keyexchg_key_gen_req
> ecdh_keyexchg_key_gen_req;
> +        struct virtio_crypto_ecdh_keyexchg_key_compute_req
> ecdh_keyexchg_key_compute_req;
>      } u;
>  };
>  \end{lstlisting}
> @@ -939,4 +995,878 @@ The device MUST parse the
> virtio_crypto_aead_data_req based on the \field{op_cod
>  The device MUST copy the result of cryptographic operation to the guest
> memory recorded by \field{dst_data}.\field{addr} field in struct
> virtio_crypto_aead_input.
>  The device MUST copy the digest result to the guest memory recorded by
> \field{digest_result_addr} field in struct virtio_crypto_aead_input.
>  The device MUST set the \field{status} field in strut virtio_crypto_aead_input:
> VIRTIO_CRYPTO_OP_OK: success; VIRTIO_CRYPTO_OP_ERR: creation failed or
> device error; VIRTIO_CRYPTO_OP_NOTSUPP: not supported.
> -When the \field{op_code} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device
> MUST verify and return the verification result to the driver, and if the
> verification result is incorrect, VIRTIO_CRYPTO_OP_BADMSG (bad message)
> MUST be returned to the driver.
> \ No newline at end of file
> +When the \field{op_code} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device
> MUST verify and return the verification result to the driver, and if the
> verification result is incorrect, VIRTIO_CRYPTO_OP_BADMSG (bad message)
> MUST be returned to the driver.
> +\subsubsection{Asymmetric Crypto Service}\label{sec:Device Types / Crypto
> Device / Device Operation /
> +Crypto operation / Asymmetric Crypto Service}
> +
> +In general, asymmetric crypto service can be referred as signature,
> verification,
> +encryption, decryption, key generation and key exchange. Not each algorithm
> supports
> +all these services.
> +
> +Unlike symmetric crypto service, asymmetric crypto service normally does't
> +need session operations, the request is encapsulated within one packet which
> is represented
> +by \field{virtio_crypto_op_data_req}.
> +(see \ref{sec:Device Types / Crypto Device / Device Operation / Data
> Virtqueue}).
> +
> +Once service request is handled by the device, the device writes back the
> operation results to the corresponding
> +fields in the request packet.
> +
> +\paragraph{General Device Requirements: Asymmetric Crypto
> Service}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}

If they are requirements, please use unified \devicenormative{\paragraph}{ Asymmetric Crypto Service}...

> +The device SHOULD parse the field \field{opcode} within
> \field{virtio_crypto_op_header} then handle the corresponding service request.
> +
> +The device SHOULD set the operation status in field \field{status} within
> \field{idata}.
> +
> +The device SHOULD write back the operation result to the iovec buffer, which
> is represented by \field{virtio_crypto_iovec} within \field{idata} if the operation
> is successful.
> +
> +\paragraph{General Driver Requirements: Asymmetric Crypto
> Service}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}

Please use \drivernormative{\paragraph}...
You'd better go over the whole patch about this point :)

> +The driver SHOULD set the corresponding \field{opcode} in
> \field{virtio_crypto_op_header} according to different services.
> +
> +The driver SHOULD offers operatable iovec buffer represented by
> \field{virtio_crypto_iovec} within \field{idata} if the service request structure
> defines.
> +
> +\paragraph{Signature: ECDSA signature operation}\label{sec:Device Types /
> Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}

The above label is incorrect. It should be:

{sec:Device Types / Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service / Signature: ECDSA signature operation}

So that we can identify the section by label. The same with below labels, need to be fiexed.

> +
> +\begin{lstlisting}
> +struct virtio_crypto_ec_group {
> +    struct virtio_crypto_iovec xg;
> +    struct virtio_crypto_iovec yg;
> +    struct virtio_crypto_iovec n;
> +    struct virtio_crypto_iovec q;
> +    struct virtio_crypto_iovec a;
> +    struct virtio_crypto_iovec b;
> +    struct virtio_crypto_iovec h;
> +};
> +
> +typedef enum {
> +    VIRTIO_CRYPTO_EC_FIELD_TYPE_PRIME,
> +    VIRTIO_CRYPTO_EC_FIELD_TYPE_BINARY
> +} VIRTIO_CRYPTO_EC_FIELD_TYPE;
> +
> +struct virtio_crypto_ecdsa_sign_para{
> +    /* Hash alogrithms applied to msg */
> +    le32 hash_algo;
> +    le32 reserved;
> +    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
> +
> +    /* EC Group parameters */
> +    struct virtio_crypto_ec_group ec;
> +    /* Random value */
> +    struct virtio_crypto_iovec k;
> +    /* Private Key */
> +    struct virtio_crypto_iovec d;
> +};
> +
> +struct virtio_crypto_ecdsa_sign_output {
> +    /* Message need to be signed */
> +    struct virtio_crypto_iovec msg;
> +};
> +
> +struct virtio_crypto_ecdsa_sign_input {
> +    /* operation result */
> +    le32 status;
> +    le32 reserved;
> +
> +    /* signature result */
> +    struct virtio_crypto_iovec r;
> +    struct virtio_crypto_iovec s;
> +};
> +\end{lstlisting}
> +
> +ECDSA signature operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_ecdsa_sign_req {
> +    struct virtio_crypto_ecdsa_sign_para parameter;
> +    struct virtio_crypto_ecdsa_sign_output odata;
> +
> +    struct virtio_crypto_ecdsa_sign_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: ECDSA signature
> operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: ECDSA signature
> operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_SIGN,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDSA.
> +
> +The driver SHOULD set all fields in \field{parameter} and \field{odata} except
> field \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it operates other fields in \field{idata}.
> +Only if the operation is successful, the \field{r,s} in \field{idata} are operatable.

\field{r,s} ? Is't legal?

> +
> +\paragraph{Signature: DSA signature operation}\label{sec:Device Types /
> Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_dsa_group {
> +    struct virtio_crypto_iovec p;
> +    struct virtio_crypto_iovec q;
> +    struct virtio_crypto_iovec g;
> +};
> +
> +struct virtio_crypto_dsa_sign_para {
> +    /* Hash alogrithms applied to msg */
> +    le32 hash_algo;
> +    le32 reserved;
> +
> +    /* DSA group parameter */
> +    struct virtio_crypto_dsa_group dsa;
> +    /* Random value */
> +    struct virtio_crypto_iovec k;
> +    /* Private Key */
> +    struct virtio_crypto_iovec x;
> +};
> +
> +struct virtio_crypto_dsa_sign_output {
> +    struct virtio_crypto_iovec msg;
> +};
> +
> +struct virtio_crypto_dsa_sign_input  {
> +    /* operation result */
> +    le32 status;
> +    le32 reserved;
> +
> +    /* signature result */
> +    struct virtio_crypto_iovec r;
> +    struct virtio_crypto_iovec s;
> +};
> +\end{lstlisting}
> +DSA signature operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_dsa_sign_req {
> +    struct virtio_crypto_dsa_sign_para parameter;
> +    struct virtio_crypto_dsa_sign_output odata;
> +
> +    struct virtio_crypto_dsa_sign_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: DSA signature
> operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: DSA signature
> operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_SIGN,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_DSA.
> +
> +The driver SHOULD set all fields in \field{parameter} and \field{odata} except
> field \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it operates other fields in \field{idata}.
> +Only if the operation is successful, the \field{r,s} in \field{idata} are operatable.
> +

I think s/SHOULD/MUST/ is more appropriate. Isn't it?

> +\paragraph{Signature: RSA signature operation}\label{sec:Device Types /
> Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_rsa_pub_key{
> +    /* The RSA modules */
> +    struct virtio_crypto_iovec n;
> +    /* The RSA public exponent */
> +    struct virtio_crypto_iovec e;
> +};
> +
> +struct virtio_crypto_rsa_priv_key_rep1{
> +    /* The RSA modules */
> +    struct virtio_crypto_iovec n;
> +    /* The RSA private exponent */
> +    struct virtio_crypto_iovec d;
> +};
> +
> +struct virtio_crypto_rsa_priv_key_rep2{
> +    /* The first factor */
> +    struct virtio_crypto_iovec p;
> +    /* The second factor */
> +    struct virtio_crypto_iovec q;
> +    /* The first factor's CRT exponent */
> +    struct virtio_crypto_iovec dp;
> +    /* The second factor's CRT exponent */
> +    struct virtio_crypto_iovec dq;
> +    /* The first CRT coeffieient */
> +    struct virtio_crypto_iovec qinv;
> +    /* The factors array when prime_number > 2 */
> +    struct virtio_crypto_iovec r[];
> +    /* The CRT exponent array when prime_number > 2 */
> +    struct virtio_crypto_iovec d[];
> +    /* The CRT coeffieient array when prime_number > 2 */
> +    struct virtio_crypto_iovec t[];
> +};
> +
> +struct virtio_crypto_rsa_priv_key {
> +    le32 prime_number;
> +#define VIRTIO_CRYPTO_RSA_PRIV_KEY_REPTYPE1 0
> +#define VIRTIO_CRYPTO_RSA_PRIV_KEY_REPTYPE2 1
> +    le32 priv_key_rep_type;
> +    union {
> +        struct virtio_crypto_rsa_priv_key_rep1 privkey_rep1;
> +        struct virtio_crypto_rsa_priv_key_rep2 privkey_rep2;
> +    }key;
> +};
> +
> +struct virtio_crypto_rsa_sign_para {
> +    /* Hash alogrithms applied to msg */
> +    le32 hash_algo;
> +    le32 padding_mode;
> +    struct virtio_crypto_rsa_priv_key priv_key;
> +};
> +
> +struct virtio_crypto_rsa_sign_output {
> +    struct virtio_crypto_iovec msg;
> +};
> +
> +struct virtio_crypto_rsa_sign_input {
> +    le32 status;
> +    le32 reserved;
> +
> +    struct virtio_crypto_iovec signature;
> +};
> +\end{lstlisting}
> +
> +RSA signature operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_rsa_sign_req {
> +    struct virtio_crypto rsa_sign_para parameter;
> +    struct virtio_crypto rsa_sign_output odata;
> +
> +    struct virtio_crypto rsa_sign_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: RSA signature
> operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: RSA signature
> operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_SIGN,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> +
> +The driver SHOULD set all fields in \field{parameter} and \field{odata} except
> field \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it operates other fields in \field{idata}.
> +Only if the operation is successful, the \field{signature} in \field{idata} is
> operatable.
> +
> +\paragraph{Verification: Common Structure}\label{sec:Device Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +The result of verification operation can be represented by structure
> \field{virtio_crypto_asym_verify_gen_input}.
> +
> +\begin{lstlisting}
> +struct virtio_crypto_asym_verify_gen_input {
> +    /* Operation result */
> +    le32 status;
> +    /* Verification result */
> +#define VIRTIO_CRYPTO_ASYM_VERIFY_SUCCESS 0
> +#define VIRTIO_CRYPTO_ASYM_VERIFY_FAIL -1

Why not use the following generic results?

#define VIRTIO_CRYPTO_OP_OK        0
#define VIRTIO_CRYPTO_OP_ERR       1
#define VIRTIO_CRYPTO_OP_BADMSG    2

And the VIRTIO_CRYPTO_OP_BADMSG is used to show the verification result is incorrect.

> +    le32 verify_result;
> +};
> +\end{lstlisting}
> +
> +\paragraph{Verification: ECDSA Verification Operation}\label{sec:Device Types
> /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_ecdsa_verify_para {
> +    /* Hash alogrithms applied to msg */
> +    le32 hash_algo;
> +    le32 reserved;
> +
> +    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
> +    /* EC Group parameters */
> +    struct virtio_crypto_ec_group ec;
> +
> +    /* Public key */
> +    struct virtio_crypto_iovec x;
> +    struct virtio_crypto_iovec y;
> +};
> +
> +struct virtio_crypto_ecdsa_verify_output {
> +    /* Signature value */
> +    struct virtio_crypto_iovec r;
> +    struct virtio_crypto_iovec s;
> +
> +    struct virtio_crypto_iovec msg;
> +};
> +\end{lstlisting}
> +
> +ECDSA Verification Operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_ecdsa_verify_req {
> +    struct virtio_crypto_ecdsa_verify_para parameter;
> +    struct virtio_crypto_ecdsa_verify_output odata;
> +
> +    struct virtio_crypto_asym_verify_gen_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: ECDSA Verification
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: ECDSA Verification
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_VERIFY,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDSA.
> +
> +The driver SHOULD set all fields in \field{parameter} and \field{odata} except
> field \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it checks \field{verify_result}.
> +
> +\paragraph{Verification: DSA Verification Operation}\label{sec:Device Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_dsa_verify_para {
> +    le32 hash_algo;
> +    le32 reserved;
> +
> +    /* DSA Group parameters */
> +    struct virtio_crypto_dsa_group dsa;
> +
> +    /* Public key */
> +    struct virtio_crypto_iovec y;
> +};
> +
> +struct virtio_crypto_dsa_verify_output {
> +    /* Signature value */
> +    struct virtio_crypto_iovec r;
> +    struct virtio_crypto_iovec s;
> +
> +    struct virtio_crypto_iovec msg;
> +};
> +\end{lstlisting}
> +
> +DSA Verification Operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_dsa_verify_req {
> +    struct virtio_crypto_dsa_verify_para parameter;
> +    struct virtio_crypto_dsa_verify_output odata;
> +
> +    struct virtio_crypto_asym_verify_gen_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: DSA Verification
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata}.
> +
> +\subparagraph{Driver Requirements: DSA Verification
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_VERIFY,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_DSA.
> +
> +The driver SHOULD set all fields in \field{parameter} and \field{odata} except
> field \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it checks \field{verify_result}.
> +
> +\paragraph{Verification: RSA Verification Operation}\label{sec:Device Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_rsa_verify_para {
> +    le32 hash_algo;
> +    le32 padding_mode;
> +    struct virtio_crypto_rsa_pub_key pubkey;
> +};
> +
> +struct virtio_crypto_rsa_verify_output {
> +    struct virtio_crypto_iovec msg;
> +};
> +\end{lstlisting}
> +
> +RSA verification operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_rsa_verify_req {
> +    struct virtio_crypto_rsa_verify_para parameter;
> +    struct virtio_crypto_rsa_verify_output odata;
> +
> +    struct virtio_crypto_asym_verify_gen_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: RSA Verification
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata}.
> +
> +\subparagraph{Driver Requirements: RSA Verification
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_VERIFY,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> +
> +The driver SHOULD set all fields in \field{parameter} and \field{odata} except
> field \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it checks \field{verify_result}.
> +
> +\paragraph{Encryption: RSA Encryption Operation}\label{sec:Device Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_rsa_enc_para {
> +    le32 padding_mode;
> +    le32 reserved;
> +    struct rsa_pub_key pub_key;
> +};
> +
> +struct virtio_crypto_rsa_enc_output {
> +    struct virtio_crypto_iovec msg;
> +};
> +
> +struct virtio_crypto_rsa_enc_input {
> +    le32 status;
> +    le32 reserved;
> +
> +    struct virtio_crypto_iovec cmsg;
> +};
> +\end{lstlisting}
> +
> +RSA encryption operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_rsa_enc_req {
> +    struct virtio_crypto_rsa_enc_para parameter;
> +    struct virtio_crypto_rsa_enc_output odata;
> +
> +    struct virtio_crypto_rsa_enc_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: RSA Encryption
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: RSA Encryption
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_ENCRYPT,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> +
> +The driver SHOULD set all fields in \field{parameter} and \field{odata} except
> field \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it operates other fields in \field{idata}.
> +Only if the operation is successful, the \field{cmsg} in \field{idata} is
> operatable.
> +
> +\paragraph{Decryption: RSA Decryption Operation}\label{sec:Device Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_rsa_dec_para {
> +    le32 padding_mode;
> +    le32 reserved;
> +    struct virtio_crypto_rsa_priv_key priv_key;
> +};
> +
> +struct virtio_crypto_rsa_dec_output {
> +    struct virtio_crypto_iovec cmsg;
> +}
> +
> +struct virtio_crypto_rsa_dec_input {
> +    le32 status;
> +    le32 reserved;
> +
> +    struct virtio_crypto_iovec msg;
> +};
> +\end{lstlisting}
> +
> +RSA decryption operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_rsa_dec_req {
> +    struct virtio_crypto_rsa_dec_para parameter;
> +    struct virtio_crypto_rsa_dec_output odata;
> +
> +    struct virtio_crypto_rsa_dec_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: RSA Decryption
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: RSA Decryption
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_DECRYPT,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> +
> +The driver SHOULD set all fields in \field{parameter} and \field{odata} except
> field \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it operates other fields in \field{idata}.
> +Only if the operation is successful, the \field{msg} in \field{idata} is operatable.
> +
> +\paragraph{Key Generation: RSA Key Generation Operation}\label{sec:Device
> Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_rsa_keygen_para {
> +    /* The modules length in bytes */
> +    le32 modulus_len;
> +    le32 rsa_prime_number;
> +    le32 priv_key_rep_type;
> +    le32 reserved;
> +
> +    /* the public exponent */
> +    struct virtio_crypto_iovec e;
> +};
> +
> +struct virtio_crypto_rsa_keygen_input {
> +    le32 status;
> +    le32 reserved;
> +
> +    struct virtio_crypto_rsa_priv_key priv_key;
> +    struct virtio_crypto_rsa_pub_key pub_key;
> +};
> +\end{lstlisting}
> +
> +RSA key-generation operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_rsa_keygen_req {
> +    struct virtio_crypto_rsa_keygen_para parameter;
> +
> +    struct virtio_crypto_rsa_keygen_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: RSA Key Generation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: RSA Key Generation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_KEY_GEN,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> +
> +The driver SHOULD set all fields in \field{parameter} except \field{reserved}
> field.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it operates other fields in \field{idata}.
> +Only if the operation is successful, the \field{priv_key} and \field{pub_key} in
> \field{idata} are operatable.
> +
> +\paragraph{Key Generation: DSA Key Generation operation}\label{sec:Device
> Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_dsa_keygen_para {
> +    le32 modulus_len;
> +    le32 reserved;
> +};
> +
> +struct virtio_crypto_dsa_keygen_input {
> +    le32 status;
> +    le32 reserved;
> +
> +    /* DSA Group parameters */
> +    struct virtio_crypto_dsa_group dsa;
> +    /* Private key */
> +    struct virtio_crypto_iovec x;
> +    /* Public key */
> +    struct virtio_crypto_iovec y;
> +};
> +\end{lstlisting}
> +
> +DSA key-generation operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_dsa_keygen_req {
> +    struct virtio_crypto_dsa_keygen_para parameter;
> +
> +    struct virtio_crypto_dsa_keygen_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: DSA Key Generation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: DSA Key Generation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_KEY_GEN,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_DSA.
> +
> +The driver SHOULD set all fields in \field{parameter} except \field{reserved}
> field.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it operates other fields in \field{idata}.
> +Only if the operation is successful, the \field{priv_key} and \field{pub_key} in
> \field{idata} are operatable.
> +
> +\paragraph{Key Generation: EC Key Generation operation }\label{sec:Device
> Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_ec_keygen_para {
> +    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
> +
> +    /* EC group parameters */
> +    struct virtio_crypto_ec_group ec;
> +};
> +
> +struct virtio_crypto_ec_keygen_input {
> +    le32 status;
> +    le32 reserved;
> +
> +    /* Private key */
> +    struct virtio_crypto_iovec d;
> +
> +    /* Public key */
> +    struct virtio_crypto_iovec x;
> +    struct virtio_crypto_iovec y;
> +};
> +\end{lstlisting}
> +
> +EC key-generation operation request is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_ec_keygen_req {
> +    struct virtio_crypto_ec_keygen_para parameter;
> +
> +    struct virtio_crypto_ec_keygen_input key;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: EC Key Generation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: EC Key Generation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_KEY_GEN,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDH or
> VIRTIO_CRYPTO_ASYM_ECDSA.
> +
> +The driver SHOULD set all fields in \field{parameter} except \field{reserved}
> field.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> before it operates other fields in \field{idata}.
> +Only if the operation is successful, the other fields in \field{idata} are
> operatable.
> +
> +\paragraph{Key Exchange: Common Structure}\label{sec:Device Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +Key Exchange request has two kinds of operations in general, key generation
> and key computation.
> +For DH, it has additional operation: parameter generation operation.
> +
> +\begin{lstlisting}
> +typdef enum VIRTIO_CRYPTO_KEY_EXCHANGE_OP {
> +    VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_KEY,
> +    VIRTIO_CRYPTO_KEY_EXCHANGE_COMPUTE_KEY,
> +    /* It's only valid in case algorithm is DH */
> +    VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_DH_PARAM
> +} VIRTIO_CRYPTO_KEY_EXCHANGE_OP;
> +\end{lstlisting}
> +
> +\paragraph{Key Exchange: DH Parameter Generation
> Operation}\label{sec:Device Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_dh_parameter {
> +    le32 modules_len;
> +    le32 reserved;
> +
> +    /* random odd prime number */
> +    struct virtio_crypto_iovec p;
> +    /* base (g) */
> +    struct virtio_crypto_iovec g;
> +};
> +
> +struct virtio_crypto_dh_keyexchg_para {
> +    VIRTIO_CRYPTO_KEY_EXCHANGE_OP keyexchg_op;

sizeof(enum foo) is implementation-specific according to the C standard.
You must explicitly choose a type (u8, le16, le32) in this specification
so that the struct layout is compatible between compilers.

You can move keyexchg_op to struct virtio_crypto_dh_parameter, 
instead of the reserved property.

> +    struct virtio_crypto_dh_parameter dh_param;
> +};
> +
> +struct virtio_crypto_dh_keyexchg_param_gen_input {
> +    le32 status;
> +    le32 reserved;
> +};
> +\end{lstlisting}
> +
> +DH Parameter Generation Operation in Key-Exchange is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_dh_keyexchg_param_gen_req {
> +    struct virtio_crypto_dh_keyexchg_para parameter;
> +
> +    struct virtio_crypto_dh_keyexchg_param_gen_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: Key Exchange: DH Parameter
> Generation Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation result in \field{idata}, and set \field{p
> and g} in \field{dh_param}.
> +
> +\subparagraph{Driver Requirements: Key Exchange: DH Parameter
> Generation Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_KEY_EXCHG,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_DH.
> +
> +The driver SHOULD set the \field{keyexchg_op} to
> VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_DH_PARAM in \field{parameter}.
> +The driver SHOULD set \field{modules_len} in \field{dh_param}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> firstly.
> +Only if the operation is successful, the other fields in \field{idata} are
> operatable.
> +
> +\paragraph{Key Exchange: DH Key Generation Operation}\label{sec:Device
> Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_dh_keyexchg_keygen_input {
> +    le32 status;
> +    le32 reserved;
> +
> +    /* private key */
> +    struct virtio_crypto_iovec x;
> +    /* public key */
> +    struct virtio_crypto_iovec y;
> +};
> +\end{lstlisting}
> +
> +DH Key Generation Operation in Key-Exchange is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_dh_keyexchg_key_gen_req {
> +    struct virtio_crypto_dh_keyexchg_para parameter;
> +
> +    struct virtio_crypto_dh_key_exchg_keygen_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: Key Exchange: DH Key Generation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: Key Exchange: DH Key Generation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_KEY_EXCHG,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_DH.
> +
> +The driver SHOULD set the \field{keyexchg_op} to
> VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_KEY in \field{parameter}.
> +
> +The driver SHOULD set all other fields in \field{parameter} except field
> \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> firstly.
> +Only if the operation is successful, the other fields in \field{idata} are
> operatable.
> +
> +\paragraph{Key Exchange: DH Key Computation Operation}\label{sec:Device
> Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_dh_keyexchg_compute_key_output {
> +    /* local private key */
> +    struct virtio_crypto_iovec x;
> +    /* peer's public key */
> +    struct virtio_crypto_iovec y;
> +};
> +
> +struct virtio_crypto_dh_keyexchg_compute_key_input {
> +    le32 status;
> +    le32 reserved;
> +
> +    struct virtio_crypto_iovec shared_secret;
> +};
> +\end{lstlisting}
> +
> +DH Key Computation Operation in Key-Exchange is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_dh_keyexchg_key_compute_req {
> +    struct virtio_crypto_dh_keyexchg_para parameter;
> +    struct virtio_crypto_dh_keyexchg_compute_key_output odata;
> +
> +    struct virtio_crypto_dh_keyexchg_compute_key_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: Key Exchange: DH Key Computation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: Key Exchange: DH Key Computation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_KEY_EXCHG,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_DH.
> +
> +The driver SHOULD set the \field{keyexchg_op} to
> VIRTIO_CRYPTO_KEY_EXCHANGE_COMPUTE_KEY in \field{parameter}.
> +
> +The driver SHOULD set all other fields in \field{parameter} except field
> \field{reserved}.
> +
> +The driver SHOULD set all fields in \field{odata} except field \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> firstly.
> +Only if the operation is successful, the other fields in \field{idata} are
> operatable.
> +
> +\paragraph{Key Exchange: ECDH Key Generation Operation}\label{sec:Device
> Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_ecdh_keyexchg_keygen_para {
> +    VIRTIO_CRYPTO_KEY_EXCHANGE_OP keyexchg_op;
> +    struct virtio_crypto_ec_keygen_para parameter;
> +};
> +\end{lstlisting}
> +
> +ECDH Key Generation Operation in Key-Exchange is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_ecdh_keyexchg_key_gen_req {
> +    struct virtio_crypto_ecdh_keyexchg_keygen_para parameter;
> +
> +    struct virtio_crypto_ec_keygen_input idata;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Device Requirements: Key Exchange: ECDH Key Generation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: Key Exchange: DH Key Generation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_KEY_EXCHG,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDH.
> +
> +The driver SHOULD set the \field{keyexchg_op} to
> VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_KEY in \field{parameter}.
> +
> +The driver SHOULD set all other fields in \field{parameter} except field
> \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> firstly.
> +Only if the operation is successful, the other fields in \field{idata} are
> operatable.
> +
> +\paragraph{Key Exchange: ECDH Key Computation
> Operation}\label{sec:Device Types /
> +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> Service}
> +
> +\begin{lstlisting}
> +struct virtio_crypto_ecdh_keyexchg_compute_key_para {
> +    VIRTIO_CRYPTO_KEY_EXCHANGE_OP keyexchg_op;
> +    struct virtio_crypto_ec_keygen_para parameter;
> +};
> +
> +struct virtio_crypto_ecdh_keyexchg_compute_key_output {
> +    /* local private key */
> +    struct virtio_crypto_iovec d;
> +
> +    /* peer's public key */
> +    struct virtio_crypto_iovec x;
> +    struct virtio_crypto_iovec y;
> +};
> +
> +struct virtio_crypto_ecdh_keyexchg_compute_key_input {
> +    le32 status;
> +    le32 reserved;
> +
> +    struct virtio_crypto_iovec shared_secret;
> +};
> +\end{lstlisting}
> +
> +ECDH Key Computation Operation in Key-Exchange is defined as below:
> +\begin{lstlisting}
> +struct virtio_crypto_ecdh_keyexchg_key_compute_req {
> +    struct virtio_crypto_ecdh_keyexchg_compute_key_para parameter;
> +    struct virtio_crypto_ecdh_keyexchg_compute_key_output odata;
> +
> +    struct virtio_crypto_ecdh_keyexchg_compute_key_input idata;
> +};
> +\end{lstlisting}
> +
> +
> +\subparagraph{Device Requirements: Key Exchange: ECDH Key Computation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The device SHOULD set the operation results in \field{idata} according to the
> general device requirments for asymmetric crypto service.
> +
> +\subparagraph{Driver Requirements: Key Exchange: ECDH Key Computation
> Operation}\label{sec:Device Types / Crypto Device /
> +Device Operation / Crypto operation / Asymmetric Crypto Service}
> +The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to
> VIRTIO_CRYPTO_ASYM_KEY_EXCHG,
> +set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDH.
> +
> +The driver SHOULD set the \field{keyexchg_op} to
> VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_KEY in \field{parameter}.
> +
> +The driver SHOULD set all other fields in \field{parameter} except field
> \field{reserved}.
> +
> +The driver SHOULD check the operation result \field{status} in \field{idata}
> firstly.
> +Only if the operation is successful, the other fields in \field{idata} are
> operatable.
> --
> 1.9.3


Regards,
-Gonglei

Xin Zeng Sept. 23, 2016, 5:39 a.m. UTC | #2

On Wednesday, September 21, 2016 3:03 PM, Gonglei (Arei) Wrote:
> > -----Original Message-----
> > From: Xin Zeng [mailto:[e-mail]]
> > Sent: Wednesday, September 21, 2016 1:15 PM
> > To: [e-mail]; [e-mail]; Gonglei
> (Arei)
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]; Huangweidong (C); Xin Zeng
> > Subject: [V0 1/1] virtio crypto device specification: asymmetric crypto
> service
> >
> > This patch introduces asymmetric crypto service into virtio crypto
> > device. The asymmetric crypto service can be referred as signature,
> > verification, encryption, decryption, key generation and key exchange.
> > This patch depends on another virtio crypto device spec patch:
> > https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04563.html.
> >
> > Signed-off-by: Xin Zeng <[e-mail]>
> > ---
> >  virtio-crypto.tex | 932
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 931 insertions(+), 1 deletion(-)
> >
> > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > index c3554e3..699d8dc 100644
> > --- a/virtio-crypto.tex
> > +++ b/virtio-crypto.tex
> > @@ -46,6 +46,7 @@ struct virtio_crypto_config {
> >      le32 kdf_algo;
> >      le32 aead_algo;
> >      le32 primitive_algo;
> > +    le32 rsa_padding;
> 
> The structure doesn't 64-bit aligned now. Please add a padding.
> 

Yes. We also need remove some fields for now as Michael suggested in another mail.

> >  };
> >  \end{lstlisting}
> >
> > @@ -67,6 +68,7 @@ The following services are defined:
> >  #define VIRTIO_CRYPTO_SERVICE_HASH   (1) /* HASH service */
> >  #define VIRTIO_CRYPTO_SERVICE_MAC    (2) /* MAC (Message
> > Authentication Codes) service */
> >  #define VIRTIO_CRYPTO_SERVICE_AEAD   (3) /* AEAD (Authenticated
> > Encryption with Associated Data) service */
> > +#define VIRTIO_CRYPTO_SERVICE_ASYM  (4) /* Asymmetric crypto
> service*/
> >  \end{lstlisting}
> >
> >  The last driver-read-only fields specify detailed algorithms masks
> > @@ -140,6 +142,28 @@ The following AEAD algorithms are defined:
> >  #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3
> >  \end{lstlisting}
> >
> > +The following asymmetric algorithms are defined:
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_ASYM_NONE        0
> > +#define VIRTIO_CRYPTO_ASYM_RSA         1
> > +#define VIRTIO_CRYPTO_ASYM_DSA         2
> > +#define VIRTIO_CRYPTO_ASYM_DH          3
> > +#define VIRTIO_CRYPTO_ASYM_ECDSA       4
> > +#define VIRTIO_CRYPTO_ASYM_ECDH	       5
> > +\end{lstlisting}
> > +
> > +The following rsa padding capabilities are defined:
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_RSA_NO_PADDING         0
> > +#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING      1
> > +#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING     2
> > +#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING 3
> > +#define VIRTIO_CRYPTO_RSA_X931_PADDING       4
> > +#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING  5
> > +\end{lstlisting}
> > +
> >  \begin{note}
> >  More algorithms will be defined in the future.
> >  \end{note}
> > @@ -238,6 +262,18 @@ struct virtio_crypto_op_header {
> >      VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
> >  #define VIRTIO_CRYPTO_AEAD_DECRYPT \
> >      VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> > +#define VIRTIO_CRYPTO_ASYM_SIGN    \
> > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x00)
> > +#define VIRTIO_CRYPTO_ASYM_VERIFY \
> > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x01)
> > +#define VIRTIO_CRYPTO_ASYM_ENCRYPT  \
> > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x02)
> > +#define VIRTIO_CRYPTO_ASYM_DECRYPT  \
> > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x03)
> > +#define VIRTIO_CRYPTO_ASYM_KEY_GEN  \
> > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x04)
> > +#define VIRTIO_CRYPTO_ASYM_KEY_EXCHG \
> > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x05)
> >      le32 opcode;
> >      /* algo should be service-specific algorithms */
> >      le32 algo;
> > @@ -540,6 +576,26 @@ struct virtio_crypto_op_data_req {
> >          struct virtio_crypto_hash_data_req  hash_req;
> >          struct virtio_crypto_mac_data_req   mac_req;
> >          struct virtio_crypto_aead_data_req  aead_req;
> > +        struct virtio_crypto_ecdsa_sign_req ecdsa_sign_req;
> > +        struct virtio_crypto_dsa_sign_req dsa_sign_req;
> > +        struct virtio_crypto_rsa_sign_req rsa_sign_req;
> > +
> > +        struct virtio_crypto_ecdsa_verify_req ecdsa_verify_req;
> > +        struct virtio_crypto_dsa_verify_req dsa_verify_req;
> > +        struct virtio_crypto_rsa_verify_req rsa_verify_req;
> > +
> > +        struct virtio_crypto_rsa_enc_req rsa_enc_req
> > +        struct virtio_crypto_rsa_dec_req rsa_dec_req;
> > +
> > +        struct virtio_crypto_rsa_keygen_req rsa_keygen_req;
> > +        struct virtio_crypto_dsa_keygen_req dsa_keygen_req;
> > +        struct virtio_crypto_ec_keygen_req ec_keygen_req;
> > +
> > +        struct virtio_crypto_dh_keyexchg_param_gen_req
> > dh_keyexchg_param_gen_req;
> > +        struct virtio_crypto_dh_keyexchg_key_gen_req
> > dh_keyexchg_key_gen_req;
> > +        struct virtio_crypto_dh_keyexchg_key_compute_req
> > dh_keyexchg_key_compute_req;
> > +        struct virtio_crypto_ecdh_keyexchg_key_gen_req
> > ecdh_keyexchg_key_gen_req;
> > +        struct virtio_crypto_ecdh_keyexchg_key_compute_req
> > ecdh_keyexchg_key_compute_req;
> >      } u;
> >  };
> >  \end{lstlisting}
> > @@ -939,4 +995,878 @@ The device MUST parse the
> > virtio_crypto_aead_data_req based on the \field{op_cod
> >  The device MUST copy the result of cryptographic operation to the guest
> > memory recorded by \field{dst_data}.\field{addr} field in struct
> > virtio_crypto_aead_input.
> >  The device MUST copy the digest result to the guest memory recorded by
> > \field{digest_result_addr} field in struct virtio_crypto_aead_input.
> >  The device MUST set the \field{status} field in strut
> virtio_crypto_aead_input:
> > VIRTIO_CRYPTO_OP_OK: success; VIRTIO_CRYPTO_OP_ERR: creation failed
> or
> > device error; VIRTIO_CRYPTO_OP_NOTSUPP: not supported.
> > -When the \field{op_code} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device
> > MUST verify and return the verification result to the driver, and if the
> > verification result is incorrect, VIRTIO_CRYPTO_OP_BADMSG (bad message)
> > MUST be returned to the driver.
> > \ No newline at end of file
> > +When the \field{op_code} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device
> > MUST verify and return the verification result to the driver, and if the
> > verification result is incorrect, VIRTIO_CRYPTO_OP_BADMSG (bad message)
> > MUST be returned to the driver.
> > +\subsubsection{Asymmetric Crypto Service}\label{sec:Device Types /
> Crypto
> > Device / Device Operation /
> > +Crypto operation / Asymmetric Crypto Service}
> > +
> > +In general, asymmetric crypto service can be referred as signature,
> > verification,
> > +encryption, decryption, key generation and key exchange. Not each
> algorithm
> > supports
> > +all these services.
> > +
> > +Unlike symmetric crypto service, asymmetric crypto service normally
> does't
> > +need session operations, the request is encapsulated within one packet
> which
> > is represented
> > +by \field{virtio_crypto_op_data_req}.
> > +(see \ref{sec:Device Types / Crypto Device / Device Operation / Data
> > Virtqueue}).
> > +
> > +Once service request is handled by the device, the device writes back the
> > operation results to the corresponding
> > +fields in the request packet.
> > +
> > +\paragraph{General Device Requirements: Asymmetric Crypto
> > Service}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> 
> If they are requirements, please use unified
> \devicenormative{\paragraph}{ Asymmetric Crypto Service}...
> 

Thanks, will fix it in next version.

> > +The device SHOULD parse the field \field{opcode} within
> > \field{virtio_crypto_op_header} then handle the corresponding service
> request.
> > +
> > +The device SHOULD set the operation status in field \field{status} within
> > \field{idata}.
> > +
> > +The device SHOULD write back the operation result to the iovec buffer,
> which
> > is represented by \field{virtio_crypto_iovec} within \field{idata} if the
> operation
> > is successful.
> > +
> > +\paragraph{General Driver Requirements: Asymmetric Crypto
> > Service}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> 
> Please use \drivernormative{\paragraph}...
> You'd better go over the whole patch about this point :)
> 
> > +The driver SHOULD set the corresponding \field{opcode} in
> > \field{virtio_crypto_op_header} according to different services.
> > +
> > +The driver SHOULD offers operatable iovec buffer represented by
> > \field{virtio_crypto_iovec} within \field{idata} if the service request
> structure
> > defines.
> > +
> > +\paragraph{Signature: ECDSA signature operation}\label{sec:Device Types
> /
> > Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> 
> The above label is incorrect. It should be:
> 
> {sec:Device Types / Crypto Device / Device Operation / Crypto operation /
> Asymmetric Crypto Service / Signature: ECDSA signature operation}
> 
> So that we can identify the section by label. The same with below labels,
> need to be fiexed.
> 

Thanks, will fix it.

> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_ec_group {
> > +    struct virtio_crypto_iovec xg;
> > +    struct virtio_crypto_iovec yg;
> > +    struct virtio_crypto_iovec n;
> > +    struct virtio_crypto_iovec q;
> > +    struct virtio_crypto_iovec a;
> > +    struct virtio_crypto_iovec b;
> > +    struct virtio_crypto_iovec h;
> > +};
> > +
> > +typedef enum {
> > +    VIRTIO_CRYPTO_EC_FIELD_TYPE_PRIME,
> > +    VIRTIO_CRYPTO_EC_FIELD_TYPE_BINARY
> > +} VIRTIO_CRYPTO_EC_FIELD_TYPE;
> > +
> > +struct virtio_crypto_ecdsa_sign_para{
> > +    /* Hash alogrithms applied to msg */
> > +    le32 hash_algo;
> > +    le32 reserved;
> > +    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
> > +
> > +    /* EC Group parameters */
> > +    struct virtio_crypto_ec_group ec;
> > +    /* Random value */
> > +    struct virtio_crypto_iovec k;
> > +    /* Private Key */
> > +    struct virtio_crypto_iovec d;
> > +};
> > +
> > +struct virtio_crypto_ecdsa_sign_output {
> > +    /* Message need to be signed */
> > +    struct virtio_crypto_iovec msg;
> > +};
> > +
> > +struct virtio_crypto_ecdsa_sign_input {
> > +    /* operation result */
> > +    le32 status;
> > +    le32 reserved;
> > +
> > +    /* signature result */
> > +    struct virtio_crypto_iovec r;
> > +    struct virtio_crypto_iovec s;
> > +};
> > +\end{lstlisting}
> > +
> > +ECDSA signature operation request is defined as below:
> > +\begin{lstlisting}
> > +struct virtio_crypto_ecdsa_sign_req {
> > +    struct virtio_crypto_ecdsa_sign_para parameter;
> > +    struct virtio_crypto_ecdsa_sign_output odata;
> > +
> > +    struct virtio_crypto_ecdsa_sign_input idata;
> > +};
> > +\end{lstlisting}
> > +
> > +\subparagraph{Device Requirements: ECDSA signature
> > operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The device SHOULD set the operation results in \field{idata} according to
> the
> > general device requirments for asymmetric crypto service.
> > +
> > +\subparagraph{Driver Requirements: ECDSA signature
> > operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The driver SHOULD set the \field{opcode} in
> \field{virtio_crypto_op_header} to
> > VIRTIO_CRYPTO_ASYM_SIGN,
> > +set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDSA.
> > +
> > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> except
> > field \field{reserved}.
> > +
> > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > before it operates other fields in \field{idata}.
> > +Only if the operation is successful, the \field{r,s} in \field{idata} are
> operatable.
> 
> \field{r,s} ? Is't legal?
> 

It's legal. No complaints for this from xelatex.
 
> > +
> > +\paragraph{Signature: DSA signature operation}\label{sec:Device Types /
> > Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_dsa_group {
> > +    struct virtio_crypto_iovec p;
> > +    struct virtio_crypto_iovec q;
> > +    struct virtio_crypto_iovec g;
> > +};
> > +
> > +struct virtio_crypto_dsa_sign_para {
> > +    /* Hash alogrithms applied to msg */
> > +    le32 hash_algo;
> > +    le32 reserved;
> > +
> > +    /* DSA group parameter */
> > +    struct virtio_crypto_dsa_group dsa;
> > +    /* Random value */
> > +    struct virtio_crypto_iovec k;
> > +    /* Private Key */
> > +    struct virtio_crypto_iovec x;
> > +};
> > +
> > +struct virtio_crypto_dsa_sign_output {
> > +    struct virtio_crypto_iovec msg;
> > +};
> > +
> > +struct virtio_crypto_dsa_sign_input  {
> > +    /* operation result */
> > +    le32 status;
> > +    le32 reserved;
> > +
> > +    /* signature result */
> > +    struct virtio_crypto_iovec r;
> > +    struct virtio_crypto_iovec s;
> > +};
> > +\end{lstlisting}
> > +DSA signature operation request is defined as below:
> > +\begin{lstlisting}
> > +struct virtio_crypto_dsa_sign_req {
> > +    struct virtio_crypto_dsa_sign_para parameter;
> > +    struct virtio_crypto_dsa_sign_output odata;
> > +
> > +    struct virtio_crypto_dsa_sign_input idata;
> > +};
> > +\end{lstlisting}
> > +
> > +\subparagraph{Device Requirements: DSA signature
> > operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The device SHOULD set the operation results in \field{idata} according to
> the
> > general device requirments for asymmetric crypto service.
> > +
> > +\subparagraph{Driver Requirements: DSA signature
> > operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The driver SHOULD set the \field{opcode} in
> \field{virtio_crypto_op_header} to
> > VIRTIO_CRYPTO_ASYM_SIGN,
> > +set \field{algo} to VIRTIO_CRYPTO_ASYM_DSA.
> > +
> > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> except
> > field \field{reserved}.
> > +
> > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > before it operates other fields in \field{idata}.
> > +Only if the operation is successful, the \field{r,s} in \field{idata} are
> operatable.
> > +
> 
> I think s/SHOULD/MUST/ is more appropriate. Isn't it?

Yes, in this case it's better, thanks.

> 
> > +\paragraph{Signature: RSA signature operation}\label{sec:Device Types /
> > Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_rsa_pub_key{
> > +    /* The RSA modules */
> > +    struct virtio_crypto_iovec n;
> > +    /* The RSA public exponent */
> > +    struct virtio_crypto_iovec e;
> > +};
> > +
> > +struct virtio_crypto_rsa_priv_key_rep1{
> > +    /* The RSA modules */
> > +    struct virtio_crypto_iovec n;
> > +    /* The RSA private exponent */
> > +    struct virtio_crypto_iovec d;
> > +};
> > +
> > +struct virtio_crypto_rsa_priv_key_rep2{
> > +    /* The first factor */
> > +    struct virtio_crypto_iovec p;
> > +    /* The second factor */
> > +    struct virtio_crypto_iovec q;
> > +    /* The first factor's CRT exponent */
> > +    struct virtio_crypto_iovec dp;
> > +    /* The second factor's CRT exponent */
> > +    struct virtio_crypto_iovec dq;
> > +    /* The first CRT coeffieient */
> > +    struct virtio_crypto_iovec qinv;
> > +    /* The factors array when prime_number > 2 */
> > +    struct virtio_crypto_iovec r[];
> > +    /* The CRT exponent array when prime_number > 2 */
> > +    struct virtio_crypto_iovec d[];
> > +    /* The CRT coeffieient array when prime_number > 2 */
> > +    struct virtio_crypto_iovec t[];
> > +};
> > +
> > +struct virtio_crypto_rsa_priv_key {
> > +    le32 prime_number;
> > +#define VIRTIO_CRYPTO_RSA_PRIV_KEY_REPTYPE1 0
> > +#define VIRTIO_CRYPTO_RSA_PRIV_KEY_REPTYPE2 1
> > +    le32 priv_key_rep_type;
> > +    union {
> > +        struct virtio_crypto_rsa_priv_key_rep1 privkey_rep1;
> > +        struct virtio_crypto_rsa_priv_key_rep2 privkey_rep2;
> > +    }key;
> > +};
> > +
> > +struct virtio_crypto_rsa_sign_para {
> > +    /* Hash alogrithms applied to msg */
> > +    le32 hash_algo;
> > +    le32 padding_mode;
> > +    struct virtio_crypto_rsa_priv_key priv_key;
> > +};
> > +
> > +struct virtio_crypto_rsa_sign_output {
> > +    struct virtio_crypto_iovec msg;
> > +};
> > +
> > +struct virtio_crypto_rsa_sign_input {
> > +    le32 status;
> > +    le32 reserved;
> > +
> > +    struct virtio_crypto_iovec signature;
> > +};
> > +\end{lstlisting}
> > +
> > +RSA signature operation request is defined as below:
> > +\begin{lstlisting}
> > +struct virtio_crypto_rsa_sign_req {
> > +    struct virtio_crypto rsa_sign_para parameter;
> > +    struct virtio_crypto rsa_sign_output odata;
> > +
> > +    struct virtio_crypto rsa_sign_input idata;
> > +};
> > +\end{lstlisting}
> > +
> > +\subparagraph{Device Requirements: RSA signature
> > operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The device SHOULD set the operation results in \field{idata} according to
> the
> > general device requirments for asymmetric crypto service.
> > +
> > +\subparagraph{Driver Requirements: RSA signature
> > operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The driver SHOULD set the \field{opcode} in
> \field{virtio_crypto_op_header} to
> > VIRTIO_CRYPTO_ASYM_SIGN,
> > +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> > +
> > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> except
> > field \field{reserved}.
> > +
> > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > before it operates other fields in \field{idata}.
> > +Only if the operation is successful, the \field{signature} in \field{idata} is
> > operatable.
> > +
> > +\paragraph{Verification: Common Structure}\label{sec:Device Types /
> > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > Service}
> > +
> > +The result of verification operation can be represented by structure
> > \field{virtio_crypto_asym_verify_gen_input}.
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_asym_verify_gen_input {
> > +    /* Operation result */
> > +    le32 status;
> > +    /* Verification result */
> > +#define VIRTIO_CRYPTO_ASYM_VERIFY_SUCCESS 0
> > +#define VIRTIO_CRYPTO_ASYM_VERIFY_FAIL -1
> 
> Why not use the following generic results?
> 
> #define VIRTIO_CRYPTO_OP_OK        0
> #define VIRTIO_CRYPTO_OP_ERR       1
> #define VIRTIO_CRYPTO_OP_BADMSG    2
> 
> And the VIRTIO_CRYPTO_OP_BADMSG is used to show the verification result
> is incorrect.

I think this is two different semantic meanings, one is operation result,
the other is verification result especially it only exists in verification, so I think it makes sense to 
use two different sets of error codes with different names.
Probably we can remove OP from current error code, e.g,  s/ VIRTIO_CRYPTO_OP_ERR /VIRTIO_CRYPTO_ERR, 
then it makes more sense to use these error codes through the entire virtio-crypto spec.

> 
> > +    le32 verify_result;
> > +};
> > +\end{lstlisting}
> > +
> > +\paragraph{Verification: ECDSA Verification Operation}\label{sec:Device
> Types
> > /
> > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > Service}
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_ecdsa_verify_para {
> > +    /* Hash alogrithms applied to msg */
> > +    le32 hash_algo;
> > +    le32 reserved;
> > +
> > +    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
> > +    /* EC Group parameters */
> > +    struct virtio_crypto_ec_group ec;
> > +
> > +    /* Public key */
> > +    struct virtio_crypto_iovec x;
> > +    struct virtio_crypto_iovec y;
> > +};
> > +
> > +struct virtio_crypto_ecdsa_verify_output {
> > +    /* Signature value */
> > +    struct virtio_crypto_iovec r;
> > +    struct virtio_crypto_iovec s;
> > +
> > +    struct virtio_crypto_iovec msg;
> > +};
> > +\end{lstlisting}
> > +
> > +ECDSA Verification Operation request is defined as below:
> > +\begin{lstlisting}
> > +struct virtio_crypto_ecdsa_verify_req {
> > +    struct virtio_crypto_ecdsa_verify_para parameter;
> > +    struct virtio_crypto_ecdsa_verify_output odata;
> > +
> > +    struct virtio_crypto_asym_verify_gen_input idata;
> > +};
> > +\end{lstlisting}
> > +
> > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > before it checks \field{verify_result}.
> > +
> > +\paragraph{Verification: RSA Verification Operation}\label{sec:Device
> Types /
> > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > Service}
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_rsa_verify_para {
> > +    le32 hash_algo;
> > +    le32 padding_mode;
> > +    struct virtio_crypto_rsa_pub_key pubkey;
> > +};
> > +
> > +struct virtio_crypto_rsa_verify_output {
> > +    struct virtio_crypto_iovec msg;
> > +};
> > +\end{lstlisting}
> > +
> > +RSA verification operation request is defined as below:
> > +\begin{lstlisting}
> > +struct virtio_crypto_rsa_verify_req {
> > +    struct virtio_crypto_rsa_verify_para parameter;
> > +    struct virtio_crypto_rsa_verify_output odata;
> > +
> > +    struct virtio_crypto_asym_verify_gen_input idata;
> > +};
> > +\end{lstlisting}
> > +
> > +\subparagraph{Device Requirements: RSA Verification
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The device SHOULD set the operation results in \field{idata}.
> > +
> > +\subparagraph{Driver Requirements: RSA Verification
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The driver SHOULD set the \field{opcode} in
> \field{virtio_crypto_op_header} to
> > VIRTIO_CRYPTO_ASYM_VERIFY,
> > +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> > +
> > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> except
> > field \field{reserved}.
> > +
> > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > before it checks \field{verify_result}.
> > +
> > +\paragraph{Encryption: RSA Encryption Operation}\label{sec:Device Types
> /
> > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > Service}
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_rsa_enc_para {
> > +    le32 padding_mode;
> > +    le32 reserved;
> > +    struct rsa_pub_key pub_key;
> > +};
> > +
> > +struct virtio_crypto_rsa_enc_output {
> > +    struct virtio_crypto_iovec msg;
> > +};
> > +
> > +struct virtio_crypto_rsa_enc_input {
> > +    le32 status;
> > +    le32 reserved;
> > +
> > +    struct virtio_crypto_iovec cmsg;
> > +};
> > +\end{lstlisting}
> > +
> > +RSA encryption operation request is defined as below:
> > +\begin{lstlisting}
> > +struct virtio_crypto_rsa_enc_req {
> > +    struct virtio_crypto_rsa_enc_para parameter;
> > +    struct virtio_crypto_rsa_enc_output odata;
> > +
> > +    struct virtio_crypto_rsa_enc_input idata;
> > +};
> > +\end{lstlisting}
> > +
> > +\subparagraph{Device Requirements: RSA Encryption
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The device SHOULD set the operation results in \field{idata} according to
> the
> > general device requirments for asymmetric crypto service.
> > +
> > +\subparagraph{Driver Requirements: RSA Encryption
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The driver SHOULD set the \field{opcode} in
> \field{virtio_crypto_op_header} to
> > VIRTIO_CRYPTO_ASYM_ENCRYPT,
> > +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> > +
> > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> except
> > field \field{reserved}.
> > +
> > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > before it operates other fields in \field{idata}.
> > +Only if the operation is successful, the \field{cmsg} in \field{idata} is
> > operatable.
> > +
> > +\paragraph{Decryption: RSA Decryption Operation}\label{sec:Device
> Types /
> > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > Service}
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_rsa_dec_para {
> > +    le32 padding_mode;
> > +    le32 reserved;
> > +    struct virtio_crypto_rsa_priv_key priv_key;
> > +};
> > +
> > +struct virtio_crypto_rsa_dec_output {
> > +    struct virtio_crypto_iovec cmsg;
> > +}
> > +
> > +struct virtio_crypto_rsa_dec_input {
> > +    le32 status;
> > +    le32 reserved;
> > +
> > +    struct virtio_crypto_iovec msg;
> > +};
> > +\end{lstlisting}
> > +
> > +RSA decryption operation request is defined as below:
> > +\begin{lstlisting}
> > +struct virtio_crypto_rsa_dec_req {
> > +    struct virtio_crypto_rsa_dec_para parameter;
> > +    struct virtio_crypto_rsa_dec_output odata;
> > +
> > +    struct virtio_crypto_rsa_dec_input idata;
> > +};
> > +\end{lstlisting}
> > +
> > +\subparagraph{Device Requirements: RSA Decryption
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The device SHOULD set the operation results in \field{idata} according to
> the
> > general device requirments for asymmetric crypto service.
> > +
> > +\subparagraph{Driver Requirements: RSA Decryption
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The driver SHOULD set the \field{opcode} in
> \field{virtio_crypto_op_header} to
> > VIRTIO_CRYPTO_ASYM_DECRYPT,
> > +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> > +
> > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> except
> > field \field{reserved}.
> > +
> > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > before it operates other fields in \field{idata}.
> > +Only if the operation is successful, the \field{msg} in \field{idata} is
> operatable.
> > +
> > +\paragraph{Key Generation: RSA Key Generation
> Operation}\label{sec:Device
> > Types /
> > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > Service}
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_rsa_keygen_para {
> > +    /* The modules length in bytes */
> > +    le32 modulus_len;
> > +    le32 rsa_prime_number;
> > +    le32 priv_key_rep_type;
> > +    le32 reserved;
> > +
> > +    /* the public exponent */
> > +    struct virtio_crypto_iovec e;
> > +};
> > +
> > +struct virtio_crypto_rsa_keygen_input {
> > +    le32 status;
> > +    le32 reserved;
> > +
> > +    struct virtio_crypto_rsa_priv_key priv_key;
> > +    struct virtio_crypto_rsa_pub_key pub_key;
> > +};
> > +\end{lstlisting}
> > +
> > +RSA key-generation operation request is defined as below:
> > +\begin{lstlisting}
> > +struct virtio_crypto_rsa_keygen_req {
> > +    struct virtio_crypto_rsa_keygen_para parameter;
> > +
> > +    struct virtio_crypto_rsa_keygen_input idata;
> > +};
> > +\end{lstlisting}
> > +
> > +\subparagraph{Device Requirements: RSA Key Generation
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The device SHOULD set the operation results in \field{idata} according to
> the
> > general device requirments for asymmetric crypto service.
> > +
> > +\subparagraph{Driver Requirements: RSA Key Generation
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The driver SHOULD set the \field{opcode} in
> \field{virtio_crypto_op_header} to
> > VIRTIO_CRYPTO_ASYM_KEY_GEN,
> > +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> > +
> > +The driver SHOULD set all fields in \field{parameter} except
> \field{reserved}
> > field.
> > +
> > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > before it operates other fields in \field{idata}.
> > +Only if the operation is successful, the \field{priv_key} and \field{pub_key}
> in
> > \field{idata} are operatable.
> > +
> > +\paragraph{Key Generation: DSA Key Generation
> operation}\label{sec:Device
> > Types /
> > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > Service}
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_dsa_keygen_para {
> > +    le32 modulus_len;
> > +    le32 reserved;
> > +};
> > +
> > +struct virtio_crypto_dsa_keygen_input {
> > +    le32 status;
> > +    le32 reserved;
> > +
> > +    /* DSA Group parameters */
> > +    struct virtio_crypto_dsa_group dsa;
> > +    /* Private key */
> > +    struct virtio_crypto_iovec x;
> > +    /* Public key */
> > +    struct virtio_crypto_iovec y;
> > +};
> > +\end{lstlisting}
> > +
> > +DSA key-generation operation request is defined as below:
> > +\begin{lstlisting}
> > +struct virtio_crypto_dsa_keygen_req {
> > +    struct virtio_crypto_dsa_keygen_para parameter;
> > +
> > +    struct virtio_crypto_dsa_keygen_input idata;
> > +};
> > +\end{lstlisting}
> > +
> > +\subparagraph{Device Requirements: DSA Key Generation
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The device SHOULD set the operation results in \field{idata} according to
> the
> > general device requirments for asymmetric crypto service.
> > +
> > +\subparagraph{Driver Requirements: DSA Key Generation
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The driver SHOULD set the \field{opcode} in
> \field{virtio_crypto_op_header} to
> > VIRTIO_CRYPTO_ASYM_KEY_GEN,
> > +set \field{algo} to VIRTIO_CRYPTO_ASYM_DSA.
> > +
> > +The driver SHOULD set all fields in \field{parameter} except
> \field{reserved}
> > field.
> > +
> > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > before it operates other fields in \field{idata}.
> > +Only if the operation is successful, the \field{priv_key} and \field{pub_key}
> in
> > \field{idata} are operatable.
> > +
> > +\paragraph{Key Generation: EC Key Generation
> operation }\label{sec:Device
> > Types /
> > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > Service}
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_ec_keygen_para {
> > +    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
> > +
> > +    /* EC group parameters */
> > +    struct virtio_crypto_ec_group ec;
> > +};
> > +
> > +struct virtio_crypto_ec_keygen_input {
> > +    le32 status;
> > +    le32 reserved;
> > +
> > +    /* Private key */
> > +    struct virtio_crypto_iovec d;
> > +
> > +    /* Public key */
> > +    struct virtio_crypto_iovec x;
> > +    struct virtio_crypto_iovec y;
> > +};
> > +\end{lstlisting}
> > +
> > +EC key-generation operation request is defined as below:
> > +\begin{lstlisting}
> > +struct virtio_crypto_ec_keygen_req {
> > +    struct virtio_crypto_ec_keygen_para parameter;
> > +
> > +    struct virtio_crypto_ec_keygen_input key;
> > +};
> > +\end{lstlisting}
> > +
> > +\subparagraph{Device Requirements: EC Key Generation
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The device SHOULD set the operation results in \field{idata} according to
> the
> > general device requirments for asymmetric crypto service.
> > +
> > +\subparagraph{Driver Requirements: EC Key Generation
> > Operation}\label{sec:Device Types / Crypto Device /
> > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > +The driver SHOULD set the \field{opcode} in
> \field{virtio_crypto_op_header} to
> > VIRTIO_CRYPTO_ASYM_KEY_GEN,
> > +set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDH or
> > VIRTIO_CRYPTO_ASYM_ECDSA.
> > +
> > +The driver SHOULD set all fields in \field{parameter} except
> \field{reserved}
> > field.
> > +
> > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > before it operates other fields in \field{idata}.
> > +Only if the operation is successful, the other fields in \field{idata} are
> > operatable.
> > +
> > +\paragraph{Key Exchange: Common Structure}\label{sec:Device Types /
> > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > Service}
> > +
> > +Key Exchange request has two kinds of operations in general, key
> generation
> > and key computation.
> > +For DH, it has additional operation: parameter generation operation.
> > +
> > +\begin{lstlisting}
> > +typdef enum VIRTIO_CRYPTO_KEY_EXCHANGE_OP {
> > +    VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_KEY,
> > +    VIRTIO_CRYPTO_KEY_EXCHANGE_COMPUTE_KEY,
> > +    /* It's only valid in case algorithm is DH */
> > +    VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_DH_PARAM
> > +} VIRTIO_CRYPTO_KEY_EXCHANGE_OP;
> > +\end{lstlisting}
> > +
> > +\paragraph{Key Exchange: DH Parameter Generation
> > Operation}\label{sec:Device Types /
> > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > Service}
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_dh_parameter {
> > +    le32 modules_len;
> > +    le32 reserved;
> > +
> > +    /* random odd prime number */
> > +    struct virtio_crypto_iovec p;
> > +    /* base (g) */
> > +    struct virtio_crypto_iovec g;
> > +};
> > +
> > +struct virtio_crypto_dh_keyexchg_para {
> > +    VIRTIO_CRYPTO_KEY_EXCHANGE_OP keyexchg_op;
> 
> sizeof(enum foo) is implementation-specific according to the C standard.
> You must explicitly choose a type (u8, le16, le32) in this specification
> so that the struct layout is compatible between compilers.
> 

You are right. Will fix this.

> You can move keyexchg_op to struct virtio_crypto_dh_parameter,
> instead of the reserved property.

They represent two different semantic meaning. I preferred to keep current structure definition.

> 
> > --
> > 1.9.3
> 
> 
> Regards,
> -Gonglei

Gonglei (Arei) Sept. 23, 2016, 7:57 a.m. UTC | #3

> -----Original Message-----
> From: Zeng, Xin [mailto:[e-mail]]
> Sent: Friday, September 23, 2016 1:39 PM
> To: Gonglei (Arei); [e-mail]; [e-mail]
> Cc: [e-mail]; Keating, Brian A; Griffin, John; Ma, Liang J; Hanweidong
> (Randy); Wubin (H)
> Subject: RE: [V0 1/1] virtio crypto device specification: asymmetric crypto
> service
> 
> On Wednesday, September 21, 2016 3:03 PM, Gonglei (Arei) Wrote:
> > > -----Original Message-----
> > > From: Xin Zeng [mailto:[e-mail]]
> > > Sent: Wednesday, September 21, 2016 1:15 PM
> > > To: [e-mail]; [e-mail]; Gonglei
> > (Arei)
> > > Cc: [e-mail]; [e-mail]; [e-mail];
> > > [e-mail]; Huangweidong (C); Xin Zeng
> > > Subject: [V0 1/1] virtio crypto device specification: asymmetric crypto
> > service
> > >
> > > This patch introduces asymmetric crypto service into virtio crypto
> > > device. The asymmetric crypto service can be referred as signature,
> > > verification, encryption, decryption, key generation and key exchange.
> > > This patch depends on another virtio crypto device spec patch:
> > > https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04563.html.
> > >
> > > Signed-off-by: Xin Zeng <[e-mail]>
> > > ---
> > >  virtio-crypto.tex | 932
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++-
> > >  1 file changed, 931 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > index c3554e3..699d8dc 100644
> > > --- a/virtio-crypto.tex
> > > +++ b/virtio-crypto.tex
> > > @@ -46,6 +46,7 @@ struct virtio_crypto_config {
> > >      le32 kdf_algo;
> > >      le32 aead_algo;
> > >      le32 primitive_algo;
> > > +    le32 rsa_padding;
> >
> > The structure doesn't 64-bit aligned now. Please add a padding.
> >
> 
> Yes. We also need remove some fields for now as Michael suggested in another
> mail.
> 
> > >  };
> > >  \end{lstlisting}
> > >
> > > @@ -67,6 +68,7 @@ The following services are defined:
> > >  #define VIRTIO_CRYPTO_SERVICE_HASH   (1) /* HASH service */
> > >  #define VIRTIO_CRYPTO_SERVICE_MAC    (2) /* MAC (Message
> > > Authentication Codes) service */
> > >  #define VIRTIO_CRYPTO_SERVICE_AEAD   (3) /* AEAD (Authenticated
> > > Encryption with Associated Data) service */
> > > +#define VIRTIO_CRYPTO_SERVICE_ASYM  (4) /* Asymmetric crypto
> > service*/
> > >  \end{lstlisting}
> > >
> > >  The last driver-read-only fields specify detailed algorithms masks
> > > @@ -140,6 +142,28 @@ The following AEAD algorithms are defined:
> > >  #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3
> > >  \end{lstlisting}
> > >
> > > +The following asymmetric algorithms are defined:
> > > +
> > > +\begin{lstlisting}
> > > +#define VIRTIO_CRYPTO_ASYM_NONE        0
> > > +#define VIRTIO_CRYPTO_ASYM_RSA         1
> > > +#define VIRTIO_CRYPTO_ASYM_DSA         2
> > > +#define VIRTIO_CRYPTO_ASYM_DH          3
> > > +#define VIRTIO_CRYPTO_ASYM_ECDSA       4
> > > +#define VIRTIO_CRYPTO_ASYM_ECDH	       5
> > > +\end{lstlisting}
> > > +
> > > +The following rsa padding capabilities are defined:
> > > +
> > > +\begin{lstlisting}
> > > +#define VIRTIO_CRYPTO_RSA_NO_PADDING         0
> > > +#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING      1
> > > +#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING     2
> > > +#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING 3
> > > +#define VIRTIO_CRYPTO_RSA_X931_PADDING       4
> > > +#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING  5
> > > +\end{lstlisting}
> > > +
> > >  \begin{note}
> > >  More algorithms will be defined in the future.
> > >  \end{note}
> > > @@ -238,6 +262,18 @@ struct virtio_crypto_op_header {
> > >      VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
> > >  #define VIRTIO_CRYPTO_AEAD_DECRYPT \
> > >      VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> > > +#define VIRTIO_CRYPTO_ASYM_SIGN    \
> > > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x00)
> > > +#define VIRTIO_CRYPTO_ASYM_VERIFY \
> > > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x01)
> > > +#define VIRTIO_CRYPTO_ASYM_ENCRYPT  \
> > > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x02)
> > > +#define VIRTIO_CRYPTO_ASYM_DECRYPT  \
> > > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x03)
> > > +#define VIRTIO_CRYPTO_ASYM_KEY_GEN  \
> > > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x04)
> > > +#define VIRTIO_CRYPTO_ASYM_KEY_EXCHG \
> > > +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x05)
> > >      le32 opcode;
> > >      /* algo should be service-specific algorithms */
> > >      le32 algo;
> > > @@ -540,6 +576,26 @@ struct virtio_crypto_op_data_req {
> > >          struct virtio_crypto_hash_data_req  hash_req;
> > >          struct virtio_crypto_mac_data_req   mac_req;
> > >          struct virtio_crypto_aead_data_req  aead_req;
> > > +        struct virtio_crypto_ecdsa_sign_req ecdsa_sign_req;
> > > +        struct virtio_crypto_dsa_sign_req dsa_sign_req;
> > > +        struct virtio_crypto_rsa_sign_req rsa_sign_req;
> > > +
> > > +        struct virtio_crypto_ecdsa_verify_req ecdsa_verify_req;
> > > +        struct virtio_crypto_dsa_verify_req dsa_verify_req;
> > > +        struct virtio_crypto_rsa_verify_req rsa_verify_req;
> > > +
> > > +        struct virtio_crypto_rsa_enc_req rsa_enc_req
> > > +        struct virtio_crypto_rsa_dec_req rsa_dec_req;
> > > +
> > > +        struct virtio_crypto_rsa_keygen_req rsa_keygen_req;
> > > +        struct virtio_crypto_dsa_keygen_req dsa_keygen_req;
> > > +        struct virtio_crypto_ec_keygen_req ec_keygen_req;
> > > +
> > > +        struct virtio_crypto_dh_keyexchg_param_gen_req
> > > dh_keyexchg_param_gen_req;
> > > +        struct virtio_crypto_dh_keyexchg_key_gen_req
> > > dh_keyexchg_key_gen_req;
> > > +        struct virtio_crypto_dh_keyexchg_key_compute_req
> > > dh_keyexchg_key_compute_req;
> > > +        struct virtio_crypto_ecdh_keyexchg_key_gen_req
> > > ecdh_keyexchg_key_gen_req;
> > > +        struct virtio_crypto_ecdh_keyexchg_key_compute_req
> > > ecdh_keyexchg_key_compute_req;
> > >      } u;
> > >  };
> > >  \end{lstlisting}
> > > @@ -939,4 +995,878 @@ The device MUST parse the
> > > virtio_crypto_aead_data_req based on the \field{op_cod
> > >  The device MUST copy the result of cryptographic operation to the guest
> > > memory recorded by \field{dst_data}.\field{addr} field in struct
> > > virtio_crypto_aead_input.
> > >  The device MUST copy the digest result to the guest memory recorded by
> > > \field{digest_result_addr} field in struct virtio_crypto_aead_input.
> > >  The device MUST set the \field{status} field in strut
> > virtio_crypto_aead_input:
> > > VIRTIO_CRYPTO_OP_OK: success; VIRTIO_CRYPTO_OP_ERR: creation
> failed
> > or
> > > device error; VIRTIO_CRYPTO_OP_NOTSUPP: not supported.
> > > -When the \field{op_code} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device
> > > MUST verify and return the verification result to the driver, and if the
> > > verification result is incorrect, VIRTIO_CRYPTO_OP_BADMSG (bad
> message)
> > > MUST be returned to the driver.
> > > \ No newline at end of file
> > > +When the \field{op_code} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device
> > > MUST verify and return the verification result to the driver, and if the
> > > verification result is incorrect, VIRTIO_CRYPTO_OP_BADMSG (bad
> message)
> > > MUST be returned to the driver.
> > > +\subsubsection{Asymmetric Crypto Service}\label{sec:Device Types /
> > Crypto
> > > Device / Device Operation /
> > > +Crypto operation / Asymmetric Crypto Service}
> > > +
> > > +In general, asymmetric crypto service can be referred as signature,
> > > verification,
> > > +encryption, decryption, key generation and key exchange. Not each
> > algorithm
> > > supports
> > > +all these services.
> > > +
> > > +Unlike symmetric crypto service, asymmetric crypto service normally
> > does't
> > > +need session operations, the request is encapsulated within one packet
> > which
> > > is represented
> > > +by \field{virtio_crypto_op_data_req}.
> > > +(see \ref{sec:Device Types / Crypto Device / Device Operation / Data
> > > Virtqueue}).
> > > +
> > > +Once service request is handled by the device, the device writes back the
> > > operation results to the corresponding
> > > +fields in the request packet.
> > > +
> > > +\paragraph{General Device Requirements: Asymmetric Crypto
> > > Service}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> >
> > If they are requirements, please use unified
> > \devicenormative{\paragraph}{ Asymmetric Crypto Service}...
> >
> 
> Thanks, will fix it in next version.
> 
> > > +The device SHOULD parse the field \field{opcode} within
> > > \field{virtio_crypto_op_header} then handle the corresponding service
> > request.
> > > +
> > > +The device SHOULD set the operation status in field \field{status} within
> > > \field{idata}.
> > > +
> > > +The device SHOULD write back the operation result to the iovec buffer,
> > which
> > > is represented by \field{virtio_crypto_iovec} within \field{idata} if the
> > operation
> > > is successful.
> > > +
> > > +\paragraph{General Driver Requirements: Asymmetric Crypto
> > > Service}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> >
> > Please use \drivernormative{\paragraph}...
> > You'd better go over the whole patch about this point :)
> >
> > > +The driver SHOULD set the corresponding \field{opcode} in
> > > \field{virtio_crypto_op_header} according to different services.
> > > +
> > > +The driver SHOULD offers operatable iovec buffer represented by
> > > \field{virtio_crypto_iovec} within \field{idata} if the service request
> > structure
> > > defines.
> > > +
> > > +\paragraph{Signature: ECDSA signature operation}\label{sec:Device Types
> > /
> > > Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> >
> > The above label is incorrect. It should be:
> >
> > {sec:Device Types / Crypto Device / Device Operation / Crypto operation /
> > Asymmetric Crypto Service / Signature: ECDSA signature operation}
> >
> > So that we can identify the section by label. The same with below labels,
> > need to be fiexed.
> >
> 
> Thanks, will fix it.
> 
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_ec_group {
> > > +    struct virtio_crypto_iovec xg;
> > > +    struct virtio_crypto_iovec yg;
> > > +    struct virtio_crypto_iovec n;
> > > +    struct virtio_crypto_iovec q;
> > > +    struct virtio_crypto_iovec a;
> > > +    struct virtio_crypto_iovec b;
> > > +    struct virtio_crypto_iovec h;
> > > +};
> > > +
> > > +typedef enum {
> > > +    VIRTIO_CRYPTO_EC_FIELD_TYPE_PRIME,
> > > +    VIRTIO_CRYPTO_EC_FIELD_TYPE_BINARY
> > > +} VIRTIO_CRYPTO_EC_FIELD_TYPE;
> > > +
> > > +struct virtio_crypto_ecdsa_sign_para{
> > > +    /* Hash alogrithms applied to msg */
> > > +    le32 hash_algo;
> > > +    le32 reserved;
> > > +    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
> > > +
> > > +    /* EC Group parameters */
> > > +    struct virtio_crypto_ec_group ec;
> > > +    /* Random value */
> > > +    struct virtio_crypto_iovec k;
> > > +    /* Private Key */
> > > +    struct virtio_crypto_iovec d;
> > > +};
> > > +
> > > +struct virtio_crypto_ecdsa_sign_output {
> > > +    /* Message need to be signed */
> > > +    struct virtio_crypto_iovec msg;
> > > +};
> > > +
> > > +struct virtio_crypto_ecdsa_sign_input {
> > > +    /* operation result */
> > > +    le32 status;
> > > +    le32 reserved;
> > > +
> > > +    /* signature result */
> > > +    struct virtio_crypto_iovec r;
> > > +    struct virtio_crypto_iovec s;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +ECDSA signature operation request is defined as below:
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_ecdsa_sign_req {
> > > +    struct virtio_crypto_ecdsa_sign_para parameter;
> > > +    struct virtio_crypto_ecdsa_sign_output odata;
> > > +
> > > +    struct virtio_crypto_ecdsa_sign_input idata;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\subparagraph{Device Requirements: ECDSA signature
> > > operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The device SHOULD set the operation results in \field{idata} according to
> > the
> > > general device requirments for asymmetric crypto service.
> > > +
> > > +\subparagraph{Driver Requirements: ECDSA signature
> > > operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The driver SHOULD set the \field{opcode} in
> > \field{virtio_crypto_op_header} to
> > > VIRTIO_CRYPTO_ASYM_SIGN,
> > > +set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDSA.
> > > +
> > > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> > except
> > > field \field{reserved}.
> > > +
> > > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > > before it operates other fields in \field{idata}.
> > > +Only if the operation is successful, the \field{r,s} in \field{idata} are
> > operatable.
> >
> > \field{r,s} ? Is't legal?
> >
> 
> It's legal. No complaints for this from xelatex.
> 
> > > +
> > > +\paragraph{Signature: DSA signature operation}\label{sec:Device Types /
> > > Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_dsa_group {
> > > +    struct virtio_crypto_iovec p;
> > > +    struct virtio_crypto_iovec q;
> > > +    struct virtio_crypto_iovec g;
> > > +};
> > > +
> > > +struct virtio_crypto_dsa_sign_para {
> > > +    /* Hash alogrithms applied to msg */
> > > +    le32 hash_algo;
> > > +    le32 reserved;
> > > +
> > > +    /* DSA group parameter */
> > > +    struct virtio_crypto_dsa_group dsa;
> > > +    /* Random value */
> > > +    struct virtio_crypto_iovec k;
> > > +    /* Private Key */
> > > +    struct virtio_crypto_iovec x;
> > > +};
> > > +
> > > +struct virtio_crypto_dsa_sign_output {
> > > +    struct virtio_crypto_iovec msg;
> > > +};
> > > +
> > > +struct virtio_crypto_dsa_sign_input  {
> > > +    /* operation result */
> > > +    le32 status;
> > > +    le32 reserved;
> > > +
> > > +    /* signature result */
> > > +    struct virtio_crypto_iovec r;
> > > +    struct virtio_crypto_iovec s;
> > > +};
> > > +\end{lstlisting}
> > > +DSA signature operation request is defined as below:
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_dsa_sign_req {
> > > +    struct virtio_crypto_dsa_sign_para parameter;
> > > +    struct virtio_crypto_dsa_sign_output odata;
> > > +
> > > +    struct virtio_crypto_dsa_sign_input idata;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\subparagraph{Device Requirements: DSA signature
> > > operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The device SHOULD set the operation results in \field{idata} according to
> > the
> > > general device requirments for asymmetric crypto service.
> > > +
> > > +\subparagraph{Driver Requirements: DSA signature
> > > operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The driver SHOULD set the \field{opcode} in
> > \field{virtio_crypto_op_header} to
> > > VIRTIO_CRYPTO_ASYM_SIGN,
> > > +set \field{algo} to VIRTIO_CRYPTO_ASYM_DSA.
> > > +
> > > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> > except
> > > field \field{reserved}.
> > > +
> > > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > > before it operates other fields in \field{idata}.
> > > +Only if the operation is successful, the \field{r,s} in \field{idata} are
> > operatable.
> > > +
> >
> > I think s/SHOULD/MUST/ is more appropriate. Isn't it?
> 
> Yes, in this case it's better, thanks.
> 
> >
> > > +\paragraph{Signature: RSA signature operation}\label{sec:Device Types /
> > > Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_rsa_pub_key{
> > > +    /* The RSA modules */
> > > +    struct virtio_crypto_iovec n;
> > > +    /* The RSA public exponent */
> > > +    struct virtio_crypto_iovec e;
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_priv_key_rep1{
> > > +    /* The RSA modules */
> > > +    struct virtio_crypto_iovec n;
> > > +    /* The RSA private exponent */
> > > +    struct virtio_crypto_iovec d;
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_priv_key_rep2{
> > > +    /* The first factor */
> > > +    struct virtio_crypto_iovec p;
> > > +    /* The second factor */
> > > +    struct virtio_crypto_iovec q;
> > > +    /* The first factor's CRT exponent */
> > > +    struct virtio_crypto_iovec dp;
> > > +    /* The second factor's CRT exponent */
> > > +    struct virtio_crypto_iovec dq;
> > > +    /* The first CRT coeffieient */
> > > +    struct virtio_crypto_iovec qinv;
> > > +    /* The factors array when prime_number > 2 */
> > > +    struct virtio_crypto_iovec r[];
> > > +    /* The CRT exponent array when prime_number > 2 */
> > > +    struct virtio_crypto_iovec d[];
> > > +    /* The CRT coeffieient array when prime_number > 2 */
> > > +    struct virtio_crypto_iovec t[];
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_priv_key {
> > > +    le32 prime_number;
> > > +#define VIRTIO_CRYPTO_RSA_PRIV_KEY_REPTYPE1 0
> > > +#define VIRTIO_CRYPTO_RSA_PRIV_KEY_REPTYPE2 1
> > > +    le32 priv_key_rep_type;
> > > +    union {
> > > +        struct virtio_crypto_rsa_priv_key_rep1 privkey_rep1;
> > > +        struct virtio_crypto_rsa_priv_key_rep2 privkey_rep2;
> > > +    }key;
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_sign_para {
> > > +    /* Hash alogrithms applied to msg */
> > > +    le32 hash_algo;
> > > +    le32 padding_mode;
> > > +    struct virtio_crypto_rsa_priv_key priv_key;
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_sign_output {
> > > +    struct virtio_crypto_iovec msg;
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_sign_input {
> > > +    le32 status;
> > > +    le32 reserved;
> > > +
> > > +    struct virtio_crypto_iovec signature;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +RSA signature operation request is defined as below:
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_rsa_sign_req {
> > > +    struct virtio_crypto rsa_sign_para parameter;
> > > +    struct virtio_crypto rsa_sign_output odata;
> > > +
> > > +    struct virtio_crypto rsa_sign_input idata;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\subparagraph{Device Requirements: RSA signature
> > > operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The device SHOULD set the operation results in \field{idata} according to
> > the
> > > general device requirments for asymmetric crypto service.
> > > +
> > > +\subparagraph{Driver Requirements: RSA signature
> > > operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The driver SHOULD set the \field{opcode} in
> > \field{virtio_crypto_op_header} to
> > > VIRTIO_CRYPTO_ASYM_SIGN,
> > > +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> > > +
> > > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> > except
> > > field \field{reserved}.
> > > +
> > > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > > before it operates other fields in \field{idata}.
> > > +Only if the operation is successful, the \field{signature} in \field{idata} is
> > > operatable.
> > > +
> > > +\paragraph{Verification: Common Structure}\label{sec:Device Types /
> > > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > > Service}
> > > +
> > > +The result of verification operation can be represented by structure
> > > \field{virtio_crypto_asym_verify_gen_input}.
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_asym_verify_gen_input {
> > > +    /* Operation result */
> > > +    le32 status;
> > > +    /* Verification result */
> > > +#define VIRTIO_CRYPTO_ASYM_VERIFY_SUCCESS 0
> > > +#define VIRTIO_CRYPTO_ASYM_VERIFY_FAIL -1
> >
> > Why not use the following generic results?
> >
> > #define VIRTIO_CRYPTO_OP_OK        0
> > #define VIRTIO_CRYPTO_OP_ERR       1
> > #define VIRTIO_CRYPTO_OP_BADMSG    2
> >
> > And the VIRTIO_CRYPTO_OP_BADMSG is used to show the verification result
> > is incorrect.
> 
> I think this is two different semantic meanings, one is operation result,
> the other is verification result especially it only exists in verification, so I think it
> makes sense to
> use two different sets of error codes with different names.

Verification is a kind of operation I think, but...

> Probably we can remove OP from current error code, e.g,  s/
> VIRTIO_CRYPTO_OP_ERR /VIRTIO_CRYPTO_ERR,
> then it makes more sense to use these error codes through the entire
> virtio-crypto spec.
> 
...I agree. Let's do it in the following version.

Regards,
-Gonglei

> >
> > > +    le32 verify_result;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\paragraph{Verification: ECDSA Verification Operation}\label{sec:Device
> > Types
> > > /
> > > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > > Service}
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_ecdsa_verify_para {
> > > +    /* Hash alogrithms applied to msg */
> > > +    le32 hash_algo;
> > > +    le32 reserved;
> > > +
> > > +    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
> > > +    /* EC Group parameters */
> > > +    struct virtio_crypto_ec_group ec;
> > > +
> > > +    /* Public key */
> > > +    struct virtio_crypto_iovec x;
> > > +    struct virtio_crypto_iovec y;
> > > +};
> > > +
> > > +struct virtio_crypto_ecdsa_verify_output {
> > > +    /* Signature value */
> > > +    struct virtio_crypto_iovec r;
> > > +    struct virtio_crypto_iovec s;
> > > +
> > > +    struct virtio_crypto_iovec msg;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +ECDSA Verification Operation request is defined as below:
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_ecdsa_verify_req {
> > > +    struct virtio_crypto_ecdsa_verify_para parameter;
> > > +    struct virtio_crypto_ecdsa_verify_output odata;
> > > +
> > > +    struct virtio_crypto_asym_verify_gen_input idata;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > > before it checks \field{verify_result}.
> > > +
> > > +\paragraph{Verification: RSA Verification Operation}\label{sec:Device
> > Types /
> > > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > > Service}
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_rsa_verify_para {
> > > +    le32 hash_algo;
> > > +    le32 padding_mode;
> > > +    struct virtio_crypto_rsa_pub_key pubkey;
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_verify_output {
> > > +    struct virtio_crypto_iovec msg;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +RSA verification operation request is defined as below:
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_rsa_verify_req {
> > > +    struct virtio_crypto_rsa_verify_para parameter;
> > > +    struct virtio_crypto_rsa_verify_output odata;
> > > +
> > > +    struct virtio_crypto_asym_verify_gen_input idata;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\subparagraph{Device Requirements: RSA Verification
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The device SHOULD set the operation results in \field{idata}.
> > > +
> > > +\subparagraph{Driver Requirements: RSA Verification
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The driver SHOULD set the \field{opcode} in
> > \field{virtio_crypto_op_header} to
> > > VIRTIO_CRYPTO_ASYM_VERIFY,
> > > +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> > > +
> > > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> > except
> > > field \field{reserved}.
> > > +
> > > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > > before it checks \field{verify_result}.
> > > +
> > > +\paragraph{Encryption: RSA Encryption Operation}\label{sec:Device Types
> > /
> > > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > > Service}
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_rsa_enc_para {
> > > +    le32 padding_mode;
> > > +    le32 reserved;
> > > +    struct rsa_pub_key pub_key;
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_enc_output {
> > > +    struct virtio_crypto_iovec msg;
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_enc_input {
> > > +    le32 status;
> > > +    le32 reserved;
> > > +
> > > +    struct virtio_crypto_iovec cmsg;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +RSA encryption operation request is defined as below:
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_rsa_enc_req {
> > > +    struct virtio_crypto_rsa_enc_para parameter;
> > > +    struct virtio_crypto_rsa_enc_output odata;
> > > +
> > > +    struct virtio_crypto_rsa_enc_input idata;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\subparagraph{Device Requirements: RSA Encryption
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The device SHOULD set the operation results in \field{idata} according to
> > the
> > > general device requirments for asymmetric crypto service.
> > > +
> > > +\subparagraph{Driver Requirements: RSA Encryption
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The driver SHOULD set the \field{opcode} in
> > \field{virtio_crypto_op_header} to
> > > VIRTIO_CRYPTO_ASYM_ENCRYPT,
> > > +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> > > +
> > > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> > except
> > > field \field{reserved}.
> > > +
> > > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > > before it operates other fields in \field{idata}.
> > > +Only if the operation is successful, the \field{cmsg} in \field{idata} is
> > > operatable.
> > > +
> > > +\paragraph{Decryption: RSA Decryption Operation}\label{sec:Device
> > Types /
> > > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > > Service}
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_rsa_dec_para {
> > > +    le32 padding_mode;
> > > +    le32 reserved;
> > > +    struct virtio_crypto_rsa_priv_key priv_key;
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_dec_output {
> > > +    struct virtio_crypto_iovec cmsg;
> > > +}
> > > +
> > > +struct virtio_crypto_rsa_dec_input {
> > > +    le32 status;
> > > +    le32 reserved;
> > > +
> > > +    struct virtio_crypto_iovec msg;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +RSA decryption operation request is defined as below:
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_rsa_dec_req {
> > > +    struct virtio_crypto_rsa_dec_para parameter;
> > > +    struct virtio_crypto_rsa_dec_output odata;
> > > +
> > > +    struct virtio_crypto_rsa_dec_input idata;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\subparagraph{Device Requirements: RSA Decryption
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The device SHOULD set the operation results in \field{idata} according to
> > the
> > > general device requirments for asymmetric crypto service.
> > > +
> > > +\subparagraph{Driver Requirements: RSA Decryption
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The driver SHOULD set the \field{opcode} in
> > \field{virtio_crypto_op_header} to
> > > VIRTIO_CRYPTO_ASYM_DECRYPT,
> > > +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> > > +
> > > +The driver SHOULD set all fields in \field{parameter} and \field{odata}
> > except
> > > field \field{reserved}.
> > > +
> > > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > > before it operates other fields in \field{idata}.
> > > +Only if the operation is successful, the \field{msg} in \field{idata} is
> > operatable.
> > > +
> > > +\paragraph{Key Generation: RSA Key Generation
> > Operation}\label{sec:Device
> > > Types /
> > > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > > Service}
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_rsa_keygen_para {
> > > +    /* The modules length in bytes */
> > > +    le32 modulus_len;
> > > +    le32 rsa_prime_number;
> > > +    le32 priv_key_rep_type;
> > > +    le32 reserved;
> > > +
> > > +    /* the public exponent */
> > > +    struct virtio_crypto_iovec e;
> > > +};
> > > +
> > > +struct virtio_crypto_rsa_keygen_input {
> > > +    le32 status;
> > > +    le32 reserved;
> > > +
> > > +    struct virtio_crypto_rsa_priv_key priv_key;
> > > +    struct virtio_crypto_rsa_pub_key pub_key;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +RSA key-generation operation request is defined as below:
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_rsa_keygen_req {
> > > +    struct virtio_crypto_rsa_keygen_para parameter;
> > > +
> > > +    struct virtio_crypto_rsa_keygen_input idata;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\subparagraph{Device Requirements: RSA Key Generation
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The device SHOULD set the operation results in \field{idata} according to
> > the
> > > general device requirments for asymmetric crypto service.
> > > +
> > > +\subparagraph{Driver Requirements: RSA Key Generation
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The driver SHOULD set the \field{opcode} in
> > \field{virtio_crypto_op_header} to
> > > VIRTIO_CRYPTO_ASYM_KEY_GEN,
> > > +set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
> > > +
> > > +The driver SHOULD set all fields in \field{parameter} except
> > \field{reserved}
> > > field.
> > > +
> > > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > > before it operates other fields in \field{idata}.
> > > +Only if the operation is successful, the \field{priv_key} and \field{pub_key}
> > in
> > > \field{idata} are operatable.
> > > +
> > > +\paragraph{Key Generation: DSA Key Generation
> > operation}\label{sec:Device
> > > Types /
> > > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > > Service}
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_dsa_keygen_para {
> > > +    le32 modulus_len;
> > > +    le32 reserved;
> > > +};
> > > +
> > > +struct virtio_crypto_dsa_keygen_input {
> > > +    le32 status;
> > > +    le32 reserved;
> > > +
> > > +    /* DSA Group parameters */
> > > +    struct virtio_crypto_dsa_group dsa;
> > > +    /* Private key */
> > > +    struct virtio_crypto_iovec x;
> > > +    /* Public key */
> > > +    struct virtio_crypto_iovec y;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +DSA key-generation operation request is defined as below:
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_dsa_keygen_req {
> > > +    struct virtio_crypto_dsa_keygen_para parameter;
> > > +
> > > +    struct virtio_crypto_dsa_keygen_input idata;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\subparagraph{Device Requirements: DSA Key Generation
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The device SHOULD set the operation results in \field{idata} according to
> > the
> > > general device requirments for asymmetric crypto service.
> > > +
> > > +\subparagraph{Driver Requirements: DSA Key Generation
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The driver SHOULD set the \field{opcode} in
> > \field{virtio_crypto_op_header} to
> > > VIRTIO_CRYPTO_ASYM_KEY_GEN,
> > > +set \field{algo} to VIRTIO_CRYPTO_ASYM_DSA.
> > > +
> > > +The driver SHOULD set all fields in \field{parameter} except
> > \field{reserved}
> > > field.
> > > +
> > > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > > before it operates other fields in \field{idata}.
> > > +Only if the operation is successful, the \field{priv_key} and \field{pub_key}
> > in
> > > \field{idata} are operatable.
> > > +
> > > +\paragraph{Key Generation: EC Key Generation
> > operation }\label{sec:Device
> > > Types /
> > > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > > Service}
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_ec_keygen_para {
> > > +    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
> > > +
> > > +    /* EC group parameters */
> > > +    struct virtio_crypto_ec_group ec;
> > > +};
> > > +
> > > +struct virtio_crypto_ec_keygen_input {
> > > +    le32 status;
> > > +    le32 reserved;
> > > +
> > > +    /* Private key */
> > > +    struct virtio_crypto_iovec d;
> > > +
> > > +    /* Public key */
> > > +    struct virtio_crypto_iovec x;
> > > +    struct virtio_crypto_iovec y;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +EC key-generation operation request is defined as below:
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_ec_keygen_req {
> > > +    struct virtio_crypto_ec_keygen_para parameter;
> > > +
> > > +    struct virtio_crypto_ec_keygen_input key;
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\subparagraph{Device Requirements: EC Key Generation
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The device SHOULD set the operation results in \field{idata} according to
> > the
> > > general device requirments for asymmetric crypto service.
> > > +
> > > +\subparagraph{Driver Requirements: EC Key Generation
> > > Operation}\label{sec:Device Types / Crypto Device /
> > > +Device Operation / Crypto operation / Asymmetric Crypto Service}
> > > +The driver SHOULD set the \field{opcode} in
> > \field{virtio_crypto_op_header} to
> > > VIRTIO_CRYPTO_ASYM_KEY_GEN,
> > > +set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDH or
> > > VIRTIO_CRYPTO_ASYM_ECDSA.
> > > +
> > > +The driver SHOULD set all fields in \field{parameter} except
> > \field{reserved}
> > > field.
> > > +
> > > +The driver SHOULD check the operation result \field{status} in \field{idata}
> > > before it operates other fields in \field{idata}.
> > > +Only if the operation is successful, the other fields in \field{idata} are
> > > operatable.
> > > +
> > > +\paragraph{Key Exchange: Common Structure}\label{sec:Device Types /
> > > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > > Service}
> > > +
> > > +Key Exchange request has two kinds of operations in general, key
> > generation
> > > and key computation.
> > > +For DH, it has additional operation: parameter generation operation.
> > > +
> > > +\begin{lstlisting}
> > > +typdef enum VIRTIO_CRYPTO_KEY_EXCHANGE_OP {
> > > +    VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_KEY,
> > > +    VIRTIO_CRYPTO_KEY_EXCHANGE_COMPUTE_KEY,
> > > +    /* It's only valid in case algorithm is DH */
> > > +    VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_DH_PARAM
> > > +} VIRTIO_CRYPTO_KEY_EXCHANGE_OP;
> > > +\end{lstlisting}
> > > +
> > > +\paragraph{Key Exchange: DH Parameter Generation
> > > Operation}\label{sec:Device Types /
> > > +Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto
> > > Service}
> > > +
> > > +\begin{lstlisting}
> > > +struct virtio_crypto_dh_parameter {
> > > +    le32 modules_len;
> > > +    le32 reserved;
> > > +
> > > +    /* random odd prime number */
> > > +    struct virtio_crypto_iovec p;
> > > +    /* base (g) */
> > > +    struct virtio_crypto_iovec g;
> > > +};
> > > +
> > > +struct virtio_crypto_dh_keyexchg_para {
> > > +    VIRTIO_CRYPTO_KEY_EXCHANGE_OP keyexchg_op;
> >
> > sizeof(enum foo) is implementation-specific according to the C standard.
> > You must explicitly choose a type (u8, le16, le32) in this specification
> > so that the struct layout is compatible between compilers.
> >
> 
> You are right. Will fix this.
> 
> > You can move keyexchg_op to struct virtio_crypto_dh_parameter,
> > instead of the reserved property.
> 
> They represent two different semantic meaning. I preferred to keep current
> structure definition.
> 
> >
> > > --
> > > 1.9.3
> >
> >
> > Regards,
> > -Gonglei

Patch

diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index c3554e3..699d8dc 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -46,6 +46,7 @@  struct virtio_crypto_config {
     le32 kdf_algo;
     le32 aead_algo;
     le32 primitive_algo;
+    le32 rsa_padding;
 };
 \end{lstlisting}
 
@@ -67,6 +68,7 @@  The following services are defined:
 #define VIRTIO_CRYPTO_SERVICE_HASH   (1) /* HASH service */
 #define VIRTIO_CRYPTO_SERVICE_MAC    (2) /* MAC (Message Authentication Codes) service */
 #define VIRTIO_CRYPTO_SERVICE_AEAD   (3) /* AEAD (Authenticated Encryption with Associated Data) service */
+#define VIRTIO_CRYPTO_SERVICE_ASYM  (4) /* Asymmetric crypto service*/
 \end{lstlisting}
 
 The last driver-read-only fields specify detailed algorithms masks 
@@ -140,6 +142,28 @@  The following AEAD algorithms are defined:
 #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3
 \end{lstlisting}
 
+The following asymmetric algorithms are defined:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_ASYM_NONE        0
+#define VIRTIO_CRYPTO_ASYM_RSA         1
+#define VIRTIO_CRYPTO_ASYM_DSA         2
+#define VIRTIO_CRYPTO_ASYM_DH          3
+#define VIRTIO_CRYPTO_ASYM_ECDSA       4
+#define VIRTIO_CRYPTO_ASYM_ECDH	       5
+\end{lstlisting}
+
+The following rsa padding capabilities are defined:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_RSA_NO_PADDING         0
+#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING      1
+#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING     2
+#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING 3
+#define VIRTIO_CRYPTO_RSA_X931_PADDING       4
+#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING  5
+\end{lstlisting}
+
 \begin{note}
 More algorithms will be defined in the future.
 \end{note}
@@ -238,6 +262,18 @@  struct virtio_crypto_op_header {
     VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
 #define VIRTIO_CRYPTO_AEAD_DECRYPT \
     VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
+#define VIRTIO_CRYPTO_ASYM_SIGN    \
+    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x00)
+#define VIRTIO_CRYPTO_ASYM_VERIFY \
+    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x01)
+#define VIRTIO_CRYPTO_ASYM_ENCRYPT  \
+    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x02)
+#define VIRTIO_CRYPTO_ASYM_DECRYPT  \
+    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x03)
+#define VIRTIO_CRYPTO_ASYM_KEY_GEN  \
+    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x04)
+#define VIRTIO_CRYPTO_ASYM_KEY_EXCHG \
+    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x05)
     le32 opcode;
     /* algo should be service-specific algorithms */
     le32 algo;
@@ -540,6 +576,26 @@  struct virtio_crypto_op_data_req {
         struct virtio_crypto_hash_data_req  hash_req;
         struct virtio_crypto_mac_data_req   mac_req;
         struct virtio_crypto_aead_data_req  aead_req;
+        struct virtio_crypto_ecdsa_sign_req ecdsa_sign_req;
+        struct virtio_crypto_dsa_sign_req dsa_sign_req;
+        struct virtio_crypto_rsa_sign_req rsa_sign_req;
+
+        struct virtio_crypto_ecdsa_verify_req ecdsa_verify_req;
+        struct virtio_crypto_dsa_verify_req dsa_verify_req;
+        struct virtio_crypto_rsa_verify_req rsa_verify_req;
+
+        struct virtio_crypto_rsa_enc_req rsa_enc_req
+        struct virtio_crypto_rsa_dec_req rsa_dec_req;
+
+        struct virtio_crypto_rsa_keygen_req rsa_keygen_req;
+        struct virtio_crypto_dsa_keygen_req dsa_keygen_req;
+        struct virtio_crypto_ec_keygen_req ec_keygen_req;
+
+        struct virtio_crypto_dh_keyexchg_param_gen_req dh_keyexchg_param_gen_req;
+        struct virtio_crypto_dh_keyexchg_key_gen_req dh_keyexchg_key_gen_req;
+        struct virtio_crypto_dh_keyexchg_key_compute_req dh_keyexchg_key_compute_req;
+        struct virtio_crypto_ecdh_keyexchg_key_gen_req ecdh_keyexchg_key_gen_req;
+        struct virtio_crypto_ecdh_keyexchg_key_compute_req ecdh_keyexchg_key_compute_req;
     } u;
 };
 \end{lstlisting}
@@ -939,4 +995,878 @@  The device MUST parse the virtio_crypto_aead_data_req based on the \field{op_cod
 The device MUST copy the result of cryptographic operation to the guest memory recorded by \field{dst_data}.\field{addr} field in struct virtio_crypto_aead_input.
 The device MUST copy the digest result to the guest memory recorded by \field{digest_result_addr} field in struct virtio_crypto_aead_input.
 The device MUST set the \field{status} field in strut virtio_crypto_aead_input: VIRTIO_CRYPTO_OP_OK: success; VIRTIO_CRYPTO_OP_ERR: creation failed or device error; VIRTIO_CRYPTO_OP_NOTSUPP: not supported.
-When the \field{op_code} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device MUST verify and return the verification result to the driver, and if the verification result is incorrect, VIRTIO_CRYPTO_OP_BADMSG (bad message) MUST be returned to the driver.
\ No newline at end of file
+When the \field{op_code} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device MUST verify and return the verification result to the driver, and if the verification result is incorrect, VIRTIO_CRYPTO_OP_BADMSG (bad message) MUST be returned to the driver.
+\subsubsection{Asymmetric Crypto Service}\label{sec:Device Types / Crypto Device / Device Operation /
+Crypto operation / Asymmetric Crypto Service}
+
+In general, asymmetric crypto service can be referred as signature, verification,
+encryption, decryption, key generation and key exchange. Not each algorithm supports
+all these services.
+
+Unlike symmetric crypto service, asymmetric crypto service normally does't
+need session operations, the request is encapsulated within one packet which is represented 
+by \field{virtio_crypto_op_data_req}.
+(see \ref{sec:Device Types / Crypto Device / Device Operation / Data Virtqueue}).
+
+Once service request is handled by the device, the device writes back the operation results to the corresponding
+fields in the request packet.
+
+\paragraph{General Device Requirements: Asymmetric Crypto Service}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD parse the field \field{opcode} within \field{virtio_crypto_op_header} then handle the corresponding service request.
+
+The device SHOULD set the operation status in field \field{status} within \field{idata}.
+
+The device SHOULD write back the operation result to the iovec buffer, which is represented by \field{virtio_crypto_iovec} within \field{idata} if the operation is successful.
+
+\paragraph{General Driver Requirements: Asymmetric Crypto Service}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the corresponding \field{opcode} in \field{virtio_crypto_op_header} according to different services.
+
+The driver SHOULD offers operatable iovec buffer represented by \field{virtio_crypto_iovec} within \field{idata} if the service request structure defines.
+
+\paragraph{Signature: ECDSA signature operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_ec_group {
+    struct virtio_crypto_iovec xg;
+    struct virtio_crypto_iovec yg;
+    struct virtio_crypto_iovec n;
+    struct virtio_crypto_iovec q;
+    struct virtio_crypto_iovec a;
+    struct virtio_crypto_iovec b;
+    struct virtio_crypto_iovec h;
+};
+
+typedef enum {
+    VIRTIO_CRYPTO_EC_FIELD_TYPE_PRIME,
+    VIRTIO_CRYPTO_EC_FIELD_TYPE_BINARY
+} VIRTIO_CRYPTO_EC_FIELD_TYPE;
+
+struct virtio_crypto_ecdsa_sign_para{
+    /* Hash alogrithms applied to msg */
+    le32 hash_algo;
+    le32 reserved;
+    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
+
+    /* EC Group parameters */
+    struct virtio_crypto_ec_group ec;
+    /* Random value */
+    struct virtio_crypto_iovec k;
+    /* Private Key */
+    struct virtio_crypto_iovec d;
+};
+
+struct virtio_crypto_ecdsa_sign_output {
+    /* Message need to be signed */
+    struct virtio_crypto_iovec msg;
+};
+
+struct virtio_crypto_ecdsa_sign_input {
+    /* operation result */
+    le32 status;
+    le32 reserved;
+
+    /* signature result */
+    struct virtio_crypto_iovec r;
+    struct virtio_crypto_iovec s;
+};
+\end{lstlisting}
+
+ECDSA signature operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_ecdsa_sign_req {
+    struct virtio_crypto_ecdsa_sign_para parameter;
+    struct virtio_crypto_ecdsa_sign_output odata;
+
+    struct virtio_crypto_ecdsa_sign_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: ECDSA signature operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: ECDSA signature operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_SIGN,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDSA.
+
+The driver SHOULD set all fields in \field{parameter} and \field{odata} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it operates other fields in \field{idata}.
+Only if the operation is successful, the \field{r,s} in \field{idata} are operatable.
+
+\paragraph{Signature: DSA signature operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_dsa_group {
+    struct virtio_crypto_iovec p;
+    struct virtio_crypto_iovec q;
+    struct virtio_crypto_iovec g;
+};
+
+struct virtio_crypto_dsa_sign_para {
+    /* Hash alogrithms applied to msg */
+    le32 hash_algo;
+    le32 reserved;
+
+    /* DSA group parameter */
+    struct virtio_crypto_dsa_group dsa;
+    /* Random value */
+    struct virtio_crypto_iovec k;
+    /* Private Key */
+    struct virtio_crypto_iovec x;
+};
+
+struct virtio_crypto_dsa_sign_output {
+    struct virtio_crypto_iovec msg;
+};
+
+struct virtio_crypto_dsa_sign_input  {
+    /* operation result */
+    le32 status;
+    le32 reserved;
+
+    /* signature result */
+    struct virtio_crypto_iovec r;
+    struct virtio_crypto_iovec s;
+};
+\end{lstlisting}
+DSA signature operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_dsa_sign_req {
+    struct virtio_crypto_dsa_sign_para parameter;
+    struct virtio_crypto_dsa_sign_output odata;
+
+    struct virtio_crypto_dsa_sign_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: DSA signature operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: DSA signature operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_SIGN,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_DSA.
+
+The driver SHOULD set all fields in \field{parameter} and \field{odata} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it operates other fields in \field{idata}.
+Only if the operation is successful, the \field{r,s} in \field{idata} are operatable.
+
+\paragraph{Signature: RSA signature operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_rsa_pub_key{
+    /* The RSA modules */
+    struct virtio_crypto_iovec n;
+    /* The RSA public exponent */
+    struct virtio_crypto_iovec e;
+};
+
+struct virtio_crypto_rsa_priv_key_rep1{
+    /* The RSA modules */
+    struct virtio_crypto_iovec n;
+    /* The RSA private exponent */
+    struct virtio_crypto_iovec d;
+};
+
+struct virtio_crypto_rsa_priv_key_rep2{
+    /* The first factor */
+    struct virtio_crypto_iovec p;
+    /* The second factor */
+    struct virtio_crypto_iovec q;
+    /* The first factor's CRT exponent */
+    struct virtio_crypto_iovec dp;
+    /* The second factor's CRT exponent */
+    struct virtio_crypto_iovec dq;
+    /* The first CRT coeffieient */
+    struct virtio_crypto_iovec qinv;    
+    /* The factors array when prime_number > 2 */
+    struct virtio_crypto_iovec r[];
+    /* The CRT exponent array when prime_number > 2 */
+    struct virtio_crypto_iovec d[];
+    /* The CRT coeffieient array when prime_number > 2 */
+    struct virtio_crypto_iovec t[];
+};
+
+struct virtio_crypto_rsa_priv_key {
+    le32 prime_number;
+#define VIRTIO_CRYPTO_RSA_PRIV_KEY_REPTYPE1 0
+#define VIRTIO_CRYPTO_RSA_PRIV_KEY_REPTYPE2 1
+    le32 priv_key_rep_type;
+    union {
+        struct virtio_crypto_rsa_priv_key_rep1 privkey_rep1;
+        struct virtio_crypto_rsa_priv_key_rep2 privkey_rep2;
+    }key;
+};
+
+struct virtio_crypto_rsa_sign_para {
+    /* Hash alogrithms applied to msg */
+    le32 hash_algo;
+    le32 padding_mode;    
+    struct virtio_crypto_rsa_priv_key priv_key;
+};
+
+struct virtio_crypto_rsa_sign_output {
+    struct virtio_crypto_iovec msg;
+};
+
+struct virtio_crypto_rsa_sign_input {
+    le32 status;
+    le32 reserved;
+
+    struct virtio_crypto_iovec signature;
+};
+\end{lstlisting}
+
+RSA signature operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_rsa_sign_req {
+    struct virtio_crypto rsa_sign_para parameter;
+    struct virtio_crypto rsa_sign_output odata;
+
+    struct virtio_crypto rsa_sign_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: RSA signature operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: RSA signature operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_SIGN,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
+
+The driver SHOULD set all fields in \field{parameter} and \field{odata} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it operates other fields in \field{idata}.
+Only if the operation is successful, the \field{signature} in \field{idata} is operatable.
+
+\paragraph{Verification: Common Structure}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+The result of verification operation can be represented by structure \field{virtio_crypto_asym_verify_gen_input}.
+
+\begin{lstlisting}
+struct virtio_crypto_asym_verify_gen_input {
+    /* Operation result */
+    le32 status;    
+    /* Verification result */
+#define VIRTIO_CRYPTO_ASYM_VERIFY_SUCCESS 0
+#define VIRTIO_CRYPTO_ASYM_VERIFY_FAIL -1
+    le32 verify_result;
+};
+\end{lstlisting}
+
+\paragraph{Verification: ECDSA Verification Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_ecdsa_verify_para {
+    /* Hash alogrithms applied to msg */
+    le32 hash_algo;
+    le32 reserved;
+    
+    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
+    /* EC Group parameters */
+    struct virtio_crypto_ec_group ec;
+
+    /* Public key */
+    struct virtio_crypto_iovec x;
+    struct virtio_crypto_iovec y;
+};
+
+struct virtio_crypto_ecdsa_verify_output {
+    /* Signature value */
+    struct virtio_crypto_iovec r;
+    struct virtio_crypto_iovec s;
+ 
+    struct virtio_crypto_iovec msg;
+};
+\end{lstlisting}
+
+ECDSA Verification Operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_ecdsa_verify_req {
+    struct virtio_crypto_ecdsa_verify_para parameter;
+    struct virtio_crypto_ecdsa_verify_output odata;
+
+    struct virtio_crypto_asym_verify_gen_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: ECDSA Verification Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: ECDSA Verification Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_VERIFY,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDSA.
+
+The driver SHOULD set all fields in \field{parameter} and \field{odata} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it checks \field{verify_result}.
+
+\paragraph{Verification: DSA Verification Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_dsa_verify_para {
+    le32 hash_algo;
+    le32 reserved;
+
+    /* DSA Group parameters */
+    struct virtio_crypto_dsa_group dsa;
+
+    /* Public key */
+    struct virtio_crypto_iovec y;
+};
+
+struct virtio_crypto_dsa_verify_output {
+    /* Signature value */
+    struct virtio_crypto_iovec r;
+    struct virtio_crypto_iovec s;
+
+    struct virtio_crypto_iovec msg;
+};
+\end{lstlisting}
+
+DSA Verification Operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_dsa_verify_req {
+    struct virtio_crypto_dsa_verify_para parameter;
+    struct virtio_crypto_dsa_verify_output odata;
+
+    struct virtio_crypto_asym_verify_gen_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: DSA Verification Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata}.
+
+\subparagraph{Driver Requirements: DSA Verification Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_VERIFY,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_DSA.
+
+The driver SHOULD set all fields in \field{parameter} and \field{odata} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it checks \field{verify_result}.
+
+\paragraph{Verification: RSA Verification Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_rsa_verify_para {
+    le32 hash_algo;
+    le32 padding_mode;
+    struct virtio_crypto_rsa_pub_key pubkey;
+};
+
+struct virtio_crypto_rsa_verify_output {
+    struct virtio_crypto_iovec msg;
+};
+\end{lstlisting}
+
+RSA verification operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_rsa_verify_req {
+    struct virtio_crypto_rsa_verify_para parameter;
+    struct virtio_crypto_rsa_verify_output odata;    
+
+    struct virtio_crypto_asym_verify_gen_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: RSA Verification Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata}.
+
+\subparagraph{Driver Requirements: RSA Verification Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_VERIFY,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
+
+The driver SHOULD set all fields in \field{parameter} and \field{odata} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it checks \field{verify_result}.
+
+\paragraph{Encryption: RSA Encryption Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_rsa_enc_para {
+    le32 padding_mode;
+    le32 reserved;
+    struct rsa_pub_key pub_key;
+};
+
+struct virtio_crypto_rsa_enc_output {
+    struct virtio_crypto_iovec msg;
+};
+
+struct virtio_crypto_rsa_enc_input {
+    le32 status;
+    le32 reserved;
+
+    struct virtio_crypto_iovec cmsg;
+};
+\end{lstlisting}
+
+RSA encryption operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_rsa_enc_req {
+    struct virtio_crypto_rsa_enc_para parameter;
+    struct virtio_crypto_rsa_enc_output odata;
+    
+    struct virtio_crypto_rsa_enc_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: RSA Encryption Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: RSA Encryption Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_ENCRYPT,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
+
+The driver SHOULD set all fields in \field{parameter} and \field{odata} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it operates other fields in \field{idata}.
+Only if the operation is successful, the \field{cmsg} in \field{idata} is operatable.
+
+\paragraph{Decryption: RSA Decryption Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_rsa_dec_para {
+    le32 padding_mode;
+    le32 reserved;
+    struct virtio_crypto_rsa_priv_key priv_key;
+};
+
+struct virtio_crypto_rsa_dec_output {
+    struct virtio_crypto_iovec cmsg;
+}
+
+struct virtio_crypto_rsa_dec_input {
+    le32 status;
+    le32 reserved;
+
+    struct virtio_crypto_iovec msg;
+};
+\end{lstlisting}
+
+RSA decryption operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_rsa_dec_req {
+    struct virtio_crypto_rsa_dec_para parameter;
+    struct virtio_crypto_rsa_dec_output odata;
+
+    struct virtio_crypto_rsa_dec_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: RSA Decryption Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: RSA Decryption Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_DECRYPT,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
+
+The driver SHOULD set all fields in \field{parameter} and \field{odata} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it operates other fields in \field{idata}.
+Only if the operation is successful, the \field{msg} in \field{idata} is operatable.
+
+\paragraph{Key Generation: RSA Key Generation Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_rsa_keygen_para {
+    /* The modules length in bytes */
+    le32 modulus_len;
+    le32 rsa_prime_number;
+    le32 priv_key_rep_type;
+    le32 reserved;
+
+    /* the public exponent */
+    struct virtio_crypto_iovec e;
+};
+
+struct virtio_crypto_rsa_keygen_input {
+    le32 status;
+    le32 reserved;
+
+    struct virtio_crypto_rsa_priv_key priv_key;
+    struct virtio_crypto_rsa_pub_key pub_key;
+};
+\end{lstlisting}
+
+RSA key-generation operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_rsa_keygen_req {
+    struct virtio_crypto_rsa_keygen_para parameter;
+
+    struct virtio_crypto_rsa_keygen_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: RSA Key Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: RSA Key Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_KEY_GEN,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_RSA.
+
+The driver SHOULD set all fields in \field{parameter} except \field{reserved} field.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it operates other fields in \field{idata}.
+Only if the operation is successful, the \field{priv_key} and \field{pub_key} in \field{idata} are operatable.
+
+\paragraph{Key Generation: DSA Key Generation operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_dsa_keygen_para {
+    le32 modulus_len;
+    le32 reserved;
+};
+
+struct virtio_crypto_dsa_keygen_input {
+    le32 status;
+    le32 reserved;
+
+    /* DSA Group parameters */
+    struct virtio_crypto_dsa_group dsa;
+    /* Private key */
+    struct virtio_crypto_iovec x;
+    /* Public key */
+    struct virtio_crypto_iovec y;
+};
+\end{lstlisting}
+
+DSA key-generation operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_dsa_keygen_req {
+    struct virtio_crypto_dsa_keygen_para parameter;
+
+    struct virtio_crypto_dsa_keygen_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: DSA Key Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: DSA Key Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_KEY_GEN,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_DSA.
+
+The driver SHOULD set all fields in \field{parameter} except \field{reserved} field.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it operates other fields in \field{idata}.
+Only if the operation is successful, the \field{priv_key} and \field{pub_key} in \field{idata} are operatable.
+
+\paragraph{Key Generation: EC Key Generation operation }\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_ec_keygen_para {
+    VIRTIO_CRYPTO_EC_FIELD_TYPE field_type;
+
+    /* EC group parameters */
+    struct virtio_crypto_ec_group ec;
+};
+
+struct virtio_crypto_ec_keygen_input {
+    le32 status;
+    le32 reserved;
+
+    /* Private key */
+    struct virtio_crypto_iovec d;
+
+    /* Public key */
+    struct virtio_crypto_iovec x;
+    struct virtio_crypto_iovec y;
+};
+\end{lstlisting}
+
+EC key-generation operation request is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_ec_keygen_req {
+    struct virtio_crypto_ec_keygen_para parameter;
+
+    struct virtio_crypto_ec_keygen_input key;    
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: EC Key Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: EC Key Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_KEY_GEN,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDH or VIRTIO_CRYPTO_ASYM_ECDSA.
+
+The driver SHOULD set all fields in \field{parameter} except \field{reserved} field.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} before it operates other fields in \field{idata}.
+Only if the operation is successful, the other fields in \field{idata} are operatable.
+
+\paragraph{Key Exchange: Common Structure}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+Key Exchange request has two kinds of operations in general, key generation and key computation.
+For DH, it has additional operation: parameter generation operation.
+
+\begin{lstlisting}
+typdef enum VIRTIO_CRYPTO_KEY_EXCHANGE_OP {
+    VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_KEY,
+    VIRTIO_CRYPTO_KEY_EXCHANGE_COMPUTE_KEY,
+    /* It's only valid in case algorithm is DH */
+    VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_DH_PARAM
+} VIRTIO_CRYPTO_KEY_EXCHANGE_OP;
+\end{lstlisting}
+
+\paragraph{Key Exchange: DH Parameter Generation Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_dh_parameter {
+    le32 modules_len;
+    le32 reserved;
+
+    /* random odd prime number */
+    struct virtio_crypto_iovec p;
+    /* base (g) */
+    struct virtio_crypto_iovec g;
+};
+
+struct virtio_crypto_dh_keyexchg_para {
+    VIRTIO_CRYPTO_KEY_EXCHANGE_OP keyexchg_op;
+    struct virtio_crypto_dh_parameter dh_param;
+};
+
+struct virtio_crypto_dh_keyexchg_param_gen_input {
+    le32 status;
+    le32 reserved;
+};
+\end{lstlisting}
+
+DH Parameter Generation Operation in Key-Exchange is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_dh_keyexchg_param_gen_req {
+    struct virtio_crypto_dh_keyexchg_para parameter;
+
+    struct virtio_crypto_dh_keyexchg_param_gen_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: Key Exchange: DH Parameter Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation result in \field{idata}, and set \field{p and g} in \field{dh_param}.
+
+\subparagraph{Driver Requirements: Key Exchange: DH Parameter Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_KEY_EXCHG,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_DH.
+
+The driver SHOULD set the \field{keyexchg_op} to VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_DH_PARAM in \field{parameter}.
+The driver SHOULD set \field{modules_len} in \field{dh_param}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} firstly.
+Only if the operation is successful, the other fields in \field{idata} are operatable.
+
+\paragraph{Key Exchange: DH Key Generation Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_dh_keyexchg_keygen_input {
+    le32 status;
+    le32 reserved;
+
+    /* private key */
+    struct virtio_crypto_iovec x;
+    /* public key */
+    struct virtio_crypto_iovec y;
+};
+\end{lstlisting}
+
+DH Key Generation Operation in Key-Exchange is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_dh_keyexchg_key_gen_req {
+    struct virtio_crypto_dh_keyexchg_para parameter;
+
+    struct virtio_crypto_dh_key_exchg_keygen_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: Key Exchange: DH Key Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: Key Exchange: DH Key Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_KEY_EXCHG,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_DH.
+
+The driver SHOULD set the \field{keyexchg_op} to VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_KEY in \field{parameter}.
+
+The driver SHOULD set all other fields in \field{parameter} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} firstly.
+Only if the operation is successful, the other fields in \field{idata} are operatable.
+
+\paragraph{Key Exchange: DH Key Computation Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_dh_keyexchg_compute_key_output {
+    /* local private key */
+    struct virtio_crypto_iovec x;
+    /* peer's public key */
+    struct virtio_crypto_iovec y;
+};
+
+struct virtio_crypto_dh_keyexchg_compute_key_input {
+    le32 status;
+    le32 reserved;
+
+    struct virtio_crypto_iovec shared_secret;
+};
+\end{lstlisting}
+
+DH Key Computation Operation in Key-Exchange is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_dh_keyexchg_key_compute_req {
+    struct virtio_crypto_dh_keyexchg_para parameter;
+    struct virtio_crypto_dh_keyexchg_compute_key_output odata;
+
+    struct virtio_crypto_dh_keyexchg_compute_key_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: Key Exchange: DH Key Computation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: Key Exchange: DH Key Computation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_KEY_EXCHG,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_DH.
+
+The driver SHOULD set the \field{keyexchg_op} to VIRTIO_CRYPTO_KEY_EXCHANGE_COMPUTE_KEY in \field{parameter}.
+
+The driver SHOULD set all other fields in \field{parameter} except field \field{reserved}.
+
+The driver SHOULD set all fields in \field{odata} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} firstly.
+Only if the operation is successful, the other fields in \field{idata} are operatable.
+
+\paragraph{Key Exchange: ECDH Key Generation Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_ecdh_keyexchg_keygen_para {
+    VIRTIO_CRYPTO_KEY_EXCHANGE_OP keyexchg_op;
+    struct virtio_crypto_ec_keygen_para parameter;
+};
+\end{lstlisting}
+
+ECDH Key Generation Operation in Key-Exchange is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_ecdh_keyexchg_key_gen_req {
+    struct virtio_crypto_ecdh_keyexchg_keygen_para parameter;
+
+    struct virtio_crypto_ec_keygen_input idata;
+};
+\end{lstlisting}
+
+\subparagraph{Device Requirements: Key Exchange: ECDH Key Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: Key Exchange: DH Key Generation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_KEY_EXCHG,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDH.
+
+The driver SHOULD set the \field{keyexchg_op} to VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_KEY in \field{parameter}.
+
+The driver SHOULD set all other fields in \field{parameter} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} firstly.
+Only if the operation is successful, the other fields in \field{idata} are operatable.
+
+\paragraph{Key Exchange: ECDH Key Computation Operation}\label{sec:Device Types /
+Crypto Device / Device Operation / Crypto operation / Asymmetric Crypto Service}
+
+\begin{lstlisting}
+struct virtio_crypto_ecdh_keyexchg_compute_key_para {
+    VIRTIO_CRYPTO_KEY_EXCHANGE_OP keyexchg_op;
+    struct virtio_crypto_ec_keygen_para parameter;
+};
+
+struct virtio_crypto_ecdh_keyexchg_compute_key_output {
+    /* local private key */
+    struct virtio_crypto_iovec d;
+
+    /* peer's public key */
+    struct virtio_crypto_iovec x;
+    struct virtio_crypto_iovec y;
+};
+
+struct virtio_crypto_ecdh_keyexchg_compute_key_input {
+    le32 status;
+    le32 reserved;
+
+    struct virtio_crypto_iovec shared_secret;
+};
+\end{lstlisting}
+
+ECDH Key Computation Operation in Key-Exchange is defined as below:
+\begin{lstlisting}
+struct virtio_crypto_ecdh_keyexchg_key_compute_req {
+    struct virtio_crypto_ecdh_keyexchg_compute_key_para parameter;
+    struct virtio_crypto_ecdh_keyexchg_compute_key_output odata;
+
+    struct virtio_crypto_ecdh_keyexchg_compute_key_input idata;
+};
+\end{lstlisting}
+
+
+\subparagraph{Device Requirements: Key Exchange: ECDH Key Computation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The device SHOULD set the operation results in \field{idata} according to the general device requirments for asymmetric crypto service.
+
+\subparagraph{Driver Requirements: Key Exchange: ECDH Key Computation Operation}\label{sec:Device Types / Crypto Device /
+Device Operation / Crypto operation / Asymmetric Crypto Service}
+The driver SHOULD set the \field{opcode} in \field{virtio_crypto_op_header} to VIRTIO_CRYPTO_ASYM_KEY_EXCHG,
+set \field{algo} to VIRTIO_CRYPTO_ASYM_ECDH.
+
+The driver SHOULD set the \field{keyexchg_op} to VIRTIO_CRYPTO_KEY_EXCHANGE_GEN_KEY in \field{parameter}.
+
+The driver SHOULD set all other fields in \field{parameter} except field \field{reserved}.
+
+The driver SHOULD check the operation result \field{status} in \field{idata} firstly.
+Only if the operation is successful, the other fields in \field{idata} are operatable.