[Qemu-devel] [RFC PATCH v3 1/1] virtio crypto device specification: asymmetric crypto service
This patch introduces asymmetric crypto service into virtio crypto
device spec. The asymmetric crypto service can be referred as signature,
verification, encryption, decryption, key generation and key exchange.
This patch depends on virtio crypto device spec patch:
http://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00291.html
Please help to review, thanks!
Changes since v2:
- Update some sections according to the update of virtio crypto device
spec v15.
- Fix minor spelling mistakes
- Remove trail spaces in the spec
Changes since v1:
- Remove virtio_crypto_buf to be consistent with other virtio devices'
buf representation. [Lei]
- Use "MUST" instead of "SHOULD" in some places. [Lei]
Changes since v0:
- Use devicenormative/drivernormative instead of self-defined
device/driver label. [Lei]
- Change the error code of verification to general virtio_crypto
error code. [Lei]
- Use macro instead of enum in verification result. [Lei]
- Fix the incorrect label value for paragraph and section. [Lei]
Signed-off-by: Xin Zeng <xin.z...@intel.com>
---
virtio-crypto.tex | 1109 -
1 file changed, 1107 insertions(+), 2 deletions(-)
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index 44819f9..d3236df 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -6,7 +6,7 @@ decryption requests are placed in any of teh data active queues
and are ultimate
backend crypto accelerators. The second kind of queue is the control queue
used to create
or destroy sessions for symmetric algorithms and will control some advanced
features in the future. The virtio crypto device provides the following crypto
-services: CIPHER, MAC, HASH, and AEAD.
+services: CIPHER, MAC, HASH, AEAD and ASYM.
\subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
@@ -47,6 +47,9 @@ struct virtio_crypto_config {
le32 mac_algo_l;
le32 mac_algo_h;
le32 aead_algo;
+le32 asym_algo;
+/*Rsa padding capabilities*/
+le32 rsa_padding;
/* Maximum length of cipher key */
le32 max_cipher_key_len;
/* Maximum length of authenticated key */
@@ -80,6 +83,8 @@ The following services are defined:
#define VIRTIO_CRYPTO_SERVICE_MAC2
/* AEAD (Authenticated Encryption with Associated Data) service */
#define VIRTIO_CRYPTO_SERVICE_AEAD 3
+/* ASYM (Asymmetric crypto algorithms) service */
+#define VIRTIO_CRYPTO_SERVICE_ASYM 4
\end{lstlisting}
The last driver-read-only fields specify detailed algorithms masks
@@ -153,6 +158,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_RSA1
+#define VIRTIO_CRYPTO_ASYM_DSA2
+#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_PADDING4
+#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING 5
+\end{lstlisting}
+
\begin{note}
Any other value is reserved for future use.
\end{note}
@@ -168,6 +195,7 @@ Any other value is reserved for future use.
\item The device MUST set \field{max_size} to show the maximum size of crypto
request the device supports.
\item The device MUST set \field{max_cipher_key_len} to show the maximum
length of cipher key if the device supports CIPHER service.
\item The device MUST set \field{max_auth_key_len} to show the maximum length
of authenticated key if the device supports MAC service.
+\item The device MUST set \field{rsa_padding} to show the padding capabilities
offered by the device.
\end{itemize*}
\drivernormative{\subsubsection}{Device configuration layout}{Device Types /
Crypto Device / Device configuration layout}
@@ -182,6 +210,7 @@ Any other value is reserved for future use.
\item The driver SHOULD read \field{max_size} to discover the maximum size of
crypto request the device supports.
\item The driver SHOULD read \field{max_cipher_key_len} to discover the
maximum length of cipher key the device supports.
\item The driver SHOULD read \field{max_auth_key_len} to discover the maximum
length of authenticated key the device supports.
+\item The driver MAY read \field{rsa_padding} to discover the padding
capabilities offered by the device.
\end{itemize*}
\subsection{Device Initialization}\label{sec:Device Types / Crypto Device /
Device Initialization}
@@ -264,6 +293,18 @@ struct virtio_crypto_op_header {
VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
#define VIRTIO_CRYPTO_AEAD_DECRYPT \
VIRTIO_CRYPTO_OPCODE(
[Qemu-devel] [PATCH v2 1/1] virtio crypto device specification: asymmetric crypto service
This patch introduces asymmetric crypto service into virtio crypto
device spec. The asymmetric crypto service can be referred as signature,
verification, encryption, decryption, key generation and key exchange.
This patch depends on virtio crypto device spec patch:
https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg02211.html
Changes since v1:
- Remove virtio_crypto_buf to be consistent buffer structure with other
virtio devices. [Lei]
- Use "MUST" instead of "SHOULD" in some places. [Lei]
Changes since v0:
- Use devicenormative/drivernormative instead of self-defined
device/driver label. [Lei]
- Change the error code of verification to general virtio_crypto
error code. [Lei]
- Use macro instead of enum in verification result. [Lei]
- Fix the incorrect label value for paragraph and section. [Lei]
Please help to review, thanks!
Signed-off-by: Xin Zeng <xin.z...@intel.com>
---
virtio-crypto.tex | 1113 -
1 file changed, 1110 insertions(+), 3 deletions(-)
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index 9f7faf0..c7a5a19 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -6,7 +6,7 @@ decryption requests are placed in the data queue and are
ultimately handled by t
backend crypto accelerators. The second queue is the control queue used to
create
or destroy sessions for symmetric algorithms and will control some advanced
features in the future. The virtio crypto device provides the following crypto
-services: CIPHER, MAC, HASH, and AEAD.
+services: CIPHER, MAC, HASH, AEAD and ASYM.
\subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
@@ -44,11 +44,15 @@ struct virtio_crypto_config {
le32 mac_algo_l;
le32 mac_algo_h;
le32 aead_algo;
+le32 asym_algo;
+/*Rsa padding capabilities*/
+le32 rsa_padding;
/* Maximum length of cipher key */
le32 max_cipher_key_len;
/* Maximum length of authenticated key */
le32 max_auth_key_len;
-le32 reserve;
+le32 reserved;
+
/* Maximum size of each crypto request's content */
le64 max_size;
};
@@ -76,6 +80,8 @@ The following services are defined:
#define VIRTIO_CRYPTO_SERVICE_MAC2
/* AEAD (Authenticated Encryption with Associated Data) service */
#define VIRTIO_CRYPTO_SERVICE_AEAD 3
+/* ASYM (Asymmetric crypto algorithms) service */
+#define VIRTIO_CRYPTO_SERVICE_ASYM 4
\end{lstlisting}
The last driver-read-only fields specify detailed algorithms masks
@@ -149,6 +155,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_RSA1
+#define VIRTIO_CRYPTO_ASYM_DSA2
+#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_PADDING4
+#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING 5
+\end{lstlisting}
+
\begin{note}
Any other value is reserved for future use.
\end{note}
@@ -164,6 +192,7 @@ Any other value is reserved for future use.
\item The device MUST set \field{max_size} to show the maximum size of crypto
request the device supports.
\item The device MUST set \field{max_cipher_key_len} to show the maximum
length of cipher key if the device supports CIPHER service.
\item The device MUST set \field{max_auth_key_len} to show the maximum length
of authenticated key if the device supports MAC service.
+\item The device MUST set \field{rsa_padding} to show the padding capabilities
offered by the device.
\end{itemize*}
\drivernormative{\subsubsection}{Device configuration layout}{Device Types /
Crypto Device / Device configuration layout}
@@ -178,6 +207,7 @@ Any other value is reserved for future use.
\item The driver SHOULD read \field{max_size} to discover the maximum size of
crypto request the device supports.
\item The driver SHOULD read \field{max_cipher_key_len} to discover the
maximum length of cipher key the device supports.
\item The driver SHOULD read \field{max_auth_key_len} to discover the maximum
length of authenticated key the device supports.
+\item The driver MAY read \field{rsa_padding} to discover the padding
capabilities offered by the device.
\end{itemize*}
\subsection{Device Initialization}\label{sec:Device Types / Crypto Device /
Device Initialization}
@@ -257,6 +287,18 @@ struct virtio_crypto_op_header {
VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
#define VIRTIO_CRYPTO_AEAD_DECRYPT \
VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SE
[Qemu-devel] [PATCH v1 1/1] virtio crypto device specification: asymmetric crypto service
This patch introduces asymmetric crypto service into virtio crypto
device spec. 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-10/msg01744.html
Changes since v0:
- Use devicenormative/drivernormative instead of self-defined
device/driver label. [Lei]
- Change the error code of verification to general virtio_crypto
error code. [Lei]
- Use macro instead of enum in verification result. [Lei]
- Fix the incorrect label value for paragraph and section. [Lei]
Please help to review, thanks!
Signed-off-by: Xin Zeng <xin.z...@intel.com>
---
virtio-crypto.tex | 965 +-
1 file changed, 962 insertions(+), 3 deletions(-)
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index 86e4869..43772da 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -6,7 +6,7 @@ decryption requests are placed in the data queue and are
ultimately handled by t
backend crypto accelerators. The second queue is the control queue used to
create
or destroy sessions for symmetric algorithms and will control some advanced
features in the future. The virtio crypto device provides the following crypto
-services: CIPHER, MAC, HASH, and AEAD.
+services: CIPHER, MAC, HASH, AEAD and ASYM.
\subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
@@ -44,7 +44,9 @@ struct virtio_crypto_config {
le32 mac_algo_l;
le32 mac_algo_h;
le32 aead_algo;
-le32 reserve;
+le32 asym_algo;
+le32 rsa_padding;
+le32 reserved;
};
\end{lstlisting}
@@ -70,6 +72,8 @@ The following services are defined:
#define VIRTIO_CRYPTO_SERVICE_MAC(2)
/* AEAD (Authenticated Encryption with Associated Data) service */
#define VIRTIO_CRYPTO_SERVICE_AEAD (3)
+/* ASYM (Asymmetric crypto algorithms) service */
+#define VIRTIO_CRYPTO_SERVICE_ASYM (4)
\end{lstlisting}
The last driver-read-only fields specify detailed algorithms masks
@@ -143,6 +147,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_NONE0
+#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}
Any other value is reserved for future use.
\end{note}
@@ -241,6 +267,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;
@@ -548,6 +586,23 @@ 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_g
[Qemu-devel] [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 <xin.z...@intel.com>
---
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;
};
\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_NONE0
+#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: s
[Qemu-devel] [PATCH] virtio crypto device specification
Fix spelling mistakes of keywords to make xelatex happy:
filed--->field
Signed-off-by: Xin Zeng <xin.z...@intel.com>
---
virtio-crypto.tex | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index ac1fc0a..c3554e3 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -159,7 +159,7 @@ More algorithms will be defined in the future.
\begin{itemize*}
\item The driver MUST read the ready \field{status} from the bottom bit of
status to check whether the hardware-backed
implementation is ready or not, and the driver MUST reread it after the
device reset.
-\item The driver MUST NOT transmit any packets to the device if the ready
\filed{status} is not set.
+\item The driver MUST NOT transmit any packets to the device if the ready
\field{status} is not set.
\item The driver MAY read \field{max_dataqueues} field to discover the number
of data queues the device supports.
\item The driver MUST read \field{crypto_services} field to discover which
services the device is able to offer.
\item The driver MUST read the detailed algorithms fields based on
\field{crypto_services} field.
@@ -634,7 +634,7 @@ The driver MUST set \field{src_data}.\field{flag} to
~VIRTIO_CRYPTO_IOVEC_F_NEXT
\devicenormative{\subparagraph}{HASH Service Operation}{Device Types / Crypto
Device / Device Operation / Data Virtqueue / HASH Service Operation}
-The device MUST copy the results of HASH operations to the guest memory
recorded by \field{digest_result_addr} filed in struct virtio_crypto_hash_input.
+The device MUST copy the results of HASH operations to the guest memory
recorded by \field{digest_result_addr} field in struct virtio_crypto_hash_input.
The device MUST set \field{status} in strut virtio_crypto_hash_input:
VIRTIO_CRYPTO_OP_OK: success; VIRTIO_CRYPTO_OP_ERR: creation failed or device
error; VIRTIO_CRYPTO_OP_NOTSUPP: not support.
\paragraph{MAC Service Operation}\label{sec:Device Types / Crypto Device /
Device Operation / Data Virtqueue / MAC Service Operation}
@@ -685,7 +685,7 @@ The driver MUST set
\field{hash_output}.\field{src_data}.\field{flag} to ~VIRTIO
\devicenormative{\subparagraph}{MAC Service Operation}{Device Types / Crypto
Device / Device Operation / Data Virtqueue / MAC Service Operation}
-The device MUST copy the results of MAC operations to the guest memory
recorded by \field{digest_result_addr} filed in struct virtio_crypto_mac_input.
+The device MUST copy the results of MAC operations to the guest memory
recorded by \field{digest_result_addr} field in struct virtio_crypto_mac_input.
The device MUST set \field{status} in strut virtio_crypto_mac_input:
VIRTIO_CRYPTO_OP_OK: success; VIRTIO_CRYPTO_OP_ERR: creation failed or device
error; VIRTIO_CRYPTO_OP_NOTSUPP: not support.
\paragraph{Symmetric algorithms Operation}\label{sec:Device Types / Crypto
Device / Device Operation / Data Virtqueue / Symmetric algorithms Operation}
@@ -813,9 +813,9 @@ The device MUST parse the virtio_crypto_sym_data_req based
on the \field{op_code
The device SHOULD only parse fields of struct virtio_crypto_cipher_data_req in
struct virtio_crypto_sym_data_req if the created session is
VIRTIO_CRYPTO_SYM_OP_CIPHER type.
The device MUST parse fields of both struct virtio_crypto_cipher_data_req and
struct virtio_crypto_mac_data_req in struct virtio_crypto_sym_data_req if the
created
session is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING operation type and
in the VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH mode.
-The device MUST copy the result of cryptographic operation to the guest memory
recorded by \filed{dst_data}.\field{addr} filed in struct
virtio_crypto_cipher_input in plain CIPHER mode.
-The device MUST copy the result of HASH/MAC operation to the guest memory
recorded by \filed{digest_result_addr} filed in struct
virtio_crypto_alg_chain_data_input is of the
VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING type.
-The device MUST set the \filed{status} field in strut
virtio_crypto_cipher_input or virtio_crypto_alg_chain_data_input structure:
+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_cipher_input in plain CIPHER mode.
+The device MUST copy the result of HASH/MAC operation to the guest memory
recorded by \field{digest_result_addr} field in struct
virtio_crypto_alg_chain_data_input is of the
VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING type.
+The device MUST set the \field{status} field in strut
virtio_crypto_cipher_input or virtio_crypto_alg_chain_data_input structure:
VIRTIO_CRYPTO_OP_OK: success; VIRTIO_CRYPTO_OP_ERR: creation failed or device
error; VIRTIO_CRYPTO_OP_NOTSUPP: not supported.
\subparagraph{Steps of Operation}\label{sec:Device Types / Crypto Device /
Device Operation / Data Virtqueue / Symmetric algorithms Operation / Steps of
Operation}
@@ -936,7 +936,7 @@ The driver MUST s
