DiLizium: A Two-Party Lattice-Based Signature Scheme

In this paper, we propose DiLizium: a new lattice-based two-party signature scheme. Our scheme is constructed from a variant of the Crystals-Dilithium post-quantum signature scheme. This allows for more efficient two-party implementation compared with the original but still derives its post-quantum security directly from the Module Learning With Errors and Module Short Integer Solution problems. We discuss our design rationale, describe the protocol in full detail, and provide performance estimates and a comparison with previous schemes. We also provide a security proof for the two-party signature computation protocol against a classical adversary. Extending this proof to a quantum adversary is subject to future studies. However, our scheme is secure against a quantum attacker who has access to just the public key and not the two-party signature creation protocol.


Introduction
Ever since Peter Shor proposed an algorithm that was able to efficiently break most of the classical asymmetric cryptographic primitives such as RSA or ECDSA in the 1990s [1,2], research has been conducted to find quantum-resistant replacements. This work has recently been coordinated by the U.S. National Institute of Standards and Technology (NIST). In 2016, NIST announced an effort to standardise some of the proposed public key encryption algorithms, key-establishment algorithms, and signature schemes [3].
The primary focus of NIST is to obtain drop-in replacements for the current standardised primitives in order to ease the transition. However, not all of the current application areas are covered by the standardisation process.
One important class of examples is threshold signatures. In a (t, n)-threshold scheme, the secret key is shared between n users/devices. To create a valid signature, a subset of t users/devices should collaborate and use their secret key shares. Over the years, threshold versions of a number of major cryptographic algorithms including RSA and (EC)DSA have been studied [4][5][6][7][8]. Recent interest in threshold versions of ECDSA has been influenced by applications in blockchains. However, our motivation stems more from server-assisted RSA signatures, as proposed in the scheme by Buldas et al. [9]. This scheme has been implemented in a Smart-ID mobile application and was recognised as a qualified signature creation device (QSCD) in November 2018 [10]. In 2021, the number of Smart-ID users in the Baltic countries was estimated at 2.9 million [11].
In 2019, D. Cozzo and N. Smart analysed a number of NIST post-quantum standardisation candidates and concluded that none of them provide a threshold implementation that would be comparable in efficiency to threshold RSA or even ECDSA [12].
The goal of this research is to find a suitable version of one of the NIST signature candidates (Crystals-Dilithium) that would allow for a more efficient two-party implementation but would still provide post-quantum security. From this, we propose a concrete/specific two-party signature scheme and prove its security in this paper.

Related Work
In 2020, NIST announced fifteen third-round candidates for the PQC competition, of which seven were selected as finalists and eight were selected as alternate candidates [17]. The finalists in the digital signature category were Crystals-Dilithium [18], Falcon [19], and Rainbow [20]. Crystals-Dilithium and Falcon are both lattice-based signature schemes. Falcon has better performance, signature, and key sizes; however, its implementation is more complex, as it requires sampling from the Gaussian distribution and it utilises floating-point numbers to implement an optimised polynomial multiplication [19]. The performance of a Crystals-Dilithium signature scheme is slightly slower, and the signature and key sizes are larger than the ones in Falcon; however, the signature scheme itself has a simpler structure [18]. Rainbow is a multivariate signature scheme with fast signing and verifying processes. The size of the Rainbow signature is the shortest among the finalists; however, the public key size is the largest [20].
Due to the interest aroused by the PQC competition, several works were proposed that introduce lattice-based threshold signatures and lattice-based multisignatures. The works [21][22][23][24][25][26] focused on creating multisignatures that followed the FSwA paradigm. These schemes use rejection sampling, due to which the signing process is repeated until a valid signature is created. Additionally, intermediate values produced during the signature generation process need to be kept secret until the rejection sampling has been completed. There are currently no known techniques to prove the security of FSwA signatures if intermediate values are published before the rejection sampling is performed [16]. In multisignatures [21][22][23][24][25], intermediate values are published before the rejection sampling is completed, which leads to incomplete security proofs in these works [16]. The work by M. Fukumitsu and S. Hasegawa [26] solves the problem with aborted executions of the protocol by introducing a non-standard hardness assumption (rejected Module-LWE).
In 2019, D. Cozzo and N. Smart analysed the second round NIST PQC competition signature schemes to determine whether it is possible to create threshold versions of these signature schemes [12]. The authors proposed a possible threshold version for each of the schemes using only generic Multiparty Computation (MPC) techniques, such as linear secret sharing and garbled circuits. As a result, the authors proposed that the most suitable signature scheme is Rainbow, which belongs to the multivariate family. The authors described a threshold version of Crystals-Dilithium, which is estimated to take around 12 s to produce a single signature. The authors explained that the problems with performance arise from the fact that the signature scheme consists of both linear and nonlinear operations and that it is inefficient to switch between these representations using generic MPC techniques. However, the goal of the current work is to focus on the two-party scenario. This means that some of the difficulties in D. Cozzo and N. Smart paper can be avoided.
R. Bendlin, S. Krehbiel, and C. Peikert proposed threshold protocols for generating a hard lattice with trapdoor and sampling from the discrete Gaussian distribution using the trapdoor [27]. These two protocols are the main building blocks for the Gentry-Peikert-Vaikuntanathan (GPV) signature scheme (based on hash-and-sign paradigm), where generating a hard lattice is needed for the key generation and Gaussian sampling is needed for the signing process. M. Kansal and R. Dutta proposed a lattice-based multisignature scheme with a single round signature generation that has key aggregation and signature compression in [28]. The underlying signature scheme follows neither the hash-and-sign nor FSwA paradigms, which are the main techniques used to construct lattice-based signature schemes.
In 2020, I. Damgård, C. Orlandi, A. Takahashi, and M. Tibouchi proposed a latticebased multisignature and distributed signing protocols that are based on the Dilithium-G signature scheme [16]. Dilithium-G is a version of the Crystals-Dilithium signature that requires sampling from a discrete Gaussian distribution [29]. The work contains complete classical security proofs for the proposed schemes. The work solves the problem with the aborted executions by using commitments such that, in the case of an abort, only commitment is published, the intermediate value itself stays secret. The proposed distributed signature scheme could potentially fit the Smart-ID framework; however, some questions need to be addressed. More precisely, the scheme is based on a modified version of Crystals-Dilithium from the NIST PQC competition project and uses Gaussian sampling. It is known that generating samples from the Gaussian distribution is nontrivial, which means that the insecure implementation may lead to side-channel attacks [30]. The open question is whether it is possible to use a version of the scheme more similar to the one being submitted to the NIST PQC competition.

Notation
• Let Z be a ring of all integers. Z q = Z/qZ denotes a ring of residue classes modulo q. Z[x] denotes a ring of polynomials in the variable x with integer coefficients. • R denotes a quotient ring Z[x]/(x n + 1), where n ∈ N and R q denotes a quotient ring Z q [x]/(x n + 1), where n ∈ N. • Polynomials are denoted in italic lowercase p. p ∈ R q is a polynomial of degree bound by n: p = p 0 + p 1 x + . . . + p n−1 x n−1 . It can also be expressed in a vector notation through its coefficients (p 0 , p 1 , . . . , p n−1 ). • Vectors are denoted in bold lowercase v. v ∈ R n q is a vector of dimension n: v = (v 0 , . . . , v n−1 ), where each element v i is a polynomial in R q .

•
Matrices are denoted in bold uppercase A. A ∈ R n×m q is a n × m matrix with elements in R q . • For an even positive integer α and for every x ∈ Z, define x = x mod ± α, as x in the range − α 2 < x ≤ α 2 such that x ≡ x (mod α). For an odd positive integer α and for every For an element p = p 0 + p 1 x + . . . + p n−1 x n−1 ∈ R q , its l 2 norm is defined as For an element x ∈ Z q , its infinity norm is defined as ||x|| ∞ = |x mod ± q|, where |x| denotes the absolute value of the element. For an element p = p 0 + p 1 x + . . .
S η denotes a set of all elements p ∈ R such that ||p|| ∞ ≤ η. • a ← A denotes sampling an element uniformly at random from the set A. • a ← χ(A) denotes sampling an element from the distribution χ defined over the set A. • x denotes mapping x to the least integer greater than or equal to x (e.g., 5.2 = 6). • The symbol ⊥ is used to indicate a failure or rejection.

Definitions of Lattice Problems
Definition 1 (Decisional Module-LWE (q, n, m, η, χ)). Let χ be an error distribution, given a pair (A, t) ∈ (R n×m q × R n q ) decide whether it was generated uniformly at random from R n×m q × R n q or it was generated as A ← R n×m q , (s 1 , s 2 ) ← χ(S m η × S n η ) and t := As 1 + s 2 .
The advantage of adversaryA in breaking decisional Module-LWE for the set of parameters (q, n, m, η, χ) can be defined as follows: Definition 2 (Computational Module-LWE (q, n, m, η, χ)). Let χ be an error distribution, given a pair (A, t) ∈ (R n×m q × R n q ), where A ← R n×m q , (s 1 , s 2 ) ← χ(S m η × S n η ), and t := As 1 + s 2 when finding a vector s 1 .
The advantage of adversary A in breaking computational Module-LWE for the set of parameters (q, n, m, η, χ) can be defined as follows: Definition 3 (Module-SIS (q, n, m, η)). Given a uniformly random matrix A ← R n×m q , find a vector x ← R n+m q such that A|I · x = 0 and 0 < ||x|| ∞ ≤ η.
The advantage of adversary A in breaking Module-SIS for the set of parameters (q, n, m, η) can be defined as follows: Additionally, we define the rejected Module-LWE assumption adapted from [26].
The advantage of adversaryA in breaking the rejected Module-LWE for the set of parameters (q, n, m, γ, χ, β) can be defined as follows:

Forking Lemma
The following forking lemma is adapted from [31]. x can be viewed as a public key of the signature scheme, and h 1 , . . . , h q can be viewed as replies to the random oracle queries.
Lemma 1 (General forking lemma). Fix an integer q ≥ 1 to be the number of queries. Fix set C of size |C| ≥ 2. Let B be a randomised algorithm that takes as input x, h 1 , . . . , h q , where (h 1 , . . . , h q ) ∈ C, and returns a pair with the first element being index i (integer in the range {0, . . . , q}) and the second element being side output out. Let IG be a randomised input generation algorithm. Let the accepted probability of B be denoted as acc. This is the probability that i = 0 in the following experiment: The forking algorithm F B connected with B is defined in Algorithm 1. Let us define the f rk probability as Then, Alternatively,

Lattice-Based Signature Scheme
Lattice-based cryptography is a promising candidate for the post-quantum public key cryptography standards. Among all of the submissions to the NIST PQC competition, the majority of schemes belong to the lattice-based family [17]. Many lattice-based signatures are constructed from the identification schemes using the Fiat-Shamir (FS) transform. The FS transform technique introduced in [32] allows for creating a digital signature scheme by combining an identification scheme with a hash function.
The following definition is adapted from [13].
Definition 5 (Identification scheme). An identification scheme ID is defined as a tuple of algorithms ID := (IGen, P, C, V).

•
The key generation algorithm IGen takes as input system parameters par and returns the public key and secret key as output (pk, sk). Public key pk defines the set of challenges C, the set of commitments W, and the set of responses Z.

•
The prover algorithm P = (P 1 , P 2 ) consists of two sub-algorithms. P 1 takes as input the secret key and returns a commitment w ∈ W and a state st. P 2 takes as input the secret key, a commitment, a challenge, and a state and returns a response z ∈ Z ∪ {⊥}. • The verifier algorithm V takes as input the public key and the conversation transcript and outputs a decision bit b = 1 (accepted) or b = 0 (rejected).
In the signature scheme that uses FS transform, the signing algorithm generates a transcript (w, c, z), where a challenge c is derived from a commitment w and the message to be signed m as follows c := H(w||m). The signature σ = (w, z) is valid if the transcript (w, c, z) passes the verification algorithm with b = 1. The publication [33] introduced a generalisation to this technique called Fiat-Shamir, with aborts transformation that takes into consideration aborting provers.
The following signature scheme (further referred to as the basic scheme) is a slightly modified version of the scheme [34]; the description below is based on a version described in [13] (Appendix B). The signature scheme makes use of a hash function, which produces a vector of size n with elements in {−1, 0, 1} [18]. The hashing algorithm starts with applying a collision-resistant hash function (e.g., SHAKE-256) to the input to obtain a vector s ∈ {0, 1} τ from the first τ bits of the hash function's output. Then, SampleInBall algorithm (Algorithm 2) is invoked to create a vector c in {−1, 0, 1} n with exactly τ nonzero elements. In each iteration of the for loop, the SampleInBall algorithm generates an element j ∈ {0, . . . , i} using the output of a collision-resistant hash function. Then, the algorithm performs shuffling of the elements in the vector c and takes an element from the vector s to generate −1 or 1. For an in-depth overview of the algorithm, refer to the original paper [18]. 1: (z 1 , z 2 ) = (⊥, ⊥) 2: while (z 1 , z 2 ) = (⊥, ⊥) do: 1. y 1 , y 2 ← S k γ 1 −1 2. w := Ay 1 + y 2 3. c := H 0 (m||w) ∈ B τ 4. z 1 := y 1 + cs 1 and z 2 : Algorithm 5 Verify(pk, m, σ).

Correctness
Since w = Ay 1 + y 2 , t = As 1 + s 2 , z 1 = y 1 + cs 1 . and z 2 = y 2 + cs 2 , it holds that Therefore, if a signature was generated correctly, it will successfully pass the verification.

Homomorphic Hash Function
We decided to use a homomorphic hash function instead of a homomorphic commitment scheme as in [16].
Definition 6 (Homomorphic hash function). Let + be an operation defined over X, and let ⊕ be an operation defined over R. Let x 1 , x 2 ∈ X be any two inputs to the hash function. A hash function f : X → R is homomorphic if it holds that Definition 7 (Regular hash function). Let F = { f a } a∈A , where f a : X → R be a collection of functions indexed by a set A. A family of hash functions F is called -regular if the statistical distance between its output distribution {(a, f a (x)) : a ← A, x ← X} and the uniform distribution {(a, r) : a ← A, r ← R} is at most .
One of the homomorphic hash functions available is called SWIFFT; it is a special case of the function proposed in [35][36][37]. SWIFFT is a collection of compression functions that are provably one-way and collision-resistant [38]. Additionally, SWIFFT has several statistical properties that can be proven unconditionally: universal hashing, regularity, and randomness extraction. However, due to the linearity, SWIFFT functions are not pseudorandom. It follows that the function is not a suitable instantiation of a random oracle [38]. Therefore, in the security proofs of the two-party signature scheme, SWIFFT is not used as a random oracle. Security proof makes use of such provable properties as regularity and collision resistance.

Proposed Two-Party Signature Scheme (DiLizium)
In the following section, we define and give detailed description of our two-party signature scheme: DiLizium. We start by defining the distributed signature scheme; the following definition is adapted from [16].

Definition 8 (Distributed signature protocol).
Distributed signature protocol is a protocol between P 1 , . . . , P n parties that consists of the following algorithms: • Generate public parameters par using security parameter λ as input: par ← Setup(1 λ ). • Each party P j generates a key pair consisting of secret key share and a public key using interactive algorithm and public parameters as input: (sk j , pk) ← KeyGen j (par) for each j ∈ {1, . . . , n}.

•
To sign a message m, each party P j runs an interactive signing algorithm using secret key share: (σ) ← Sign j (sk j , m) for each j ∈ {1, . . . , n}.

•
To verify a signature, the verifier needs to check if Verify(pk, m, σ) = 1. If the signature was generated correctly, verification should always succeed. Table 1 describes the parameters used in the two-party signature scheme.  Let us assume that, before starting the key generation and signing protocols, the parties invoke a Setup(1 λ ) function that, based on the security parameter λ, outputs a set of public parameters par that are described in Table 1.

Key Generation
H 1 and H 2 are some collision-resistant hash functions. The key generation protocol is parametrised by the set of public parameters par. The client begins the key generation process by sampling a share of matrix A c and by sending out the commitment to this share hk c = H 1 (A c ). The server generates its matrix share A s and sends commitment hk s to the client. Upon receiving commitments, the client and server exchange matrix shares and check if the openings for the commitments were correct. If openings are successfully verified, the client and server locally compute composed matrix The client proceeds by generating two secret vectors (s c 1 , s c 2 ) and by computing its share of the public key t c = As c 1 + s c 2 . The client sends out a commitment to the public key share comk c = H 2 (t c ). The server samples its secret vectors (s s 1 , s s 2 ) and uses them to compute its public key share t s . Next, the server sends commitment to the public key share comk s to the client.
Once the client and server have received commitments from each other, the client and server exchange public key shares. Next, the client and server both locally check if the commitments were opened correctly. If these checks succeed, the client and server locally compute the composed public key t = t c + t s . The final public key consists of composed matrix A and vector t.
It is necessary to include the server's public key share t s to the client's secret key sk c and vice versa. During the signing process, the client needs to use the server's public key share to verify the correctness of a commitment.
Protocol 1 describes two-party key generation between the parties in a more formal way. Instructions of the protocol are the same for the client and server. Therefore, Protocol 1 presents the behavior of the nth party, n ∈ {c, s}.

Signing
HomH is a homomorphic hash function from the SWIFFT family. H 0 is a hash function that outputs a vector of length n with exactly τ coefficients being either −1 or 1 and the rest being 0 as described in Algorithm 2. H 3 is a collision-resistant hash function.
The client starts the signing process by generating its shares of masking vectors (y c 1 , y c 2 ) and by computing a share of w. Next, the client uses a homomorphic hash function to compute com c = HomH(w c ) and hashes it using some collision-resistant hash function h c = H 3 (com c ). The composed output of the homomorphic hash function com = com c + com s is later used to derive a challenge. Therefore, it is crucial to ensure that com c , com s have not been chosen maliciously. Thus, before publishing these shares, the client and server should exchange commitments to the shares h c , h s .
The server, in turn, generates its shares of masking vectors (y s 1 , y s 2 ), computes its share of w, and sends commitment to com s = HomH(w s ). After receiving commitments h c , h s from each other, the client and server open the commitments by sending out shares com s , com c .
The client proceeds by checking if the server opened its commitment correctly. If the check succeeds, the client computes com = com c + com s and derives challenge c = H 0 (m||com). Next, the client computes potential signature shares (z c 1 , z c 2 ) and performs rejection sampling. If all of the conditions in rejection sampling are satisfied, the client sends its signature share to the server.
The server checks if the client opened its commitment correctly. If the check succeeds, the server computes composed com and derives challenge c. Next, the server computes its potential signature shares (z s 1 , z s 2 ) and performs rejection sampling. If all of the conditions in rejection sampling are satisfied, the server sends its signature share to the client.
Finally, the client performs verification if com s indeed contains w s . The client reconstructs w s as Az s 1 + z s 2 − ct s and checks if it is a valid opening for com s . If the check succeeds, the client computes the final signature (z 1 , z 2 ). The server performs the same verification that com c indeed contains w c using (z c 1 , z c 2 ) and t c . If the check succeeds, the server computes and outputs the final signature.
Protocol 2 describes the two-party signing process in the more formal way.

Verification
Verification is almost the same as in the original scheme except the verifier needs to apply homomorphic hash function on the reconstructed w in order to check the correctness of challenge. Algorithm 6 describes verification in the more formal way.

Correctness
Since w = Ay 1 + y 2 , t = As 1 + s 2 , z 1 = y 1 + cs 1 and z 2 = y 2 + cs 2 it holds that: Furthermore, by triangle inequality, it holds that if ||z s The same holds for the second signature component z 2 . This means that γ 2 can be defined as γ 2 = 2γ and β 2 = 2β. Therefore, if a signature was generated correctly, verification always succeed.

1.
First message: (a) A n ← R k×k q , send out hk n := H 1 (A n ).

2.
Second message: (a) Upon receiving hk i , send out A n .

4.
Fourth message (a) Upon receiving comk i , send out t n .

Verification
Final public key pk = (A, t).

Second message
(a) Upon receiving h i , send out com n .

5.
Upon receiving RESTART message (a) Client and server start signing process again from the beginning.
otherwise, return 0 Oracle 1: KeyGenO(par, sid, msg); The oracle is initialised with the set of public parameters par generated by the Setup(1 λ ) algorithm.

2.
Upon receiving query with sid = 0 for the first time, This section presents the main idea for the security proof of the proposed scheme; the full proof is given in Appendix A. The proof considers only the classical adversary and relies on the forking lemma. The idea of the proof is, given an adversary A that succeeds in creating forgeries for the distributed signature protocol, to construct an algorithm around it that can be used to solve Module-SIS problem or to break the collision resistance of the homomorphic hash function. The idea of our proof relies on the proofs from [7,16,31,39].
The proof consists of two major steps. In the first step, we construct a simulator B. Algorithm B is constructed such that it fits all of the assumptions of the forking lemma. B simulates the behavior of a single honest party P n without using its actual secret key share. In the second step, the forking algorithm is invoked to obtain two forgeries with distinct challenges and the same commitments.

Simulation
In the key-generation process, we need to simulate the way the matrix share A n and the public vector share t n are constructed. Due to the use of random oracle commitments, once the simulator obtains the adversary's commitment hk i , it can extract the matrix share A i . Next, the simulator computes its matrix share A n := A − A i using a resulting random matrix A ∈ R k×k q and programs random oracle H 1 (A n ) := hk n . Due to the Module-LWE assumption, the public vector share of the honest party t n is indistinguishable from the uniformly random vector sampled from the ring R k q . Using the same strategy as that for the matrix share, the simulator sets it public vector share t n := t − t i after seeing the adversary's commitment and programs the random oracle H 2 (t n ) := comk n .
The signature share generation starts with choosing a random challenge c ∈ C from the set of all possible challenges. Then, the simulator proceeds with randomly sampling two signature shares from the set of all possible signature shares z n 1 , z n 2 ← S k γ−β−1 . The share of vector w is computed from the signature shares, public vector share, and challenge as w n = Az n 1 + z n 2 − ct n . Then, the simulator extracts value com i from the adversary's commitment h i , computes the composed value com, and programs random oracle H 0 (com||m) := c.

Forking Lemma
The combined public key consists of matrix A uniformly distributed in R k×k q and vector t uniformly distributed in R k q . We want to replace it with the Module-SIS instance A |I , where A ∈ R k×(k+1) q . The view of adversary does not change if we set A = A|t . In order to conclude the proof, we need to invoke the forking lemma to receive two valid forgeries from the adversary that are constructed using the same commitment com = com but different challenges c = c . Using these forgeries, it is possible to find a solution to the Module-SIS problem on input A = A|t or to break the collision resistance of the homomorphic hash function.
As both forgeries out = (com, c, z 1 , z 2 , m) and out = (com , c , z 1 , z 2 , m ) are valid, it holds that If Az 1 + z 2 − ct = Az 1 + z 2 − c t, then we found a collision for the homomorphic hash function. If Az 1 + z 2 − ct = Az 1 + z 2 − c t, then it can be rearranged as Az 1 − Az 1 + z 2 − z 2 − ct + c t = 0 and this in turn leads to Considering that A|I|t is an instance of Module-SIS problem, we found a solution for Module-SIS with parameters (q, k, k + 1, ξ), where ξ ≤ 2(γ 2 − β 2 ).

Performance
In this section, we analyse the performance of our scheme according to the following metrics: It should be noted that this section does not present the exact parameter choice for the scheme and does not argue the bit security of the scheme for these parameters. The parameter choice presented in this section is illustrative and is given to provide performance estimations of the proposed scheme. Choosing correct parameters for postquantum schemes is a nontrivial multidimensional optimisation task as parameters should be chosen such that the scheme has the small signature and key sizes while having enough bits of security and an optimal number of communication rounds. Additionally, the security of the proposed scheme relies on rejected Module-LWE, which is not a wellstudied assumption, and therefore, it is difficult to estimate the bit security of the proposed scheme. The parameters presented in Table 2 are chosen based on parameters proposed in Crystals-Dilithium [18] so that the expected number of repetitions of the signing process is practical.

Number of Rejection Sampling Rounds
To estimate the number of rejection sampling rounds in the signing process, it is necessary to compute the probability that the following holds for both parties: ||z n 1 || ∞ < γ − β and ||z n 2 || ∞ < γ − β. Let σ be a coefficient of cs n i . If coefficients of y n i are in the range {−γ + β + 1 − σ, . . . , γ − β − 1 − σ}, then the corresponding coefficients of z n i are in the range {−γ + β + 1, . . . , γ − β − 1}. Therefore, the size of the correct coefficient range for y n i is 2(γ − β) − 1 and the coefficients of y n i have 2γ − 1 possibilities. Then, the probability that every coefficient of y n i in the correct range is as follows: As the client and server sample vectors y n i independently in the beginning of the signing protocol, the probability that the check succeeds for both signature components on the client and server side is the following: The expected number of repetitions can be estimated as E = 1/Pr[success].

Signature and Key Sizes
The public key consists of two components: matrix A ∈ R k×k q and vector t ∈ R k q . The matrix A can be generated out of 256-bit seed using an extendable output function, as proposed in the Crystals-Dilithium signature scheme [18]. While using this approach, only the seed used to generate the matrix needs to be stored. As both parties need to generate their matrix share, two seeds should be stored to represent matrix A. Each seed is converted to the matrix form using an extendable output function; after that, two matrix shares can be added together. The size of the public key in bytes is as follows: The secret key of the party P n consists of two vectors s n 1 , s n 2 ∈ S k η , matrix A, and vector t i ∈ R k q . It should be noted that vectors s n 1 , s n 2 may contain negative values as well, so one bit should be reserved for each coefficient to indicate the sign. Therefore, the size of the secret key in bytes can be computed as follows: 2 · n · k · ( log(η) + 1) + 2 · 256 + n · k · log(q) 8 = n · k · (2 · ( log(η) + 1) + log(q) ) + 2 · 256 8 .
Finally, a signature consists of three components: z 1 , z 2 ∈ S k γ 2 −β 2 −1 , and c ∈ {0, 1} n with exactly τ coefficients being either −1 or 1 and the rest being 0. All of the components may contain negative values, so for each coefficient of z 1 , z 2 , c one bit should be reserved to indicate the sign. With regard to storing c, it is possible to store only the positions of −1 and 1 in c. Therefore, the size of the signature in bytes can be computed as 2 · n · k · ( log(γ 2 − β 2 − 1) + 1) + τ · ( log(n) + 1) 8 .
In order to better understand key and signature sizes, let us assume the choice of parameters defined in Table 2. The key and signature sizes corresponding to this choice of parameters are listed in Table 3.  Table 3. Key and signature sizes and expected number of repetitions of the signing protocol.

Values Sizes
Public key pk 3744 bytes Secret key share sk i 4384 bytes Signature σ 6788 bytes Expected number of repetitions 3.23

Communication between Client and Server
In order to generate a key pair, four rounds of communication between the client and server are needed. Table 4 shows the sizes of messages that are exchanged between the client and server during the key generation process using illustrative parameters from Table 2. The first message is output of a hash function (commitment to matrix A i ), which consists of 256 bits. The second message contains not the matrix share itself but the seed of 256 bits that was use to generate it. The third message is output of a hash function (commitment to vector t i ), which consists of 256 bits. The fourth message is the share of public key t i , the size of which is n · k · log(q) 8 bytes.
The number of communication rounds during the signing process depends on the number of rejections E. If there are no rejections, the signature generation process requires three rounds of communication between the client and server. For E rejections, the number of communication rounds equals to 2E + 1. Table 5 shows the sizes of messages exchanged between the client and server during the signing process using illustrative parameters from Table 2. The first message is output of a hash function (commitment to com i ), which consists of 256 bits. The size of the second message in the signing process com i is caused by the structure of SWIFFT hash function. To calculate HomH(w i ), the vector w i that consists of nk elements is divided into 15 input blocks of 256 bytes each. The output produced by the homomorphic hash function consists of 15 blocks of 128 bytes each. The third message consists of the signature shares (z i 1 , z i 2 ), the size of which is 2 · n · k · ( log(γ 2 − β 2 − 1) + 1) 8 bytes. Table 4. Message sizes in the key generation process.

Messages Sizes
First message hk i 256 bits Second message A i (as seed) 256 bits Third message comk i 256 bits Fourth message t i 3680 bytes Table 5. Message sizes in the signing process.

Messages Sizes
First message (h i ) 256 bits Second message com i 1920 bytes Third message (z i 1 , z i 2 ) 6080 bytes Table 6 presents the comparison of our scheme DiLizium with other lattice-based threshold signature schemes [16,27,40]. Column "Rounds" shows the number of communication rounds in signing protocol; for the schemes with rejection sampling, it is assumed that the rejection sample passes from the first attempt. We also provide a more detailed comparison with [16], due to the fact both works are based on variants of Crystals-Dilithium and have a similar structure. We leave out the comparison with publications [21][22][23][24][25][26] as these discuss multisignatures instead of threshold. Table 6. Comparison with prior work.

Functionality Paradigm Rounds Security
Bendlin et al. [27] t-out-of-n Hash-and-Sign 1 Gentry et al. [41] Boneh et al. [40] t-out-of-n Any (Universal Thresholdizer) 1 LWE Dåmgard et al. [ The threshold signature schemes from [16] are based on Dilithium-G, which is a version of Crystals-Dilithium that uses sampling from a discrete Gaussian distribution for the generation of secret vectors. The usage of Gaussian distribution helps to decrease the number of rejections in signature schemes that follow the FSwA paradigm [16]. However, the implementation of sampling from a discrete Gaussian distribution in a manner secure against side-channel attacks is considered difficult. Therefore, in our scheme, we decided to use sampling from a uniform distribution.
Due to the structure of our scheme, we use a non-standard security assumption that was introduced in [26]. In future work, we aim to modify security proof such that it will no longer be needed to rely on rejected Module-LWE. The security of threshold signature scheme from [16] relies only on standard problem: Module-LWE and Module-SIS.
Additionally, we compare the message sizes of Dåmgard et al. [16] DS 3 with our scheme. Since this paper [16] does not provide an instantiation of parameters, we use the recommended parameters for Dilithium-G from [29] for the signature scheme. We only changed the modulus q, since by Theorem 4 [16], q should satisfy q = 5 mod 8. We selected parameters for the homomorphic commitment scheme based on the third parameter set from Baum et al. [42] (Table 2) such that the conditions from Lemma 5 and Lemma 7 are satisfied. Tables 7 and 8 present parameters that are needed to compute message sizes. We only provide a comparison of messages sent during the signing process because messages exchanged during the key generation process are similar in both schemes ( Table 9).
The first message is the output of a hash function (commitment to com n ), which consists of 256 bits. The second message is a commitment com n . The homomorphic commitment scheme defined in Dåmgard et al. [16] (Figure 7) describes a commitment to a single ring element w ∈ R q . In order to commit to a vector w ∈ R k q , it is proposed to commit to each vector element separately. Therefore, the byte size of the second message can be computed as k sig · N · (m + k com ) · log(q com ) 8 . The third message consists of a signature share z n and an opening for the commitment r n . We know that, for a valid signature share, it holds that ||z n || 2 ≤ B sig and we know that ||x|| ∞ ≤ ||x|| 2 . The signature share may contain negative values, so for each coefficient of z n , one bit should be reserved to indicate the sign. Therefore, the approximate byte size of the signature share is n · (l + k sig ) · ( log(B sig ) + 1) 8 . For a valid opening, it holds that ||r n || 2 ≤ B com . The value r n also may contain negative values, so for each coefficient of r n , one bit should be reserved to indicate the sign. The approximate byte size of the commitment opening is k sig · N · m · ( log(B com ) + 1) 8 .  [16].

Parameters for Signature Scheme Description Sizes
n The degree bound of the polynomials in the ring 256 q sig Modulus 8,380,781 (k sig , l) Dimension of matrix and vectors (4, 4) η Size bound of coefficients in the secret key share 5 τ Number on non-zero elements in the output of hash function H 0 60 σ sig Standard deviation of the Gaussian distribution ≈17,900 B sig The maximum l 2 norm of signature share z j ∈ R l+k sig q sig ≈990,000 Table 8. Illustrative parameters for Dåmgard et al. [16] statistically binding commitment scheme.

Parameters for Commitment Scheme Description Sizes
N The degree bound of the polynomials in the ring 1024 q com Modulus ≈2 55 (m, m , k com ) Dimension of matrices and vectors (6, 9, 1) σ com Standard deviation of the Gaussian distribution ≈46,000 The maximum l 2 of commitment opening r j ∈ R m q com ≈17,664,000  Table 9, we can see that the size of the second and the third messages in Dåmgard et al.'s DS 3 scheme is much larger than that in DiLizium. The reason is that scheme DS 3 Dåmgard et al. uses lattice-based homomorphic commitments. For the signature scheme to be secure, it was required to have statistical binding. Parameters that guarantee statistical binding are not very practical; however, there may exist optimal parameter choice. Currently, it is not possible to provide a more detailed comparison of the efficiency of these schemes. The main reason is that neither of the works have a reference implementation yet. Therefore, we leave the implementation of the proposed scheme and a detailed comparison for future research.

Conclusions
Nowadays, threshold signature schemes have a variety of practical applications. There are several efficient threshold versions of the RSA and (EC)DSA signature schemes that are used in practice. However, threshold instantiations of post-quantum signature schemes are less researched. Previous researches have demonstrated that creating threshold postquantum signatures is a highly non-trivial task. Some of the proposed schemes yield inefficient implementation, while others have incomplete security proofs.
In this work, we presented a new lattice-based two-party signature scheme: DiLizium. Our construction uses the SWIFFT homomorphic hash function to compute commitment in the signing process. We provide security proof for our scheme in the classical random oracle model under the Module-LWE, rejected Module-LWE, and Module-SIS assumptions. The proposed scheme can potentially substitute distributed RSA and ECDSA signature schemes in authentication applications such as Smart-ID [11]. This would allow for using these applications even in the quantum computing era.
Compared with the scheme proposed in [16], this work does not use sampling from the discrete Gaussian distribution and does not use a lattice-based homomorphic commitment scheme. In the key generation and signing processes, our scheme uses uniform sampling, which facilitates secure implementations in the future.
The security proof of the proposed scheme is based on non-standard security assumption: rejected Module-LWE. Removing this assumption from the security proof is an important part of future work. Furthermore, the concept of homomorphic hash functions is new and has not been properly studied yet. We aim to research the properties and usage of homomorphic hash functions more deeply in future work. The implementation of the proposed scheme and the exact choice of parameters for this implementation is left for future research, which may also involve optimisation of the size of keys and signature, and security proof against the quantum adversary. Funding: This paper has been supported by the Estonian Personal Research grant number 920 and European Regional Development Fund through the grant number EU48684.

Acknowledgments:
The authors are grateful to Ahto Buldas and Alisa Pankova for their support throughout the process of research.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations
The following abbreviations are used in this manuscript:

RSA
Rivest

Appendix A. Full Security Proof
This section presents detailed security proof for the two-party signature scheme.
Definition A1 (no-abort Honest-Verifier Zero-Knowledge). An identification scheme is said to be ZK -naHVZK if there exists a probabilistic expected polynomial-time algorithm Sim that is given only the public key pk and that outputs (w, c, z) such that the following holds: • The distribution of the simulated transcript produced by Sim ((w, c, z) ← Sim(pk)) has a statistical distance at most ZK from the real transcript produced by the transcript algorithm (w , c , z ) ← Trans(sk).

•
The distribution of c from the output (w, c, z) ← Sim(pk) conditioned on c =⊥ is uniformly random over the set C.
Theorem A1. Assume a homomorphic hash function HomH : {0, 1} a·b → Z b p is provably collision-resistant and -regular; then for any probabilistic polynomial time adversary A that makes a single query to the key generation oracle, q s queries to the signing oracle, and q h queries to the random oracles H 0 , H 1 , H 2 , H 3 , the distributed signature protocol is DS-UF-CMA secure in the random oracle model under Module-LWE, rejected Module-LWE, and Module-SIS assumptions.
Proof. Given an adversary A that succeeds in breaking the distributed signature protocol with advantage Adv DS-UF-CMA (A), a simulator B is constructed. B simulates the behaviour of the single honest party without using honestly generated secret keys for the computation. Algorithm B is constructed such that it fits all the assumptions of the forking lemma. By the definition of forking algorithm, it was required that B is given a public key and a random oracle query replies as input. B simulates the behaviour of the honest party P n , and the party P i is corrupted by the adversary. The algorithm B is defined in Algorithm A1.
1: Create empty hash tables HT i for i ∈ {0, . . . , 3}. 2: Create a set of queried messages M = ∅. 3: Simulate the honest party oracle as follows: • Upon receiving a query from A of the form (sid, msg), reply to the query as described in SimO KeyGen (Oracle A1) and SimO Sign (Oracle A2). • If one of the oracles terminates with output of the form (0, ⊥), then B also terminates with the same output (0, ⊥).
4: Simulate random oracles as follows: • Upon receiving a query from A to the random oracle, reply to the query as described in Algorithm A2. 5: Upon receiving a forgery σ = (z 1 , z 2 , c) on message m from A: • If m ∈ M, then B terminates with output (0, ⊥).
• Find index i f ∈ [q h + q s + 1] such that c = h i f . B terminates with the output (i f , out = (com , c , z 1 , z 2 , m )) Oracle A1: SimO KeyGen (par, sid, msg); The oracle is initialised with the set of public parameters par generated by Setup(1 λ ) algorithm.

2.
Upon receiving query with sid = 0 for the first time, Simulators for the key generation and signing processes were constructed using several intermediate games. The goal was to remove the usage of the actual secret key share of the party P n from both processes. Let Pr[G i ] denote the probability that B does not output (0,⊥) in the game G i . This means that the adversary must have created a valid forgery (as defined in Algorithm A1). Then, Pr[G 0 ] = Adv DS-UF-CMA (A). In Game 0, B simulates the honest party behaviour using the same instructions as in the original KeyGen n (par) and Sign n (sk n , m) protocols.

Appendix A.2. Game 1
In Game 1, only signing process is changed with respect to the previous game. The simulator for the signing process in Game 1 is described in Algorithm A4. Challenge c is now sampled uniformly at random, and the signature shares are computed without communicating with the adversary. Changes with respect to the previous game are highlighted .
from com. The probability that com occurred by chance in one of the previous queries to H 0 is at most (q h + q s ) 9 ] is the probability that the adversary predicted at least one of two outputs of the random oracle H 3 without making a query to it. In this case, there is no record in the hash table HT 3 that corresponds to the preimage com j . This can happen with probability at most 2 2 l 3 for each signing query. Therefore, the difference between two games is In Game 2, when the signature share gets rejected, simulator commits to a uniformly random vector w n from the ring R q instead of committing to a vector computed as Ay n 1 + y n 2 . The simulator for the signing process in Game 2 is described in Algorithm A5.
Game 1 → Game 2: The difference between Game 1 and Game 2 can be expressed with the probability that the adversary can distinguish simulated commitment with random w n from the real one when the rejection sampling algorithm does not pass. If the signature shares are rejected, it means that z n 1 ≥ γ − β or z n 2 ≥ γ − β. Let us assume that there exists an adversary D who succeeds in distinguish simulated commitment with random w n from the real one with nonnegligible probability: Then, the adversary D can be used to construct an adversary A R−MLWE who solves the rejected Module-LWE for parameters (q, k, k, γ, U, β), where U is the uniform distribution. The adversary A R−MLWE is defined in Algorithm A6.
• if H 3 (com i ) = h i : send out ABORT.
• if the flag alert is set and H 3 (com i ) = h i : set the flag bad 9 and the simulation fails with output (0, ⊥). 8. Otherwise, send out (z n 1 , z n 2 ). Upon receiving RESTART, go to step 1. 9. Upon receiving (z i 1 , z i 2 ), reconstruct w i := Az i 1 + z i 2 − ct i and check that HomH(w i ) = com i , if not: send out ABORT. 10. Otherwise, set z 1 := z n 1 + z i 1 , z 2 := z n 2 + z i 2 and output composed signature σ := (z 1 , z 2 , c).
As a consequence, the difference between the two games is bounded by the following: In Game 3, the simulator does not generate the signature shares honestly and thus does not perform rejection sampling honestly. Rejection sampling is simulated as follows: • Rejection case: with probability 1 − 1 − |S k γ−β−1 | |S k γ−1 | 2 simulator generates commitment to the random w n as in the previous game. • Otherwise, sample signature shares from the set S γ−β−1 and compute w n out of it.
random matrix A ← R k×k q , and the simulator defines its own matrix share out of it. By definition, the algorithm B (Algorithm A1) receives a pre-generated public key pk as the input. Therefore, the simulator in Game 4 is given a predefined matrix A, and in the later games, the simulator is changed so that it receives the entire public key and uses it to compute its shares A n , t n . The simulator for the key generation process in Game 4 is described in Algorithm A8. Sim KeyGen (par, A).
• if the flag bad 1 is set, then simulation fails with output (0, ⊥).
• if the flag alert is set, then sample A n ← R k×k q . Otherwise, define A n := A − A i . 5: (s n 1 , s n 2 ) ← S k η × S k η . 6: t n := As n 1 + s n 2 , send out comk n := H 2 (t n ). 7: Upon receiving comk i , send out t n . 8: Upon receiving t i , check that H 2 (t i ) = comk i . If not: send out ABORT. 9: Otherwise, t := t n + t i , pk := (A, t) and sk := (A, t i , s n , s n ).

Game 3 → Game 4:
The distribution of public matrix A does not change between Game 3 and Game 4. The difference between Game 3 and Game 4 can be expressed using bad events that happen with the following probabilities: • Pr[bad 1 ] is the probability that at least one collision occurs during at most q h queries to the random oracle H 1 made by adversary or simulator. This can happen with probability at most q h (q h + 1)/2 2 l 1 +1 , where l 1 is the length of H 1 output.
• Pr[bad 2 ] is the probability that programming random oracle H 1 fails, which happens if H 1 (A n ) has been previously asked by adversary during at most q h queries to the random oracle H 1 . This event corresponds to guessing random A n , for each query the probability of this event is bounded by 1 q n·k·k . • Pr[bad 3 ] is the probability that adversary predicted at least one of two outputs of the random oracle H 1 without making a query to it. This can happen with probability at most 2 2 l 1 . Therefore, the difference between the two games is Appendix A.6. Game 5 In Game 5, the simulator picks public key share t n randomly from the ring instead of computing it using secret keys. The simulator for the key generation process in Game 5 is described in Algorithm A9.
• if the flag bad 1 is set, then simulation fails with output (0, ⊥).
• if the flag alert is set, then sample A n ← R k×k q . Otherwise, define A n := A − A i . 3: Program random oracle H 1 to respond queries A n with hk n . Set HT 1 [A n ] := hk n . If HT 1 [A n ] has been already set, then set the flag bad 2 and the simulation fails with output (0, ⊥). 4: Send out A n . Upon receiving A i : • if H 1 (A i ) = hk i : send out ABORT.
• if the flag alert is set and H 1 (A i ) = hk i : set the flag bad 3 and the simulation fails with output (0, ⊥).
5: t n ← R k q , send out comk n = H 2 (t n ). 6: Upon receiving comk i , send out t n . 7: Upon receiving t i , check that H 2 (t i ) = comk i . If not: send out ABORT. 8: Otherwise, t := t n + t i , pk := (A, t).

Game 4 → Game 5:
In Game 5, public key share t n is sampled uniformly at random from R k q instead of computing it as As n 1 + s n 2 , where s n 1 , s n 2 are random elements from S k η . As matrix A follows the uniform distribution over R k×k q , if adversary can distinguish between Game 3 and Game 4, this adversary can be used as a distinguisher that breaks the decisional Module-LWE problem for parameters (q, k, k, η, U), where U is the uniform distribution. Therefore, the difference between two games is bounded by the advantage of adversary in breaking decisional Module-LWE: In Game 6, the simulator uses as input a random resulting public key t ∈ R k q to compute its own share t n . The simulator for the key generation process in Game 6 is described in Algorithm A10.
Game 5 → Game 6: The distributions of t, t n do not change with respect to Game 5. The difference between Game 5 and Game 6 can be expressed using bad events that happen with the following probabilities: • Pr[bad 4 ] is the probability that at least one collision occurs during at most q h queries to the random oracle H 2 made by adversary or simulator. This can happen with probability at most q h (q h + 1)/2 2 l 2 +1 , where l 2 is the length of H 2 output.
• Pr[bad 5 ] is the probability that programming random oracle H 2 fails, which happens if H 2 (t n ) was previously asked by adversary during at most q h queries to the random oracle H 2 . This event corresponds to guessing a uniformly random t n ∈ R k q , for each query the probability of this event is bounded by 1 q n·k . • Pr[bad 6 ] is the probability that adversary predicted at least one of two outputs of the random oracle H 2 without making a query to it. This can happen with probability at most 2 2 l 2 .
Therefore, the difference between the two games is  (par, A, t).
• if the flag bad 1 is set, then simulation fails with output (0, ⊥).
• if the flag alert is set, then sample A n ← R k×k q . Otherwise, define A n := A − A i . 3: Program random oracle H 1 to respond queries A n with hk n . Set HT 1 [A n ] := hk n . If HT 1 [A n ] has been already set, then set the flag bad 2 and the simulation fails with output (0, ⊥). 4: Send out A n . Upon receiving A i : • if H 1 (A i ) = hk i : send out ABORT.
• if the flag alert is set and H 1 (A i ) = hk i : set the flag bad 3 and the simulation fails with output (0, ⊥).
If HT 2 [t n ] has been already set, set flag bad 5 and the simulation fails with output (0, ⊥). 10: Send out t n . Upon receiving t i : • if H 2 (t i ) = comk i : send out ABORT.
• if the flag alert is set and H 2 (t i ) = comk i : set the flag bad 6 and simulation fails with output (0, ⊥).

Appendix A.8. Forking Lemma
Now, both key generation and signing do not rely on the actual secret key share of the honest party P n . In order to conclude the proof, it is needed to invoke forking lemma to receive two valid forgeries that are constructed using the same commitment com = com but different challenges c = c .
Currently, the combined public key consists of matrix A uniformly distributed in R k×k q and vector t uniformly distributed in R k q . We want to replace it with Module-SIS instance A |I , where A ∈ R k×(k+1) q . The view of adversary will not be changed if we set A = A|t .
Let us define an input generation algorithm IG such that it produces the following input: (A, t) for the F B . Now, let us construct B around the previously defined simulator B. B invokes the forking algorithm F B on the input (A, t).
As a result, with probability f rk two valid forgeries out = (com, c, z 1 , z 2 , m) and out = (com , c , z 1 , z 2 , m ) are obtained. Here, by the construction of F B , it holds that c = c , com = com , m = m . The probability f rk satisfiesollowing: Pr[G 6 ] = acc ≤ q h + q s + 1 |C| + (q h + q s + 1) · f rk Since both signatures are valid, it holds that HomH(Az 1 + z 2 − ct) = com = com = HomH(Az 1 + z 2 − c t) Let us examine the following cases: