From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id D78BA986549 for ; Thu, 20 Jan 2022 07:27:05 +0000 (UTC) Date: Thu, 20 Jan 2022 02:26:52 -0500 From: "Michael S. Tsirkin" Message-ID: <20220120022531-mutt-send-email-mst@kernel.org> References: <20211210125329.72786-1-helei.sig11@bytedance.com> <20211210125329.72786-2-helei.sig11@bytedance.com> <21FD1647-957D-4841-A54E-7D44EFE638B9@bytedance.com> <20220119100712-mutt-send-email-mst@kernel.org> <3bc3a06782b943e8a43b07954ba328fd@huawei.com> MIME-Version: 1.0 In-Reply-To: <3bc3a06782b943e8a43b07954ba328fd@huawei.com> Subject: [virtio-comment] Re: [V3 PATCH 1/1] virtio-crypto: introduce akcipher service Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable To: "Gonglei (Arei)" Cc: =?utf-8?B?5L2V56OK?= , "virtio-comment@lists.oasis-open.org" , "pizhenwei@bytedance.com" , "xin.zeng@intel.com" List-ID: On Thu, Jan 20, 2022 at 05:48:09AM +0000, Gonglei (Arei) wrote: >=20 >=20 > > -----Original Message----- > > From: Michael S. Tsirkin [mailto:mst@redhat.com] > > Sent: Wednesday, January 19, 2022 11:17 PM > > To: =E4=BD=95=E7=A3=8A > > Cc: virtio-comment@lists.oasis-open.org; pizhenwei@bytedance.com; > > xin.zeng@intel.com; Gonglei (Arei) > > Subject: Re: [V3 PATCH 1/1] virtio-crypto: introduce akcipher service > >=20 > > On Tue, Jan 11, 2022 at 11:14:27AM +0800, =E4=BD=95=E7=A3=8A wrote: > > > Hello virtio community, > > > > > > I=E2=80=99d like to request the TC vote on resolving the foll= ow issue: > > > =09Enhancement: https://github.com/oasis-tcs/virtio-spec/issues/129 > >=20 > > Does not look like we have a lot of response with this, and it seems ri= sky to add > > this now since spec freeze is imminent. > > I think the right way to do it is to submit the supporting patches to t= he linux > > kernel and probably qemu. > > A bunch of crypto experts on the linux mailing list. > >=20 > > In particular I note that virtio crypto already has a ton of features t= hat don't seem > > to be supported by the linux driver or qemu. Kind of reluctant to add = more > > without some review from developers implementing this. > >=20 > >=20 > Hi Michael, >=20 > I can't agree more with you. Eg. the virtio crypto doesn't support statel= ess mode currently in linux and=20 > qemu upstream lthough this virtio crypto spec already supports. If we exp= and the specification in firstly, > it may make it more difficult to maintain in the future. >=20 > Regards, > -Gonglei So what's the plan with stateless btw? why isn't it used? is it completely useless? why do we have it in the spec? > > > > On Dec 10, 2021, at 8:53 PM, Lei He wro= te: > > > > > > > > Introduce akcipher (asymmetric key cipher) service type, several > > > > asymmetric algorithms and relevent information: > > > > - RSA(padding algorithm, ASN.1 schema definition) > > > > - ECDSA(ECC algorithm) > > > > > > > > Signed-off-by: zhenwei pi > > > > Signed-off-by: Lei He > > > > --- > > > > introduction.tex | 12 +++ > > > > virtio-crypto.tex | 317 > > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++- > > > > 2 files changed, 325 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/introduction.tex b/introduction.tex index > > > > 6d52717..92a6911 100644 > > > > --- a/introduction.tex > > > > +++ b/introduction.tex > > > > @@ -79,6 +79,18 @@ \section{Normative References}\label{sec:Normati= ve > > References} > > > > =09\phantomsection\label{intro:SCMI}\textbf{[SCMI]} & > > > > =09Arm System Control and Management Interface, DEN0056, > > > > =09\newline\url{https://developer.arm.com/docs/den0056/c}, version = C > > > > and any future revisions\\ > > > > +=09\phantomsection\label{intro:rfc3447}\textbf{[RFC3447]} & > > > > + J. Jonsson.,``Public-Key Cryptography Standards (PKCS) \#1: RS= A > > Cryptography'', February 2003. > > > > +=09\newline\url{https://www.ietf.org/rfc/rfc3447.txt}\\ > > > > +=09\phantomsection\label{intro:NIST}\textbf{[FIPS186-3]} & > > > > + National Institute of Standards and Technology (NIST), FIPS P= ublication > > 180-3: Secure Hash Standard, October 2008. > > > > + > > =09\newline\url{https://csrc.nist.gov/csrc/media/publications/fips/186/= 3/archi > > ve/2009-06-25/documents/fips_186-3.pdf}\\ > > > > + \phantomsection\label{intro:rfc6025}\textbf{[RFC6025]} & > > > > + C.Wallace., ``ASN.1 Translation'', October 2010. > > > > + \newline\url{https://www.ietf.org/rfc/rfc6025.txt}\\ > > > > + \phantomsection\label{intro:rfc3279}\textbf{[RFC3279]} & > > > > + W.Polk., ``Algorithms and Identifiers for the Internet X.509 P= ublic Key > > Infrastructure Certificate and Certificate Revocation List (CRL) Profil= e'', April 2002. > > > > + \newline\url{https://www.ietf.org/rfc/rfc3279.txt}\\ > > > > > > > > \end{longtable} > > > > > > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex index > > > > 74746f9..256c144 100644 > > > > --- a/virtio-crypto.tex > > > > +++ b/virtio-crypto.tex > > > > @@ -2,7 +2,7 @@ \section{Crypto Device}\label{sec:Device Types / > > > > Crypto Device} > > > > > > > > The virtio crypto device is a virtual cryptography device as well a= s > > > > a virtual cryptographic accelerator. The virtio crypto device > > > > provides the -following crypto services: CIPHER, MAC, HASH, and > > > > AEAD. Virtio crypto > > > > +following crypto services: CIPHER, MAC, HASH, AEAD and AKCIPHER. > > > > +Virtio crypto > > > > devices have a single control queue and at least one data queue. > > > > Crypto operation requests are placed into a data queue, and service= d > > > > by the device. Some crypto operation requests are only valid in the > > > > context of a @@ -39,6 +39,8 @@ \subsection{Feature bits}\label{sec:= Device > > Types / Crypto Device / Feature bits} > > > > supported by the MAC service. > > > > \item VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE (4) stateless mode > > requests are > > > > supported by the AEAD service. > > > > +\item VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE (5) stateless mode > > requests are > > > > + supported by the AKCIPHER service. > > > > \end{description} > > > > > > > > > > > > @@ -52,6 +54,7 @@ \subsubsection{Feature bit > > > > requirements}\label{sec:Device Types / Crypto Device > > \item[VIRTIO_CRYPTO_F_HASH_STATELESS_MODE] Requires > > VIRTIO_CRYPTO_F_REVISION_1. > > > > \item[VIRTIO_CRYPTO_F_MAC_STATELESS_MODE] Requires > > VIRTIO_CRYPTO_F_REVISION_1. > > > > \item[VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE] Requires > > VIRTIO_CRYPTO_F_REVISION_1. > > > > +\item[VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE] Requires > > VIRTIO_CRYPTO_F_REVISION_1. > > > > \end{description} > > > > > > > > \subsection{Supported crypto services}\label{sec:Device Types / > > > > Crypto Device / Supported crypto services} @@ -59,7 +62,7 @@ > > > > \subsection{Supported crypto services}\label{sec:Device Types / Cry= pto > > Device / The following crypto services are defined: > > > > > > > > \begin{lstlisting} > > > > -/* CIPHER service */ > > > > +/* CIPHER (Symmetric Key Cipher) service */ > > > > #define VIRTIO_CRYPTO_SERVICE_CIPHER 0 > > > > /* HASH service */ > > > > #define VIRTIO_CRYPTO_SERVICE_HASH 1 > > > > @@ -67,6 +70,8 @@ \subsection{Supported crypto services}\label{sec:= Device > > Types / Crypto Device / > > > > #define VIRTIO_CRYPTO_SERVICE_MAC 2 > > > > /* AEAD (Authenticated Encryption with Associated Data) service */ > > > > #define VIRTIO_CRYPTO_SERVICE_AEAD 3 > > > > +/* AKCIPHER (Asymmetric Key Cipher) service */ #define > > > > +VIRTIO_CRYPTO_SERVICE_AKCIPHER 4 > > > > \end{lstlisting} > > > > > > > > The above constants designate bits used to indicate the which of > > > > crypto services are @@ -181,6 +186,24 @@ \subsubsection{AEAD > > > > services}\label{sec:Device Types / Crypto Device / Supported operat= ion > > requests, see \ref{sec:Device Types / Crypto Device / Device Operation = / Control > > Virtqueue / Session operation}. > > > > \end{enumerate} > > > > > > > > +\subsubsection{AKCIPHER services}\label{sec: Device Types / Crypto > > > > +Device / Supported crypto services / AKCIPHER services} > > > > + > > > > +The following AKCIPHER algorithms are defined: > > > > +\begin{lstlisting} > > > > +#define VIRTIO_CRYPTO_NO_AKCIPHER 0 > > > > +#define VIRTIO_CRYPTO_AKCIPHER_RSA 1 > > > > +#define VIRTIO_CRYPTO_AKCIPHER_ECDSA 2 \end{lstlisting} > > > > + > > > > +The above constants have two usages: > > > > +\begin{enumerate} > > > > +\item As bit numbers, used to tell the driver which AKCIPHER > > > > +algorithms are supported by the device, see \ref{sec:Device Types = / Crypto > > Device / Device configuration layout}. > > > > +\item As values, used to designate the algorithm in asymmetric > > > > +crypto operation requests, see \ref{sec:Device Types / Crypto Devi= ce / > > Device Operation / Control Virtqueue / Session operation}. > > > > +\end{enumerate} > > > > + > > > > + > > > > \subsection{Device configuration layout}\label{sec:Device Types / > > > > Crypto Device / Device configuration layout} > > > > > > > > Crypto device configuration uses the following layout structure: > > > > @@ -204,6 +227,7 @@ \subsection{Device configuration > > layout}\label{sec:Device Types / Crypto Device > > > > le32 reserved; > > > > /* Maximum size of each crypto request's content in bytes */ > > > > le64 max_size; > > > > + le32 akcipher_algo; > > > > }; > > > > \end{lstlisting} > > > > > > > > @@ -241,6 +265,7 @@ \subsection{Device configuration > > > > layout}\label{sec:Device Types / Crypto Device > > > > > > > > \item [\field{max_size}] is the maximum size of the variable-length > > parameters of > > > > data operation of each crypto request's content supported by th= e > > device. > > > > +\item [\field{akcipher_algo}] AKCIPHER algorithms bit 0-31, see \r= ef{sec: > > Device Types / Crypto Device / Supported crypto services / AKCIPHER ser= vices}. > > > > \end{description} > > > > > > > > \begin{note} > > > > @@ -323,6 +348,7 @@ \subsubsection{Operation Status}\label{sec:Devi= ce > > Types / Crypto Device / Device > > > > VIRTIO_CRYPTO_NOTSUPP =3D 3, > > > > VIRTIO_CRYPTO_INVSESS =3D 4, > > > > VIRTIO_CRYPTO_NOSPC =3D 5, > > > > + VIRTIO_CRYPTO_KEY_REJECTED =3D 6, > > > > VIRTIO_CRYPTO_MAX > > > > }; > > > > \end{lstlisting} > > > > @@ -334,6 +360,7 @@ \subsubsection{Operation > > > > Status}\label{sec:Device Types / Crypto Device / Device \item > > VIRTIO_CRYPTO_INVSESS: invalid session ID when executing crypto operati= ons. > > > > \item VIRTIO_CRYPTO_NOSPC: no free session ID (only when the > > VIRTIO_CRYPTO_F_REVISION_1 > > > > feature bit is negotiated). > > > > +\item VIRTIO_CRYPTO_KEY_REJECTED: signature verification failed (o= nly > > when AKCIPHER verification). > > > > \item VIRTIO_CRYPTO_ERR: any failure not mentioned above occurs. > > > > \end{itemize*} > > > > > > > > @@ -364,6 +391,10 @@ \subsubsection{Control Virtqueue}\label{sec:De= vice > > Types / Crypto Device / Devic > > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x02) > > > > #define VIRTIO_CRYPTO_AEAD_DESTROY_SESSION \ > > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x03) > > > > +#define VIRTIO_CRYPTO_AKCIPHER_CREATE_SESSION \ > > > > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, > > 0x04) > > > > +#define VIRTIO_CRYPTO_AKCIPHER_DESTROY_SESSION \ > > > > + VIRTIO_CRYPTO_OPCDE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, > > 0x05) > > > > le32 opcode; > > > > /* algo should be service-specific algorithms */ > > > > le32 algo; > > > > @@ -427,6 +458,11 @@ \subsubsection{Control Virtqueue}\label{sec:De= vice > > Types / Crypto Device / Devic > > > > VIRTIO_CRYPTO_F_REVISION_1 is negotiated and struct > > virtio_crypto_aead_create_session_flf is > > > > padded to 56 bytes if NOT negotiated, and \field{op_vlf} is str= uct > > > > virtio_crypto_aead_create_session_vlf. > > > > +\item If the opcode (in \field{header}) is > > VIRTIO_CRYPTO_AKCIPHER_CREATE_SESSION > > > > + then \field{op_flf} is struct virtio_crypto_akcipher_create_se= ssion_flf if > > > > + VIRTIO_CRYPTO_F_REVISION_1 is negotiated and struct > > virtio_crypto_akcipher_create_session_flf is > > > > + padded to 56 bytes if NOT negotiated, and \field{op_vlf} is st= ruct > > > > + virtio_crypto_akcipher_create_session_vlf. > > > > \item If the opcode (in \field{header}) is > > VIRTIO_CRYPTO_CIPHER_DESTROY_SESSION > > > > or VIRTIO_CRYPTO_HASH_DESTROY_SESSION or > > VIRTIO_CRYPTO_MAC_DESTROY_SESSION or > > > > VIRTIO_CRYPTO_AEAD_DESTROY_SESSION then \field{op_flf} is struc= t > > > > @@ -690,12 +726,137 @@ \subsubsection{Control > > > > Virtqueue}\label{sec:Device Types / Crypto Device / Devic The lengt= h > > > > of \field{key} is specified in \field{key_len} in struct > > virtio_crypto_aead_create_session_flf. > > > > > > > > +\subparagraph{Session operation: AKCIPHER session}\label{sec:Devic= e > > > > +Types / Crypto Device / Device Operation / Control Virtqueue / > > > > +Session operation / Session operation: AKCIPHER session} > > > > + > > > > +Due to the complexity of asymmetric key algorithms, different > > > > +algorithms require different parameters. The following data > > > > +structures are used as supplementary parameters to describe the > > asymmetric algorithm sessions. > > > > + > > > > +For the RSA algorithm, the extra parameters are as follows: > > > > +\begin{lstlisting} > > > > +struct virtio_crypto_rsa_session_para { > > > > +#define VIRTIO_CRYPTO_RSA_RAW_PADDING 0 > > > > +#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING 1 > > > > + le32 padding_algo; > > > > + > > > > +#define VIRTIO_CRYPTO_RSA_NO_HASH 0 > > > > +#define VIRTIO_CRYPTO_RSA_MD2 1 > > > > +#define VIRTIO_CRYPTO_RSA_MD3 2 > > > > +#define VIRTIO_CRYPTO_RSA_MD4 3 > > > > +#define VIRTIO_CRYPTO_RSA_MD5 4 > > > > +#define VIRTIO_CRYPTO_RSA_SHA1 5 > > > > +#define VIRTIO_CRYPTO_RSA_SHA256 6 > > > > +#define VIRTIO_CRYPTO_RSA_SHA384 7 > > > > +#define VIRTIO_CRYPTO_RSA_SHA512 8 > > > > +#define VIRTIO_CRYPTO_RSA_SHA224 9 > > > > + le32 hash_algo; > > > > +}; > > > > +\end{lstlisting} > > > > + > > > > +\field{padding_algo} specifies the padding method used by RSA sess= ions. > > > > +\begin{itemize*} > > > > +\item If VIRTIO_CRYPTO_RSA_RAW_PADDING is specified, 1) > > > > +\field{hash_algo} is ignored, 2) ciphertext and plaintext MUST be > > > > +padded with leading zeros, > > > > +3) and RSA sessions with VIRTIO_CRYPTO_RSA_RAW_PADDING MUST not > > be > > > > +used for verification and signing operations. > > > > +\item If VIRTIO_CRYPTO_RSA_PKCS1_PADDING is specified, > > > > +EMSA-PKCS1-v1_5 padding method is used(see > > > > +\hyperref[intro:rfc3447]{PKCS\#1}), \field{hash_algo} specifies ho= w the > > digest of the data passed to RSA sessions is calculated when verifying = and signing. > > > > +It only affects the padding algorithm and is ignored during encryp= tion and > > decryption. > > > > +\end{itemize*} > > > > + > > > > +The ECC algorithms such as the ECDSA algorithm, cannot use custom > > > > +curves, only the following known curves can be used(see > > > > +\hyperref[intro:NIST]{NIST-recommended curves}) > > > > + > > > > +\begin{lstlisting} > > > > +#define VIRTIO_CRYPTO_CURVE_UNKNOWN 0 > > > > +#define VIRTIO_CRYPTO_CURVE_NIST_P192 1 #define > > > > +VIRTIO_CRYPTO_CURVE_NIST_P224 2 #define > > > > +VIRTIO_CRYPTO_CURVE_NIST_P256 3 #define > > > > +VIRTIO_CRYPTO_CURVE_NIST_P384 4 #define > > > > +VIRTIO_CRYPTO_CURVE_NIST_P521 5 \end{lstlisting} > > > > + > > > > +For the ECDSA algorithm, the extra parameters are as follows: > > > > +\begin{lstlisting} > > > > +struct virtio_crypto_ecdsa_session_para { > > > > + /* See VIRTIO_CRYPTO_CURVE_* above */ > > > > + le32 curve_id; > > > > +}; > > > > +\end{lstlisting} > > > > + > > > > +The fixed-length and the variable-length parameters of AKCIPHER se= ssion > > requests are as follows: > > > > +\begin{lstlisting} > > > > +struct virtio_crypto_akcipher_create_session_flf { > > > > + /* Device read only portion */ > > > > + > > > > + /* See VIRTIO_CRYPTO_AKCIPHER_* above */ > > > > + le32 algo; > > > > +#define VIRTIO_CRYPTO_AKCIPHER_KEY_TYPE_PUBLIC 1 #define > > > > +VIRTIO_CRYPTO_AKCIPHER_KEY_TYPE_PRIVATE 2 > > > > + le32 key_type; > > > > + /* length of key */ > > > > + le32 key_len; > > > > + > > > > +#define VIRTIO_CRYPTO_AKCIPHER_SESS_ALGO_SPEC_HDR_SIZE 44 > > > > + u8 algo_flf[VIRTIO_CRYPTO_AKCIPHER_SESS_ALGO_SPEC_HDR_SIZE]; > > > > +}; > > > > + > > > > +struct virtio_crypto_akcipher_create_session_vlf { > > > > + /* Device read only portion */ > > > > + u8 key[key_len]; > > > > +}; > > > > +\end{lstlisting} > > > > + > > > > +\field{algo} decides the type used by \field{algo_flf}. > > > > +\field{algo_flf} is fixed to 44 bytes and MUST contains of be one > > > > +the following structures: > > > > +\begin{itemize*} > > > > +\item struct virtio_crypto_rsa_session_para \item struct > > > > +virtio_crypto_ecdsa_session_para \end{itemize*} > > > > + > > > > +The length of \field{key} is specified in \field{key_len} in the > > > > +struct virtio_crypto_akcipher_create_session_flf. > > > > + > > > > +If the key of an asymmetric algorithm contains multiple fields, fo= r > > > > +example, the RSA key pairs, they MUST be described using the > > > > +ASN.1 structure and MUST be DER encoded (see > > \hyperref[intro:rfc6025]{rfc6025}). > > > > +If the key of an asymmetric algorithm only contains an integer > > > > +field, for example, the ECDSA private key, then MUST be encoded > > > > +with I2OSP primitives described in \hyperref[intro:rfc3447]{PKCS\#= 1}. > > > > + > > > > +The schema of RSA keys is described with the RSAPrivateKey and > > > > +RSAPublicKey structure defined in \hyperref[intro:rfc3447]{PKCS\#1= }. > > > > + > > > > +\begin{lstlisting} > > > > +RsaPrivateKey ::=3D SEQUENCE { > > > > + version INTEGER > > > > + modulus INTEGER > > > > + publicExponent INTEGER > > > > + privateExponent INTEGER > > > > + prime1 INTEGER > > > > + prime2 INTEGER > > > > + exponent1 INTEGER > > > > + exponent1 INTEGER > > > > + coefficient INTEGER > > > > +} > > > > + > > > > +RsaPublicKey ::=3D SEQUENCE { > > > > + modulus INTEGER > > > > + publicExponent INTEGER > > > > +} > > > > +\end{lstlisting} > > > > + > > > > +The length of \field{key} is specified in \field{key_len} in struc= t > > > > +virtio_crypto_akcipher_create_session_flf. > > > > > > > > \drivernormative{\subparagraph}{Session operation: create > > > > session}{Device Types / Crypto Device / Device Operation / Control > > > > Virtqueue / Session operation / Session operation: create session} > > > > > > > > \begin{itemize*} > > > > -\item The driver MUST set the \field{opcode} field based on servic= e type: > > CIPHER, HASH, MAC, or AEAD. > > > > +\item The driver MUST set the \field{opcode} field based on servic= e type: > > CIPHER, HASH, MAC, AEAD or AKCIPHER. > > > > \item The driver MUST set the control general header, the opcode sp= ecific > > header, > > > > the opcode specific extra parameters and the opcode specific ou= tcome > > buffer in turn. > > > > See \ref{sec:Device Types / Crypto Device / Device Operation / = Control > > Virtqueue}. > > > > @@ -726,7 +887,7 @@ \subsubsection{Control > > > > Virtqueue}\label{sec:Device Types / Crypto Device / Devic Operation > > > > / Control Virtqueue / Session operation / Session operation: destro= y > > > > session} > > > > > > > > \begin{itemize*} > > > > -\item The driver MUST set the \field{opcode} field based on servic= e type: > > CIPHER, HASH, MAC, or AEAD. > > > > +\item The driver MUST set the \field{opcode} field based on servic= e type: > > CIPHER, HASH, MAC, AEAD or AKCIPHER. > > > > \item The driver MUST set the \field{session_id} to a valid value a= ssigned by > > the device > > > > when the session was created. > > > > \end{itemize*} > > > > @@ -764,6 +925,14 @@ \subsubsection{Data Virtqueue}\label{sec:Devic= e > > Types / Crypto Device / Device O > > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00) > > #define > > > > VIRTIO_CRYPTO_AEAD_DECRYPT \ > > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01) > > > > +#define VIRTIO_CRYPTO_AKCIPHER_ENCRYPT \ > > > > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, 0x00) > > > > +#define VIRTIO_CRYPTO_AKCIPHER_DECRYPT \ > > > > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, 0x01) > > > > +#define VIRTIO_CRYPTO_AKCIPHER_SIGN \ > > > > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, 0x02) > > > > +#define VIRTIO_CRYPTO_AKCIPHER_VERIFY \ > > > > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, 0x03) > > > > le32 opcode; > > > > /* algo should be service-specific algorithms */ > > > > le32 algo; > > > > @@ -857,6 +1026,17 @@ \subsubsection{Data Virtqueue}\label{sec:Devi= ce > > Types / Crypto Device / Device O > > > > and struct virtio_crypto_aead_data_flf is padded to 48 byte= s if NOT > > negotiated, > > > > and \field{op_vlf} is struct virtio_crypto_aead_data_vlf. > > > > \end{itemize*} > > > > +\item If the opcode (in \field{header}) is > > VIRTIO_CRYPTO_AKCIPHER_ENCRYPT, VIRTIO_CRYPTO_AKCIPHER_DECRYPT, > > > > + VIRTIO_CRYPTO_AKCIPHER_SIGN or > > VIRTIO_CRYPTO_AKCIPHER_VERIFY then: > > > > + \begin{itemize*} > > > > + \item If VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE is negotiated= , > > \field{op_flf} is > > > > + struct virtio_crypto_akcipher_data_flf_statless, and \fiel= d{op_vlf} > > is struct > > > > + virtio_crypto_akcipher_data_vlf_stateless. > > > > + \item If VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE is NOT > > negotiated, \field{op_flf} > > > > + is struct virtio_crypto_akcipher_data_flf if > > VIRTIO_CRYPTO_F_REVISION_1 is negotiated > > > > + and struct virtio_crypto_akcipher_data_flf is padded to 48= bytes if > > NOT negotiated, > > > > + and \field{op_vlf} is struct virtio_crypto_akcipher_data_v= lf. > > > > + \end{itemize*} > > > > \end{itemize*} > > > > > > > > \field{inhdr} is a unified input header that used to return the > > > > status of @@ -1533,3 +1713,132 @@ \subsubsection{AEAD Service > > > > Operation}\label{sec:Device Types / Crypto Device / \item > > VIRTIO_CRYPTO_ERR if any failure not mentioned above occurs. > > > > \end{itemize*} > > > > \end{itemize*} > > > > + > > > > +\subsubsection{AKCIPHER Service Operation}\label{sec:Device Types = / > > > > +Crypto Device / Device Operation / AKCIPHER Service Operation} > > > > + > > > > +Session mode AKCIPHER requests are as follows: > > > > + > > > > +\begin{lstlisting} > > > > +struct virtio_crypto_akcipher_data_flf { > > > > + /* length of source data */ > > > > + le32 src_data_len; > > > > + /* length of dst data */ > > > > + le32 dst_data_len; > > > > +}; > > > > + > > > > +struct virtio_crypto_akcipher_data_vlf { > > > > + /* Device read only portion */ > > > > + /* Source data */ > > > > + u8 src_data[src_data_len]; > > > > + > > > > + /* Device write only portion */ > > > > + /* Pointer to output data */ > > > > + u8 dst_data[dst_data_len]; > > > > +}; > > > > +\end{lstlisting} > > > > + > > > > +Each data request uses the virtio_crypto_akcipher_flf structure an= d > > > > +the virtio_crypto_akcipher_data_vlf structure to store information= used to > > run the AKCIPHER operations. > > > > + > > > > +For encryption, decryption, and signing: > > > > +\field{src_data} is the source data that will be processed, note > > > > +that for signing operations, src_data stores the data to be signed= , > > > > +which usually is the digest of some data rather than the data itse= lf. > > > > +\field{src_data_len} is the length of source data. > > > > +\field{dst_result} is the result data and \field{dst_data_len} is = the length of > > it. > > > > + > > > > +For verification: > > > > +\field{src_data_len} refers to the length of the signature, and > > > > +\field{dst_data_len} refers to the length of signed data, where th= e signed > > data is usually the digest of some data. > > > > +\field{src_data} is spliced by the signature and the signed data, > > > > +the src_data with the lower address stores the signature, and the = higher > > address stores the signed data. > > > > +\field{dst_data} is always empty for verification. > > > > + > > > > +Different algorithms have different signature formats. > > > > +For the RSA algorithm, the result is determined by the padding > > > > +algorithm specified by \field{padding_algo} in structure > > virtio_crypto_rsa_session_para. > > > > + > > > > +For the ECDSA algorithm, the signature is composed of the followin= g > > > > +ASN.1 structure(see \hyperref[intro:rfc3279]{RFC3279}) > > > > +and MUST be DER encoded. > > > > +\begin{lstlisting} > > > > +Ecdsa-Sig-Value ::=3D SEQUENCE { > > > > + r INTEGER, > > > > + s INTEGER > > > > +} > > > > +\end{lstlisting} > > > > + > > > > +Stateless mode AKCIPHER service requests are as follows: > > > > +\begin{lstlisting} > > > > +struct virtio_crypto_akcipher_data_flf_stateless { > > > > + struct { > > > > + /* See VIRTIO_CYRPTO_AKCIPHER* above */ > > > > + le32 algo; > > > > + /* See VIRTIO_CRYPTO_AKCIPHER_KEY_TYPE_* above */ > > > > + le32 key_type; > > > > + /* length of key */ > > > > + le32 key_len; > > > > + > > > > + /* algothrim specific parameters described above */ > > > > + union { > > > > + struct virtio_crypto_rsa_session_para rsa; > > > > + struct virtio_crypto_ecdsa_session_para ecdsa; > > > > + } u; > > > > + } sess_para; > > > > + > > > > + /* length of source data */ > > > > + le32 src_data_len; > > > > + /* length of destination data */ > > > > + le32 dst_data_len; > > > > +}; > > > > + > > > > +struct virtio_crypto_akcipher_data_vlf_stateless { > > > > + /* Device read only portion */ > > > > + u8 akcipher_key[key_len]; > > > > + > > > > + /* Source data */ > > > > + u8 src_data[src_data_len]; > > > > + > > > > + /* Device write only portion */ > > > > + u8 dst_data[dst_data_len]; > > > > +}; > > > > +\end{lstlisting} > > > > + > > > > +In stateless mode, the format of key and signature, the meaning of > > > > +src_data and dst_data, are all the same with session mode. > > > > + > > > > +\drivernormative{\paragraph}{AKCIPHER Service Operation}{Device > > > > +Types / Crypto Device / Device Operation / AKCIPHER Service > > > > +Operation} > > > > + > > > > +\begin{itemize*} > > > > +\item If the driver uses the session mode, then the driver MUST se= t > > > > + \field{session_id} in struct virtio_crypto_op_header to a vali= d > > > > + value assigned by the device when the session was created. > > > > +\item If the VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE feature bit i= s > > negotiated, 1) if the > > > > + driver uses the stateless mode, then the driver MUST set the \= field{flag} > > field in > > > > + struct virtio_crypto_op_header to ZERO and MUST set the fields= in > > struct > > > > + virtio_crypto_akcipher_flf_stateless.sess_para, 2) if the driv= er uses the > > session > > > > + mode, then the driver MUST set the \field{flag} field in struc= t > > virtio_crypto_op_header > > > > + to VIRTIO_CRYPTO_FLAG_SESSION_MODE. > > > > +\item The driver MUST set the \field{opcode} field in struct > > virtio_crypto_op_header > > > > + to one of VIRTIO_CRYPTO_AKCIPHER_ENCRYPT, > > VIRTIO_CRYPTO_AKCIPHER_DESTROY_SESSION, > > > > + VIRTIO_CRYPTO_AKCIPHER_SIGN, and > > VIRTIO_CRYPTO_AKCIPHER_VERIFY. > > > > +\end{itemize*} > > > > + > > > > +\devicenormative{\paragraph}{AKCIPHER Service Operation}{Device > > > > +Types / Crypto Device / Device Operation / AKCIPHER Service > > > > +Operation} > > > > + > > > > +\begin{itemize*} > > > > +\item If the VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE feature bit i= s > > negotiated, the > > > > + device MUST parse the virtio_crypto_akcipher_data_vlf_stateles= s > > based on the \field{opcode} > > > > + field in general header. > > > > +\item The device MUST copy the result of cryptographic operation i= n the > > dst_data[]. > > > > +\item The device MUST set the \field{status} field in struct > > virtio_crypto_inhdr to > > > > + one of the following values of enum VIRTIO_CRYPTO_STATUS: > > > > +\begin{itemize*} > > > > +\item VIRTIO_CRYPTO_OK if the operation success. > > > > +\item VIRTIO_CRYPTO_NOTSUPP if the requested algorithm or operatio= n is > > unsupported. > > > > +\item VIRTIO_CRYPTO_BADMSG if the verification result is incorrect= . > > > > +\item VIRTIO_CRYPTO_INVSESS if the session ID invalid when in sess= ion > > mode. > > > > +\item VIRTIO_CRYPTO_KEY_REJECTED if the signature verification fai= led. > > > > +\item VIRTIO_CRYPTO_ERR if any failure not mentioned above occurs. > > > > +\end{itemize*} > > > > +\end{itemize*} > > > > -- > > > > 2.11.0 > > > > >=20 This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lis= ts Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/