Bilingual Signature Using Lattice-Based Cryptography

Abstract

This invention provides a method and system for two-party calculation of digital signatures of messages using a grid-based digital signature scheme. [Solution] The grid-based digital signature scheme uses a private key that includes a public key and a first private key share and a second private key share that are secretly shared between a first party and a second party. The method includes the steps of: the first party 110 receiving a message for signing; obtaining a first private key share held by the first party; calculating a first party share of the digital signature based on the message, the first private key share and the secret sharing data (216); receiving a second party share of the digital signature from the second party; and forming a digital signature by combining the first party share of the digital signature and the second party share of the digital signature (218).

Description

[Technical Field]

[0001] This disclosure describes a mechanism for distributed digital signatures involving two parties. [Background technology]

[0002] A digital signature is a method for proving the authenticity of a digital message or document. If a recipient can verify that a digital signature attached to a digital message is valid, they can reasonably believe that the message was created by a known or trusted sender, that the sender cannot deny sending the message, and that the message was not tampered with during transit. Digital signatures are used to verify the authenticity of messages, documents, and other assets such as websites.

[0003] Digital signature schemes often use asymmetric key pairs, i.e., a public key and a private key. The sender's private key is used to generate the digital signature, and the sender's public key is used by the recipient of the digital signature to verify that the digital signature and any message associated with it originate from that sender.

[0004] The security of a signature scheme depends on the confidentiality of the secret key material used. One way to improve the security of a signature scheme is to distribute the secret material across multiple devices so that a sufficient number of devices must work together to create the digital signature. Several two-party and multi-party schemes exist for implementing digital signature schemes against conventional cryptographic schemes. WO 2018 / 073685 A1 describes generating a composite digital signature through a combination of steps performed by a first party and a second party.

[0005] Currently, there is growing interest in cryptographic methods that are secure against attacks posed by the increasing computational power of quantum computers.

[0006] The Module-Lattice-Based Digital Signature Standard (ML-DSA) is a digital signature algorithm standardized by the U.S. National Institute of Standards and Technology (NIST) as Federal Information Processing Standards Publication FIPS 204. ML-DSA is based on a scheme called CRYSTALS (Cryptographic Suite for Algebraic Lattices)-Dilithium. It is considered impossible to forge an ML-DSA signature even with a sufficiently powerful quantum computer. ML-DSA defines three main algorithms: (i) a key generation algorithm that generates a private and public key, (ii) a signing algorithm that signs the message using the private key, and (iii) a verification algorithm that verifies whether the signature is valid against the public key. ML-DSA is intended to be implemented on a single device; that is, ML-DSA is intended to create, store, and use private key material in a single location. [Overview of the project] [Means for solving the problem]

[0007] One embodiment provides a computer implementation method for two-party computation of digital signatures of messages using a grid-based digital signature scheme, wherein the grid-based digital signature scheme uses a public key and a private key including a first private key share and a second private key share, and the method is performed by the first party, The steps include receiving the message to be signed, The steps include obtaining the first private key share held by the first party, A step of calculating a first party share of a digital signature based on a message, a first private key share, and secret sharing data, wherein the secret sharing is performed between a second party holding a second private key share, The steps include receiving a second party share of the digital signature from the second party, The process includes the step of forming a digital signature by combining the first party share of the digital signature and the second party share of the digital signature.

[0008] Optionally, the method further includes the step of forming a digital signature by combining the first party's share of the digital signature and the second party's share of the digital signature, and then verifying the digital signature at the first party.

[0009] Optionally, verification includes the step of calculating hashes of message M, public key, and digital signature.

[0010] Optionally, the method further includes the step of sending a digital signature to a second party if verification is successful.

[0011] Optionally, the method further includes the step of discarding the first private key share if verification fails.

[0012] Optionally, the step of computing a digital signature includes generating a first party share of a polynomial masking vector y having coefficients.

[0013] Optionally, the step of generating the first party share of the masking vector includes the step of generating random bits of coefficients.

[0014] The optional step of calculating a digital signature is: A step of calculating the first party share of a matrix-vector product w by multiplying the first party share of a matrix A and a masking vector y contained in the public key, wherein the first party share of the matrix-vector product w includes a polynomial having the first party share of the coefficients, This includes the step of determining the higher bit values ​​of the coefficients of the matrix-vector product w.

[0015] Optionally, the step of determining the upper bit values of the coefficients of the matrix-vector product w includes the step of determining the first party's share of the upper bit values in the matrix-vector product w.

[0016] Optionally, the step of determining the first party's share of the upper bit values in the matrix-vector product w includes calculating the first party's share of the masked quantity using the first party's share of the coefficient value and the first party's share of the secret-shared random value s; sending the first party's share of the masked quantity to the second party and receiving the second party's share of the masked quantity from the second party; and restoring the combined masked quantity using the masked quantity of the first party and the masked quantity of the second party.

[0017] Optionally, the method includes splitting the combined masked quantity into digits according to a mixed-radix base; receiving the first party's share of the characteristic vector corresponding to the digits of the random value s; and further includes adding the first party's share of the characteristic vector of the digits of the random value s and the corresponding digit of the masked quantity.

[0018] The addition performs a carry for digits that overflow the corresponding base.

[0019] Optionally, the radix base includes the values 31, 24, 16, 16, 89 for the ML-DSA scheme with a value of α = 190464, and the radix base includes the values 31, 33, 32, 16, 33 for the ML-DSA scheme with a value of α = 523776.

[0020] Optionally, the total upper bit values of the coefficients of the matrix-vector product w include the first party's share of the upper bit values and the second party's share of the upper bit values, and the method includes sending the first party's share of the upper bit values to the second party; The steps include receiving the second party's share of the higher bit values ​​from the second party, The process includes the step of restoring the total high-order bit value by adding the first party's share of the high-order bit value and the second party's share of the high-order bit value.

[0021] Optionally, the method further includes the step of calculating a challenge value c which includes a hash of the message M and the total most significant bits of the coefficients of the matrix-vector product w.

[0022] Optionally, this method is A step of determining the first party share of the secret sharing signature amount z calculated using the first party share of the masking vector y, the challenge value c, and the first party share of the private key, The method further includes the step of performing a first rejection check on the coefficient value of the secret sharing signature amount z in cooperation with a second party.

[0023] Optionally, the method further includes the step of receiving the result of a first rejection check based on a comparison of the first party's share and the second party's share of the secret sharing signature amount z.

[0024] Optionally, this method is A step of determining the first party share of a further secret sharing signature amount x calculated using the first party share of the matrix-vector product w, the challenge value c, and the first party share of the private key, The further step includes performing a second rejection check on a coefficient value of the additional secret sharing signature amount x in cooperation with a second party.

[0025] Optionally, the method further includes the step of receiving the result of a second rejection check based on a comparison of the first party's share and the second party's share of an additional secret sharing signature amount x.

[0026] Optionally, the method further includes a step of declassifying the signature amount z to the first party if the first rejection check is passed and the second rejection check is passed.

[0027] Optionally, the communication between the first and second parties may use an authentication code asymmetrically.

[0028] Optionally, the first party's share of the signature includes quantity z and challenge value c.

[0029] Optionally, the first party transmits data to the second party using a combination of the data and at least one first party authentication code.

[0030] Optionally, the first party receives data from the second party using a combination of the data and at least one authentication code of the second party.

[0031] Optionally, the method further includes the step of generating a public key and a first private key share.

[0032] Optionally, the method further includes the step of receiving a first party share of random values ​​s from a correlated random number provider.

[0033] Optionally, the method further includes the steps of receiving a seed from a correlated random number provider and generating a first party share of multiple random numbers from the seed.

[0034] Optionally, the grid-based digital signature scheme is the Module Grid-Based Digital Signature Standard (ML-DSA).

[0035] The first party may be a client device, or it may be a server. Many of the functions of this method are the same for both the first and second parties.

[0036] One embodiment provides a computer implementation method for two-party computation of digital signatures of messages using a grid-based digital signature scheme, wherein the grid-based digital signature scheme uses a public key and a private key including a first private key share and a second private key share, and the method is performed by the second party, The steps include receiving the message to be signed or the hash of the message to be signed, The steps include obtaining the second private key share held by the second party, A step of calculating a second party share of a digital signature based on a message, a second private key share, and secret sharing data, wherein the secret sharing is performed between the first party who holds the first private key share, This includes the step of outputting the second party's share of the digital signature to the first party.

[0037] The method performed by the second party may perform all or part of the functions described in the method performed by the first party.

[0038] One embodiment provides an apparatus configured to perform the method of a second party.

[0039] One embodiment provides a computer-readable medium that stores instructions causing a processor to perform one of the described or requested methods when executed by the processor.

[0040] One embodiment provides a system comprising an apparatus configured to perform the method of a first party and an apparatus configured to perform the method of a second party.

[0041] One advantage of this disclosure is that grid-based digital signature schemes such as ML-DSA can be implemented across multiple parties. The process of generating a valid signature requires the cooperation of a first and second party. This enhances security because an adversary must actively or passively compromise both parties in order to break the scheme. For example, if a server is the sole party involved in the formation of a digital signature, a successful attack on the server could allow the attacker to create numerous forged digital signatures in the user's name.

[0042] In ML-DSA, a single party performs all the computations required to generate a message signature. In this two-party scheme, the computations are shared between two parties (client and server). At each stage of the algorithm, each party holds only a share of the total value. For example, one stage of the ML-DSA algorithm analyzes the coefficient values ​​of a matrix and divides them into upper and lower bits. This stage is more difficult to implement in a two-party scheme because each client holds only a share of the coefficient values. This method uses secret sharing techniques. For a quantity with a value v in the algorithm, each party holds a share v, which is a part of the total value v. Each party is unaware of the value of the share held by the other party.

[0043] This disclosure will be described in detail with reference to the following attached drawings. [Brief explanation of the drawing]

[0044] [Figure 1] This document shows an example of an overall system architecture, including server and client devices, for implementing a digital signature method. [Figure 2] Here is another example of a system architecture for implementing this method. [Figure 3] This document outlines the ML-DSA signature scheme. [Figure 4] This outlines the method for performing a signature attempt. [Figure 5A] This section provides more detailed instructions on how to perform a signature attempt. [Figure 5B] This section provides more detailed instructions on how to perform a signature attempt. [Figure 6] This shows the protocol used in the higher bit stage of the signature attempt. [Figure 7A] This shows the partial redistribution protocol used in the higher bit stage of the signature attempt. [Figure 7B] This shows the partial redistribution protocol used in the higher bit stage of the signature attempt. [Figure 8] This shows the equivalence checks used in the method for performing a signature attempt. [Figure 9] This shows the asymmetric partial redistribution protocol used in rejection checks. [Figure 10] This section outlines the disclosure steps for performing a signature trial. [Figure 11] This demonstrates key generation. [Figure 12] An example of a protocol for signing is shown. [Figure 13] An example of a protocol for signature attempts is shown below. [Figure 14] An example of a protocol for calculating the higher bits is shown. [Figure 15] An example of a protocol for zero-equivalence checking is shown below. [Figure 16] An example of a protocol for symmetric subdistribution is shown. [Figure 17] An example of a protocol for rejection checking is shown below. [Figure 18] An example of a disclosure protocol is shown below. [Figure 19] An example of a protocol for key generation is shown below. [Figure 20] An example of a protocol for asymmetric partial redistribution is shown. [Figure 21] A schematic diagram of the computer equipment that can be used to carry out this method is shown.

[0045] Similar reference numerals are used for similar components throughout the specification and drawings. [Modes for carrying out the invention]

[0046] ML-DSA is described in NIST Publication FIPS204. ML-DSA is based on the CRYSTALS-Dilithium signature scheme, which is described by Ducas et al. in "CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme," IACR Transactions on Cryptographic Hardware and Embedded Systems, Vol. 2018, No. 1, pp. 238-268.

[0047] Figure 1 shows an example of a system architecture for implementing the method relating to this disclosure. The system comprises a first party device 110 and a second party device 120, which are connected to each other via a network 130.

[0048] The first party device 110 may be a client device such as a mobile phone, smartphone, tablet device, laptop, PC, or other computing device.

[0049] The second party device 120 may be a server. The server may be configured to provide services for connecting to a plurality of client devices 110. However, in some examples, the second party device may be a client device similar to device 110. In the following description, the first party device 110 will be referred to as a client device and the second party device 120 as a server. However, the reader will understand that the scope of this disclosure is not limited thereto.

[0050] The first party device 110 has one or more processors 112 and a memory 114 for storing data 116 and instructions 119. The second party device 120 has one or more processors 122 and a memory 124 for storing data 124 and instructions 129.

[0051] The network connection 130 may be a wired or wireless connection. For example, the network connection may be a wireless wide-area network (e.g., 2G, 3G, 4G, 4G LTE, or 5G cellular connection) or a wireless local area network connection (e.g., WiFi). If both devices 110 and 120 are client devices, the connection may be a short-range connection such as Bluetooth. As the reader should understand, this is not an exhaustive list of possible connections between devices 110 and 120.

[0052] Figure 1 shows a portion of the data 116 stored in the memory 114 of the client device 110. The data 116 includes the complete public key pk117 and the private key sk= <s1> _c、 <s2>Includes the client share 118 of _c. Part of the data 126 stored in memory 124 of server 120 is the complete public key pk127 and the private key sk= <s1> _s、 <s2>This includes the server share of _s. The server may store a number of private key server shares corresponding to server shares for different client devices 110.

[0053] Figure 2 shows another example of a system architecture for implementing this method. There are many users who wish to securely sign documents using less secure devices (e.g., client devices 110 such as smartphones) and / or authenticate themselves to third parties 180. In this method, signing uses the ML-DSA algorithm, which is jointly performed by a first party (client device 110) and a second party (server 120). Server 120 is the service provider of "Parties in Threshold Signature". User 110 contacts service provider 120, and the two jointly execute a key generation protocol 210. This generates secret shares 118 and 128 of the ML-DSA private key. Client device 110 stores its secret key share 118, and server 120 stores its secret key share 128 of this jointly generated key. Client device 110 and server 120 also know the corresponding public keys 117 and 127, respectively. The overall system also includes a Public Key Infrastructure (PKI) 190. In this simplified system, the PKI is represented as a single entity 190. In reality, the PKI contains multiple distinct entities. PKI 190 stores the public key corresponding to client device 110. A third party 180 can obtain the client device's public key from PKI 190 and authenticate client 110. Client device 110 uses PKI 190 (possibly with the help of service provider 120) to distribute a statement that its public key 117 was created by it. Client device 110 and service provider 120 locally store a secret share of the private key, and the service provider records that this particular share corresponds to this particular client device 110.

[0054] The user has a value M that they wish to have signed. Value M may be a document or message to which the user claims responsibility, or it may be a challenge from someone to whom the user wishes to authenticate themselves. The user contacts the service provider using a client device and also provides the value M. After the service provider 120 is notified, both the user (using its client device 110) and the service provider 120 agree to sign value M. They jointly execute the signature protocol 220. Each party calculates its share of the digital signature. Both parties, or perhaps only one of them, know the corresponding signature σ output by the signature protocol. In this example, the first party forms the signature by combining its first party share of the digital signature and its second party share of the digital signature (block 218). In an alternative configuration, the second party forms the signature by combining its first party share of the digital signature and its second party share of the digital signature (block 218). The formation in block 218 may be additive, forming the signature from the first and second party shares.

[0055] Here, assume that third party 180 holds both the value M and the signature σ, along with the claim that the signature was created by client device 110. This party 180 uses PKI 190 to look up its user's public key, which is an ML-DSA public key. The party checks the signature σ for the value M using the ML-DSA verification algorithm 230. Party 180 does not need to know that the public key (and the corresponding private key) was generated by the two-party key generation protocol 210, or that the signature was generated by the two-party signature protocol 220. To third party 180, it is simply an ML-DSA signature.

[0056] As described above, client 110 and server 120 cooperate between the key generation protocol 210 and the signature protocol 220. The way the devices cooperate is a form of multi-party computation (MPC). This is a branch of cryptography that deals with the design and analysis of algorithms that enable multiple parties to compute a function on inputs while keeping their inputs private. In this method, through two-party computation, client 110 and server 120 can create an ML-DSA signature without either party possessing all of the corresponding private keys. Each party 110, 120 possesses only a share of the private key, which is kept secret from the other party. This helps to improve the security of the signature scheme. Various MPC techniques are used in this method. These include secret sharing techniques, which distribute a secret value among multiple participants so that no participant can recover the distributed value without the cooperation of the other party (or multiple parties). A simple example of secret sharing is additive sharing. The secret value is divided into two secret shares, which are then added together to form the secret value. Each party holding a secret share may perform various linear operations locally. These operations include addition, multiplication, and constant introduction.

[0057] In the system shown in Figure 2, if the key has already been generated by the pair of parties 110 and 120, the client device 110 and server 120 can proceed directly to the signature protocol 220. The signature protocol may be executed on multiple occasions using the same key.

[0058] Figure 2 also shows a third party called a Correlated Randomness Provider (CRP)140. The CRP will be explained in more detail below.

[0059] Figure 3 shows an overview of the ML-DSA signature scheme. The actual ML-DSA scheme includes several additional post-processing steps based on public values ​​that have been omitted for clarity. The key generation procedure is shown in box 210. This begins with randomly generating a matrix A and two vectors s_1 and s_2 with dimensions such that the calculation A·s_1+s_2 is possible. The actual dimensions are listed in Table 1 of NIST FIPS 204. The elements of the matrix and vectors are polynomials of degree up to 255, with coefficients taken modulo q. The polynomial operation is performed on polynomial X 256 The operation is performed modulo +1. The elements of matrix A are arbitrary polynomials, but the elements of vectors s_1 and s_2 are restricted, and their coefficients must be between -η and η, where the value η is very small. ML-DSA has a value of η = 2 or 4. After generating A, s_1 and s_2, matrix-vector multiplication is performed to obtain a vector t of length k. The public key pk is defined as (A, t) and the private key sk is defined as (s_1, s_2). ML-DSA has a value of q = 8380417.

[0060] The signing procedure 220 (for message M) is shown in box 220. This begins in step 221, which generates a random vector y of length l, where the coefficients are restricted to between -γ1 and γ1-1.

[0061] In step 222, w is calculated as the matrix-vector product A·y. The matrix w contains a set of elements, each having a coefficient. This method calculates the upper bits of the coefficients of the elements of w. The vector of the upper bits is w H This is how it is written.

[0062] The next step, 223, is the message and the upper bit w H The hash of is calculated to obtain the "challenge" c. The hash function defined in NIST FIPS 204 is such that the challenge c is a single polynomial (of degree up to 255). The coefficients of c are from the set {-1, 0, 1}. Of the 256 coefficients of c, there are exactly τ non-zero coefficients. Next, the elements of the vector s_1 are multiplied by the value c, and the resulting vector is added to the vector y. The resulting polynomial vector (of length l) is called z.

[0063] At this point, the signature (z,c) has been calculated. However, outputting this could potentially leak information about the private key, because not all possible values ​​of s1 and s2 may be consistent with the values ​​of z and c and the sampling method of y. On the other hand, there are cases where outputting (z,c) does not leak anything. Steps 226 and 227 implement checks to ensure that nothing is leaked. All polynomial coefficients in z must be between -γ1+β+1 and γ1-β-1. The lower bits of all polynomial coefficients in vector x (length k) must be between -γ2+β+1 and γ2-β-1. If these checks pass, it is safe to publish the signature (z,c) in step 228.

[0064] The ML-DSA verification method is shown in box 230. Verification uses the public key (A,t) and the received signature to perform checks on the values ​​of z and c.

[0065] Figure 4 shows an overview of the signature protocol implemented by parties 110 and 120. Client 110 and server 120 each hold shares of the message M to be signed, the public key (A,t), and the additively distributed private key (s_1,s_2), where the modulus of distribution is q as defined in the ML-DSA specification. The parties, with the assistance of the correlated random number provider (CRP) 140, collaboratively compute a signature for M by executing the steps of the ML-DSA signature algorithm primarily under a secure two-party computation protocol, ultimately obtaining an additive share of the signature while ensuring that information regarding the private key is not leaked to each other or to third parties.

[0066] At the end of a signing attempt, client 110 may receive the client share [z]_c and c of the signature. Alternatively, it may receive a rejection and start a new signing attempt. Similarly, at the end of a signing attempt, server 120 may receive the server share [z]_s and c of the signature. Alternatively, it may receive a rejection and start a new signing attempt. A successful signing attempt may also deliver the server share [z]_s and c of the signature to client 110. Client 110 combines [z]_c + [z]_s and verifies the signature. To protect against potentially deviant servers, the signature z is first disclosed only to client 110. Only after successful local verification of the signature does client 110 send the signature to server 120.

[0067] The functions of the first party device 110 and the second party device 120 are symmetrical with respect to most of this method.

[0068] Figure 4 shows the parties sending data along with a control value called a Message Authentication Code (MAC). The MAC code provides some assurance that the sending party has not tampered with the message. Parties 110 and 120 communicate with each other when sending shared values, etc. Additive distribution of values ​​does not provide protection against a potentially malicious party altering its share. If any share of the shared value is tampered with, the output of the protocol that depends on it may become inaccurate. In some cases, disclosing the output may be insecure, potentially exposing information about confidential material, which is unacceptable. Therefore, to achieve security against a potentially malicious party, a specific mechanism is needed that allows the other party to verify that the share received from the potentially malicious party is correct. One way to achieve this is to use a “control value” that is disclosed along with the share, which can then be used to verify its correctness. Such a “control value” is similar to a Message Authentication Code (MAC) and is often referred to by the same name for historical reasons. One appropriate form of MAC code is called the BeDOZa MAC. These are described in "Semi-Homomorphic Encryption and Multiparty Computation" by Rikke Bendlin et al., Advances in Cryptology-EUROCRYPT 2011-30th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Tallinn, Estonia, May 15-19, 2011.

[0069] For a value v, these MACs are of the form Δ_s·[v]_c (called the server MAC) and Δ_c·[v]_s (called the client MAC). These values ​​are additively distributed between the parties. The Δ value is selected (generated) by the parties from the same ring as the value v and is known only to those parties and CRP140. Due to certain security considerations arising from the security proof for the properties of the BeDOZa MAC, the ring of Δ values ​​must necessarily be a field. Therefore, only values ​​distributed in a field can be assigned a MAC.

[0070] amount <v>_c is a triplicate consisting of the client share of value v[v]_c, the client share of the client MAC for v, and the client share of the server MAC for v. <v>_s is defined similarly.

[0071] Figures 5A and 5B show an overview of the signing attempt of the signing protocol implemented by parties 110 and 120. This shows how the ML-DSA signing procedure 220 of Figure 3 is implemented by two parties 110 and 120. Each part of the protocol is shown as a box (e.g., 232, 238, 240) and will be described in more detail in subsequent drawings. Each party 110 and 120 performs calculations on the secretly shared value. Communication between parties 110 and 120 exists at some point in the protocol. At some point, the parties exchange their own secret shares of a value to determine the combined value. However, for most of this method, parties 110 and 120 perform calculations on their own secret shares without communication with the other party.

[0072] In block 232, client 110 and server 120 begin by generating a polynomial vector y. The coefficients of the polynomial are additively distributed modulo q, but each coefficient belongs to a smaller range, the size of which is a power of 2. Each coefficient is generated by calling a well-known protocol for generating random bits and calculating the coefficient as a linear combination of those bits. This block implements step 221 in Figure 3.

[0073] In blocks 234 and 236, parties 110 and 120 calculate the secretly shared value w = Ay, where w is a matrix of polynomials with coefficients. This block implements step 222 in Figure 3. It can be seen that client 110 and server 120 each implement the same functionality but use their own secret shares. For example, in block 234, client 110 uses the client share of the secretly shared vector y. <y>Perform the operation on _c. Similarly, in block 236, server 120 receives the server share of the secretly shared vector y. <y>Perform the operation on _s.

[0074] Blocks 238 and 240 are the higher bits w of the coefficients of matrix w. H Determine the following. This task is more difficult to implement between two parties with secretly shared values ​​compared to a single party. For client 110, block 238 is the client's share of matrix w. <w>Perform an operation on _c and return its share of the higher bits of matrix w. For server 120, block 238 is the server's share of matrix w. <w>Perform an operation on _s and return the share of the upper bits of the matrix w. Block 240 combines the two shares of the upper bit values into the combined upper bit value w H Combine them into. This part of the method operates without the client or server knowing the complete matrix w.

[0075] To calculate the upper bits of the secretly shared value w, the client and server use a protocol that divides w or w + Q (randomly selected) into digits according to a mixed-radix base. The digits are represented as secretly shared characteristic vectors. By choosing the base, the upper bits can be approximately calculated as a linear combination of the bits within the characteristic vector, and the non-linear part becomes an equivalence check. The division of w into digits is done with the help of a correlated random number provider that distributes the random value and the secret shares of its division into digits. This part of the protocol provides security for the client against a server attempting to deviate from the protocol, and similarly for the server against a potentially deviating client. Deviations are captured by the MAC code.

[0076] In block 240, the client and server disclose the upper bits of w. Block 240 outputs the value w H >_c, server share <w H >_s) that represents the upper bits of both shares of w. The client and server each receive w H H

[0077] Blocks 242 and 244 use the upper bits of w and M as arguments to a hash function to obtain the challenge c. These blocks implement step 223 of FIG. 3. [[ID=2�]]

[0078] Blocks 242 and 244 also calculate the secret shares of the values z = y + cs1 and x = lowbits(w) - cs2. This calculation is a linear combination of the secretly shared values already held by the parties. These blocks implement steps 224 and 225 of FIG. 3.

[0079] ​​Next, the values ​​z and x are compared to constants as part of the rejection check in block 246.

[0080] The comparison of the secretly shared value z with the boundary value B is performed again by the comparison protocol, the external structure of which follows an existing protocol that calculates the overflow bits of z and (zB) and combines them to obtain the comparison result. The overflow bits indicate whether the two shares of z held by the client and server are added to z or to z+Q.

[0081] To calculate this overflow bit, the client and server again use the random value obtained from the CRP to divide z into smaller digits.

[0082] If the rejection check passes, the signature z (with the other component c already known) is disclosed. Existing protocols operate under the assumption that neither the client nor the server deviates from the protocol. The rejection check in box 246 assumes that the server does not deviate from the protocol between the parties; that is, if the server chooses to deviate, it is not caught. The protocol does not allow the client to deviate. Because the rejection check in box 246 has the characteristic of not catching a server that deviates, the long public logical AND in box 248 is also configured not to catch a server that deviates.

[0083] Referring again to Figures 5A and 5B, the overall method can be considered to include Phase 1, Challenge Calculation, Phase 2, and Final Check, where, In the first phase, the protocol generates some secret-sharing data and some public data. The first phase includes the generation of masking vector 232 and upper bits 238. Challenge calculations 242 and 244 take the publicly available data and message M from the first phase, apply a hash function to them to generate c, Phase 2 takes the secret sharing data, challenge c, and private key share from Phase 1 and generates [z]_c. Next, it receives [z]_s and calculates z. In the final check, the client verifies that (z,c) is a valid signature for message M, and if it is not, it discards its private key share.

[0084] It was found that it is sufficient to make rejection check 246 actively secure for only one of these parties. Passive security is sufficient for the other party. Here, "passive security" actually means "active privacy," that is, if a party deviates from the protocol, the result may be erroneous, but the party will not know the secret unless the result is disclosed. Having active security for only one party makes the protocol simpler. For example, there is less communication.

[0085] The protocol again uses homomorphic MACs to add protection against potentially deviant clients.

[0086] An example of a protocol for signing is shown in Figure 12. An example of a protocol for attempting to sign is shown in Figure 13.

[0087] Note that in the protocol [Protocol 18] shown in Figure 13, μ is the only value that depends on the message. μ is used for the first time on line 7. Therefore, the signing process is based on the upper bit protocol and w H The disclosure may be reorganized to be performed as a pre-calculation, possibly in parallel with the execution of rejection checks from previous signature attempts, or possibly during times when the network and server load is lower (such as at night). Multiple signature attempts may also be performed in parallel.

[0088] Some of the steps in this method will be explained in more detail below.

[0089] [Higher bit protocol] The ML-DSA method defines the "higher bits" of the coefficients of matrix w as follows:

number

number

[0090] Q-1=2 23 -2 13 =2 13 Note that the date is 3 / 11 / 31.

[0091] The ML-DSA parameter α has the values ​​α = 190464 = (Q-1) / 44 (for ML-DSA-44) and α = 523776 = (Q-1) / 16 (for ML-DSA-65 and ML-DSA-87). For the remainder of this section, we will use α = 190464. Therefore, to calculate the higher bits of v, the first step is to calculate v' := (v + α / 2 - 1) mod Q, and then calculate "v' / α" unless v' = Q-1 (in which case this needs to be handled separately).

[0092] The following example shows the higher bits of v = 2000000. By definition, the result should be 11. In fact, v' = 2095231 and v' / α = 11 + 127 / 190464.

[0093] Figure 6 shows an overview of the upper bit protocol of the signature protocol implemented by parties 110 and 120. Each party holds a share of the coefficient values ​​in matrix w.

[0094] Here, we have selected v=2000000, which represents the client share of v. <v>Server shares of _c and v <v>This means it is the actual value obtained when _s is added together. Share <v>_c and <v>_s is summed to 2,000,000 modulo Q. For example, <v>_c=2000000 and <v>_s=0, or <v>_c=1500000 and <v>_s=500000, or <v>_c=5000000 and <v>_s=5380417 is possible.

[0095] Therefore, the first thing to do is to define v′ by adding α / 2-1 to v (and taking "mod Q", which is "automatic" for secretly shared values). This is shown in blocks 250 and 252. v′=2095231 has already been calculated. Now we need to partition this into digits according to the radix base (r1,...,rk,2s+1). The subprotocol "symmetric sub-redistribution" 254 performs the partition into digits.

[0096] The radix base is (31, 24, 16, 16, 89), where the leftmost number is the size of the least significant digit. In this example, k=4 and s=44. With this base, the digit values ​​are: (1, r1, r1*r2, r1*r2*r3, r1*r2*r3*r4) = (1, 31, 744, 11904, 190464).

[0097] The result of partitioning v' into digits is: (b1,b2,b3,b4,d)=(3,4,0,0,11). The least significant digit is the leftmost. In fact, v' = 11·190464 + 4·31 + 3.

[0098] The "symmetric subredistribution" protocol 254 may give a partition of v' into digits, or a partition of v'+Q into digits. Since v'+Q=10475648, the partition into digits is: (4, 4, 0, 0, 55).

[0099] The "symmetric partial redistribution" subprotocol 254 returns not only the digits but also the characteristic vectors of those digits. In this example, we are given five vectors of lengths 31, 24, 16, 16, and 89, each having one element "1" and the rest being "0", and all elements are additively distributed modulo Q between the client and server. Using these vectors, any function applied to a single digit becomes a linear function that can be evaluated by the client and server without further communication between them.

[0100] The characteristic vector of a value x is a vector v of length R, where x is possible in the range of 0 to (R-1). All elements of v are equal to 0, but v[x] is equal to 1. For example, if x=5 and x is fixed in some way so that its possible values ​​fall within the range of 0...9, then the characteristic vector v of x is as follows: (v[0],v[1],…v[9])=(0, 0, 0, 0, 0, 1, 0, 0, 0, 0)

[0101] If there is a division into digits v', then the value v H It can be seen that is basically d. If there is a partition of v' + Q into digits (b1, b2, b3, b4, d), then Q should be subtracted from it first. Subtraction usually gives (b1-1, b2, b3, b4, d-44), and the value v H This means it is a D-44.

[0102] These two cases can be combined into "d if d < 44, otherwise d - 44". This general rule can be evaluated without further communication between the client and server, and the result is secret-shared again. Using the notation in Figure 6, the general rule is evaluated by calculating t0 + t1, with some exceptions.

[0103] One exception is that when d≧44, i.e., when there is a partition into digits of v′+Q, the partition is (0,0,0,0,d), and here when d≧45, it should return d-45 instead of d-44. In practice, Q should be subtracted, leaving (30,23,15,15,d-45), and then the most significant digit is returned.

[0104] Another exception is when v' = Q-1. In this case, the partition into digits is (0, 0, 0, 0, 44), and we will later show that it is impossible to obtain a partition of v' + Q from the "symmetric subredistribution" protocol in this case. In fact, this is not an exception, and the general rule "d if d < 44, otherwise d-44" works for this case. The correct answer is 0, and the rule also returns 0. For the "major exceptions" mentioned above, we can calculate a value that indicates when this exception occurs. This value is as follows:

number

[0105] Here, all these checks to determine if a digit is equal to a specific value can be read from the characteristic vectors of those digits. The exception occurs precisely when all five adductors (the last of which is a sum, and at most one element can be equal to 1) are equal to 1, and the possible values ​​of x are {0, 1, 2, 3, 4, 5}. Using the "zero equivalence" protocol, we find the value z that indicates whether 5-x is equal to zero. Subtract z from the result given by the general rule.

[0106] From the above, the output of the upper bit protocol is largely calculated according to this "general rule": "d if d < 44, otherwise d - 44". Let gr(d) be the "general rule" function applied to d.

[0107] If the client and server only have a share of d, then since "gr" is not a linear function, it is not possible to calculate the share of gr(d) without communicating with each other. However, if the client and server have a share of the elements of the characteristic vector D of d, then it is possible to calculate the share of gr(d) without communicating with each other. In fact, gr(d)=D[1]+2*D[2]+3*D[3]+...+43*D

[43] +D

[45] +2*D

[46] +3*D

[47] +...+43*D

[87] +44*D

[88] These are linear functions of D[0], D[1], ..., D

[88] .

[0108] Block 258 in Figure 6 defines values ​​x1, x2, and x as specific linear combinations of values ​​b_{i,j} and d_i. These linear combinations can be computed without communication between the client and server. These calculations are performed on linear combinations of bits of the characteristic vector. The server performs the same calculations as the client, but uses the <...>_S share. Therefore, the operation is as follows: x1=b_{1,1}+b_{2,1}+…+b_{k,1} x² = d_{s+1} + d_{s+2} + ... + d_{2s} x = k + 1 - x1 - x2 The subprotocol "zero equivalent?" (block 260) is called on the secretly shared value x. Block 260 returns the value z, which is either 0 or 1, and is also secretly shared. Block 262 then computes several linear combinations. t0=d_1+2*d_2+3*d_3+…+(s-1)*d_{s-1} t1=d_{s+1}+2*d_{s+2}+3*d_{s+3}+…+s*d_{2s} These calculations are also performed on a linear combination of bits of the characteristic vector. The final step in block 262 is to compute another linear combination, t0 + t1 - z. This quantity is equal to the most significant bit of the input v.

[0109] An example of a protocol for the higher bits is shown in Figure 14.

[0110] value w H Please note that this will be disclosed during the execution of the protocol. We do not consider this to be a security concern. In short, · Value w H Since it does not depend on (s1,s2), it can be revealed early. The value w depends on y, but w H Computationally, it does not depend on y. Therefore, z and r L Even if it depends on (s1,s2) and y, w H Disclosing (and disclosing) h simultaneously with (and before) h does not disclose more information about (s1, s2) and y compared to disclosing h alone. • If the rejection check passes, the ML-DSA difficulty assumption suggests that disclosing the signature is safe. H Since it can be obtained from the public key and signature with negligible computational complexity, w H It is safe to disclose z at the same time (but before z).

[0111] [Symmetric Partial Redistribution Protocol] Figures 7A and 7B illustrate the symmetric subredistribution protocol. The structure of this protocol is the same as that used in the MPC protocol. If we have a secretly shared value v and want to compute a secretly shared value f(v), we obtain a secretly shared random value s and the corresponding secretly shared f(s) by some means (e.g., from a correlated random number provider). We disclose y=vs and perform the computation on f(s) and y to obtain f(v). The function f must be "sufficiently homomorphic" for this protocol structure to work. We find that the "symmetric redistribution to characteristic vector of digits" function is sufficiently homomorphic.

[0112] Let's continue with the same example. The cardinal number is Let (r1,r2,r3,r4,r5) = (31, 24, 16, 16, 89), Let v = 2095231 be the number of parts to be divided into. We also have (correlated) random numbers from a correlated random number provider. CRP140 starts with a random value s which is divided into a client share of s and a server share of s. Each share is divided into digits, and the digits are expanded into characteristic vectors (CV) 270, 272. The client share of CV is 270, and the server share of CV is 272. In Figure 7A, client 110 receives the client share of the digits of s in CV from CRP140. The client receives its share in vectors q_1, ..., q_k. In these vectors, the element q_{i,j} indicates whether the i-th digit of s is equal to (j-1). The client does not have q_{i,j}. It has a share of that q_{i,j}.

[0113] We randomly select s=4809829. Its digit division is (24, 19, 0, 4, 25). This can be verified. 25·190464+4·11904+19·31+24 =4761600+47616+589+24=4809829. The protocol calculates y=vs. This calculation is modulo Q. We obtain the following: y=2095231-4809829=-2714598≡5665819(modQ).

[0114] The value y is revealed, and both the client and server divide it into digits. It is found that the digits of y are (11, 8, 15, 11, 29).

[0115] Here, we have s (secretly shared) and y (known to both the client and the server), and we want to find the digit of v = y + s. In reality, in this example, y + s is not equal to v. In this example, y + s is equal to v + Q. When s > v, we can see that y + s = v + Q. When s ≤ v, y = (vs) mod Q = vs, and y + s = v. This is the origin of the randomness in the result of "symmetric subredistribution".

[0116] The numbers s have (24, 19, 0, 4, 25) and (11, 8, 15, 11, 29) digits. The protocol simply performs multi-digit addition. 1. Add 24 and 11. The result is 35. Since the base is 31, the result has 4 digits, and the carry is 1. 2. Add 19 and 8, and also add the carry of 1. The result is 28. Since the base is 24, the result has 4 digits and the carry is 1. 3. Add 0 and 15, and also add the carry of 1. The result is 16. Since the base is 16, the result has 0 digits and a carry of 1. 4. Add 4 and 11, and also add the carry of 1. The result is 16. Since the base is 16, the result has 0 digits and a carry of 1. 5. Add 25 and 29, and also add the carry of 1. The result is 55. Since the base is 89, no carry occurs here. The result is (4, 4, 0, 0, 55). Since the digits of s are represented as characteristic vectors and the digits of y are known to both the client and the server, digit addition and carry can be implemented very directly. This is shown in Figures 7A and 7B. Addition is a shift only at the zi position, where zi is the i-th digit of y. Addition with a carry is a shift of only one position. The choice of whether or not to add a carry is handled by an if-then-else protocol.

[0117] This protocol uses the following: If α = 190464, the set of cardinal numbers is: 31, 24, 16, 16, 89. If α = 523776, the set of cardinal numbers is: 31, 33, 32, 16, 33.

[0118] Figure 16 shows an example of a protocol with several different details.

[0119] [Zero-Equivalent Protocol] This is shown in block 260 of Figure 6 and in Figure 8. The input is a shared value. <v>The sharing occurs modulo q. The output is the shared bit. The variance may be under different laws. Bit b is exactly equal to 1 if v is zero. The value v must be less than a certain (fairly small) public boundary value B. Otherwise, the protocol's output is undefined.

[0120] The zero-equalization protocol uses shared values <v>And from the boundary value b, the following is satisfied <z>To obtain.

Number

[0121] The specification of "zero-equivalent" includes a parameter called "limit value" and denoted as "b". On the client side, the input to the protocol is the shared value of v <v>_c. The protocol gives the correct output only if the input "v" to the protocol is strictly less than b. An external protocol that calls a "zero-equivalent" protocol should guarantee that the input is between 0 and (b-1).

[0122] In the "higher bits" protocol in Figure 6, the value x_1 (is shared, and the client<x_1> The server has _C and<x_1> The value of x_1 (which has _S) is between 0 and k. This is because it is the sum of k bits, and each bit can be either 0 or 1. Therefore, the value x_1 is between 0 and k. The value x_2 is either 0 or 1, because it is the sum of the subvectors of the one-hot vector. The value x is equal to (k+1)-x_1-x_2, and therefore between 0 and (k+1). For this reason, we use the limit value (k+2) for the "zero-equivalent" protocol. In the example implementation, k=4.

[0123] The "zero-equivalent" protocol uses the modulo Q and parameter "a" from parameters Q and b. The input to the "zero-equivalent" protocol is v. The CRP generates a random value m and secretly shares it between the client and the server. The client and the server each calculate their respective shares of d := m + a * v. This is a linear calculation. The client calculates with its share. Symmetrically, the server calculates with its share.

[0124] The client and server disclose the value d. In addition to the random value m, CRP also secretly shares a characteristic vector of value m / a (truncate). That is, the vector t of length 7 (index 0-6) is as follows: If 0 ≤ m ≤ 1396735, then t = (1, 0, 0, 0, 0, 0, 0) If 1396736≦m≦2793591, then t=(0,1,0,0,0,0,0) If 2793592≦m≦4190387, then t=(0,0,1,0,0,0,0) If 4190388≦m≦5587183, then t=(0,0,0,1,0,0,0) If 5587184 ≤ m ≤ 6983980, then t = (0,0,0,0,1,0,0) If 6983980≦m≦8380416, then t=(0,0,0,0,0,1,0)

[0125] Both the client and the server have a disclosed value d, where a is a parameter. Therefore, the client locally calculates k := d / a (truncate). The server also calculates the same k. Then, using k, it creates a vector. <t>Index it.

[0126] (Therefore, the actual parameters are Q=8380417, b=6, and a=1396736.)

[0127] An example of the protocol is shown in Figure 15.

[0128] [Rejection Check] This protocol performs rejection checks as shown in Figures 3, 226, 227 and block 246 of Figure 6. The input is a shared vector [z] and [x] for each component dispersed on the modulo q of ML-DSA. L The output is a public bit indicating whether the check passed.

[0129] MAC is used by only one party (the server) and provides that party with a guarantee of legitimacy. The other party (the client) receives a guarantee of privacy but no guarantee of legitimacy. The guarantee of privacy is maintained only as long as the disclosed value is not made known to the server. Both legitimacy and privacy for the client are restored by final verification. In final verification, the server sends [z]_s to the client, but the client does not immediately send [z]_c to the server. Only after the client is satisfied that certain checks have passed does the client send z (which at this point is functionally equivalent to [z]_c from the server's perspective) to the server.

[0130] The inequality check may be implemented as an "asymmetric sub-redistribution" protocol followed by two "overflows," and then several arithmetic operations.

[0131] An example of the protocol is shown in Figure 18.

[0132] [Disclosure (Declassify)] Figure 9 shows the disclosure protocol, which is shown in block 240 of Figure 5A, block 278 of Figure 7A, and block 330 of Figure 8. Client 110 sends the value and the hash.

[0133] The disclosure protocol is used to disclose vectors of shared values ​​(to reveal values ​​to each other). Note that a party will only accept the other party's share if they also receive a hash value that matches the correct MAC value for the share they received. A sincere party will cease execution of the protocol (and delete the confidential material) if the security check enabled by the use of MAC (line 5 of Protocol 1) fails. The protocol can be modified to reveal values ​​to only one of the parties, or to disclose values ​​that do not have MACs.

[0134] An example of the protocol is shown in Figure 17.

[0135] [Asymmetric Partial Redistribution Protocol] Figure 9 shows the asymmetric partial redistribution protocol, which is used in the rejection check for block 246 in Figure 5B. An example of the protocol is shown in Figure 20.

[0136] This protocol is <z>or <x>This is applied to the coefficient (which is secretly shared). The structure of "asymmetric partial redistribution" is as follows: The CRP secretly shares a specific value with the client and the server. The client receives a random value from the CRP. <z>_c or <x>A single value is calculated to mask _c, and this is sent to the server. The client output of the protocol is a portion of the share the client received from CRP. The server output of the protocol is calculated based on the server's input share, the value received from the client, and the share received from CRP.

[0137] [Key generation] This protocol follows the steps of the key generation procedure shown in box 210 of Figure 3. Matrix A is generated publicly. The client and server agree on a random seed from which A is extracted. The coefficients of the polynomials in vectors s1 and s2 are generated as follows. Note that these will come from either a 5-element set or a 9-element set.

[0138] When generating random values ​​from a 5-element set, distributed modulo q in ML-DSA, a protocol for generating shared random numbers modulo 5 is first used. Then, the five possible values ​​are mapped to "-2", "-1", "0", "1", and "2", and distributed modulo q.

[0139] For random values ​​from a set of 9 elements, first a protocol for generating modulo 3 distributed random numbers is used and repeated. Next, the three possible values ​​from the first call are mapped to "-3", "0", and "3", and distributed modulo q. Then, the three possible values ​​from the first (second?) call are mapped to "-1", "0", and "1", and distributed modulo q. Next, these two are added together. The rest of the key generation consists of linear operations.

[0140] The key generation protocol is designed to be secure against actively corrupted CRPs. This is achieved by the client and server additionally verifying that the CRP input is correctly generated. In the key generation protocol, the CRP input is a collection of one-hot 0-1 vectors of length 5 (or 3 depending on the security level). To verify this, the client and server add the elements of the vector and publicly check that the sum is 1. They also form all pairwise products of the elements of the vector (not many, since the vector itself is short) and check that all products are 0. Before calculating the pairwise products, the client and server multiply the elements of the vector by a random constant to ensure that the CRP could not know the value being multiplied.

[0141] An example of the protocol is shown in Figure 19.

[0142] [CRP] The two-party computation protocol relies on a third participant, the correlated random number provider (CRP). The protocol may also be called a 2+1 party protocol. The purpose of the CRP is to issue (generate and distribute) additively distributed values ​​to the parties (server and client). The generated values ​​maintain specific relationships (or relationships) defined by the protocol in which these values ​​are used.

[0143] The CRP receives no information from the server or client except for randomly (or pseudo-randomly) generated Δ values. Alternatively, the CRP may generate the Δ values ​​themselves and send them to the client and server. Furthermore, a sincere CRP does not influence the protocol's output. Therefore, the CRP is not considered a third party in the protocol.

[0144] The amount of data that the CRP needs to send to the parties can be very large. Traffic to one of the parties can be significantly reduced by providing that party with only a seed that can be expanded into a share vector. Let f be a cryptographically secure pseudorandom number generator, and f(s) = < <v>Let >_1. Then v=< <v>>_0+f(s), where < <v>>_0 is sent to the server, and s is sent to the client. For example, a user's client device may only need to contact the CRP very rarely (strictly speaking, only once so far) to agree on the random seed that this user's client device will use. The CRP generates the service provider's correlated random number portion based on the random numbers into which the user's random seed is unfolded. A high-bandwidth connection exists from the CRP to the service provider (but not in the reverse direction) for communicating the service provider's correlated random number portion.

[0145] In reality, there are several different types of correlated random numbers generated by CRP. One form of random numbers generated by CRP is the secret sharing of a random value s, and the secret sharing of the elements of the digit characteristic vector of s used in the upper bit and partial redistribution protocols. Another form of random numbers generated by CRP is the secret sharing of a random value v, and the secret sharing of the elements of the characteristic vector of v. There is also the secret sharing of a random bit b (that bit must be distributed, modulo q). And there is the usual multiplication triplets (secret sharing of random values ​​a and b, and secret sharing of value c=ab). Rejection checks also introduce secret sharing of a random value s, and secret sharing of the digits of s.

[0146] Generally, secure computation using authenticated secret-sharing values ​​consists of two phases: an offline phase and an online phase. The offline phase can be performed without input to the computation. The output of that phase (called correlated random numbers) is used in all nonlinear operations in the online phase (i.e., all operations except addition and multiplication with constants). The offline phase is typically significantly more expensive than the online phase. The offline phase may be replaced by a "+1" party, i.e., a "correlated random number provider (CRP)," which generates correlated random numbers and sends them to the computational parties.

[0147] Figure 21 shows a schematic and simplified representation of a computer device 600 that can be used to perform the methods described herein, either alone, in combination with other computer devices, or as part of a network or “cloud” computing configuration.

[0148] The computer device 600 comprises various data processing resources, such as a processor 602 (particularly a hardware processor), coupled to a central bus structure. Further data processing resources, such as memory 604, are also connected to the bus structure. A display adapter 606 connects a display device 608 to the bus structure. One or more user input device adapters 610 connect user input devices 612, such as a keyboard and / or mouse, to the bus structure. One or more communication adapters 614 are also connected to the bus structure, providing connectivity to other computer systems 600 and other networks.

[0149] During operation, the processor 602 of the computer system 600 executes a computer program that includes computer executable instructions, which may be stored in memory 604. If executed, the computer executable instructions may cause the computer system 600 to perform one or more of the methods described herein. The results of the executed processing may be displayed to the user via the display adapter 606 and the display device 608. User input for controlling the operation of the computer system 600 may be received from the user input device 612 via the user input device adapter 610.

[0150] It will become clear that some features of the computer system 600 shown in Figure 21 may not be present in certain cases. For example, one or more of the computer devices 600 may not require a display adapter 606 or a display device 608. This may be the case, for example, with certain server-side computer devices 600 that are used solely for processing power and do not need to display information to the user. Similarly, the user input device adapter 610 and the user input device 612 may not be required. In its simplest form, the computer device 600 comprises a processor 602 and memory 604.

[0151] The detailed description above illustrates various exemplary configurations and methods for performing distributed signatures. However, it will be understood by those skilled in the art that the described configurations and methods are merely illustrative and that various modifications can be made without departing from the scope of the attached claims.

[0152] More generally, please understand that the number of steps shown in the drawings is not intended to be limited. Steps may be repeated as many times as necessary, and certain steps may be omitted.

[0153] The computer device discussed above may be a local computer or a server.

[0154] While various specific combinations of components and method steps have been described, these are merely illustrative. Components and method steps may be combined in any suitable configuration or combination. Components and method steps may also be omitted to leave any suitable combination of components or method steps.

[0155] The methods described may be implemented using computer-executable instructions. Computer program products or computer-readable media may contain or store computer-executable instructions. Computer program products or computer-readable media may include hard disk drives, flash memory, read-only memory (ROM), CDs, DVDs, caches, random access memory (RAM), and / or other storage media on which information is stored for any duration (e.g., for long periods, permanently, for short moments, for temporary buffering, and / or for information caching). Computer programs may contain computer-executable instructions. Computer-readable media may be tangible or non-temporary computer-readable media. The term "computer-readable" includes "machine-readable."

[0156] In implementation, the modules, components, and other features described herein may be implemented as individual components, or they may be integrated into the functionality of hardware components such as ASICs, FPGAs, DSPs, or similar devices.

[0157] The singular terms "a" and "an" should not be interpreted as meaning "only one." Rather, unless otherwise stated, they should be interpreted as meaning "at least one" or "one or more." The word "comprising" and its derivatives, including "comprises" and "comprise," include each of the listed features, but do not exclude the inclusion of one or more further features.

[0158] The embodiments described above are for illustrative purposes only, and should be considered in all respects as illustrative and not restrictive. It will be understood that modifications of the embodiments described can be made without departing from the scope of this disclosure. It will also be apparent that there are many modifications that are not described but fall within the scope of the appended claims.< / v> < / v> < / v> < / x> < / z> < / x> < / z> < / t> < / v> < / z> < / v> < / v> < / v> < / v> < / v> < / v> < / v> < / v> < / v> < / v> < / v> < / v> < / w> < / w> < / y> < / y> < / v> < / v> < / s1> < / s1>

Claims

1. A computer implementation method for two-party computation of a digital signature of a message using a grid-based digital signature scheme, wherein the grid-based digital signature scheme uses a public key and a private key including a first private key share and a second private key share, and the method is performed by the first party, The steps include receiving the message to be signed, The steps include obtaining the first private key share held by the first party, A step of calculating a first party share of the digital signature based on the message, the first private key share, and the secret sharing data, wherein the secret sharing is performed with a second party who holds the second private key share. The steps include receiving the second party share of the digital signature from the second party, The steps of forming the digital signature by combining the first party share of the digital signature and the second party share of the digital signature, Methods that include...

2. The method according to claim 1, further comprising the step of verifying the digital signature at the first party after forming the digital signature by combining the first party's share of the digital signature and the second party's share of the digital signature.

3. The method according to claim 2, wherein the verification includes the step of calculating a hash of the message M, the public key, and the digital signature.

4. The method according to claim 2 or 3, further comprising the step of transmitting the digital signature to the second party if the verification is successful.

5. The method according to any one of claims 2 to 4, further comprising the step of discarding the first private key share if the verification is unsuccessful.

6. The method according to any one of claims 1 to 5, wherein the step of calculating the digital signature includes the step of generating a first party share of a polynomial masking vector y having coefficients.

7. The method according to claim 6, wherein the step of generating a first party share of the masking vector includes the step of generating random bits of the coefficient.

8. The step of calculating the aforementioned digital signature is: A step of calculating the first party share of a matrix-vector product w by multiplying the first party share of the matrix A and the masking vector y contained in the public key, wherein the first party share of the matrix-vector product w includes a polynomial having the first party share of the coefficients, The steps include determining the higher bit values ​​of the coefficients of the matrix-vector product w, The method according to claim 6 or 7, including the method described in claim 6 or 7.

9. The step of determining the higher bit values ​​of the coefficients of the matrix-vector product w is: The method according to claim 8, comprising the step of determining the share of the first party of the higher bit values ​​in the matrix-vector product w.

10. The step of determining the share of the first party in the higher bit values ​​of the matrix-vector product w is: A step of calculating the first party share of the masked quantity using the first party share of the coefficient value and the first party share of the secretly shared random value s, The steps include transmitting the first party's share of the masked amount to the second party and receiving the second party's share of the masked amount from the second party, A step of restoring a combined masked amount using the masked amount of the first party and the masked amount of the second party, The method according to claim 9, including the method described in claim 9.

11. The steps include dividing the combined masked amount into digits according to the mixed radix base, The steps include receiving the first party share of the characteristic vector corresponding to the digit of the random value s, A step of adding the first party share of the characteristic vector of the digit of the random value s and the corresponding digit of the masked quantity, The method according to claim 10, further comprising:

12. The method according to claim 11, wherein the radix base includes the values ​​31, 24, 16, 16, and 89 for an ML-DSA system having a value of α = 190464, and the radix base includes the values ​​31, 33, 32, 16, and 33 for an ML-DSA system having a value of α = 523776.

13. The total high-order bit values ​​of the coefficients of the matrix-vector product w include the first party's share of the high-order bit values ​​and the second party's share of the high-order bit values, and the method is The steps include transmitting the first party's share of the above-higher bit value to the second party, The steps include receiving the second party's share of the aforementioned higher bit value from the second party, The steps include restoring the total high-order bit value by adding the share of the first party and the share of the second party in the high-order bit value, The method according to any one of claims 8 to 12, including the method described in any one of claims 8 to 12.

14. The method according to any one of claims 8 to 13, further comprising the step of calculating a challenge value c which includes a hash of a message M and the total high-order bit values ​​of the coefficients of the matrix-vector product w.

15. The steps include determining the first party share of the secret sharing signature amount z calculated using the first party share <y>_c of the masking vector y, the challenge value c, and the first party share of the private key s1_c, The steps include: performing a first rejection check on the coefficient value of the secret sharing signature amount z in cooperation with the second party; The method according to any one of claims 1 to 14, further comprising:

16. The method according to claim 15, further comprising the step of receiving the result of the first rejection check based on a comparison of the first party's share and the second party's share of the secret sharing signature amount z.

17. The steps include determining the first party share of a further secret sharing amount x calculated using the first party share of the matrix-vector product w, the challenge value c, and the first party share of the secret key s2_c, The steps include performing a second rejection check on the coefficient value of the further secret sharing signature amount x in cooperation with the second party, The method according to claim 15 or 16, further comprising:

18. The method according to claim 17, further comprising the step of receiving the result of the second rejection check based on a comparison of the first party's share and the second party's share of the further secret sharing signature amount x.

19. The method of claim 18, further comprising the step of declassifying the signature amount z to the first party if the first rejection check and the second rejection check are passed.

20. The method according to any one of claims 15 to 19, wherein the communication between the first party and the second party uses an authentication code asymmetrically.

21. The method according to any one of claims 1 to 20, wherein the first party share of the signature includes the amount z and the challenge value c.

22. The method according to any one of claims 1 to 21, wherein the first party transmits the data to the second party using a combination of the data and at least one first party authentication code.

23. The method according to any one of claims 1 to 22, wherein the first party receives data from the second party using a combination of data and at least one second party authentication code.

24. The method according to any one of claims 1 to 23, further comprising the step of generating the public key and the first private key share.

25. The method according to any one of claims 1 to 24, further comprising the step of receiving a first party share of a random number value s from a correlated random number provider.

26. The steps include receiving a seed from the aforementioned correlated random number provider, The steps include generating a first party share of multiple random values ​​from the aforementioned seed, The method according to claim 25, further comprising:

27. The method according to any one of claims 1 to 26, wherein the lattice-based digital signature scheme is the Module-Lattice-Based Digital Signature Standard (ML-DSA).

28. The method according to any one of claims 1 to 27, wherein the first party is a client device.

29. The method according to any one of claims 1 to 28, wherein the first party is a server.

30. A computer implementation method for two-party computation of a digital signature of a message using a grid-based digital signature scheme, wherein the grid-based digital signature scheme uses a public key and a private key including a first private key share and a second private key share, and the method is performed by the second party, The steps include receiving the message to be signed or the hash of the message to be signed, The steps include obtaining the second private key share held by the second party, A step of calculating a second party share of the digital signature based on the message, the second private key share, and the secret sharing data, wherein the secret sharing is performed between the first party holding the first private key share, The steps include outputting the second party's share of the digital signature to the first party, Methods that include...

31. An apparatus configured to perform the method described in any one of claims 1 to 30.

32. A computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 30.

33. A system comprising the apparatus according to claim 31 configured as the first party, and the apparatus according to claim 31 configured as the second party.

Images