2PC-MPC: Emulating Two Party ECDSA in

Large-Scale MPC

Offir Friedman1 , Avichai Marmor1 , Dolev Mutzari1 , Omer Sadika1 , Yehonatan

C. Scaly1 , Yuval Spiizer1 , and Avishay Yanai

dWallet Labs, [email protected]

Abstract. Motivated by the need for a massively decentralized network

concurrently servicing many clients, we present novel low-overhead UC-
secure, publicly verifiable, threshold ECDSA protocols with identifiable
abort. For the first time, we show how to reduce the message complexity
from O(n2 ) to O(n) and the computational complexity from O(n) to
practically O(1) (per party, where n is the number of parties). We require
only a broadcast channel for communication. Therefore, we natively
support use-cases like permissionless bridges and decentralized custody,
where P2P channels between every pair of parties are infeasible. Consequently,
the message complexity is reduced and the protocol is publicly verifiable.
We enable all communication to be public (over a broadcast channel),
by using a threshold additively homomorphic encryption scheme and
novel zero-knowledge proofs. To further reduce the computation and
communication overheads, our protocols employ novel batching and amortization
techniques, which may be of independent interest.
Our second main contribution is the introduction of the notion of a 2PC-
MPC protocol – a two-party ECDSA protocol where the second party is
fully emulated by a network of n parties. This notion assures that both
the first party (the client) and (a threshold) of the network are required to
participate in signing, while abstracting away the internal structure of the
network. In particular, the communication and computation complexities
of the client remain independent of the network properties (e.g. size).
This allows ultimate decentralization in distributed custody use-cases,
as recent growing interest in the industry demands.
We report that our implementation completes the signing phase in 1.23
and 12.703 seconds, for 256 and 1024 parties, respectively.

1 Introduction
The Elliptic Curve Digital Signature Algorithm (ECDSA) is one of NIST’s
standards for digital signing. Much effort has been made for thresholdizing
ECDSA in the past years [GGN16, BGG17, LN18, GG19, DKLS19, CGG+ 20,
DOK+ 20, DJN+ 20, GKSS20, CCL+ 20, ANO+ 22, BMP22, DKLS23, ZYP23,
WMYC23], and threshold ECDSA schemes have been widely deployed. This
is mainly due to its widespread use as an authentication scheme in Bitcoin,
Ethereum and alike, in which the signature constitutes a proof of ownership of
the funds. Threshold signature based solutions flourish in the cryptocurrency
industry, and focus on two main types of use cases: distributed custody (e.g.,
2 Authors Suppressed Due to Excessive Length

Fireblocks, Zengo, and Qredo) and decentralized bridges (e.g., Thorchain, Keep
Network, and the Internet Computer). Distributed custody leverages threshold
signature protocols to mitigate the self custodial risks of loss and theft, by
distributing the secret signing key of the client, who is the legal owner of the
funds, between multiple signers. Typically, the key is shared between the client
and a (potentially distributed) custodian in a way that requires the active
consent of both in order to produce a signature. A decentralized bridge consists of
a network of nodes who distributively manage multiple signing keys for different
wallets, each holding a pool of funds on different blockchains used to form cross-
chain liquidity pools. This enables a single entity (the network) to permissionlessly
own, manage and transfer funds (and information) across different blockchains.
When a client owning wallets on two different blockchains wishes to transfer
funds between them it can send funds to one end of the bridge’s liquidity pool
and request a withdrawal of an equivalent amount to the client’s wallet on
the the other end. The bridge network then creates and distributedly signs a
corresponding transaction that can then be broadcasted by the client to the
other blockchain, to complete the exchange.
Due to inherent limitations of existing threshold signing protocols, all real
world networks we are aware of are deployed with a rather small number of nodes
– in the order of 10-20. This is not on par with the vision of decentralization,
since when the number of nodes is small it is difficult to argue that these nodes
are not colluding.
In this paper we address the question of whether we can achieve an efficient
massively decentralized network for concurrently servicing numerous clients, and
propose the first threshold signature protocol that can truly scale to practically
any number of nodes. Our protocol enjoys properties that are very important
in real-world deployments. This includes UC-security – which is necessary when
multiple instances of the protocol should run concurrently, and public-verifiability
– which is necessary in public (permissionless) networks with financial rewards
and punishments, so that that parties who misbehave need to be identifiable.
To date, all practical threshold ECDSA schemes were designed to work over
unicast channels, assuming secure point-to-point (P2P) channels between every
pair of parties. While secure point-to-point channels can be constructed in theory
(under an appropriate PKI setup), in practice they inherently incur a high
network load (i.e., maintaining a high number of sessions concurrently) and a
message complexity of Ω(n2 ), as each party computes and sends a message in
private to every other party. When aiming for a large scale protocol, it is not
reasonable to rely on such pairwise channels. Therefore there is a need for a new
design, relying on a broadcast channel instead.
Generic MPC protocols in the broadcast channel model are ubiquitous, and
oftentimes enjoy extra desirable properties like identifiable abort (IA) and public
verifiability (PV). The broadcast channel itself may either be implemented in-
house by the protocol’s participants or rely on an external implementation. In
recent years the use of a blockchain as a broadcast channel has surged, as it offers
immutability of messages (which enables easy recovery from failures) as well
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 3

as incentive mechanisms for faithful participation. However, among the various

multiparty threshold ECDSA protocols, [GGN16] is the only one designed to
operate in the broadcast communication model. That protocol, however, relies on
a trusted setup, which obviously hinders its applicability to the aforementioned
use cases, which were incepted in order to avoid the trusted party in the first
place. Emulating the setup phase of [GGN16] in a distributed setting is possible
in theory (using e.g., [ACS02]) but is considered infeasible since it requires
a distributed generation of safe primes from which the parameters to a zero-
knowledge proof system are derived.
Designing a protocol over a broadcast channel (such as [GGN16]) would
naturally improve the message complexity to O(n) (instead of the Ω(n2 ) message
complexity incurred by protocols over a point-to-point network), yet, each party
intuitively reads and processes a message from every other party, and so the
computational complexity remains Ω(n).
In this work we leverage the fact that all messages are public and present
two ways to further reduce the computational complexity of processing these
messages to practically O(1). See Section 1.2 for more details.
Considering concrete efficiency (i.e., wall-clock time to produce a signature)
the DKLS protocol [DKLS23] is the state of the art, demonstrating that 250
parties can produce a signature in a few seconds. That protocol, however, relies
on a P2P network which, as mentioned above, requires a large bandwidth. In
addition, [DKLS23] lacks identifiable abort, which hinders its usefulness for
permissionless use-cases such as the aforementioned distributed bridge, as it
would be quite easy for every single party to mount a denial of service attack.
In that context, the state-of-the-art protocol that enjoys identifiable abort is
[CGG+ 20], which offers two variants: the first requires each party to verify O(n2 )
zero-knowledge proofs, and the second requires O(n) verifications at the cost
of three additional communication rounds. Since verification is a heavyweight
operation, both variants are not scalable with the number of parties, and become
impractical already at about 20 parties.
2PC-MPC: A Novel Approach to Decentralized Protocols. Our improvements
in communication and computation enable distributed signing solutions like
bridges, where the signing key owner is the network itself, to scale to an extremely
large number of participants. In contrast, when the owner of the signing key is
an external client, as in the distributed custody use case, the signing protocol
must be conducted between the custodian and the client. This was the driving
force for designing practical two-party signature protocols (e.g., [Lin17]). In such
protocols the custody plays as a service provider who cannot sign without the
client’s active consent. Such custody solutions increase the trust in the service
provider but still suffer from centralization. For instance, the service provider
may completely deny service from a client or censor specific transactions. In
addition, it leaves open the following attack vector: Consider a client who is
an organization with multiple authorised signers. Deploying a two-party signing
protocol in that setting means duplicating the client’s share of the signing key
among all authorised signers, while the service provider possesses the other share.
4 Authors Suppressed Due to Excessive Length

Thus, it is sufficient for the service provider to collude with only a single member
of the organization in order to steal all the client’s funds.
These issues motivate the need for a decentralized service provider, meaning
that the service provider’s share of the signing key is now shared among a
network of n participants that emulate the operation of the provider. This,
however, requires a distributed signing protocol for an access structure that is
different than the usual threshold access structure that is addressed in (almost
all) previous works. The new access structure requires half of the signing key to
be in posession of the client, whereas the network, collectively, possesses the other
half. To produce a signature the client along with at least t + 1 honest parties
must collaborate, keeping the client safe even in the extreme case that all network
participants are compromised. Similar to the usual access structure discussed
above (for decentralized bridges), a protocol for the new access structure must
be proven secure under universal composition (UC) in order to concurrently serve
many clients. The only work that addresses a similar access structure in the UC
framework is [BMP22]; in that protocol, however, each party must separately
verify zero-knowledge proofs from every other party and so it is not practical for
networks as large as we envision.
Capturing that special access structure can take different approaches. For
instance, one may model the client as n virtual parties (as done in [ZYP23]
against a semi-honest adversary), so its power is equal to that of the service
provider. This approach incurs a high computation and communication complexity
on the client, that is dependent on the network size. An alternative would be
to use an hierarchical threshold secret sharing scheme [Tas07] with two levels
of hierarchy – the client is at the top and the network participants are at the
bottom, such that reconstruction is possible only by a collaboration between the
client and at least t + 1 network participants.
In this work we take a novel approach, named 2PC-MPC, that is reminiscent
to the hierarchical structure. Specifically, the client and each network participant
possess only one share, however, in contrast to the hierarchical secret sharing
scheme the client in our protocol is agnostic to the fact that it interacts with
a distributed party. Rather, it follows the protocol as if it is interacting with a
single party only (hence 2PC), which is emulated by the network via an MPC
protocol. We stress that being agnostic to the network structure does not imply
that the structure is hidden from the user, and when deployed in a permissionless
setting it is public. The benefit of our 2PC-MPC approach is that the client
can always refer to the network as an abstract second-party. Thus, allowing the
network to evolve, by adding new parties, removing old parties, or even changing
its internal access structure, without involving the client at all.

1.1 Our Contribution

We propose the first large-scale UC-secure threshold ECDSA protocols and
introduce the notion of 2PC-MPC. Our protocol only uses a broadcast channel
for communication, thus achieving public verifiability. It supports our novel
2PC-MPC approach, but can also be folded back to standard threshold access
structure. We have a tradeoff between the round complexity and computational
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 5

complexity of the participants: In 3 rounds we achieve linear computational

complexity for each player, whereas if we go to 7 rounds (for the network
participants only, not the client), the complexity per player goes down to constant
(in practice). We guarantee UC-security with identifiable abort.
We implemented our protocol and report (in Section 7) on both the key-
generation, presignature and signature times as a whole for sets of up to 1,024
parties; for the signature part, we compare against what is reported in [DKLS19]
and find that for n = 256 our protocol is 7 − 8× faster, whereas their protocol
becomes impractical for a larger number of parties. In addition, we provide a
microbenchmark for proof and verification time of Schnorr proof batching and
aggregation with up to 1,000 parties and batches of size 1,000. This is important
in order to understand the impact of using an AHE scheme that requires range
proofs (as in Paillier’s scheme). Our protocols are natively designed to operate
over a broadcast channel, which makes them inherently applicable to blockchain
networks where direct point-to-point channels are not available. Our protocols
are accompanied with a security proof via a UC simulation and hence are fit
to real-world deployment, where a many instances of the protocol are run at
the same time. In comparison to previous works, our protocols differ in two
dimensions:
– Access structure. We address two access structures in one go. The first access
structure is a two-level hierarchy, capturing the setting of 1 + n parties (may
also be pronounced as ‘one plus t out of n’). The first party is alone at the
top level and the other n are at the second, such that a qualified set consists
of the party at the first level together with any t + 1 parties from the second
level. The second one is the usual t out of n (‘threshold’) access structure.
Our protocol for the latter is a byproduct of the former. That is, by taking
the protocol for the first structure and ignoring the first party we get the
usual threshold signature protocol; consequently, and due to space limit, the
exposition in the paper is focused to the former access structure.
– Rounds vs. computational complexity. Our protocols can be optimized to either
round or computational complexity. When optimized to the number of rounds,
we get a three (3) round protocol where presignature takes two rounds and
the signature takes one, matching the state of the art protocol by Doerner et
al. [DKLS23] (which is a concurrent and independent work). Our protocol is
favorable to [DKLS23] in that it builds on a broadcast channel rather than
P2P channels, which is leveraged to achieve identifiable abort (which is not
possible in [DKLS23] as is). The downside of that variant of our protocol is
that the number of expensive operations (exponentiations) to be done by each
party is linear in the number of parties. One of our contribution is showing
that the number of exponentiations can be reduced to practically constant,
allowing scaling to even thousands of participants, but incurring seven (7)
communication rounds (six of them for presignature).
Addressing the aforementioned hierarchical access structure, we introduce
the concept of a 2PC-MPC threshold ECDSA. In such a protocol the client is
interacting with a network while being unaware of its topology, or even of the
6 Authors Suppressed Due to Excessive Length

precise size of the network. From the client’s point of view, it is interacting
with a single party and hence its computation and communication overhead
remains low. The network almost perfectly emulates the second party in a 2-
out-of-2 ECDSA protocol (the client is the first party), where messages from the
network’s participants are aggregated into a single message which is effectively
the only one received and processed by the client. This notion is important in
case the network operates as a blockchain, where we cannot expect a client to
directly interact with the blockchain’s nodes. Instead, it broadcasts its messages
to be processed by the blockchain and being notified whenever the blockchain
has a response. This communication model reduces the attack surface of the
system in a real deployment, since the user does not know the identities of the
participants’ endpoints over the network. We believe that our ideas may also
find use in devising a topology hiding protocol, in which the network’s properties
(e.g., size and topology) are hidden from the user. Such a notion was recently
addressed in theory for general MPC ([MOR14] and follow ups), but has never
been tackled in the context of threshold ECDSA, and we leave it to future
work. Following the discussion above, in Table 1 we provide a comprehensive
comparison of threshold ECDSA protocols.

1.2 Our Techniques

We introduce a set of new techniques to achieve the aforementioned results.
Utilizing the Broadcast Model without Trusted Setup. As in prior works,
we use additively homomorphic encryption with a single global public key, where
the secret key is shared between all parties, together with a threshold decryption
protocol. Whereas the above suffices in the semi-honest setting, it is insufficient
when considering malicious security models. There, we need to make sure that
we have a suitable zero-knowledge proof system in order to provide our UC
identifiable abort guarantees. Whereas prior works either assumed a trusted
setup [GGN16] or P2P channels [CMP20], we cannot rely on such solutions.
The main challenge is the reliance of prior works on range proofs that require
trusted setup. Our approach is to rely on transparent-setup range proof systems,
such as BulletProofs [BBB+ 18]. However, solutions such as BulletProofs provide
a range-guarantee only modulo the group order, which is insufficient. We divide
the witness into “digits” and commit to each such digit individually. This by
itself is does not solve the problem and we need to combine, in a nontrivial
manner, a range proof (modulo the group order) together with a gap sigma
protocol similar to those used in [GGN16].
Supporting 2PC-MPC Access. Recall that in such a protocol the client is
interacting with a network while being unaware of its topology, or even of the
precise size of the network.
To do this, we start with a 2PC protocol (see Appendix I), and distribute
the functionality of one of the parties. To this end, we require aggregatable zero-
knowledge proofs. That is, a set of parties, each holding a share of the witness,
collaboratively generate the proof, in a small (constant) number of rounds. The
protocol is aggregatable if, at every round, the messages of the individual parties
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 7

Channels IA Threshold Rounds Messages Computation UC Assumptions

[GGN16] BC No t<n 6 O(n) O(n) No sRSA, DCR
[BGG17] BC No t<n 4 O(n) O(n) No sRSA
2 2
[LN18] P2P No t<n 7 O(n ) O(n ) No DCR or OT, DDH
[GG19] P2P & BC No t<n 8 O(n2 ) O(n2 ) No sRSA, DCR, DDH
[DKLS19] P2P & BC No t < n ⌈log t⌉ + 6 O(n2 ) O(n2 ) Yes DH
[CGG+ 20] P2P Yes t<n 4 O(n3 ) O(n3 ) Yes sRSA, DCR, DDH
[CGG+ 20] P2P Yes t<n 7 O(n2 ) O(n2 ) Yes sRSA, DCR, DDH
[DJN+ 20] P2P No t < n/2 4 O(n2 ) O(n2 ) Yes -
2 2
[GKSS20] P2P Yes t<n 13 O(n ) O(n ) Yes DCR or OT, DDH
[CCL+ 20] P2P No t<n 8 O(n2 ) O(n2 ) No SR, LO, HSM, DDH
[ANO+ 22] P2P & BC No t = n − 1 2 O(n2 ) O(n2 ) No Ring-LPN
[DKLS23] P2P No t<n 3 O(n2 ) O(n2 ) Yes DH
2
[WMYC23] P2P Yes t<n 5 O(n ) O(n) No SR, LO, HSM, DDH
∗
Ours (Sec. 3) BC Yes t<n 7 O(n) O(1) Yes DCR∗∗
Ours (Appx. M) BC Yes t<n 3 O(n) O(n) Yes DCR∗∗
Table 1: Comparison of threshold ECDSA protocols. BC refers to a broadcast channel,
P2P refers to pairwise point-to-point channels, IA refers to identifiable abort, and UC
refers to universally composability. Cells with a green color refer to a favorable property.
In the Threshold column, t < n means that the protocol may deal with a dishonest
majority, t < n/2 means that honest majority is assumed, and t = n − 1 means that
the protocol requires all parties to participate. ‘Rounds’ refers to total number (presign
+ sign) of communication rounds (when applied, ignoring rounds used to implement
the broadcast channel). ‘Messages’ refers to the message complexity of the protocol
in total for all parties whereas ‘Computation’ refers to the computation complexity
per party. The assumptions listed in the table are strong RSA (sRSA), decisional
composite residuosity (DCR), {decisional} Diffie-Helman ({D}DH), oblivious transfer
(OT) which may be constructed under various assumptions, hard subgroup membership
(HSM) and ring-learning parity with noise (LPN), Strong Root (SR), Low Order (LO),
Non-Colluding Semi-Honest Server (NC-SHS). ∗ O(1) refers to the number of heavy
operations like exponentiations and proof verification whereas the number of simple
arithmetic operations like addition in a field/ring are linear in the number of parties.
∗∗
Our protocol relies on the semantic security of the additively homomorphic scheme,
which in turn relies on DCR in case this is implemented via the Paillier encryption
scheme. In the latter, we count only expensive operations like encryption/decryption
and NIZK proof generation and verification.

are simply summed together, and this sum is the only information required for
the next step of the protocol. Protocols of this form are particularly efficient
since it requires minimal processing of the other parties’ messages. We show
how to achieve this for our 2PC protocol, which enjoys a convenient structure
for this purpose.
Minimizing Computational Complexity. We leverage the fact that all messages
are public and present two ways to reduce the computational complexity of
processing these messages to practically O(1).

1. Amortization. Protocols over a broadcast channel often use an additively

homomorphic encryption scheme, and invoke a threshold decryption sub-
protocol at some stages (see, e.g., [GGN16]). Typically in that sub-protocol
the parties broadcast their decryption shares for some ciphertext, which are
8 Authors Suppressed Due to Excessive Length

then combined locally by each party to get the final plaintext – incurring
Ω(n) exponentiations per party.
Instead, we show that this can be done by a single designated party only,
who can inform the others about the resulting plaintext in a verifiable
manner. When many executions of threshold decryption are run in parallel,
picking a different designated party for each ciphertext reduces the amortized
complexity to O(1) exponentiations per party per ciphertext.
2. Aggregation. The security and correctness of the protocol are ensured by
the fact that the messages broadcast by the parties are accompanied by a
zero-knowledge proof. Then, the parties separately verify a proof broadcasted
by any other party before proceeding to the next protocol step. Identifying
the verification of these proofs as one of the computationally heaviest operations
in many threshold ECDSA protocols, we again use the aggregateable nature
of our zero-knowledge proof system as follows. We first aggregate the n
proofs into a single aggregated proof, and then verify only one aggregated
proof. While verification of the aggregated proof remains a heavyweight
operation, the aggregation operation is orders of magnitude lighter. Thus,
the overall computational complexity consists of a simple aggregation of n
proofs (n multiplications in a group) followed by only one proof verification
(O(1) exponentiations) and so, even considering thousands of parties, the
computational complexity is reduced to practically O(1).

2 Preliminaries

We use κ, s ∈ N as a computational and statistical security parameters, resp.

For x, y ∈ {0, 1}∗ the expression x||y is the concatenation of x and y. Uniformly
sampling a random value x from a set X is denoted by x ← X. The result of a
probabilistic algorithm A on inputs x1 , x2 , . . . is written by x ← A(x1 , x2 , . . .);
in addition, when we want to explicitly mention the randomness used by the
algorithm we write x = A(x1 , x2 , . . . ; r). (G, G, q) denote an elliptic curve
group written in additive notation, a generator and the prime order of the group,
respectively. We usually denote group elements by capital letters. For an element
R ∈ G, we write R|x−axis to denote its x-coordinate. We denote its bit-length
by ||x||2 , and let ⌈x⌉ = 2||x||2 be the closest power of two larger than x.
The ECDSA Signature. Given an elliptic curve group (G, G, q), a hash function
H : {0, 1}∗ → Zq (modeled as a random oracle), secret key x ∈ Zq and public key
X = x · G, respectively, a signature σ on a message msg ∈ {0, 1}∗ is computed
as follows: Let m = H(msg), sample k ← Zq , compute R = k −1 · G and set
r = R|x−axis . Then, compute s′ = k(m + rx) mod q and s = min(s′ , q − s′ ) (to
ensure uniqueness of the signature), and output the signature σ = (r, s).
Verification is done as follows: Given a message msg and the signature σ =
(r, s), output accept if (H(msg)s−1 · G + rs−1 · X)|x−axis mod q = r and
s < q − s. Otherwise output reject. Indeed, if σ = (r, s) is computed correctly
on msg with m = H(msg), then ms−1 · G + rs−1 · X = ms−1 · G + rxs−1 · G =
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 9

(m + rx)s−1 · G = (m + rx)k −1 (m + rx)−1 · G = k −1 · G = R and so, projection

to the x coordinate results with R|x−axis = r as required.1
Additively Homomorphic Encryption. Our protocol requires an AHE (Additively
Homomorphic Encryption). Unlike the approach of [BMP22, Lin17, GGN16],
instead of explicitly instantiating our protocol with the Paillier crypto-system,
we choose to work with a generic AHE scheme. This is done both to simplify
proofs and make constructions more modular, as well as to support future
implementations of the protocol using leveled or fully homomorphic encryption
to save communication rounds. Following this approach enables us, for example,
to abstract away the need of masking the plaintext, which resides in Zq , with
a sufficiently large factor of q, to prevent information leakage upon decryption.
Indeed, in Paillier, since the plaintext space is ZN where inevitably N ≫ q
(||N || ≥ 2048, whereas typically, ||q|| = 256), the number of modular reductions
that take place must be kept hidden. This would not be necessary if we chose
an AHE with a plaintext space Zq (or Znq ) which can be achieved with class-
groups based cryptography [BDO23]. Using a class-group based encryption is
advantageous as it adjust the plaintext space to be exactly that needed by the
ECDSA scheme, which enables avoiding range proofs in the protocol. When the
AHE scheme’s plaintext space does not match that needed by ECDSA, we need
it to have secure function evaluation (see discussion below). As demonstrated
in Fig. 2, the aforementioned range-proofs take a substantial portion of the
pre- signature, which tips the scales to the use of Class-Group-based schemes.
However, they are about 10× slower than Paillier, and their security is less
established (relying on stronger assumptions like Low-Order and Strong-Root).
Should range proof become more efficient it would tip the scales back toward
using Paillier’s scheme.
The comprehensive formal definition of an AHE scheme is given in Appendix
B. Below we only give our formal definition of secure function evaluation for AHE
schemes, as it is not yet standardized in the literature. Informally, an additively
homomorphic encryption scheme AHE = (Gen, Enc, Dec, Add) is parameterized
with plaintext, randomness and ciphertext spaces Ppk , Rpk and Cpk , respectively,
where Ppk is a Z-module. Algorithm Gen(1κ , aux) → (pk; sk) is used to generate
a public-private key-pair; given a public key pk algorithm Enc(pk, pt; ηenc ) → ct
translates a plaintext pt and randomness ηenc to a ciphertext ct; given a private
key sk algorithm Dec(sk, ct) → pt translates a ciphertext to a plaintext; and the
fact the the scheme is additively homomorphic means that there is an algorithm
Add(pk, ct1 , ct2 ) → ct3 that translates ciphertexts ct1 , ct2 to a ciphertext ct3
such that decryption of ct3 is equal to the sum of the decryptions of ct1 and ct2 .
We may write P and C instead of Ppk and Cpk . In addition, we denote
homomorphic addition of two ciphertexts ct1 and ct2 by ct1 ⊕ct2 and a multiplication
of a ciphertext ct by a scalar α by α ⊙ ct. Every affine function can be efficiently
computed homomorphically by an algorithm Eval(pk, f, ct1 , . . . , ctℓ ; ηeval ). Whenever
1
Note that we use the non-ambiguous variant of ECDSA, which is the standard in
blockchain applications. In addition, looking ahead, we exploit the property that for
each (X, r, m) there exist only one valid signature.
10 Authors Suppressed Due to Excessive Length

we omit the randomness in Eval(pk, f, ct1 , . . . , ctℓ ), we refer to the process of

sampling a randomness ηeval ← {0, 1}poly(κ) and running Eval(pk, f, ct1 , . . . , ctℓ ; ηeval ).
Pℓ
Given a public key pk, an affine function f (x1 , . . . , xℓ ) = a0 + i=1 ai xi (with
ai ∈ Z and ℓ, ∥ai ∥2 ∈ poly(κ) for all 0 ≤ i ≤ ℓ) and ℓ ciphertexts ct1 , . . . , ctℓ ∈ C,
Eval outputs a ciphertext ct.
The definitions for correctness and semantic security of an AHE schemes
are standard in the literature and appear in Definitions B.2 and B.3. Secure
function evaluation (Definition 2.1), states that evaluating some function f on
ciphertexts ct1 , . . . , ctℓ ∈ C and giving the resulting ciphertext to an adversary
who has the decryption key does not reveal anything about f , except what can be
learned from the (decrypted) result alone. Note that secure function evaluation
is stronger than function privacy as defined in [BPMW16], as here the adversary
is in possession of the private decryption key sk and the randomness ηi used
to encrypt each plaintext pti . Indeed, in our protocols, party B sends A an
encryption of its ECDSA private key x, followed by party A homomorphically
evaluating a private affine function over ctx = Enc(x). For instance, for a private
affine function f (x) = ax + b it sends ct = Eval(pk, f, ctx ). We must therefore
ensure that A, learns nothing about a and b beyond ax + b given x, pk, sk, η and
ct, where ctx = Enc(pk, x; η). An alternative presentation of the definition can be
formulated via an experiment in a standard way, see Definition B.5 (Appendix
B) for a formal treatment.
Definition 2.1 AHE has secure function evaluation if there exists a PPT algorithm
SEval such that for every PPT adversary A, every ℓ-ary affine function f as above,
every (pk, sk) and every plaintexts pt1 , . . . , ptℓ ∈ P and randomness η1 , . . . , ηℓ ,
| Pr[A(1κ , pk, sk, {pti , ηi }ℓi=1 , Eval(pk, f, (ct1 , . . . , ctℓ ))) = 1]
(1)
− Pr[A(1κ , pk, sk, {pti , ηi }ℓi=1 , SEval (pk, f (pt1 , . . . , ptℓ ))) = 1]| ≤ neg(κ)

where cti ← Enc(pk, pti ; ηi ), and the probability is over the coins used by Eval
and the random coins of A and S.

Remark on the use of Paillier’s AHE. When using the Paillier’s AHE the
‘actual’ plaintext space (ZN ) does not match the ‘effective’ plaintext space (in
our case, this is Zq , in order to match the order of the ECDSA group), it is
required to keep track on the upper bound on the effective plaintexts within
the larger domain. To this end, the Enc function, in addition to the ciphertext,
outputs the upper bound PT = q as well. Then, any ciphertext resulting from
applying an ℓ-ary function on ℓ+1 ciphertexts (ct0 , PT0 ), . . . , (ctℓ , PTℓ ) is accompanied
Pℓ
with the upper bound PT = i=0 PTi . This will come into play later, when
proving that the Paillier’s AHE has secure function evaluation, as well as when
proving the security of the zero-knowledge proofs.
Threshold AHE. Let B = {B1 , . . . , Bn } be a set of parties and U ⊂ B, where
|U | ≤ t < n, be those parties under the control of the adversary. A threshold
AHE FTAHE is defined in Functionality 1. The functionality is parameterized
with an AHE scheme AHE = (Gen, Enc, Dec, Add) with semantic security and
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 11

secure function evaluation. The parties in B can generate a key and prove its
validity to the certifiers. In the context of our 2PC-MPC protocol, the certifiers
are the users (represented by party A) who engage with B. Finally, any set of
t + 1 honest parties can decrypt a ciphertext using a previously generated key,
unless the adversary decides to abort.

FUNCTIONALITY 1 Threshold AHE: FTAHE
The functionality interacts with B = (B1 , . . . , Bn ), an adversary, and a set of certifiers.
It is parameterized with AHE = (Gen, Enc, Dec, Add), κ and t < n.

– Upon receiving (keygen, sid) from all parties in B, for a fresh sid, run (pk; sk) ←
AHE.Gen(1κ ), send pk to the adversary and receive the adversary’s response
(continue, U ′ ). If continue = 1 or U ′ ∩ U = ∅ then send (pubkey, sid, pk) to
all parties in B and store (sid, pk; sk), otherwise send (pubkey, sid, ⊥, U ′ ∩ U ).
– Upon receiving (certify, pk) from some party, if (·, pk; ·) is stored then return 1 to
that party, otherwise return 0.
– Upon receiving (decrypt, pk, ct) from at least t + 1 parties, if (sid, pk; sk) is stored
for some sid and sk, compute pt = AHE.Dec(sk, ct), send (decrypted, pk, ct, pt) to
the adversary and wait to the adversary’s response (continue, U ′ ). If continue =
1 or U ′ ∩ U = ∅ then send (decrypted, pk, ct, pt) to everyone, otherwise, send
(decrypted, pk, ct, ⊥, U ′ ∩ U ) to everyone.

Homomorphic Commitments. Homomorphic commitments and their batched

version are standard in the literature; for completeness, we provide a formal
definition in Appendix C.1. For the notation, a commitment scheme consists of
algorithms (Setup, Com). Algorithm Setup is given (G, G, q, T ) for a batch size T .
and outputs public parameters pp including the message and randomness spaces
Mpp = ZTq , Rpp = Zq . The commitment algorithm Compp defines a function
Mpp × Rpp → Cpp that satisfies perfect hiding and computational binding.
In addition, for homomorphic commitments Com is a group homomorphism:
Com(m1 ; ρ1 ) ⊕ Com(m2 ; ρ2 ) = Com(m1 + m2 ; ρ1 + ρ2 ).
Zero-Knowledge Proofs
We use the standard zero-knowledge and committed zero-knowledge functionalities
defined by ((x, w), ·) → (·, (x, R(x, w)) where the prover P has a statement x and
a witness w, the verifier V obtains only the statement and its validity R(x, w) (or
alternatively (x, w) ∈ LR where LR is the language associated with relation R.
R R
See Functionalities 9 (Fzk ) for zero-knowledge and 11 (Fcom−zk ) for committed
zero-knowledge (in Appendix C.2). These functionalities were formerly given
in [Lin17]. In addition, we use a trivial extension to batched and aggregateable
versions of zero-knowledge. Specifically, batched zero-knowledge is defined with
P and V as above by ((⃗x, w), ⃗ ·) → (·, (⃗x, ∀i R(xi , wi )). When the relation R
is associated with a homomorphism (x; w) ∈ R ⇐⇒ ϕ(w) = x, one can
define an aggregateable zero-knowledge proof, as in Functionality 12. This is
defined with provers P1 , . . . , Pn and verifier V by ((x1 , w1 ), . . . , (xn , wn ), ·) →
12 Authors Suppressed Due to Excessive Length

P
(·, (x, ∀i R(xi , wi )) where x = i xi . In our protocols we choose to work with the
ideal functionalities for (stand-alone, batched or aggregateable) zero-knowledge
proofs as it makes it easier to work with. Our instantiation of the zero-knowledge
proof is proven as a secure sigma protocol, given any range proof in the hybrid
model, which in turn is shown to be sufficient to securely compute the aforementioned
functionalities [HL10, Theorem 6.5.2].
Languages used in our protocols.
The notation we use to describe the relations follows: the language associated
with relation R is the set LR = {x | ∃w : (x, w) ∈ R}; we write L[params] =
{S; s | f (params, S, s)} to denote a language {x | ∃s : f (params, S, s) = 1} where
params typically refers to global parameters (e.g., a public-key of an encryption
scheme, or a global verification key), S refers to a set of public values and s refers
R
to a set of secret values. Note that in Fzk (Functionality 9) we implicitly require
‘knowledge’ of the witness s from the prover P . Note that we may omit params
from a language specification when it is clear from context. The languages in
our protocols are listed below:

– Knowledge of the discrete log of an elliptic-curve point.

LDL [(G, G, q)] = {(P ; x) | P = x · G} (2)

– Knowledge of decommitment.

LDCom [pp] = {C; m, ρ | C = Compp (m; ρ) ∧ m ∈ Mpp ∧ ρ ∈ Rpp ∧ C ∈ Cpp } (3)

– Commitment of discrete log.

LDComDL [pp, (G, G, q)] = {C, Y ; m, ρ | C = Compp (m; ρ) ∧ Y = m · G} (4)

– Ratio between committed values is the discrete log. (Recall that Mpp = Zq .)

LDComRatio [pp, (G, G, q)] = {C1 , C2 , X; m, x, ρ1 , ρ2 |X = x · G (5)

∧C1 =Compp (m, ρ1 )
∧C2 =Compp (x · m, ρ2 )}

– Range of committed value.

LRange [pp, a, b] = {C; m, ρ | (C; m, ρ) ∈ LDCom [pp] ∧ a ≤ m ≤ b} (6)

Proving relation to this language is used as a building block for proving more complex
relations that involve range claims, that is, Languages 7,8.
– Committed affine evaluation. This language is later on specified for the Paillier
encryption scheme, see Appendix D.

LDComEval [pp, pk, c⃗t, q, ℓ, s, κ] = {ctEval , C; ⃗a, ρ, ω, η (7)

Eval
| ct x), c⃗t; η)
= AHE.Eval(pk, f⃗a (⃗
∧ C = Compp (⃗a; ρ)
∧ ai ∈ [0, q) ∧ ρ ∈ Rpp ∧ η ∈ Rpk }
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 13

– AHE encryption of a discrete log.

LEncDL [pk, (G, G, q)] = {(ct, X; x, η) | ct = AHE.Enc(pk, x; η) ∧ X = x · G ∧ x ∈ [0, q)}
(8)
– AHE analogue of a DH tuple; namely, ciphertexts of values x, y and xy. This language
uses the specific evaluation algorithm of the Paillier encryption scheme, see Appendix
D.
LEncDH [pk, ctx ] = {(cty , ctz ; y, ηy , ηz ) | cty = AHE.Enc(pk, y; ηy ) (9)
∧ ctz = AHE.Eval(pk, f, ctx ; 0, ηz ) s.t. f (x) = y · x mod q ∧ y ∈ [0, q)}
– Correct AHE key generation. The specification of the language depends on the choice
of the AHE scheme (Definition B.1) and so it is not mentioned here explicitly. The
specification for the Paillier encryption scheme, denoted LGenPal [κ], is given in 23.
LGenAHE [κ] = {pk; aux | (pk; sk) = AHE.Gen(1κ , aux)} (10)

Threshold Signature. Following the works by Canetti et al. [CMP20, CGG+ 20]
and follow ups [BMP22, Mak22], we use the threshold signature from Functionality
14 (Appendix F), which is not defined specifically for ECDSA; rather, it is a
generic one, and the ECDSA part only comes to play whenever a signature has to
be verified (in case it is not already stored in the functionality’s repository). We
refer the reader to [CMP20, CGG+ 20] for a thorough discussion about the choices
made in the functionality. An important observation in the aforementioned works
is that if the environment cannot break the unforgeability of the signature scheme
after the execution of (potentially multiple instances of) the protocol, then a
‘trivial’ simulation is perfect, where a ‘trivial’ simulation refers to the situation
where a simulator samples all values for the honest parties as prescribed, and
follows the instructions of the protocol. To complete the proof then, one has to
show that indeed the environment cannot break unforgeability, which is done
via a reduction, which in turn builds on a standard stand-alone simulation. This
means that we can use some useful techniques like rewinding the adversary,
and avoid expensive primitives like UC secure zero-knowledge proofs, when
constructing the simulator. This simulation is formalized by the notion of G ∗ -
simulatability as defined below, G ∗ is an enhanced signing oracle that processes
requests for key-generation, presigning and signing.
Signing Oracle. An enhanced signing oracle is modeled as a functionality
with key generation, presign and sign commands. A secure implementation of
the oracle in Functionality 2 is analogous to enhanced existential unforgeability
security definition of the ECDSA signature (where the adversary has information
about the randomness before seeing the signature, see [BMP22] for a discussion).
Definition 2.2 is for unforgeability in the context of an enhanced signing
oracle G ∗ , as given in [BMP22, Def. 3.2]. Note that the definition is described
for ECDSA rather than a generic signature scheme, nevertheless, we note that
the ECDSA scheme is proven (in [BMP22]) to be G ∗ -existential unforgeable.
Definition 2.2 We say that Sig = (Gen, Sign, Verfiy) is G ∗ -existentially unforgeable
∗
ECDSA scheme if for every adversary A there exists µ ∈ neg such that Pr[ExpGEU (A, 1κ ) =
∗
1] ≤ µ(κ), where ExpGEU is defined in Experiment 3.
14 Authors Suppressed Due to Excessive Length

FUNCTIONALITY 2 Enhanced Signing Oracle For ECDSA: G ∗

Parameters. A hash function H : {0, 1}∗ → {0, 1}∗ .

Operation.

1. On input (keygen, (G, G, q)), sample x ← Zq and return X = x · G. Store (X; x)

in memory and ignore future calls to keygen.
2. On input pres, sample k ← Zq and return R = k−1 · G. Store (R; k) in memory
and standby.
3. On input (sign, msg, R) do:
(a) Retrieve (R; k) from memory. If no such R exists or R is undefined, sample
k ← Zq and (re)assign R := k−1 · G.
(b) Set s = k(m + rx) mod q where m = H(msg) and r = R|x−axis .
(c) Erase (R; k) from memory and return σ = (r, s).
∗
EXPERIMENT 3 G ∗ -Existential Unforgeability ExpGEU (A, 1κ )

The experiment interact with an adversary A and is parameterized with 1κ .

1. Call G ∗ with (keygen, (G, G, q)) and hand X to A.

2. The adversary A makes poly(κ) adaptive calls to G ∗ (on either of the interfaces
keygen, pres or sign).
3. The adversary A returns (m, σ).

The experiment’s output is 1 iff Verfiy(X, m, σ) = 1 and m was not queried to G ∗ ,

otherwise output 0.

Definition 2.3 A threshold signature protocol Π = (Πkgen , Πpres , Πsign ) is G ∗ -

simulatable in the random oracle model if for every adversary A who corrupts
at most t of the parties there exists a simulator S with a black box access to A,
to a random oracle H and to a signing oracle G ∗ , such that:
1. The simulator S queries G ∗ only on messages given as input to the parties
in Π.Πsign (w.l.o.g. it is assumed that the parties agree on these messages),
2. The real and ideal distributions are computationally indistinguishable, namely:
c
{RealH κ H κ
Π,A (1 , z)}κ∈N,z∈{0,1}∗ ≡ {IdealG ∗ ,S (1 , z)}κ∈N,z∈{0,1}∗ .

G ∗ -Simulatability and UC Security. Let Sig = (Gen, Sign, Verfiy) be a

signature scheme, and let Π = (Πkgen , Πpres , Πsign ) be a threshold signature
protocol for Sig. Following [CMP20], the idea is to show that if Sig and Π satisfy
some limited security properties, like stand alone simulatability, then protocol Π
UC-realizes the threshold signature functionality Ftsig (Figure 14) in the strict
global random oracle model: Let A be an adaptive adversary, RealH κ
Π,A (1 , z)
be the adversary’s view in the execution of Π in the presence of A and auxiliary
input z, where H is a random oracle. Without loss of generality, we can assume
that RealH κ Π
Π,A (1 , z) = (pk , . . .) where pk is the public verification key output
from the execution of Πkgen . Next, for a PPT algorithm S, with a black box
G∗
access to A, H and G ∗ , we define IdealH κ S
G ∗ ,S (1 , z) = (pk , Out ) that refers
∗
to the public verification key generated by G and the output of the simulator.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 15

The following theorem [BMP22, Theorem 5.5] is in the heart of the proof
technique that was introduced in [CMP20]. The theorem states that, for a
signature scheme Sig that has enhanced unforgeability, if Π is G ∗ -simulatable
then it is UC-secure. Proving G ∗ -simulatability is a much easier task as it can
leverage non-UC primitives and in particular may involve rewinding of the
adversary. A proof of the following theorem is given in Appendix G.

Theorem 2.4 For a signature scheme Sig and a threshold signature protocol
Π for Sig, let G ∗ be an enhanced signing oracle as defined above. Then Π UC
realizes Ftsig (Functionality 14) in the strict global random oracle model if

1. Sig is G ∗ -existentially unforgeable (Definition 2.2), and

2. Π is G ∗ -simulatable in the random oracle model (Definition 2.3).
3. The outputs of Πkeygen and Πsign are all distinct (except with negligible
probability).

Discussion on Ftsig (Functionality 14). While Ftsig (Functionality F) is easy

to UC-simulate, it comes with caveats. As introduced in [CMP20] (or [Can04]
for non-threshold signatures), the functionality allows the adversary to set the
public key, which is often used as an identifier in blockchain systems. In addition,
it lets the adversary set independent (potentially different) signatures to the
same value. Therefore, Ftsig is extended to overcome those hurdles. In Step
1(c)i the functionality outputs an error if the same public key is certified in
two different session id’s, and similarly, in Step 2(c)ii the functionality ‘rejects’
repeating signatures (even repeating signatures for the same message). To prove
that our protocol realizes that (extended) functionality we added condition 3 in
Theorem 2.4. To that end, we utilize the fact that even when a single honest party
participates in the protocol, the resulting public key is uniformly distributed over
a large space and therefore never repeats, and the same holds for the signatures
due to the random nonce.

3 The 2PC-MPC Protocol

For the 2PC-MPC protocol, party B is replaced with n independent parties

B1 , . . . , Bn that together emulate party B interacting with A. When distributing
the role of B we have to take a special care about the following building blocks:

– Threshold AHE. When B is distributed, all secret values of B are distributed

as well. In particular, the AHE private key sk should also be shared amongst
the parties B1 , . . . , Bn . This leads to the definition of a threshold parameter
t ≤ n, and the assumption that the adversary may corrupt at most t parties
out of B1 , . . . , Bn . As an instantiation, one may use any UC-secure protocol
for threshold AHE key generation and threshold decryption (e.g., [FMM+ 23]
for a Paillier-based and [BDO23] for class-groups based encryption).
– Range proof and proof aggregation. In our protocol, the range statements
are encapsulated within other languages. Proofs for those languages are composed
16 Authors Suppressed Due to Excessive Length

of two components: a Schnorr proof and a range proof (that share the same
statement and witness). Previous works [GGN16, CGG+ 20, BMP22] use a
designated verifier range proof. Namely, the proof parameter is comprised of a
bi-prime that is a product of safe primes that are generated separately by each
verifier, and so in order to prove a statement to the public one has to prove
the statement to each verifier individually. Instead, in our zero-knowledge
protocol we treat the range proof abstractly, which enables plugging any
range proof implementation. This way, one can plug and play any range proof
implementation, depending on the needs. In our case, to obtain the 2PC-
MPC effect, it is important to use publicly verifiable aggregateable proofs. To
this end, we use Bulletproof [BBB+ 18] for range statements as their proofs
are aggregateable and have a trustless setup. Specifically, to prove a range
statement to multiple verifiers in a single shot, we enhance the statement
to include a commitment to the witness as well. The prover then sends (1)
a Schnorr proof of knowledge for the enhanced statement, from which an
extractor can extract a witness (but not necessarily in the adequate range),
and (2) an independent range proof of knowledge on the committed value,
from which an extractor can extract a witness in the specified range. Since
the commitment used in both proofs is the same and the commitment scheme
is computationally binding, we must have that the extractor extracted the
same witness. The above, however, is not sufficient because it only states that
the witness is in the right range Mpp , namely, it is in the right range after
a reduction to some modulus. To solve this, a range check is added to the
response of the range proof, which essentially ensures that the two extracted
witnesses are in fact the same over the integers. This is true as long as the
claimed range is much smaller than the commitment space Cpp . When this is
not the case we decompose the witness w = i wi ∆i such that ∆ is much
P
smaller than Cpp , and then proving, using a batch proof, that all wi ’s are
smaller than ∆. The formal description of the proof appears in Section 5.2.

3.1 The protocol

Key generation. On the first execution of the key-generation in Protocol

4 the parties generate an AHE key: in Step 2c the parties Bi , . . . , Bn send
(keygen, sid) to FTAHE and wait to the response (pubkey, sid, pk, U ′ ∩ U ). If
pk = ⊥ then the parties abort and output the identified cheaters U ′ ∩ U ,
otherwise, they continue with pk as their public encryption key. The other party
A verifies the correctness of the public key by sending (certify, pk) to that
functionality.
Then, the secret signing key share of B is distributively sampled, so that each
Bi samples its own share of xi , provides Xi = xi ·G and cti = AHE.Enc(pk, xi ; ρi )
and proves that cti is an encryption of the discrete log of Xi . These proofs
LEncDL
are being aggregated by functionality
P Fagg−zk so L
A and every Bi receive the
aggregated statement XB = X
i i and ct key = i cti (such that ctkey is an
encryption of the discrete log of XB , denoted xB ).
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 17

Presigning and Signing. From A’s perspective, the presign is almost the
same as the two-party protocol in Appendix I, except that A also gets Enc(γ)
and Enc(γ · xB ), for some unknown γ. Consequentially, at the signing phase,
A will homomorphically compute an encryption of its share of the signature
multiplied by γ. Meanwhile, the parties B1 , . . . , Bn distributively generate their
signature nonce share kB as well as that masking value γ. These values are
securely multiplied and only their product, γ · kB mod q is being exposed via
threshold decryption, but this is deferred to the signing phase. By this, when
the parties obtain A’s encrypted signature share in the signing phase, the can
eliminate γ by multiplication with (γkB )−1 , to derive the signature. See a formal
description in Protocol 5 and 6.

PROTOCOL 4 Key-Generation Πkeygen : KeyGen(G, G, q)
The protocol is parameterized with the ECDSA group description (G, G, q). The
protocol interacts with n + 1 parties A, B1 , . . . , Bn , where all parties hold pk as input.
The parties agree on a fresh sid and do as follows:

1. A’s first message:

(a) A samples a random xA ← Zq and computes XA = xA · G.
LDL
(b) A sends (com–prove, pidA , XA ; xA ) to Fcom−zk .
2. Bi ’s first message:
LDL
(a) Each Bi receives (receipt, pidA ) from Fcom−zk .
(b) Each Bi samples a random xi ← Zq and computes Xi = xi · G.
(c) Only on first execution: Each Bi sends (keygen, sid) to FTAHE and
wait for the functionality’s response. If the functionality responds with
(pubkey, sid, ⊥, U ′ ∩ U ) then output U ′ ∩ U and abort; otherwise, if the
functionality responds with (pubkey, sid, pk) then continue.
(d) Each Bi computes cti = AHE.Enc(pk, xi ; ρi ) for a randomly chosen ρi .
LEncDL
(e) Each Bi sends (prove, sid, pidi , Xi , cti ; xi , ρi ) to Fagg−zk .
LEncDL
(f) Each Bi receives (proof, sid, XB , ctkey ) from Fagg−zk , if not, it receives and
outputs the set of corrupted parties and aborts.
3. A’s second message:
LEncDL
(a) A receives (proof, sid, XB , ctkey ) from Fagg−zk . Note that A implicitly receives
pk as well, as it is part of the public parameters of language LEncDL .
(b) A sends (certify, pk) to FTAHE and waits for its response. If the response is 1
then continue, otherwise abort.
LDL
(c) A sends (decom–proof, pidA ) to Fcom−zk .
4. Bi ’s verification.
LDL
(a) Each Bi receives (decom–proof, pidA , XA ) from Fcom−zk , if not, it aborts.
5. Output.
– A outputs X = XA + XB and record (keygen, XB , X, ctkey , pk).
– Each Bi outputs X = XA + XB and record (keygen, XA , X, ctkey , pk).

Security. Theorem 2.4 states that it is sufficient to prove G ∗ -simulatability

in order to achieve UC security for a threshold signature Ftsig as defined in
18 Authors Suppressed Due to Excessive Length

PROTOCOL 5 Presigning Πpres : Presign ((G, G, q), sid)
The protocol interacts with A, B1 , . . . , Bn where everyone has pk and ctkey as input.
Before proceeding, all parties verify that sid has never been used before. Then they do
as follows:

1. A’s message:
(a) A samples a random kA ← Zq and computes KA = Com(kA ; ρ1 ).
L
(b) A sends (prove, sid, pidA , KA ; kA , ρ1 ) to FzkDCom .
2. Bi ’s message:
(a) First round:
L
i. Bi receives (proof, sid, pidA , KA ) from FzkDCom , if not, it aborts.
∗ P
ii. Bi samples ki ← Zq and computes Ri = ki · G. Denote kB = i ki .
i i i i
iii. Bi samples γi ∈ [0, q), ηmask1 , ηmask2 , ηmask3 , ηmask4 ∈ Rpk , and computes
A. cti1 = AHE.Enc(pk, γi ; ηmask
i
1
),
i i
B. ct2 = AHE.Eval(pk, fi , ctkey ; ηmask 2
) where fi (x) = γi · x,
i i
C. ct3 = AHE.Enc(pk, ki ; ηmask3 ).
L [pk,ctkey ]
iv. Bi sends (prove, sid∥“γ”, pidi , cti1 , cti2 ; γi , ηmask
i
1
i
, ηmask 2
EncDH
) to Fagg−zk .
i i LEncDL
v. Bi sends (prove, sid, pidi , Ri , ct3 ; ki , ηmask3 ) to Fagg−zk .
(b) Second round:
LEncDH [pk,ctkey ]
i. Bi receives (proof, sid∥“γ”, ct1 , ct2 ) from Fagg−zk and
LEncDL
(proof, sid, R, ct3 ) from Fagg−zk .
L [pk,ct ]
ii. Otherwise, if Bi receives (malicious, sid, U ′ ) from Fagg−zk EncDH key
and/or
′′ LEncDL
(malicious, sid, U ) from Fagg−zk , it records the malicious parties (M
and/or M ′ ) and aborts.
iii. Bi computes cti4 = AHE.Eval(pk, fi′ , ct1 ; ηmask i
4
) where fi′ (x) = ki · x.
LEncDH [pk,ct1 ]
iv. Bi sends (prove, sid∥“k”, pidi , cti3 , cti4 ; ki , ηmask
i
3
i
, ηmask 4
) to Fagg−zk .
(c) Proof verification:
LEncDH [pk,ct1 ]
Bi receives (proof, sid∥“k”, ct3 , ct4 ) from Fagg−zk . Otherwise, if Bi
L [pk,ct ]
receives (malicious, sid, U ′ ) from Fagg−zk
EncDH 1
, it records the malicious
parties and aborts.
3. A’s verification
LEncDL
(a) A receives (proof, sid, RB , ct3 ) from Fagg−zk , if not, it aborts.
L
EncDH [pk,ct
key ]
(b) A receives (proof, sid, ct1 , ct2 ) from Fagg−zk , if not, it aborts.
4. Output
(a) A records (presign, sid, RB , ct1 , ct2 ; kA , ρ1 ), where ct1 and ct2 are encryptions
of γ and γ · xB .
(b) Bi records (presign, sid, RB , KA , ct1 , ct2 , ct4 ), where ct4 encrypts γ · kB mod q.

Functionality 14. This enables using tools like non-UC zero-knowledge proofs
and the rewinding technique.

Theorem 3.1 Πecdsa = (Πkgen , Πpres , Πsign ) (Protocols 4, 5 and 6) is G ∗ -simulatable

(according to Definition 2.3) in the (FTAHE , Fzk , Fagg−zk , Fcom−zk )-hybrid and
random oracle model, assuming Com is computationally binding and AHE is
a semantically secure encryption scheme with secure function evaluation.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 19

PROTOCOL 6 Signing Πsign : Sign ((G, G, q), sid, msg)

1. A’s message:
−1
(a) A computes R = (kA )−1 · RB (= kA kB · G) and r = R|x−axis mod q; denote
−1
k = kA kB .
(b) A samples ρ2 ∈ Rpp and computes UA = Com(kA · xA ; ρ2 ).
(c) A sets a1 = r · kA · xA + m · kA and a2 = r · kA .
(d) A homomorphically evaluates ct1 , ct2 , on its private function fA (x1 , x2 ) :=
a1 x1 + a2 x2 :
– ctA ← AHE.Eval(pk, fA , ct1 , ct2 ; ηeval )
(e) A sends the following proofs:
L [pp,(G,R,q)]
– A sends (prove, sid, pidA , KA , RB ; kA , ρ1 ) to FzkDComDL .
– A sends (prove, sid, pidA , KA , UA , XA ; kA , xA , ρ1 , ρ2 ) to
L [pp,(G,G,q)]
FzkDComRatio .
– A computes C1 = (r ⊙ UA ) ⊕ (m ⊙ KA ) and C2 = r ⊙ KA , and sends
(prove, sid, pidA , ctA , C1 , C2 ; a1 , a2 , r · ρ2 + m · ρ1 , r · ρ1 , η) to
L [pp,pk,ct1 ,ct2 ]
FzkDComEval .
2. Bi ’s verification and output:
(a) Bi receives the following proofs, otherwise, it aborts.
L [pp,(G,R,q)]
– (proof, sid||pidA , KA , RB ) from FzkDComDL .
LDComRatio [pp,(G,G,q)]
– (proof, sid||pidA , KA , UA , XA ) from Fzk .
L [pp,pk,ct1 ,ct2 ]
– (proof, sid||pidA , ctA , C1 , C2 ) from FzkDComEval .
(b) Bi verifies that the values used in the proofs are consistent with values obtained
previously by Bi , specifically:
– There are records (keygen, XA , X, ctkey , pk) and (presign, sid, RB , KA , pt′ ),
and
– C1 = (r ⊙ UA ) ⊕ (m ⊙ KA ) and C2 = r ⊙ KA , where r = R|x−axis .
(c) Bi sends (decrypt, pk, ctA ) and (decrypt, pk, ct4 ) to FTAHE and waits
for its response. Let the responses be (decrypted, pk, ctA , ptA , UA ) and
(decrypted, pk, ct4 , pt4 , U4 ) respectively; if ptA = ⊥ or pt4 = ⊥ then output
UA ∪ U4 and abort; otherwise compute s′ = pt−1 4 · ptA mod q (which is equal
to (γkB )−1 · ((rkA xA + mkA )γ + rkA γxB ) = k−1 (rx + m) mod q as required)
and output s = min{s′ , q − s′ } (to ensure uniqueness of the signature).
3. Output: Bi outputs σ = (r, s).

Due to space limit, we defer the full proof to Appendix H and give here only
the intuition. We separate the proof of G ∗ -simulatability to two cases, where in
the first case all parties in B are corrupted (and A is honest) and in the second
A, together with n − 1 parties in B are corrupted (and Bi for some i is honest).
In the first case, the simulator can produce a signing key and presignature in
exactly the same distribution as when produced by G ∗ . The only difference is
that the simulator encrypts the partial signature sA directly (which is then
multiplied by (γkB )−1 to get the final signature), whereas in the real protocol
party A encrypts some partial signature that is equal sA only after a reduction
modulo q. In addition, the simulator commits to zero, instead of the actual
commitment UA . However, the two cases are indistinguishable thanks to the fact
that the AHE scheme has secure function evaluation and that the commitment
20 Authors Suppressed Due to Excessive Length

scheme is perfectly hiding. In the second case, the simulator uses an encryption of
zero instead of the actual ciphertexts ctkey , ct1 , . . . , ct4 . The simulation is shown
indistinguishable to the real execution (where these ciphertexts decrypt to values
different than zero) using a series of hybrids, each changes one of the ciphertexts
to be computed just like in the real execution. Then it is argued that consecutive
hybrids are indistinguishable thanks to the semantic security of the AHE scheme.
On instantiation with the Paillier encryption scheme. The protocol described
above impacts the parameters to be chosen by the underlying encryption scheme.
Specifically, note that by the Definition of Paillier.Eval (in Appendix D) and by
the constraint implied by the zero-knowledge protocol for language LDComEval
(in Section 5), the size of N , the bi-prime modulus of the encryption scheme’s
plaintext space (before reduction modulo q) must be treated carefully. Given that
n < σ (i.e., the number of participants is smaller than the statistical security
parameter), we have that N > q 7 is sufficient to ensure the security of our
protocol.

4 Enhanced Batch Schnorr Protocols

We build on the general Schnorr protocol from Appendix J and show how to
extend it to an enhanced form (to treat a range claim as part of the statement).
Let ϕ : H → G denote a group homomorphism from (H, +), the witness
group, to (G, ·), the associated statement group, and E ⊂ Z≥0 (zero and positive
integers) denote the challenge space.
When the statement includes range statements, we use ‘enhanced’ witness
and statement groups Ĥ and Ĝ that embed H and G, respectively. Specifically, let
(ϕ, H, G, E) and (ϕ̂, Ĥ, Ĝ, E, R, S) be such that Ĥ = H×K, Ĝ = G×C, ϕ̂(u, v) =
(ϕ(u), θ(u; v)) and R, S ⊆ H (where R is the domain from which the witnesses
wi are claimed to be and S is the domain from which the prover draws the mask
for the witness). For our purposes we instantiate θ to be any homomorphic
commitment scheme Com (see Definition C.1) with public parameters p cp, and
so θ(u; v) ∈ C = Cppb is a commitment to u ∈ G using randomness v ∈ K = Rppb.
When applied to a vector (or vectors) ϕ and θ are applied element-wise.
Definition 4.1 An m-batch enhanced Schnorr protocol for the tuple (ϕ̂, Ĥ, Ĝ, E, R, S)
⃗ ∈ Gm and secret witness
consists of the following process. For common input X
m
⃗ ∈ R to the prover, such that ϕ(wj ) = Xj for all j ∈ [1, m]:
w
1. P samples ⃗v ← Km , ρ ← K and α ← S and sends Y ⃗ = (θ(w1 ; v1 ), . . . , θ(wm ; vm )),
A A
X = ϕ(α) and Y = θ(α, ρ) to V.
⃗ ; w, LRange [R]
2. P sends (prove, sid, pid, Y ⃗ ⃗v ) to Fbatch−zk .
⃗ A A
3. Upon receiving Y , X , Y from P and (proof, sid, pid, Y ⃗ ) from F LRange [R]
batch−zk
(same Y⃗ in both messages), V sends a random challenge ⃗e ← E m to P.
Pm m
4. P replies with z = α + j=1 ej · wj ∈ H and z ′ = ρ + j=1 ej · vj ∈ K.
P
m
5. V checks that ϕ̂(z, z ′ ) = (X A , Y A ) j=1 (Xj , Yj )ej ∈ Ĝ, namely, ϕ(z) =
Q
A
Qm ej ′ A
Lm
X j=1 Xj ∈ G and θ(z, z ) = Y ⊕ ( j=1 ej · Yj ) ∈ C (recall that ⊕
denotes hom. addition in C). In addition, V checks that z ∈ S and z ′ ∈ K.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 21

We now present a security definition for an enhanced Schnorr protocol, which is

analogous to Definition J.1. For µ, ε ∈ poly(κ), we define the following properteis:
– µ-HVZK. If Xi = ϕ(wi ) and wi ∈ R for all i ∈ [1, m], then the simulated
transcript (X, ⃗ A, ⃗ Y ⃗ , ⃗e, z, z ′ ) and (proof, sid, ssid, Y
⃗ ) is statistically µ-close to
′
the honest transcript, where z ∈ S and z ← K, ⃗e ← E m , Yj ← θ(0, K) for all
Qm −e Lm
j ∈ [1, m], A1 = ϕ(z) j=1 Xj j ∈ G and A2 = θ(z, z ′ ) ⊕ ( j=1 −ej · Yj ) ∈
C.
– ε-Knowledge soundness. There exists a set V such that:
• Sampling E ← E m×(m+1) , it holds that Pr[E ∈ V ] ≥ 1 − neg(κ).
• There exists a PPT extractor E such that given (1κ , X, ⃗ Y⃗ , X A , Y A , E, Z, Z ′ )
and (proof, w, ⃗ ⃗v ) where E = (⃗e1 , . . . , ⃗em+1 ), Z = (⃗z1 , . . . , ⃗zm+1 ) and
Z ′ = (⃗z1′ , . . . , ⃗zm+1
′
) such that V(X, ⃗ Y
⃗ , X A , Y A , (proof, θ(w,⃗ ⃗v ), ⃗ej , ⃗zj , ⃗zj′ ) =
1 for all j ∈ [1, m + 1], and E ∈ V , then,

Pr[ϕ(w) ⃗ θ(w,
⃗ =X, ⃗ ,w
⃗ ⃗v ) = Y ⃗ ∈ Hm , ⃗v ∈ Km
⃗ Y
⃗ ⃗v ) ← E(1κ , X,
| (w, ⃗ , X A , Y A , E, Z, Z ′ )] ≥ 1 − ε.

Importantly, assuming the extractor has (proof, θ(w, ⃗ ⃗v )) is allowed as

Lrange
we assume Fzk is instantiated with a proof of knowledge, and therefore
these values can be extracted from it.

4.1 Aggregation of Enhanced Schnorr Batch Proofs

Let Π denote a (µ, ε)-secure enhanced batch Schnorr protocol for (ϕ̂, Ĥ, Ĝ, E, R, S).
We want to construct a proof aggregation among n provers P1 , . . . , Pn , in possession
of the witnesses wj for each statement Xj , for (ϕ̂, Ĥ, Ĝ, E, nR, nS), where nR
and nS refer to the sets of n-sums from R and S, respectively. This new tuple
implies that nR, nS ⊆ H. Namely, for every j ∈ [m], party Pi has wi,j ∈ R
P
such that wj = i wi,j ∈ nR and ϕ(wj ) = ⃗ (Xi,j )m
PXj . DenotingQ by Xi = Q j=1 =
(ϕ(wi,j ))j , we also have Xj = ϕ(wj ) = ϕ( i wi,j ) = i ϕ(wi,j ) = i Xi,j . We
show that under this aggregation process, HVZK and knowledge soundness are
preserved. The protocol proceeds as follows, each prover Pi :

1. Samples αi ← S, ρi ← K, ⃗vi ← Km , ui ← {0, 1}κ and computes Y ⃗i =

(θ(wi,1 ; vi,1 ), . . . , θ(wi,m ; vi,m ))) and XiA = ϕ(αi ), YiA = θ(αi , ρi ). Then, it
broadcasts Ci = H(sid, pidi , X ⃗ i, Y
⃗i , X A , Y A , ui ). Recall that Yi,j = θ(wi,j ; vi,j ) =
i i
Comppb (wj,i ; vj,i ) is a homomorphic commitment.
2. Receives Ci′ from each party 1 ≤ i′ ≤ n.
⃗ i, Y ⃗i , X A , Y A , ui ) and sends (prove, sid, pidi , Y ⃗i ; w LRange [R]
3. Broadcasts (X i i ⃗ i , ⃗vi ) to Fagg−zk .
⃗ ⃗ A A
4. Upon receiving (Xi′ , Yi′ , Xi′ , Yi′ , ui′ ) from Pi′ and (proof, sid, pid, Yi′ ) from ⃗
LRange [R]
Fagg−zk for all i′ ∈ [n], party Pi :
⃗ ⃗ A A
– checks that Ci′ = PH(sid, pid i′ , X
Qi′ , Yi′ , XAi′ , Yi′ , ui′ )Qand aborts otherwise;
– computes u = i ui , X = i′ ∈[n] Xi′ , Y A = i′ ∈[n] YiA
A
′ , and Xj =
Q Q
X
i ∈[n] i ,j
′ ′ , Y j = Y
i ∈[n] i ,j
′ ′ for all j ∈ [m];
22 Authors Suppressed Due to Excessive Length

– calculates ⃗e = H(sid, {pid ⃗ ⃗ A A

Pmi′ }i′ , X, Y , X , Y′ , u); Pm
– broadcasts zi = αi + j=1 ej · wi,j and zi = ρi + j=1 ej · vi,j ∈ K.

Upon receiving zi′ and zi′′ from Pi′ for all i′ ∈ [n], the verifier V:
′ ′
P P
1. computes z = i′ ∈[n] zi , z = i′ ∈[n] zi′ and verifies that z ∈ nS and
′

′
z ∈ K. Qm e Lm
2. verifies that ϕ(z) = X A j=1 Xj j ∈ G and θ(z; z ′ ) = Y A ⊕( j=1 ej ·Yj ) ∈ C
(recall that ⊕ denotes homomorphic addition in C).
3. If one of the above checks fail, validate them again per each j, to identify
the set of malicious provers U ′ .
4. If no cheater detected then output accept.

Theorem 4.2 The above protocol preserves completeness, zero-knowledge and

knowledge soundness, that is:
– Completeness. If all Pi ’s are honest then V outputs accept.
– zero-knowledge. W.l.o.g suppose that P1 is honest and all P2 , . . . , Pn are
corrupted. There exists a simulator S such that for every statement X, ⃗ the
statistical distance between a real protocol execution and the output of the
simulator S(X) ⃗ is negligible (in the programmable random oracle model).
– Knowledge Soundness. This is the same as in Definition 4.1.

Proof. Completeness of the protocol is trivial and omitted for lack of space.
The proof for zero-knowledge follows from the HVZK property of the single
prover protocol, as follows:
1. S samples a random value r ← {0, 1}2κ and broadcasts (sid, pid1 , r).
2. S emulates H and receives from A the values it commits to.
3. S sets X⃗ 1 = X/ ⃗ Q′ X ⃗ ′ κ
v1 ∈ Km and computes
i ̸=1 i , and samples u1 ← {0, 1} , ⃗
⃗1 = θ(⃗0, ⃗v1 ).
Y
4. S defines H′ ≡ H except for H′ (sid, pid1 , X ⃗ 1, Y
⃗1 , u) = r, and thereafter
′
answers oracle queries according to H (rather than H).
5. S opens the commitment.
6. S runs the simulator for a single prover, on statement (sid, pid1 , X ⃗ 1, Y
⃗1 ) and
A A ⃗′ ′′ ′ ′′ ⃗ ⃗1 , X A , Y A ) =
obtains (X1 , Y1 , ⃗e, ⃗z, z ). It defines H ≡ H except for H (sid, pid1 , X1 , Y 1 1
⃗e, and thereafter answers oracle queries according to H (rather than H′ ).
′′

7. S then broadcasts the simulated responses (sid, pid1 , ⃗z1 , z⃗′ 1 ).

Due to the HVZK of the single prover protocol and union bound, the statistical
distance between the simulated and real transcripts is 2−s · n, where n is the
number of participating provers. Therefore, we increase S further by n. ⊔
⊓

5 Instantiating Fzk for LDComEval

We provide a full protocol and proof for LDComEval . A standard way to batch
zero-knowledge proofs is presented in Appendix J and the specific security proof
for LDComEval is given in Appendix K. In Appendix L we show how to instantiate
Fzk for the other languages; their security proofs are essentially the same.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 23

5.1 The Language LDComEval

Consider LDComEval in Equation (7). We will instantiate AHE with the Paillier
encryption scheme, in order to extract the randomness η in the final stage of the
knowledge soundness proof. Recall that Paillier.Eval is defined in Appendix D.
In particular, we stress that randomizers in Rpk are represented as pairs (ω, η).
Furthermore, any homomorphic commitment scheme Com as in Definition C.1
with a sufficiently large message space suffices. Depending on the range proof
implementation, Com may be a batched-Perdersen commitment, a list of Pedersen
commitments per each ai (as Bulletproof [BBB+ 18] requires), or a single Pedersen
bit-commitment as in [DPLS19]. Our proof is indifferent to the particular instantiation.
Furthermore, we set the following:


– ϕ(⃗a, ρ, ω, η) = Paillier.Eval(pk, f⃗a (⃗x), c⃗t; ω, η), Com(⃗a, ρ)
– H = Zℓ+1 × Rpp × Z × Rpk
– G = Cpk × Cpp
– E = [0, 2κ )
Pℓ
– R = [0, q)ℓ+1 × Rpp × [0, 2s i=1 PTi ) × Rpk
Pℓ
– S = [0, q2κ+s )ℓ+1 × Rpp × [0, 22s+κ i=1 PTi ) × Rpk

Recall, from the description of the Paillier encryption scheme in Appendix D,

that PTi be the upper bound associated with cti . Furthermore, PTeval is defined
to be the upper bound on the plaintext encrypted under the result of Paillier.Eval,
before the reduction modulo N takes place.

5.2 Schnorr Protocol for LDComEval

In order to claim that C = Compp (m; ρ) is a commitment over a message m

that lies within a certain range m ∈ [0, ∆), we must have [0, ∆) ⊂ Mpp . For
example, in Pedersen commitments over an elliptic curve, where Mpp = [0, q),
this translates to q > ∆. Indeed, Mpp = [0, q) is only defined modulo q.
Instead of working with a high order group, we express every Pd−1witness in
base ∆. Specifically, denote d := log∆ ⌈q⌉; then we have ai = ai,j ∆j ;
s
Pℓ Pℓω −1 j=0 i
similarly, we define ℓω = ⌈logq 2 i=1 PTi ⌉ and set ω = i=0 ωi · q , and
Pd−1 j
ωi = j=0 ωi,j ∆ ;
Then, we treat the ai,j ’s and ωi,j ’s as the witnesses, and [0, ∆) as the range
to be claimed. This avoids arithmetic over high-order elliptic curves, as well as
aligns all witnesses to lie in the same interval [0, ∆), hence simplifies the analysis.
We require q > ∆·(d(ℓ+1+ℓω )·2κ+s +2κ ). Therefore, we can think of Paillier.Eval
as follows:  
Enc(1; 0)
 ct1 
Eval
   ..

ct = Paillier.Eval(pk, f⃗a (⃗x), c⃗t; ω, η) = a0 a1 . . . aℓ ω ⊙ ⊕Paillier.Enc(0; η)
 
 . 
 ctℓ 
Enc(q; 0)
(11)
24 Authors Suppressed Due to Excessive Length

Decomposing the witness in base ∆, we can write Eq. 11 as follows:

 
Enc(1; 0)

 ct1 

   .
..

a0,0 a1,0 . . . aℓ,0 ω0,0 . . . ωℓω −1,0 



Eval
= ∆0 . . . ∆d−1 
  .. .. .. .. .. .. .. ⊙
ct ct ⊕Paillier.Enc(0; η)
  
. . . . . . .   ℓ
Enc(q; 0)
 
a0,d−1 a1,d−1 . . . aℓ,d−1 ω0,d−1 . . . ωℓω −1,d−1  

 .. 

 . 
Enc(q ℓω ; 0)
(12)
Then, we can denote aℓ+i,j = ωi−1,j to simplify notation, and let A be the
matrix in Eq. 12 whose (i, j)th entry is ai,j (i ∈ [0, ℓω ], j ∈ [0, d−1]). Furthermore,
we denote by ⃗v∆ the row vector ∆0 . . . ∆d−1 , and denote by ⃗c the column vector

T
of ciphertexts Enc(1; 0) ct1 . . . ctℓ Enc(1; 0) Enc(q; 0) . . . Enc(q ℓω ; 0) . Therefore,


equivalently, we prove the following language:

LDComEval [pp, pk, c⃗t] = {ctEval , C; A, ρ, η |ctEval = ⃗v∆ · A ⊙ ⃗c ⊕ Enc(0; η)

∧ C = Compp (A; ρ)
∧ A ∈ [0, ∆)(ℓ+1+ℓω )×d
∧ ρ ∈ Rpp ∧ η ∈ Rpk }

Protocol 7 is now parameterized with

– ϕ(A, ρ, η) = (⃗v∆ · A ⊙ ⃗c ⊕ Enc(0; η), Com(A; ρ))

– H = Z(ℓ+1+ℓω )×d × Rpp × Rpk
– G = Cpk × Cpp
– E = [0, 2κ )
– R = [0, ∆)(ℓ+1+ℓω )×d × Rpp × Rpk
– S = [0, ∆ · d(ℓ + 1 + ℓω ) · 2κ+s )(ℓ+1+ℓω )×d × Rpp × Rpk

HVZK. We need to show that for every (ctEval , C; A, ρ, η) ∈ RDComEval [pp, pk, c⃗t]
there exists a PPT simulator S, such that
s
Spp,pk,c⃗t (ctEval , C) ≡ {View(Ppp,pk,c⃗t (A, ρ, η) ↔ Vpp,pk,c⃗t (ctEval , C)}
≡ {⃗v∆ · B ⊙ ⃗c ⊕ Enc(0; ξ), Com(B; ν),
(proof, Com(B; ν)), e, B + e · A, ξ + eη, ν + eρ}

over the random variables B ∈ [0, ∆ · d(ℓ + 1 + ℓω ) · 2κ+s )d×(ℓ+1+ℓω ), ξ ∈ Z∗N and
ν ∈ Rpp .
Consider the following simulator S:

1. S uniformly samples e ∈ [0, 2κ ), Z ∈ [0, ∆ · d(ℓ + 1 + ℓω )2κ+s )d×(ℓ+1+ℓω ),

z Eval ∈ Rpk , z Com ∈ Rpp ,
2. S computes CU = Com(Z; z Com ) ⊖ (e ⊙ C).
3. S computes ctU = ⃗v∆ · Z ⊙ ⃗c ⊕ Enc(0; z Eval ) ⊖ (e ⊙ ctEval ).
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 25

PROTOCOL 7 ZK proof for LDComEval

1. P samples the matrix B ∈ [0, ∆ · d(ℓ + 1 + ℓω ) · 2κ+s )d×(ℓ+1+ℓω ) as well as,

ν ∈ Rpp , ξ ∈ R∗pk , computes
ctU = ⃗v∆ · B ⊙ ⃗c ⊕ Enc(0; ξ) and CU = Compp (B; ν), and sends (prove, C; A, ρ) to
LRange [pp,0,∆]
Fzk−batch , and (ctU , CU ) to V.
Range L [pp,0,⌈q⌉]
2. Upon receiving (ctU , CU ) from P and (proof, C) from Fzk−batch (with the
same C in both messages), V sends a random challenge e ← [0, 2κ ) to P.
3. P responds with (Z, z Eval , z Com ), where:
– Z = B + e · A ∈ Zd×(ℓ+1+ℓω ),
– z Eval = ξ + eη ∈ Rpk , and
– z Com = ν + e · ρ ∈ Rpp .
4. V verifies the following equations:

⃗v∆ · Z ⊙ ⃗c ⊕ Enc(0; z Eval ) = ctU ⊕ (e ⊙ ctEval ) (13)

Com
Com(Z; z ) = CU ⊕ (e ⊙ C) (14)

In addition, V verifies that:

– z Com ∈ Rpp , z Eval ∈ Rpk , C, CU ∈ Cpp , c⃗t, ctEval , ctU ∈ Cpk , and
– Z ∈ [0, ∆ · (d(ℓ + 1 + ℓω ) · 2κ+s + 2κ ))d×(ℓ+1+ℓω ).

4. S outputs (ctU , CU , (proof, C), e, Z, z Eval , z Com .

First note that this transcript is accepting, as it is computed so that it passes
verification. Z is sampled with a valid range for each entry, and ctU and CU
are fixed such that the equations hold. We now argue that this transcript is
indistinguishable from a transcript between a prover who knows the witness and
a honest verifier. Indeed, e,z Eval and z Com are identically distributed, and Z is
statistically indistinguishable. Indeed, in the simulation each of the entries Zi,j
distributes uniformly (and independently) over [0, ∆·d(ℓ+1+ℓω )2κ+s ). In a real
execution, each entry distributes uniformly over [0, ∆d(ℓ + 1 + ℓω )2κ+s ) + εi,j for
some offset εi,j ∈ [0, ∆2κ ), which encodes e times the corresponding witness in
[0, ∆). Therefore, the statistical distance between each pair of entries is bounded
1
by d(ℓ+1+ℓ ω
) · 2s . Therefore, the statistical distance is bounded by:
SD[S, P ↔ V] = SD[S|e,Z,z Eval ,zCom , (P ↔ V)|e,Z,z Eval ,zCom ] (15)
≤ SD[S|e , (P ↔ V)|e ] + SD[S|zEval , (P ↔ V)|zEval ] + SD[S|zCom , (P ↔ V)|zCom ] +
SD[S|Z , (P ↔ V)|Z ] (16)
1
≤ 0 + 0 + 0 + d(ℓ + 1 + ℓω ) · = 2−s (17)
d(ℓ + 1 + ℓω )2s
Where Eq. 15 follows since the rest of the transcript is deterministically
determined due to the verification equations, and 16 follows because e, z Eval , zCom
and each entry of Z are mutually independent in both simulation and real
execution (see Lemma C.4).
ε-Knowledge Soundness. Given two accepting transcripts (ctU , CU , e, Z, z Eval , z Com ),
(ctU , CU , ê, Ẑ, ẑ Eval , ẑ Com ) where e ̸= ê, and given (proof, A, ρ) where Com(A; ρ) =
26 Authors Suppressed Due to Excessive Length

C, we construct a PPT extractor E that outputs A, η, ρ such that (ctEval , C; A, η, ρ) ∈

LDComEval [pk, pp, c⃗t]. The extractor is defined as follows:

– Using (e, Z, z Com ) and (ê, Ẑ, ẑ Com ), apply Eq. 14 as follows. Compute:

Com(Z − Ẑ; z Com − ẑ Com ) = (e − e′ ) ⊙ C = Com(Ã; ρ̃)

For à = (e − ê)−1 (Z − Ẑ) mod q and ρ̃ = (e − ê)−1 (z Com − ẑ Com ) mod q.

Note that à = A mod q because otherwise, the extractor finds two openings
for the commitment Com, which breaks the binding of the commitment (for
Pedersen, this translates to finding a discrete log). Therefore, ε must be
negligible in κ, in contradiction. In particular, Ã now has entries within
[0, ∆), therefore à = A.
– Therefore, (e − ê)A = Z − Ẑ mod q. Thus, there exist K ∈ Zd×(ℓ+1+ℓω ),
such that:
qK = (Z − Ẑ) − (e − ê)A (18)
Because the range checks validate, by triangular inequality, we can bound
the ℓ∞ -norm (max absolute entry) of the RHS of Eq. 18 by ∆(d(ℓ + 1 + ℓω ) ·
2κ+s + 2κ ) + ∆2κ < q, and therefore we can deduce that K = 0, that is, the
equation holds over Z:

(e − ê)A = Z − Ẑ (19)

In particular, the equation holds modulo Ppk , that is, modulo N in case of
the Paillier AHE cryptosystem.

Then, from Eq. 13 we have:

⃗v∆ · (Z − Ẑ) ⊙ ⃗c ⊕ (Enc(0; z Eval ) ⊖ Enc(0; ẑ Eval )) = (e − ê) ⊙ ctEval

Denote ct0 = ⃗v∆ ·A⊙⃗c. Subtracting (⊖) (e− ê)ct0 from both sides, by Eq. 19,
we get

Enc(0; z Eval ) ⊖ Enc(0; ẑ Eval ) = (e − ê)(ctEval ⊖ ct0 ) (20)

To extract the randomizer η, we rewrite Eq. 20 in Paillier notation:
N e−ê
z Eval ctEval
 
⇒ = mod N 2
ẑ Eval ct0
z Eval ctEval
We use Lemma 5.1, by having y = ẑ Eval
, x= ct0 , k = e − ê, M = N 2 and
Eval
observing that N, e−e′ are co-prime2 , to get η̃ such that η̃ N = ctct0 mod N 2 and
so ctEval ⊖ct0 = Enc(N, 0; η̃). By rearranging we get ctEval = ⃗v∆ ·A⊙⃗c⊕Enc(0; η̃) =
Eval(pk, f⃗a (⃗x), c⃗t; ω, η̃), where ⃗a and ω are in the required range.
2
Since N = p1 p2 where p1 , p2 ≫ 2κ , and e ̸= e′ .
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 27

Lemma 5.1 Suppose that y N = xk mod M , where k and N are co-prime and
x, y ∈ Z∗M . Then, there exists η ∈ Z∗M , such that η N = x mod M . Furthermore,
η can be computed efficiently given x, y, N, k.
Proof. Since k and N are co-prime, there exists u, v ∈ Z such that ku + N v = 1,
and u, v ∈ poly(||M ||2 ). Thus: x = xku+N v = (y u · xv )N mod M and therefore,
η := (y u · xv ) satisfies the equation η N = x mod M .

6 Optimizations
Presign batching. Instead of running multiple instances of the presign protocol
in parallel, we can use batched Schnorr proofs, in which one proves statements
that belong to multiple sessions at the same time. This is done by having each
party sampling m nonces and following the same protocol as in Protocol 5,
except that instead of sending a proof to Fzk , sending a proof of m statements
in one shot to Fbatch−zk . Then, in the signing Protocol 6, the parties use a fresh
nonce on each invocation. A proof by simulation of this modified protocol works
exactly the same as the one with a single-nonce presign. Instantiating Fbatch−zk
is done via batched enhance Schnorr protocol as shown in Section 4 in general,
and in Appendix K for the specific language LDComEval .
We note that the proof of language LEncDH in Step 2(b)iv (in the second
round of Protocol 5) cannot be batched with our technique, as ct1 is part
of the public parameters and it is different in each presign instance. In this
case Fbatch−zk is realized by invoking Fzk multiple times in parallel. From A’s
perspective, however, the presign ends after the first round (i.e., in Step 3 A
does not verifies the aforementioned proof), and so this does not impact its
latency or communication overheads. We remark that since the computation
and communication overheads incurred by the zero-knowledge proof is similar to
that of computing the statement itself, protecting against a malicious adversary
is about 2× more expensive than protecting against a semi-honest adversary.
Optimized Threshold Decryption Intuitively, in order to realize FTAHE ’s
decryption, each party will have to send its decryption share of a threshold
AHE scheme, validate all decryption shares from each other party, then combine
all decryption shares to get the plaintext and derive the signature. Although
Tiresias [FMM+ 23] demonstrate that validating decryption shares can be scaled
by batching multiple sid’s, in our case, batching multiple signing requests from
multiple users, combining the decryption shares is still computationally heavy,
and scales at least linearly by the number of parties.
To resolve this issue, we observe that it is enough for a single party Bi
to compute the plaintext and derive the signature. Therefore, when getting n
signing requests from n different sid’s, each party Bi could be responsible for
decrypting a different ciphertext. Overall, each party will compute one decryption
share per ciphertext, and will derive only one plaintext out of n, resulting with
an amortized cost of only O(1) exponentiations.
We refer to Appendix E for the detailed proof and below explain the proof
sketch. To simulate the new protocol, S first extracts the adversary’s secret
28 Authors Suppressed Due to Excessive Length

decryption shares ski for the TAHE scheme. Then, to simulate the honest party
decryption shares for ct4 , ctA , it uses these key shares and the corresponding
plaintexts (which are simulated in the same way as in Simulation 19). Then, it
calls the adversary which then outputs s′ , and there are two options:
1. (r, s′ ) is a valid signature on m. Since there is only one correct value for s
given r, m, this is the only message it can send to avoid the next round.
2. It sends s′ ̸= s, and therefore the signature doesn’t verify. In this case, the
parties fall back to the heavy protocol, and send their decryption shares with
zk proofs. S can simulate those proofs for the honest parties.

O(1) User Complexity (Independent of n) As mentioned, Bulletproof’s

verification time scales linearly with the witness size. In particular, the verification
time of the user A for the range proofs will depend on the number of parties n in
B. To overcome this, we use the well-known range proof used back in [GGN16],
that is based on a Pedersen commitment over the hidden-order group Z∗N̂ . We
A
refer to [BMP22] for the details. The required changes in our protocol follow:

1. In key generation, the user A also has to generate the required public parameters
for the above commitment, namely N̂ , and send it to Fcom−zk . Therefore,
when opening the commitment, A has to prove in zk that N̂A is valid (in
particular, composed of safe primes).
2. When realizing Fagg−zk , the parties in B will generate two proofs: one with
Bulletproofs, and the other one respect to A’s bi-prime N̂ A .
3. Lastly, the above range proof is a gap sigma protocol. This means that while
correctness and zk are ensured only for a prover that uses a witness in the
correct range, knowledge soundness will extract a witness in a potentially
larger domain, namely S, rather than R as in Definition 4.1. Therefore, the
user will treat ct1 and ct2 as encryptions of plaintexts in the broader domain
S, and will therefore use a mask ω in a proportionally larger domain (×2κ+s )
as well, to mask its secret linear evaluation function.

Three Rounds Protocol Below we show how to transform the 7-round 2PC-
MPC Protocol described in Section 3 into a 3-round protocol for a typical
threshold access structure. Intuitively, proof aggregation costs an additional
round, as the parties run the protocol interactively. This aggregation is crucial for
a 2PC-MPC access structure, as the parties must mimic a single party. However,
for a threshold access structure, such aggregation is not strictly required and
therefore a trade-off is presented between round and computation complexity.
Therefore, two changes are made. First, the user’s secrets become public,
e.g., xA = 0 and kA = 1, so that the protocol only involves the parties {Bi }ni=1 .
Second, in presign, we replace the Fagg−zk functionalities with Fcom−zk . At first
glance, this results with a 5 round protocol. However, we may treat encrypted
values as commitments, as observed in [CGG+ 20]. This saves commitment rounds
and results with a 3-round protocol. In Appendix M, we specify the 2-round
presign protocol, present its simulation in detail, and prove indistinguishability.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 29

7 Instantiation & Evaluation

We instantiate the additively homomorphic encryption with Paillier encryption

scheme [Pai99] using a 2048-bit bi-prime modulus N , and for the threshold
Paillier protocol we use Tiresias implementation [FMM+ 23]. We use Pedersen
commitment [Ped91] as our homomorphic commitment scheme Com over the
same ECDSA group G = secp256k1. Random oracle calls are instantiated via
SHA3-256. Zero-knowledge proofs for range statements, namely, instantiation
L
of Fzkrange as well as its batched and aggregateable versions, are implemented
using Bulletproof [BBB+ 18]. Instantiating all other zero-knowledge proofs is
done using our proof system as described in Sections 4 and 5.
Our protocol can be instantiated with any broadcast channel, and each
instantiation may have a different impact on the full protocol’s latency and
throughput. The runtime of the whole signing phase is composed (at the parties
in B) of computing the decryption share and aggregation of the shares from all
parties. Notably, due to amortized decryption, we can decrypt n signatures and
in parallel while keeping the latency fixed. The signature runtime for various n
and t are given in Figure 1 for both party A (user), party Bi (server) and a
party in [DKLS19]. This is the first time that a threshold ECDSA protocol is
able to run for such a large number of parties. For [DKLS19] we draw a dashed
line for the estimated time it would take (using a quadratic interpolation). Note
that user runtime does not depend on the number of parties in the network. The
runtime for key-generation and presignature protocols is given in Appendix A.

Fig. 1: Servers and user runtime for the signing phase.

Our implementation is written in pure Rust, and will be released as open

source. In our implementation we use crypto-bigint3 for computations over big
integers and modular arithmetics over unknown order groups. k2564 for the group
operations. For the Bulletproofs we use dalek-cryptography5 over the Ristretto

3
https://github.com/RustCrypto/crypto-bigint
4
https://github.com/RustCrypto/elliptic-curves/tree/master/k256
5
https://github.com/dalek-cryptography/bulletproofs/tree/main
30 Authors Suppressed Due to Excessive Length

group6 . All the above gives us a full constant-time implementation, which is

especially important when implementing cryptography.
We evaluate the performance of our scheme with n (the number of parties)
varying from 10 to 1000, and B (the batch size) varying from 1 (without batching)
to 1000. For the threshold decryption protocol, we use t = (2/3)n as the threshold.
All experiments are conducted over MacBook Pro Apple M1 Max @ 3.22GHz
utilizing a single core (single threaded). Parallelization can scale throughput
perfectly with the number of cores as computation is completely independent.

Fig. 2: Separation of the computational cost of the presign protocol (Protocol 5)

to times, in milliseconds, for statement computation, Schnorr proofs and range
proof generation + verification. Note the y-axis is in logarithmic scale, therefore
the bottleneck is clearly the Bulletproofs. Therefore, when using Class Groups, the
statement computation becomes the bottelneck, and malicious security is for essentially
“free” (due to batching and aggregation).

Fig. 3: Verification time of Schnorr proofs without aggregation scales linearly with n,
whereas verification of an aggregated proof remains constant. Indeed, proof aggregation
incurs a cost that asymptotically scales with the number of parties. However, the
proof time is orders of magnitude cheaper than a single verification, therefore the
computational overhead, dictated by proof verification, remains practically constant,
even for thousand parties.

6
https://ristretto.group/
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 31

References
ACS02. Joy Algesheimer, Jan Camenisch, and Victor Shoup. Efficient Computation
Modulo a Shared Secret with Application to the Generation of Shared Safe-
Prime Products. In CRYPTO, volume 2442, pages 417–432. Springer, 2002.
ANO+ 22. Damiano Abram, Ariel Nof, Claudio Orlandi, Peter Scholl, and Omer
Shlomovits. Low-bandwidth threshold ECDSA via pseudorandom
correlation generators. In SP, pages 2554–2572. IEEE, 2022.
Ban05. Endre Bangerter. Efficient zero knowledge proofs of knowledge for
homomorphisms. PhD thesis, Citeseer, 2005.
BBB+ 18. Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter
Wuille, and Greg Maxwell. Bulletproofs: Short proofs for confidential
transactions and more. In 2018 IEEE symposium on security and privacy
(SP), pages 315–334. IEEE, 2018.
BDO23. Lennart Braun, Ivan Damgård, and Claudio Orlandi. Secure multiparty
computation from threshold encryption based on class groups. In Helena
Handschuh and Anna Lysyanskaya, editors, CRYPTO, pages 613–645,
2023.
BGG17. Dan Boneh, Rosario Gennaro, and Steven Goldfeder. Using level-1
homomorphic encryption to improve threshold DSA signatures for bitcoin
wallet security. In LATINCRYPT, volume 11368 of Lecture Notes in
Computer Science, pages 352–377. Springer, 2017.
BMP22. Constantin Blokh, Nikolaos Makriyannis, and Udi Peled. Efficient
Asymmetric Threshold ECDSA for MPC-based Cold Storage. Cryptology
ePrint Archive, 2022.
BPMW16. Florian Bourse, Rafaël Del Pino, Michele Minelli, and Hoeteck Wee. FHE
Circuit Privacy Almost for Free. In Advances in Cryptology - CRYPTO
2016 - 36th Annual International Cryptology Conference, Santa Barbara,
CA, USA, August 14-18, 2016, Proceedings, Part II, volume 9815 of Lecture
Notes in Computer Science, pages 62–89. Springer, 2016.
Can04. Ran Canetti. Universally composable signature, certification, and
authentication. In Proceedings. 17th IEEE Computer Security Foundations
Workshop, 2004., pages 219–233. IEEE, 2004.
CCL+ 20. Guilhem Castagnos, Dario Catalano, Fabien Laguillaumie, Federico
Savasta, and Ida Tucker. Bandwidth-efficient threshold EC-DSA. In
PKC, volume 12111 of Lecture Notes in Computer Science, pages 266–296.
Springer, 2020.
CGG+ 20. Ran Canetti, Rosario Gennaro, Steven Goldfeder, Nikolaos Makriyannis,
and Udi Peled. UC non-interactive, proactive, threshold ECDSA with
identifiable aborts. In CCS, pages 1769–1787, 2020.
CHI+ 21. Megan Chen, Carmit Hazay, Yuval Ishai, Yuriy Kashnikov, Daniele
Micciancio, Tarik Riviere, Abhi Shelat, Muthu Venkitasubramaniam, and
Ruihan Wang. Diogenes: Lightweight scalable RSA modulus generation
with a dishonest majority. In (SP), pages 590–607. IEEE, 2021.
CMP20. Ran Canetti, Nikolaos Makriyannis, and Udi Peled. UC non-interactive,
proactive, threshold ECDSA. IACR Cryptol. ePrint Arch., page 492, 2020.
DJN+ 20. Ivan Damgård, Thomas Pelle Jakobsen, Jesper Buus Nielsen,
Jakob Illeborg Pagter, and Michael Bæksvang Østergård. Fast threshold
ECDSA with honest majority. In SCN, volume 12238 of LNCS, pages
382–400. Springer, 2020.
32 Authors Suppressed Due to Excessive Length

DKLS19. Jack Doerner, Yashvanth Kondi, Eysa Lee, and Abhi Shelat. Threshold
ECDSA from ECDSA assumptions: The multiparty case. In SP 2019,
pages 1051–1066. IEEE, 2019.
DKLS23. Jack Doerner, Yashvanth Kondi, Eysa Lee, and Abhi Shelat. Threshold
ECDSA in three rounds. IACR Cryptol. ePrint Arch., page 765, 2023.
DOK+ 20. Anders P. K. Dalskov, Claudio Orlandi, Marcel Keller, Kris Shrishak, and
Haya Shulman. Securing DNSSEC keys via threshold ECDSA from generic
MPC. In ESORICS, volume 12309, pages 654–673. Springer, 2020.
DPLS19. Rafaël Del Pino, Vadim Lyubashevsky, and Gregor Seiler. Short Discrete
Log Proofs for FHE and Ring-LWE Ciphertexts. In IACR International
Workshop on Public Key Cryptography, pages 344–373. Springer, 2019.
FMM+ 23. Offir Friedman, Avichai Marmor, Dolev Mutzari, Yehonatan C. Scaly,
Yuval Spiizer, and Avishay Yanai. Tiresias: Large scale, maliciously secure
threshold paillier. IACR Cryptol. ePrint Arch., page 998, 2023.
GG19. Rosario Gennaro and Steven Goldfeder. Fast multiparty threshold ECDSA
with fast trustless setup. IACR Cryptol. ePrint Arch., page 114, 2019.
GGN16. Rosario Gennaro, Steven Goldfeder, and Arvind Narayanan. Threshold-
optimal DSA/ECDSA signatures and an application to bitcoin wallet
security. In International Conference on Applied Cryptography and
Network Security, pages 156–174. Springer, 2016.
GKSS20. Adam Gagol, Jedrzej Kula, Damian Straszak, and Michal Swietek.
Threshold ECDSA for decentralized asset custody. IACR Cryptol. ePrint
Arch., page 498, 2020.
HL10. Carmit Hazay and Yehuda Lindell. Efficient Secure Two-Party Protocols
- Techniques and Constructions. Information Security and Cryptography.
Springer, 2010.
Lin17. Yehuda Lindell. Fast secure two-party ECDSA signing. In Annual
International Cryptology Conference, pages 613–644. Springer, 2017.
LN18. Yehuda Lindell and Ariel Nof. Fast secure multiparty ECDSA with
practical distributed key generation and applications to cryptocurrency
custody. In CCS, pages 1837–1854. ACM, 2018.
Mak22. Nikolaos Makriyannis. On the classic protocol for MPC schnorr signatures.
IACR Cryptol. ePrint Arch., page 1332, 2022.
Mau15. Ueli Maurer. Zero-knowledge proofs of knowledge for group
homomorphisms. Designs, Codes and Cryptography, 77:663–676, 2015.
MOR14. Tal Moran, Ilan Orlov, and Silas Richelson. Topology-hiding computation.
Cryptology ePrint Archive, Paper 2014/1022, 2014. https://eprint.
iacr.org/2014/1022.
Pai99. Pascal Paillier. Public-Key Cryptosystems Based on Composite Degree
Residuosity Classes. In Jacques Stern, editor, EUROCRYPT, volume 1592,
pages 223–238. Springer, 1999.
Ped91. Torben P. Pedersen. Non-interactive and information-theoretic secure
verifiable secret sharing. In Joan Feigenbaum, editor, CRYPTO, volume
576 of Lecture Notes in Computer Science, pages 129–140. Springer, 1991.
Tas07. Tamir Tassa. Hierarchical threshold secret sharing. J. Cryptol., 20(2):237–
264, 2007.
WMYC23. Harry W. H. Wong, Jack P. K. Ma, Hoover H. F. Yin, and Sherman S. M.
Chow. Real threshold ECDSA. In NDSS. The Internet Society, 2023.
ZYP23. Guy Zyskind, Avishay Yanai, and Alex ’Sandy’ Pentland. Unstoppable
wallets: Chain-assisted threshold ECDSA and its applications. IACR
Cryptol. ePrint Arch., page 832, 2023.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 33

A Additional Runtime Results

Note that the runtime for the user does depend on the number of parties since as
of now we do not know how to aggregate Bulletproofs. As mentioned in the paper,
one can opt using an AHE scheme that support a plaintext space equivalent to
the ECDSA group, thereby avoiding the use of range proofs, which will turn the
user runtime independent of the number of parties.

Fig. 4: (a) Fig. 5: (b)

Fig. 6: Runtime for our key-generation (a) and presignature (b) protocol for various
number of parties, n and threshold t.

B Additively Homomorphic Encryption

The formal definition of AHE below are inspired from [CHI+ 21] and [BPMW16].
We first describe the non-threshold version which is used in the two party
protocol, and later show its extension to the threshold security model.
Definition B.1 (AHE) An additively homomorphic encryption scheme is associated
with an ensemble {Kκ }κ and consists of four polynomial time algorithms: AHE =
(Gen, Enc, Dec, Add) specified as follows:
– Gen(1κ , aux) → (pk; sk). A probabilistic algorithm that is given a security
parameter 1κ and possibly some auxiliary information aux and samples a
key-pair (pk, sk) from Kκ . In the following, we assume that the resulting pk
contains the description of the security parameter 1κ , the auxiliary information
aux, as well as the plaintext, randomness and ciphertext spaces Ppk , Rpk and
Cpk , respectively, where Ppk is a Z-module.
In addition, for the purpose in this paper we require an AHE scheme to be
associated with a language LGenAHE [κ] = {pk; aux | (pk; sk) = Gen(1κ , aux)}
(see Eq. 10) that expresses the fact that pk was generated correctly.
– Enc(pk, pt; ηenc ) → ct. A deterministic algorithm that on input a public key
pk, a plaintext pt ∈ Ppk and randomness ηenc ∈ Rpk , outputs a ciphertext
ct ∈ Cpk . We define Enc(pk, pt) as a probabilistic algorithm that first uniformly
samples ηenc ∈ Rpk and then outputs ct = Enc(pk, pt; ηenc ) ∈ Cpk .
34 Authors Suppressed Due to Excessive Length

– Dec(sk, ct) → pt. A deterministic algorithm that on input a secret key sk

and a ciphertext ct ∈ Cpk outputs a plaintext pt ∈ Ppk .
– Add(pk, ct1 , ct2 ) → ct3 . A deterministic algorithm that on input a public
key pk and two ciphertexts ct1 , ct2 ∈ Cpk outputs a ciphertext ct3 ∈ Cpk
such that if ct1 = Enc(pk, m1 ; η1 ) and ct2 = Enc(pk, m2 ; η2 ) then ct3 =
Enc(pk, m1 + m1 ; η1 + η2 ), where m1 + m2 and η1 + η2 are over Ppk and Rpk ,
respectively. Imposing correctness will ensure that Add is a homomorphic
addition. Note that efficient homomorphic scalar multiplication is implied by
the Add operation (e.g., via double-and-add).

For brevity, we may write P and C instead of Ppk and Cpk when the public
key pk is clear from the context. In addition, we denote homomorphic addition
of two ciphertexts ct1 and ct2 by ct1 ⊕ ct2 and a multiplication of a ciphertext
ciphertext ct by a scalar α by α ⊙ ct.
Every affine function can be efficiently computed homomorphically by an
algorithm Eval(pk, f, ct1 , . . . , ctℓ ; ηeval ). Whenever we omit the randomness in
Eval(pk, f, ct1 , . . . , ctℓ ), we refer to the process of sampling a randomness ηeval ←
{0, 1}poly(κ) and running Eval(pk, f, ct1 , . . . , ctℓ ; ηeval ). Given a public key pk, an
Pℓ
affine function f (x1 , . . . , xℓ ) = a0 + i=1 ai xi (with ai ∈ Z and ℓ, ∥ai ∥2 ∈ poly(κ)
for all 0 ≤ i ≤ ℓ) and ℓ ciphertexts ct1 , . . . , ctℓ ∈ C, Eval outputs a ciphertext ct.

Definition B.2 (Correctness) AHE is correct if for every κ, every t ∈ poly(κ),

every ℓ-ary affine function f as above, and every plaintexts pt1 , . . . , ptt ∈ P,

Pr[Dec(sk, Eval(pk, f, (ct1 , . . . , ctℓ ))) = f (pt1 , . . . , ptℓ )] ≥ 1 − neg(κ)

where (pk, sk) ← Gen(1κ ) and cti ← Enc(pk, pti ), and the probability is over the
coins used by algorithms Gen, Enc and Eval.
Lℓ
Note that for correctness, algorithm Eval may simply output ct = Enc(pk, a0 ) i=1 ai ⊙ cti ,
however, such an algorithm may not satisfy secure function evaluation (see
below).

Definition B.3 (Semantic security) AHE is semantically secure if for every

PPT adversary A there exists a PPT algorithm S such that for every pair of
PPTs f, h : {0, 1}∗ → {0, 1}∗ , and every pt ∈ P:
| Pr[A(1κ , Enc(pk, pt), 1|pt| , h(1κ , pt)) = f (1κ , pt)]
(21)
− Pr[S(1κ , 1|pt| , h(1κ , pt)) = f (1κ , pt)] | < neg(κ)

where (pk, sk) ← Gen(1κ ) and h refers the auxiliary information function in
possession of the adversary. The probability is over the random coins of Gen and
Enc.

Definition B.4 (Secure Function Evaluation) AHE has secure function evaluation
if there exists a PPT algorithm SEval such that for every PPT adversary A, every
ℓ-ary affine function f as above, every (pk, sk) and every plaintexts pt1 , . . . , ptℓ ∈
P and randomness η1 , . . . , ηℓ ,
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 35

| Pr[A(1κ , pk, sk, {pti , ηi }ℓi=1 , Eval(pk, f, (ct1 , . . . , ctℓ ))) = 1]

(22)
− Pr[A(1κ , pk, sk, {pti , ηi }ℓi=1 , SEval (pk, f (pt1 , . . . , ptℓ ))) = 1]| ≤ neg(κ)

where cti ← Enc(pk, pti ; ηi ), and the probability is over the coins used by Eval
and the random coins of A and S.

An alternative formulation to the secure function evaluation property using

Experiment 8 is given below. One can show equivalence between the two definitions.
Definition B.5 (Secure Function Evaluation (Experiment)) AHE has secure
function evaluation if there exists a PPT algorithm SEval such that for every PPT
adversary A, we have Pr[ExpA,SEval (1κ ) = 1] ≤ 21 + neg(κ).

Secure Function Evaluation ExpA,SEval (1κ )

EXPERIMENT 8

1. A(1κ ) outputs (pk, sk), ℓ, {pti , ηi }ti=1 , f where (pk, sk) is an AHE’s key-pair,

{pti , ηi }ℓi=1 are plaintexts and randomness from which one can obtain ciphertexts
ct1 , . . . , ctℓ , and f is a ℓ-ary affine function as above (with coefficients chosen by
A).
2. The experiment picks b ← {0, 1} uniformly at random, then
– if b = 0: compute ctEval = Eval(pk, f, (ct1 , . . . , ctℓ )), where cti =
AHE.Enc(pk, pti ; ηi ) for all i,
– if b = 1: compute ctEval = SEval (pk, f (pt1 , . . . , ptℓ )).
3. Hand ctEval to A and receive the bit b′ .
4. Output 1 if b = b′ and 0 otherwise.

C Standard Definitions
Some definitions that are standard in the literature are provided in this section
for completeness.

C.1 Commitments and homomorphic commitments

Definition C.1 (Batch Commitment) A non-interactive commitment scheme
consists of a pair of PPT algorithms (Setup, Com). The setup algorithm pp ←
Setup(G, G, q, T ), where T ∈ N, outputs the spaces Mpp = ZTq , Rpp = Zq and
Cpp = G as well as a generators H1 , . . . , HT . The commitment algorithm Compp
defines a function Mpp × Rpp → Cpp for message space Mpp , randomness space
Rpp and commitment space Cpp . For a message m ⃗ ∈ Mpp , the algorithm draws
ρ ← Rpp uniformly at random, and computes commitment C = Compp (m; ⃗ ρ).
Whenever the public parameters are clear from the context we write Com instead
of Compp .
A commitment schemes has hiding and binding properties as follows:
36 Authors Suppressed Due to Excessive Length

– Perfect hiding. For every adversary A, every pp ← Setup(·) and every m ⃗1∈
⃗ 0, m
Mpp
1
Pr[A(m⃗ 0, m ⃗ b ; ρ)) = b] = ,
⃗ 1 , Com(m
2
where the probability is under a uniform choice of b ∈ {0, 1} and ρ ∈ Rpp .
– Computational binding. For every PPT adversary A and every pp ← Setup(·),

Pr[(m ⃗ 1 , ρ0 , ρ1 ) ← A(pp) : m
⃗ 0, m ⃗ 0 ̸= m
⃗ 1 ∧Com(m ⃗ 1 ; ρ1 )] ≤ neg(κq )
⃗ 0 ; ρ0 ) = Com(m

where κq is a computational security parameter associated with q, and the

probability is under the random coins of A. The above assumes m ⃗1 ∈
⃗ 0, m
Mpp and ρ0 , ρ1 ∈ Rpp .

Definition C.2 (Batch Homomorphic Commitments) A homomorphic commitment

scheme is a non-interactive commitment scheme such that M, R and C are all
abelian groups, and for all m ⃗ 2 ∈ M, ρ1 , ρ2 ∈ R we have (in the following,
⃗ 1, m
‘+’ is defined differently for each group):

Com(m
⃗ 1 ; ρ1 ) + Com(m
⃗ 2 ; ρ2 ) = Com(m
⃗1+m
⃗ 2 ; ρ1 + ρ2 )

C.2 Zero Knowledge Proofs

R
The functionality is denoted by Fzk , and formally defined in Functionality 9 and
its batched version in Functionality 10.
The notation we use to describe the relations follows: the language associated
with relation R is the set LR = {x | ∃w : (x, w) ∈ R}; we write L[params] =
{S; s | f (params, S, s)} to denote a language {x | ∃s : f (params, S, s) = 1} where
params typically refers to global parameters (e.g., a public-key of an encryption
scheme, or a global verification key), S refers to a set of public values and s refers
R
to a set of secret values. Note that in Fzk (Functionality 9) we implicitly require
‘knowledge’ of the witness s from the prover P . Note that we may omit params
from the description of the languages when they are clear from the context.

R


FUNCTIONALITY 9 Zero-Knowledge: Fzk
The functionality interacts with a prover P and a set of verifiers V1 , V2 , . . . (in the
two-party case there is one verifier V).

– Upon receiving (prove, sid, ssid, x; w) from P, if (x, w) ∈

/ R or (sid, ssid, ·, ·) has been
previously called then ignore the message. Otherwise, send (proof, sid, ssid, x) to
the verifiers.

As in [Lin17], in addition to the zero-knowledge functionality, we make use of

a committed zero-knowledge proof, defined by Functionality 11. This functionality
can be simply implemented by combining a commitment scheme with the ideal
zero-knowledge functionality.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 37

R


FUNCTIONALITY 10 Batched Zero-Knowledge: Fbatch−zk
The functionality interacts with a prover P and a set of verifiers V1 , V2 , . . . (in the
two-party case there is one verifier V).

– Upon receiving (prove, sid, ssid, B, ⃗ ⃗ where B is the batch size, from P, if
x; w),
(xi , wi ) ∈
/ R for some i ∈ [B] or (sid, ssid, ·, ·) has been previously called then
ignore the message. Otherwise, send (proof, sid, ssid, B, ⃗ x) to the verifiers.

R


FUNCTIONALITY 11 Committed Zero-Knowledge: Fcom−zk
The functionality interacts with a prover P and a verifier V.

– Upon receiving (com–prove, sid, ssid, x; w) from P, if (x, w) ∈ / R for some i or

(sid, ssid, ·, ·) has been previously called then ignore the message. Otherwise, store
(sid, ssid, x; w) and send (receipt, sid, ssid) to V.
– Upon receiving (decom–proof, sid, ssid) from P, if (sid, ssid, x; w) has been stored
then send (decom–proof, sid, ssid, x) to V.

C.3 Proof Aggregation

When the relation R is associated with a homomorphism (x; w) ∈ R ⇐⇒

ϕ(w) = x, one can define an aggregated version of a zero-knowledge proof, as in
Functionality 12. The aggregated functionality gets a witness wi for each instance
xi ,P
such that ϕ(wi ) = xi , and by the homomorphic property of ϕ, concludes that
ϕ( i wi ) = ⊕i xi = x. It then sends (proof, x) to the verifier. If any of the
proofs fail the functionality alerts the corresponding set of malicious parties, to
support identifiable abort.

R


FUNCTIONALITY 12 Aggregated Zero-Knowledge: Fagg−zk
The functionality interacts with a set of provers {P1 , . . . , Pn }, and a verifier V.

– Upon receiving (prove, sid, i, xi ; wi ) from Pi for each 1 ≤ i ≤ n

– If (sid, i, ·, ·) has been previously called for some i ignore the message.
– Let U ′ be the set of all provers for which (xi , wi ) ∈ / R. If MP ̸= ∅, send
(malicious, sid, U ′ ) to the verifier, otherwise, send (proof, sid, i xi ) to the
verifiers.

C.4 Statistical Distance

Definition C.3 (Statistical Distance) Let X, Y : Ω → [M ] be two random

variables. The statistical distance between X, Y , denoted SD(X, Y ), is
X
SD(X, Y ) := | Pr[X = w] − Pr[Y = w]|
w∈Ω
38 Authors Suppressed Due to Excessive Length

Lemma C.4 Let X = (X1 , . . . , Xn ) be mutually independent n random variables,

and also Y = (Y1 , . . . , Yn ) be mutually independent random variables. Then
SD[X, Y ] ≤ SD[X1 , Y1 ] + . . . + SD[Xn , Yn ].

Proof. We prove by induction on n. Consider n = 2:

X
SD[(X1 , X2 ), (Y1 , Y2 )] := |Pr[X1 = α1 ] · Pr[X2 = α2 ] − Pr[Y1 = α1 ] · Pr[Y2 = α2 ]|
α=(α1 ,α2 )
X
= |Pr[X1 = α1 ] · Pr[X2 = α2 ] − Pr[Y1 = α1 ] · Pr[X2 = α2 ] +
α=(α1 ,α2 )

Pr[Y1 = α1 ] · Pr[X2 = α2 ] − Pr[Y1 = α1 ] · Pr[Y2 = α2 ]|

X
≤ Pr[X2 = α2 ] · |Pr[X1 = α1 ] − Pr[Y1 = α1 ]| +
α=(α1 ,α2 )
X
Pr[Y1 = α1 ] · |Pr[X2 = α2 ] − Pr[Y2 = α2 ]|
α=(α1 ,α2 )

= SD[X1 , Y1 ] + SD[X2 , Y2 ]

Then, by induction hypothesis:

SD[X, Y ] ≤ SD[X1 , Y1 ]+SD[(X2 , . . . , Xn ), (Y2 , . . . , Yn )] ≤ SD[X1 , Y1 ]+. . .+SD[Xn , Yn ]

D Instantiating AHE with Paillier’s Encryptioin Scheme

In this section we present a definition of the scheme Paillier = (Gen, Enc, Dec, Eval).
Note that we modify the original Paillier definition [Pai99]

– Gen(1κ , q). Given a security parameter 1κ and a prime q, sample poly(κ)-bit

primes p1 and p2 and output (N ; (p1 , p2 )) where N = p1 · p2 is the public
encryption key and sk = (p1 , p2 ) is the secret key. Although we acknowledge
that the actual plaintext space is ZN , we define a different, ‘virtual’, plaintext
space as needed by the application; in our case it is Zq . Define P = (Zq , +),
R = (Z∗N , ·) and C = (Z∗N 2 , ·).
The function Dec below expresses the scheme’s homomorphism Decsk :
Z∗N 2 → Zq where Decsk (ct) = Dec(sk, ct), such that Decsk (x1 ·x2 ) = Decsk (x1 )+
Decsk (x2 ) mod q.
The scheme is associated with the the language LGenPal , as defined below,
that expresses the validity of a Paillier public key. As argued in [Lin17], the
following language suffices for the purpose in this paper, although it does
not completely expresses a honest execution of Paillier.Gen().

LGenPal [κ] = {N ; ϕ(N ) | gcd(N, ϕ(N )) = 1} (23)

– Enc(pk, x; η). Given the public key N , a message x ∈ Zq and randomness

η ∈ Z∗N , output ct and PT, where

ct = (1 + N )x · η N mod N 2
 
and PT = q.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 39

The algorithm outputs PT ∈ N in order to keep track on the upper bound

of the underlying plaintext, before applying a reduction modulo q (see the
algorithm Dec below). This is necessary for security as we need that value
to never exceed N , which is used in the underlying Paillier scheme.
Note that we may omit an explicit mentioning of the upper bound output
of Enc when it does not impact the presentation.
– Dec(sk, ct). Given the secret key (p1 , p2 ) and a ciphertext ct, compute N =
p1 · p2 and output
 ϕ(N )
mod N 2 ] − 1

[ct
pt = · ϕ(N )−1 mod N mod q.
N
– Add(pk, ct1 , ct2 ). Given the public
 key N and two ciphertexts ct1 and ct2 ,
output ct3 = ct1 · ct2 mod N 2 . 
Indeed,
 if ct1 = Enc(x1 ; η1 )= (1 + N )x1 · η1 N mod N 2 and ct2 = Enc(x2 ; η2 ) =
(1 + N )x2 · η2 N mod N 2 then ct3 = (1 + N )x1 +x2 · (η1 η2 )N mod N 2 =
Enc(x1 + x2 mod N ; η1 · η2 mod N ). So if Dec(sk, ct1 ) = x′1 = x1 mod q
and Dec(sk, ct2 ) = x′2 = x2 mod q then Dec(sk, ct3 ) = x1 + x2 mod q.

As a reminder, we need to specify the Eval algorithm, and show that it

satisfies the secure function evaluation property in Eq. 1. The technique was
implicitly introduced in [GGN16], yet we highlight it here explicitly. The idea
is that, simply using ⊕, ⊙, we get an encryption of the correct value as long as
f (pt1 , . . . , ptℓ ) < N over the integers. However, simply using ⊕, ⊙ may reveal
more information about f than desired. To this end, the Eval algorithm uses
randomness, by both adding a sufficiently large random multiple of q and homomorphically
adding a fresh encryption of a0 . Then, as long as f (pt1 , . . . , ptℓ ) < N this does
not change the value f (·) mod q, and statistically hides f . In our protocols,
we make sure that f (pt1 , . . . , ptℓ ) < N using zero-knowledge (range) proofs.
Formally:
Definition D.1 (Eval) On input a public key N , an affine function f (x1 , . . . , xℓ ) =
Pℓ
a0 + i=1 ai xi where ai ∈ [0, q), and ℓ ciphertexts ct1 , . . . , ctℓ , let PTi be the
upper bound associated with cti (that is, this is the maximal value one obtains
from decrypting cti , but without reducing modulo q), then algorithm Eval outputs
(ct, PT), where
ℓ
M
ct = Enc(pk, a0 + ωq; η) (ai ⊙ cti )
i=1
Pℓ
where ω is uniformly chosen from [0, 2s i=1 PTi ) and η is uniformly chosen
from Z∗N . The upper bound associated with the resulting ct is
ℓ
X
PTeval = q + (2s + 1) · q · PTi
i=1

Theorem D.2 If the decisional composite residuosity problem is hard relative

to Paillier.Gen, then the Paillier encryption scheme is semantically-secure as per
40 Authors Suppressed Due to Excessive Length

Definition B.3. In addition, algorithm Eval in Definition D.1 is a secure function

evaluation as per definition 2.1 for the Paillier encryption scheme.
Proof.

Correctness. For every κ, every ℓ, every ℓ-ary affine function f with coefficients
in [0, q), and every plaintexts pt1 , . . . , ptℓ ∈ Zq such that pti = Dec(sk, cti ), let
PTi be the upper bound associated with cti (again, this is the maximal value
one obtains from decrypting cti , but without reducing modulo q), as long as
PTeval < N we have:
ℓ
!
M
Dec(sk, Eval(pk, f, (ct1 , . . . , ctℓ ))) = Dec sk, Enc(pk, a0 + ωq; η) (ai ⊙ cti )
i=1
ℓ ℓ
!
X Y
ai
= Dec sk, Enc(pk, a0 + ωq + ai pti ; η · (ηi ) )
i=1 i=1
ℓ
X
= a0 + ωq + ai pti
i=1
= f (pt1 , . . . , ptℓ ) mod q
where the first equality
Pℓ holds by our definitionPℓ of Eval;
Pℓthe second equality holds
because a0 +ωq + i=1 ai pti < q +q2s i=1 PTi +q i=1 PTi = PTeval < N ; the
third equality follows from the correctness of decryption of the original Paillier
encryption; and the forth equality holds by definition of f and the fact that ωq
mod q = 0.
Semantic security. Consider a trivial reduction from an adversary A breaking the
CPA-security game for the modified Paillier scheme to an adversary A′ breaking
the CPA-security game for the original scheme. When A′ gets a random public
key pk ′ = N , it sets pk = (N, q), and queries A on pk, receiving m0 , m1 ∈ Zq ,
interpreting them as m0 , m1 ∈ [0, q). It then sends the two messages m0 , m1 , as
elements of ZN , receiving c′ = AHE.Enc(N ′ , mb ; η ′ ). Then A′ passes c′ to A and
outputs whatever A outputs. Clearly, since the encryption algorithms coincide
(only that our scheme considers a smaller plaintext space), the advantage of A′
exactly equal the advantage of A, which therefore cannot be small, assuming
DCR is hard.
Secure function evaluation. We now show that Eval is statistically secure function
evaluation. That is, for every ℓ-ary affine function f as above, every (pk, sk)
and every ciphertexts (ct1 , PT1 ), . . . , (ctℓ , PTℓ ) such that pti = Dec(sk, cti ), and
every randomness η1 , . . . , ηℓ ∈ R, we have SD(X, Y ) < 2−s for random variables
X, Y as follows
(X, PTeval ) = Eval(pk, f, (ct1 , . . . , ctℓ )) and
Y = S(pk, f (pt1 , . . . , ptℓ ), PTeval ),
and S(pk, f (pt1 , . . . , ptℓ ), PTeval ) = Enc(pk, f (pt1 , . . . , ptℓ )+ωq; η) for a uniformly
Pℓ
chosen ω ← [0, 2s i=1 PTi ) and η ← Z∗N . To see this, consider ai , pti as values
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 41

Pℓ
over the integers Z and let a0 + i=1 ai pti = ω̃ · q + f (pt1 , . . . , ptt ), where
Pℓ
ω̃ ∈ [0, i=1 PTi ) and 0 ≤ f (pt1 , . . . , ptt ) < q. Then,
1 X
SD(X, Y ) = |Pr[X = c] − Pr[Y = c]|
2 ∗
c∈Z
N2

1 X X
= |Pr[X = Enc(z; ηz )] − Pr[Y = Enc(z; ηz )]|
2 ∗z∈ZN ηz ∈ZN

1 X X
= Pr[X = Enc(f (pt1 , . . . , ptℓ ) + ωq; ηz )]
2 ∗
ηz ∈ZN
Pℓ
ω∈[0,2s i=1 PTi +ω̃)

− Pr[Y = Enc(f (pt1 , . . . , ptℓ ) + ωq; ηz )]

In the above, notice that we use Enc on input z ∈ ZN ; this is valid as we consider
z as the plaintext result of some evaluation operation, before reducing modulo
q, rather than a fresh ciphertext.
For every f, {pti , ηi }ℓi=1 and ω, it holds that ηx , ηy are independent, uniformly
distributed random variables (over Z∗N ), thus:
1 X
SD(X, Y ) = Pr[X = Enc(f (pt1 , . . . , ptt ) + ωq]
2 s
Pℓ
ω∈[0,2 i=1 PTi +ω̃)

− Pr[Y = Enc(f (pt1 , . . . , ptt ) + ωq)] .

Pℓ
Now, we divide the range [0, 2s i=1 PTi + ω̃) to three non-overlapping parts:
ℓ Pℓ Pℓ
I1 = [0, ω̃), I2 = [ω̃, 2s i=1 PTi ) and I3 = [2s i=1 PTi , 2s i=1 PTi + ω̃) and
P
separately calculate the statistical distance for each. By the definition of Eval
and S we get:

∀ω ∈ I1 : Pr[X = Enc(f (pt1 , . . . , ptt ) + ωq] = 0

and Pr[Y = Enc(f (pt1 , . . . , ptt ) + ωq)] = Pℓ1 ,
2s i=1 PTi

∀ω ∈ I2 : Pr[X = Enc(f (pt1 , . . . , ptt ) + ωq] = Pℓ1

2s i=1 PTi

and Pr[Y = Enc(f (pt1 , . . . , ptt ) + ωq)] = P1 ,

2s ℓi=1 PTi

∀ω ∈ I3 : Pr[X = Enc(f (pt1 , . . . , ptt ) + ωq] = s

Pℓ1
2 i=1 PTi
and Pr[Y = Enc(f (pt1 , . . . , ptt ) + ωq)] = 0.
Therefore, we get the following, which implies secure function evaluation as
per Equation 1
Pℓ
ω̃ i=1 PTi 1
SD(X, Y ) = Pℓ < P ℓ
= s
2 s
i=1 PTi 2 s
i=1 PTi
2
⊔
⊓
42 Authors Suppressed Due to Excessive Length

E Optimized Threshold Decryption

The realization of FTAHE is done using a tuple of algorithms (Gen, Enc, Add, TDec, Rec).
Gen, Enc, Add works similarly to the definition of AHE while TDec is an operation
that each party runs locally on the chiphertext and generate a decryption share.
Collecting t + 1 such decryption shares as inputs to Rec outputs a correct
decryption. Since the TDec operation is local typically one must add a ZK proof
that this was done correctly and verify all proofs before applying Rec to them.
Verifying these proofs, especially when the number of parties (hence t) is large,
can dominate the protocol’s run time. In addition, the combination in Rec itself
may be also very expensive, especially when the plaintext space is of unknown
order and so the secret decryption key is shared over the integers (as in Paillier).
One possible optimization is for one party to locally compute Rec and provide
a proof of correct recombination. Unfortunately, generation and verification of
such proofs is not efficient in general. But in the case when the encryption is
of a signature one may verify the correctness by verifying the signature. In this
section we formalize this intuition and show that in our signing protocol this is
in fact possible. Furthermore we show that in the context of this protocol it is
possible to forgo the ZK proofs when the signature validates and only use them
when it fails.
Let us first formalize the TAHE algorithms and its correctness and security
defintions.

Definition E.1 (TAHE) Threshold additively homomorphic encryption scheme

is associated with an ensemble {Kκ }κ and consists of five polynomial time algorithms
TAHE = (Gen, Enc, Add, TDec, Rec) specified as follows:

– Gen(1κ , i, t, n, aux) → (pk, ski ). A probabilistic (possibly interactive) protocol

that is given a security parameter 1κ , the number of parties n, a threshold
1 < t < n and possibly some auxiliary information aux and samples a key-
pair (pk, {sk}i∈[n] ) ∈ Kκ . In the following, we assume that the resulting pk
contains the description of the security parameter 1κ , the auxiliary information
aux, as well as the plaintext, randomness and ciphertext spaces Ppk , Rpk , Cpk ,
respectively, where Ppk is a Z − module.
– Enc(pk, pt; ηenc ) → ct. A deterministic algorithm that on input a public key
pk, a plaintext pt ∈ Ppk and randomness ηenc ∈ Rpk , outputs a ciphertext
ct ∈ Cpk . We define Enc(pk, pt) as a probabilistic algorithm that first uniformly
samples ηenc ← Rpk and then outputs ct = Enc(pk, pt; ηenc ) ∈ Cpk
– TDec(ski , ct) → cti . A deterministic algorithm that on input a secret key sk
and a ciphertext ct ∈ Cpk outputs a plaintext pt ∈ Ppk .
– Rec(S, {cti }i∈S ) → pt. A deterministic algorithm that on input of a set S ∈
[n]

S
t+1 and a tuple of elements {cti }i∈S ∈ Cpk outputs a elements pt ∈ Ppk .
– Add(pk, ct1 , ct2 ) → ct3 . A deterministic algorithm that on input a public key
pk and two ciphertexts ct1 , ct2 ∈ Cpk outputs a ciphertext ct3 ∈ Cpk .
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 43

Correctness. TAHE is correct if for every κ, every t ∈ poly(κ), every ℓ-ary affine
[n]


function f , any subset S ∈ t+1 and every plaintexts pt1 , . . . , ptt ∈ P,

Pr[Rec(S, {TDec(ski , Eval(pk, f, (ct1 , . . . , ctℓ )))}i∈S ) = f (pt1 , . . . , ptℓ )] ≥ 1−neg(κ)

where (pk, {ski }i∈[n] ) ← Gen(1κ ) and cti ← Enc(pk, pti ), and the probability is
over the coins used by algorithms Gen, Enc and Eval.
Semantic Security. TAHE is semantically secure if for every PPT adversary A
there exists a PPT algorithm S such that for every pair of PPTs f, h : {0, 1}∗ →
{0, 1}∗ , and every pt ∈ P.

| Pr[A(1κ ,Enc(pk, pt), 1|pt| , h(1κ , pt)) = f (1κ , pt)]

− Pr[S(1κ , 1|pt| , h(1κ , pt)) = f (1κ , pt)] | < neg(κ)

where (pk, {sk}i∈[n] ) ← Gen(1κ ) and h refers to the auxiliary information

function in possession of the adversary. The probability is over the random coins
of Gen and Enc.
Share Security. TAHE is said to be share secure if for every PPT adversary A
there exist a PPT algorithm S such that

| Pr[A(1κ ,{TDec(ski , ct)}i∈U

/ ) = 1]
− Pr[A(1κ , S(pt, {TDec(ski , ct)}i∈U )) = 1] | < neg(κ)

Where (pk, {ski }i∈[n] ) ← Gen(1κ ) and U ∈ [n]

t . This notation formalizes the
idea that the decryption shares do not admit any information on the shares ski
of the secret key.
Simulatable Key Generation. TAHE scheme is said to have a simulatable key
generation if the protocol Gen realizes the functinlaity Fkeygen . This functionality
is essentially the key generaiton command from the functionality FTAHE .
Language for correct formation of shares.

LTDec = {C, ct, cti ; ρ, ski | C = Com(ski , ρ)∧cti = TDec(ct, ski )∧ski ← Gen(1κ , i)}
LTDec
We assume that there exist a realization of Fzk .

E.1 The Protocol

Assume we have a TAHE scheme that is correct, semantically secure, share

secure, admits secure function evaluation and that Gen realizes the key generation
′ ′ ′ ′
functionality Fkeygen . We define a new protocol Πecdsa = (Πkeygen , Πpres , Πsign )
′
derived from protocols 4, 5 and 6, respectively, where Πpres = Πpres , with
the following modifications:
44 Authors Suppressed Due to Excessive Length

FUNCTIONALITY 13 TAHE Key Generation: FTAHE−keygen

interacts with parties B = (B1 , . . . , Bn ), an adversary A corrupting
The functionality
a set U ∈ [n]
t
of the parties, and a set of certifiers. It is parameterized by a TAHE
scheme TAHE = (Gen, Enc, TDec, Rec, Add), and a commitment scheme Com, with a
computational security parameter κ and with threshold parameter t ∈ [1, n − 1].

– Upon receiving (keygen, sid) from all parties in B, for a fresh sid,
samples (pk, {ski }i∈[n] ) ← Kκ , calculate Ci = Com(ski , ρi )i∈[n] send
(pk, {ski }i∈U , {ρi }i∈U ) to the adversary and receive the adversary’s
response (continue, U ′ ). If continue = 1 or U ′ ∩ U = ∅ then send
(pubkey, sid, pk, {Ci }i∈[n] ) to all parties in B.
– Upon receiving (certify, pk) from some certifier, if (·, pk; ·) is stored then return 1
to that certifier, otherwise return 0.

1. Key Generation. FTAHE is replaced with a call to FTAHE−keygen .

2. Sign. The two calls to TAHE with the decrypt command in Step 2c of
Protocol 6 are replaced as follows:
(a) Bi calculates decryption shares ctiA = TDec(ctA , ski ), cti4 = TDec(ct4 , ski )
and broadcasts ctiA and cti4 .
(b) Bi calculates i∗ = H(sid) mod (n). Then i∗ is the designated party
who will reconstruct the decrypted value out of the decryption shares.
If i = i∗ , Bi calculates ptA = Rec({ctiA }i∈S ) and pt4 = Rec({cti4 }i∈S ′ )
[n]
for S, S ′ ∈ t+1 . In addition, it calculate s′ = pt−1


4 · ptA mod q and
′ ′
s = min(s , q − s ) as done in Protocol 6.
(c) Bi verifies that (r, s) is a valid signature on msg and r = R|x−axis mod q
(where R previously obtained in the protocol), if so – broadcast s, upon
which every party applies the same verification. Otherwise continue to
the Fault Detection step below.
(d) Fault Detection.
i. Upon receiving s from i∗ if s ̸= ⊥ and (r, s) is not valid consider i∗
corrupted and abort. Otherwise (s = ⊥) continue.
ii. Send (Ci , ctA , ctiA ; ski , ρ) to Fzk
TDec
. Consider a party malicious if no
TDec
message is received from Fzk .

E.2 Proof

Again following Theorem 2.4, it is sufficient to prove G ∗ -simulatability, where

G ∗ is a signing oracle, and so we prove the following:

Theorem E.2 :

′ ′ ′ ′
Πecdsa = (Πkgen , Πpres , Πsign ) is G ∗ -simulatable (according to Definition 2.3)
in the (Fkeygen , Fzk , Fagg−zk , Fcom−zk )-hybrid and random oracle model.

Proof. Simulating the messages A sends Bi is the same since no changes occurred
′
between Πecdsa and Πecdsa regarding these messages. We thus focus on the case
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 45

were A is corrupted along with a subset U ∈ [n]

t of the parties. We will describe
the changes in the simulations. Simulations for Key Generation, Presign and sign
that is, 17,18 and 19 respectively.

1. General. Replace any calls to AHE with calls to TAHE.

2. Key Generation. We replace command 3.(b) in the original by the following:
Upon receiving (keygen, sid) from A on behalf of all Bi for i ∈ U emulate
Fkeygen . Generate (pk, {ski }i∈U , {ρi }i∈U ), send them to the adversary and
await it’s response (continue, U ′ ). If U ′ ∩U = ∅ send (newkey, sid, pk, {Ci }i∈[n] )
to all parties, otherwise abort.
3. Pre-sign This simulator is unchanged.
4. Sign We replace command 4.(c) with the following:
(a) In step 3.(c).(i), calculate ctiA = TDec(ctA , ski ), cti4 = TDec(ct4 , ski )
for i ∈ U . Call upon Sshares from the definition of Share Security to
generate ctiA , cti4 from ptA , {ctiA }i∈U and pt4 , {cti4 }i∈U respectively. Send
to the adversary (ctiA , cti4 )i∈U
/ .
(b) In step 3.(c).ii, upon receiving {ct ¯ iA , ct
¯ iA }i∈U if i∗ ∈ U the adversary
∗
should also send s or (abort). If i ∈ / U run Rec on some random subset
[n]


S ← t+1 of the decryption shares to get s. If S has s verify (r, s) is
valid, if it is not or abort was sent go to Fault Detection.
TDec
(c) Fault Detection. Emulate Fzk to send the adversary proofs of correct
generation of the shares for the honest parties. Further more consider
parties in U as cheaters if they sent ct ¯ i4 ̸= cti4 or ct
¯ iA ̸= ctiA .

First notice that from Semantic Security and Secure function evaluation of the
TAHE any messages generated by the original simulator by calls to AHE are still
indistinguishable in the new simulation. Further more notice that by Simulatable
Key Generation the messages sent during the key generation simulation are
indistinguishable. The only new messages except for fault detection are the
shares which are indistinguishable by the Share Security property of the TAHE.
All is left to show G ∗ simulatability is to prove that aborts happens in the real
world and the ideal world. Let us look at different cases:

1. Valid signature: If the signature is valid both the real and ideal worlds will
not abort. Furthermore since there is only one valid signature given that r
is constant there is no choice of decryption shares for the adversary that can
result in a different signature that is valid.
2. Invalid signature: If the signature is not valid i∗ ∈ U , in this case both
the real world and the ideal world will consider them cheaters and abort. If
i∗ ∈/ U we know by the simulation so far that a correct decryption would
have resulted in a correct signature. Thus the only way for a signature to
be invalid is for one of the decryption shares of the adversary to be invalid.
This will be caught in both the real and ideal world by the ideal functionality
TDec
Fzk .
46 Authors Suppressed Due to Excessive Length

F Ideal Functionality for Threshold Signature

Functionality 14 formalizes the ideal threshold signature scheme. The functionality

is parameterized with a set of signatories P = {P1 , . . . , Pn } and an efficiently
representable access structure Γ . In practice Γ will be either the threshold
access structure (t, n) or the hierarchical one 1 + (t, n). Both structures are
parameterized with t < n. In the former it is sufficient that t + 1 parties to
produce a signature and in the latter t + 1 as well as another designated parties
must collaborate.

G Proof of Theorem 2.4

We follow the same proof structure from [CMP20, BMP22]. Following [CMP20,
Lemma 7.3], we show that if protocol Π = (Πkeygen , Πpres , Πsign ) (in Protocols 4-
6) does not UC-realize Functionality 14 (Ftsig ), then there exists an environment
Z that can forge signatures for previously unsigned messages in an execution of
Π. As described in [CMP20, Section 7.4.1] and [BMP22], the simulator simply
runs the code of the honest parties as prescribed by Π, i.e. the simulator samples
all the secrets as prescribed and plays against the adversary in exactly the same
way as in the real execution. To interact with the functionality the simulator
proceeds as follows:

1. At the end of an execution of Protocol Πkeygen , the simulator sends the

obtained public key X, together with the ECDSA verification algorithm,V, to
the functionality. Then, the simulator sends to the functionality the expected
key confirmation on behalf of the malicious parties. If Πkeygen is halted for
any reason, then the simulator is instructed to halt as well.
2. At the end of an execution of Protocol Πsign the simulator sends the computed
signature σ = (r, s) to the functionality. (The simulator does not interact
with the functionality if it fails to calculate the signature, or during the
simulation of Πpres ).

The above simulation is perfect unless Z can cause the ideal functionality to
output an error (errors in the functionality appear in red color). There are three
potential errors in our extended functionality: (i) Identifier – the same public key
X was certified for two different sid’s 1(c)i; (ii) Uniqueness of signatures – the
same signature σ is provided for two different sid’s 2(c)ii; and (iii) Unforgeability
– a valid signature that was never recorded before, is sent for verification. In the
functionality, a verification of an unrecorded signature always returns β = 0
(Step 3b) exactly for that reason, to reflect the fact that the signature scheme
is unforgeable.
In the following we explain why any of the above error states is reached with
only a negligible probability.

1. Reaching the Identifier state is possible only in case the environment causes
the parties in the real world to reach to the same public key in two different
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 47

Γ


FUNCTIONALITY 14 Ideal Threshold Signature Functionality: Ftsig
Parameters: P = P1 , . . . , Pn is the set of signatories and Γ ⊆ 2P is an efficient
representation of a monotone access structure over P .

1. Key-generation:
(a) Upon receiving (keygen, ssid) from some party Pi , interpret ssid = (. . . , P ),
where P = (P1 , . . . , Pn ).
– If Pi ∈ P , send to S and record (keygen, ssid, Pi ).
– Otherwise ignore the message.
(b) Once (keygen, ssid, Pj ) is recorded for all Pj ∈ P , send (newkey, ssid) to the
adversary S and do:
i. Upon receiving (newkey, ssid, X, V) from S, record (ssid, X, V).
ii. Upon receiving (newkey, ssid) from Pi ∈ P , output (newkey, ssid, X) if
it is recorded.
(c) Once (ssid, X, V) is recorded, upon receiving (confirmkey, ssid) from each
Pi ∈ P :
i. If there is no set P ′ ∈ Γ for which all Pi ∈ P are corrupted, and there is
a record of (confirmkey, ssid′ , X, . . .) with ssid′ ̸= ssid, output an error.
(Identifier)
ii. Record (confirmkey, ssid, X, V).
2. Signing:
(a) Upon receiving (sign, sid = (ssid, . . .), m) from some party Pi , send to S and
record (sign, sid, m, i)
(b) Upon receiving (sign, sid = (ssid, . . .), m, j) from S, if Pj is corrupted record
(sign, sid, m, j).
(c) Once (sign, sid, m, i) is recorded for all Pi ∈ P ′ for some P ′ ∈ Γ , send
(sign, sid, m) to the adversary S and, upon receiving (signature, sid, m, σ)
from S,
i. If the tuple (sid, m, σ, 0) is recorded, output an error.
ii. If a tuple (sid′ , ·, σ, 1) is recorded, and there is no set P ′ ∈ Γ for which all
Pi ∈ P ′ are corrupted, then record (sid, m, σ, 0). (Uniqueness of signatures)
iii. Else, record (sid, m, σ, 1).
(d) Upon receiving (signature, sid, m) from Pi ∈ P :
i. If (sid, m, σ, 1) is recorded, output (signature, sid, m, σ) to Pi .
ii. Else ignore the message.
3. Verification:
Upon receiving (sig-verify, sid, m, σ, X) from a party X, send
(sig-verify, sid, m, σ, X) to S and do:
(a) If a tuple (sid, m, σ, β ′ ) is recorded, then set β = β ′ .
(b) Else (m was never signed), if there is no set P ′ ∈ Γ for which all Pi ∈ P ′ are
corrupted, set β = 0. (Unforgeability)
(c) Else (m was never signed and there is a corrupted set P ′ ∈ Γ ), set β =
V(m, σ, X).
Record (m, σ, β) and output (istrue, sid, m, σ, β) to X .

runs of Πkeygen that engage at least one honest party (not necessarily the
same honest party in both of them). We note that this protocol is input-less,
and depends only on the random tape of the parties, which, by examining the
48 Authors Suppressed Due to Excessive Length

protocol description. Specifically, each honest party Pi picks an independent

uniform share xi on every protocol run. Consider the list of all xi ’s that
were ever generated by all honest parties Pi ’s, then with overwhelming
probability this list has no repeating value. Now, the protocol guarantees
an independence choice of the xi ’s between all parties (even the corrupted
ones) for a specific run, by the invocation of Fcom−zk in the first step. Thus,
at the end of the first step the future resulting secret key is guaranteed to
be uniformly distributed, or the protocol aborts, in which case no key is
generated. Since the public key space is isomorphic to the secret key space,
and the generated secret key at each run of Πkeygen involves at least one
independent uniformly chosen share xi then the resulting secret key (and
hence public key) is unique.
2. Reaching the Uniqueness of signatures state is possible only in case the
environment causes the parties in the real world to reach to the same signature,
on different runs of (Πpres , Πsign ) (potentially, on different session id’s). Following
the same argument above (but now referring to values ki ’s in Protocol Πpres ),
we get that this is only happening with negligible probability.
3. We argue that reaching the Unforgeability state is possible only in case the
adversary managed to forge a signature for a message that was never signed.
Suppose that an adversary A outputs a forgery in the real world (where
executing Π, potentially concurrently many times, under the ‘orchestration’
of Z), then, we construct another adversary A′ that is given a public key X
and works as follows: A′ runs A and Z internally and do as follows. Whenever
Z invokes Πkeygen , except one special time, our adversary A′ simulates the
honest parties and together with A they generate a public key. At the special
time, A′ uses the simulatability of Π to produce a key identical to that of its
input, namely X. From that point and on, A′ simulates the honest parties
at all protocol instances (either key generation or sign). If A at any point
outputs a valid signature under the X key for a message that was never
signed, then A′ uses it as its forgery. If A forges a signature with a non-
negligible probability then, since A picks the instance of Πkeygen for which it
injects X at random, and since the number of instances is polynomial in κ,
and since the adversary cannot distinguish between the simulation of these
instances, the probability that A forges a signature under X (and hence A′
forges a signature under X as well) is non-negligible.

H Security 2PC-MPC

Following Theorem 2.4, it is sufficient to prove G ∗ -simulatability for the 1 + n

protocol, where G ∗ is a signing oracle, and so we prove the following:

Theorem H.1 Πecdsa = (Πkgen , Πpres , Πsign ) (Protocols 4, 5 and 6) is G ∗ -simulatable

(according to Definition 2.3) in the (FTAHE , Fzk , Fagg−zk , Fcom−zk )-hybrid and
random oracle model, assuming Com is computationally binding and AHE is
a semantically secure encryption scheme with secure function evaluation.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 49

We separate the proof into two cases: in the first case all Bi ’s are corrupted
and A is honest, and in the second case A as well as n−1 of the Bi ’s are corrupted.
We note that a similar simulation will go through for a weaker adversary, who
corrupts less n or n − 1 parties of B, respectively.
Case 1: A is Honest The formal simulation is presented in Simulations 15-16.
To show that the simulation is indistinguishable from the real protocol, we
define two hybrids where the first hybrid coincides with the simulation (Figures
15-16) and the second hybrid coincides with the real execution. Namely:
1. Hybrid1 is similar to the simulation in Figures 15-16, except that S emulates
G ∗ locally (instead of using G ∗ as an oracle).
2. Hybrid2 is similar to Hybrid1 except that, in Step 3 in Simulation 16
the simulator S computes ctA ← AHE.Eval(pk, fA , ctkey ) using the correct
fA and ctkey , where fA ’s coefficients a0 , a1 are determined by the correct
values xA and kA . S can do this because now (when emulating G ∗ locally) it
has access to these secrets. In that case, S knows xA since it generates the
LEncDL
secret signing key x and receives B’s share when B calls Fzk in Step 3 in
Simulation 15, then, it computes xA = x − xB mod q; in addition S knows
kA since it generates the secret nonce k and receives B’s share when B calls
LDL
Fagg−zk in Step 4(a)ii in Simulation 15, then S computes kA = k −1 · kB .
Hybrid1 is identically-distributed to the simulation (in Figures 15-16) since
the only difference is that in the simulation G ∗ ’s random tape is used to sample
the secret key (which determines the public key) and the nonce, whereas in the
hybrid this is done by the simulator. Nevertheless, in both cases these values are
sampled from the exact same distribution. Note that G ∗ also produces signatures
on messages of the adversary’s choice, however, a signature is fully determined
by the message, the secret key and the nonce.
Hybrid1 and Hybrid2 are computationally indistinguishable. We reduce
indistinguishability between the two hybrids to the secure function evaluation
property (Definition B.5) of the AHE scheme: Let A be an adversary that
distinguishes between Hybrid1 and Hybrid2 with probability ϵ. We construct
an adversary A′ that breaks the secure function evaluation property with the
same probability as follows: Run Hybrid1 above except of the following modification.
In Step 3 under command Πsign in Simulation 16, engage in Experiment 8 by
handing ((pk, sk), ℓ = 1, {pt = xB , η}, f (x) = fA ) to the experiment, where xB , η
and fA ’s coefficients are extracted as explained above. Receive ciphertext ctEval
from the experiment and use ctA = ctEval for the rest of the simulation. Run
A with the resulting simulation and respond to the experiment with whatever
bit that A outputs. Observe that if the experiment’s bit is 0 then the resulting
simulation is distributed identically to Hybrid1 and if the bit is 1 then the
resulting simulation is distributed identically to distributed Hybrid2. Therefore,
A′ breaks AHE’s secure function evaluation with the same probability as A
distinguishes between Hybrid1 and Hybrid2, namely, with probability ϵ. Since
AHE has secure function evaluation, this means that ϵ ∈ neg(κ).
Finally, it is easy to see that Hybrid2 is identical to the real execution, where
S takes the role of the uncorrupted party A and runs A internally. Note that the
50 Authors Suppressed Due to Excessive Length

real-execution is run in the (FTAHE , Fzk , Fagg−zk , Fcom−zk )-hybrid model, which
are perfectly simulated. We stress that this hybrid is identically distributed to
the real execution even though in Step 2 under command Πpres in Simulation 15
the simulator commits to zero instead of the correct value, as Com is a perfectly
hiding commitment scheme. ⊔
⊓

H.1 Case 2: Bi (i ∈ [n]) is Honest

In this case we consider an adversary A who corrupts party A as well as n − 1

parties in B. The simulator is presented in Simulations 17,18 and 19.
We define the following hybrids where Hybrid1 coincides with the simulation
(Figures 17,18 and 19) and Hybrid7 coincides with the real execution. Note that
in Hybrid1 all the ciphertexts ctkey , ct1 , ct2 , ct3 , ct4 are decrypted to zero. These
values are gradually replaced with correct values as we transit from Hybridi to
Hybridi + 1. The correct values are known to the simulators in the hybrids as
the simulator takes the role of G ∗ instead of using it as an oracle. This does not
change the distribution of the values as the simulator samples the key and the
presignature as well as computes the signature exactly the same as G ∗ would. In
more detail:

1. Hybrid1 is similar to the simulation in Figures 17,18 and 19, except that
S emulates G ∗ locally (instead of using G ∗ as an oracle).
2. Hybrid2 is similar to Hybrid1 except that, S encrypts the correct value
xB instead of zero in Step 3c in Simulation 17. S can do this because it now
that it emulates G ∗ locally, it has access to these secrets.
3. Hybrid3 is similar to Hybrid2 except that in Step 4(a)iii in Simulation
j
18, S picks its own γi ∈ [0, q), computes cti1 = AHE.Enc(γi ; ηmask 1
) and then
L j
outputs ct1 = j∈[n] ct1 instead of an encryption of zero (recall that ⊕ is
the homomorphic addition operation of the AHE scheme).
4. Hybrid4 is similar to Hybrid3 except that in Step 4(a)iii in Simulation 18,
S computes cti2 = AHE.Eval(pk, fi , ctkey ; ηmask
i
2
) where fi (x) = γi · x, and
L j
then outputs ct2 = j∈[n] ct2 instead of an encryption of zero.
5. Hybrid5 is similar to Hybrid4 except that in Step 4(a)iv in Simulation 18,
S computes cti2 = AHE.Eval(pk, fi , ctkey ; ηmask
i
2
) where fi (x) = γi · x, and
L j
then outputs ct2 = j∈[n] ct2 instead of an encryption of zero.
6. Hybrid6 is similar to Hybrid5 except that in Step 4(a)iv in Simulation
18, S computes cti4 = AHE.Eval(pk, fi′ , ct1 ; ηmask
i
4
) where fi′ (x) = ki · x, and
L j
then outputs ct4 = j∈[n] ct4 instead of an encryption of zero.
7. Hybrid7 is similar to Hybrid6 except that in Step 4b in Simulation 19, S
computes pt4 = γkB mod q and ptA = kA · γ(r · x + m) mod q.

Hybrid1 and Hybrid2 are computationally indistinguishable – distinguishing

the two reduces to breaking the CPA-security of the encryption scheme AHE.
Indeed, consider an adversary A′ engaged in the CPA-security game of AHE.
Adversary A′ gets a random public key pk ′ , sends two messages m0 = 0 and
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 51

m1 ← Zq to the experiment, and receives back a ciphertext ct′ ← AHE.Enc(pk, mb ).

Then, A′ uses S from Hybrid1 with the following changes:
1. Instead of generating new AHE key pair, it uses pk = pk ′ and ctkey = ct′
from the CPA-security game.
2. It uses XB = m1 · G.
Then, if b = 0, the view of A′ is identically distributed to Hybrid1, whereas
if b = 1, the view of A′ is identically distributed to Hybrid2. Therefore,
any advantage of A′ in distinguishing the to hybrids directly translates to an
advantage in the CPA-security game. Since AHE is semantically secure (which
is equivalent to CPA-security), we conclude that the distributions of the two
hybrids are computationally indistinguishable.
Then for all i = 2, . . . , 6 we have that Hybridi is indistinguishable from
Hybridi + 1 as distinguishing the two is reduced to the security of secure
function evaluation property of the AHE scheme, similar to the reduction presented
in the case of honest A above. Finally, it is easy to see that Hybrid7 is identically
distributed to the real execution of the protocol.

I The Two Party Protocol

We consider two parties, Alice and Bob, denoted by A and B respectively.
Looking ahead, party B can be simulated by a set of n parties. Alice and Bob hold
a common reference string sid ∈ {0, 1}∗ called the session identifier. Moreover,
they have public identities pidA , pidB , respectively.

I.1 Key Generation

The key-generation protocol is formally described in Protocol 20. The parties
run a protocol to obtain a random group element X ∈ G as the public key,
for which they will hold an additive sharing xA + xB = x where X = x · G.
This works by A choosing a random integer xA ← Zq and computing the group
element XA = xA · G. Party A then commits to XA and the fact that it knows
LDL
its discrete log x, using the Fcom−zk functionality. Party B then samples its own
share xB ← Zq , computes XB = xB · G and sends XB to A, along with a proof
of knowledge of xB . Next, party A verifies the proof (and aborts if verification
fails), and then decommits to XA and its proof of knowldege, which is verified
by B. At this stage, both parties can compute and store the ECDSA verification
key X = XA + XB = (xA + xB ) · G = x · G.
In addition to the above steps, B generates its own AHE key-pair (pk, sk) and
LGenAHE
hand pk to A along with a proof of validity, which is done through the Fzk
functionality. Using pk, party B encrypts its own secret key share, and sends
the ciphertext ctkey to A along with a proof that the ciphertext indeed hides its
secret key share (which is the discrete log of XB ). If all proofs go through, the
parties output their secret key shares, xA , xB and the public values XA , XB , pk
and ctkey (party B outputs its decryption key sk as well).
52 Authors Suppressed Due to Excessive Length

I.2 Presigning

The presigning protocol is formally described in Protocol 21. The goal of the
protocol is to randomly choose the signature nonce k and have the parties hold
their shares kA and kB . In the first message A commit to its random secret kA
and prove knowledge of it. In the second message B picks its random secret kB
and send RB = (kB )−1 · G to A, in addition to proving knowledge of the discrete
(k )−1
log of RB . Given RB , party A can compute the value R = RB A , which is
used in the signature protocol.

I.3 Signing

The first message of A consists of a ciphertext ctA that is computed by a secure

evaluation of an affine function fA (x) = a0 + a1 · x on ctkey , where a0 = rkA xA +
mkA and a1 = rkA are two coefficients known to A. The result is an encryption
of rkA xA + mkA + rkA xB = kA (rx + m). Party A sends B the values KA and
ctA computed earlier, along with a proof that ctA was evaluated correctly with
respect to kA , xA , r, m and ctk ey. That proof is separated to multiple statements,
which are proven individually. The first statement is that KA is a commitment
of the discrete log of RB with respect to the basis element R; namely, that
−1
kA · R = RB , or alternatively that kA · RB = R, which means that k −1 · G = R
as required. The second statement is that the value committed in UA equals the
value committed in KA times the discrete log of XA , namely (kA · xA ). Finally,
using the commitments KA and UA (to values kA and kA xA , resp.) and given
r = R|x−axis mod q and m, both parties can homomorphically compute the
commitments C0 and C1 to the coefficients a0 and a1 , respectively. The third
statement is that ctA is an encryption of fA (ctkey ) where C0 and C1 are the
commitments to fA ’s coefficients.
Apart from verifying the above proofs sent from party A, party B decrypt ctA
and obtains pt = kA (m + rx). Party B can obtain the signature by multiplying
pt with kB modulo q.

I.4 Security of the Two-Party Protocol

Theorem 2.4 states that in order to prove UC security of the protocol one only
has to prove that it is G ∗ -simulatable, as that property guarantees that the
adversary (the environment) cannot break the signature scheme’s unforgeability
even after an execution of (potentially multiple instances of) the protocol. In
that case, there is a ‘trivial’ simulator in the UC model: The simulator S
participates in the ideal world (with Ftsig ), and simulates the real-world protocol
Π2ecdsa = (Π2kgen , Π2pres , Π2sign ) by running A internally, taking the role of all
honest parties (and the (Fzk , Fcom ) functionalities). Specifically:

– Upon receiving (keygen, ssid, Pi ) from all parties, S initiates Π2kgen between
the simulated honest parties and the real adversary A, resulting with a key
X. Then, upon receiving (newkey, ssid), S sends (newkey, ssid, X, V) where
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 53

V is the verification algorithm for the signature in the real world (which is the
ECDSA verification algorithm in our case). Then once all (not simulated)
honest parties query (newkey, ssid), the functionality will transfer them
(newkey, ssid, X), and therefore the honest parties will output the same
public key X. Therefore, the key generation simulation is perfect by the
definition of Ftsig .
– Upon receiving (sign, sid, m, Pi ) from all parties, S initiates Π2pres and then
Π2sign , again by simulating the honest parties and oracle access to A, resulting
with a signature σ. Upon receiving (sign, sid, m), S responds with (signature, sid, m, σ).
Then, by definition, whenever an honest party queries Ftsig for the signature,
it gets (signature, sid, m, σ). Therefore, again, the simulation is perfect,
unless there was a record of (sid, m, σ, 0), in which case the functionality
outputs an error. However, there are only two ways in which (m, σ, 0) is
recorded. In both cases, some party X , potentially ̸∈ P, queried (sig-verify, sid, m, σ, X)
on a message m (note that only (m, σ, 1) is recorded in the signing phase). In
the first case, m was never signed, while not all parties in P are corrupted/quarantined.
In this case, the functionality records (m, σ, 0). The reason being that, if no
signing query on m is recorded, and not all parties are corrupted, if the
signature scheme is unforgeable, the signature must be invalid, and there is
no reason to validate it. Nevertheless, if an adversary can forge a signature,
this will result with a distinction between the real and ideal world. For the
second case, all parties in P are corrupted, in which case the adversary knows
the private key and is able to sign messages, therefore, they are validated
with V and there will be no difference from the real world in this scenario.
Thus, the view of the environment Z in the ideal world (which is comprised
of the view of A when run internally, and the outputs of honest parties in the
ideal world, where S interacts with Ftsig ) is identical to Z’s view in the real
world (which is comprised of A’s view and the outputs of honest parties in the
real world), unless A is able to forge signatures.
Therefore, theorem 2.4 states that it is only required to prove the following:
Theorem I.1 Π2ecdsa = (Π2kgen , Π2pres , Π2sign ) is G ∗ -simulatable (Def. 2.3) in
the (FTAHE , Fzk , Fcom−zk )-hybrid and random oracle model.
Proof. We will first simulate the two-party protocol in the (FTAHE , Fzk , Fcom−zk , G ∗ , H)-
hybrid model. The formal description of the simulator S is given in Figures 23,24,
simulating protocol against a corrupt A and B respectively. To show that the
above simulation is indistinguishable from the real protocol, we define two hybrids
where the first hybrid coincides with the simulation (Figures 23,24) and the
second hybrid coincides with the real execution. Namely:
1. Hybrid1 is similar to the simulation in Figures 23,24, except that S emulates
G ∗ locally (instead of using G ∗ as an oracle).
2. Hybrid2 is similar to Hybrid1 except that, when A is corrupted, S encrypts
the correct value xB instead of zero in Step 4 of command Π2kgen , in Simulation
23. S can do this because it previously got xA and now (when emulating G ∗
locally) it has access to x and thus xB = x − xA mod q.
54 Authors Suppressed Due to Excessive Length

3. Hybrid3 is similar to Hybrid2 except that, when B is corrupted, in Step 3

in Simulation 24 S computes ctA ← AHE.Eval(pk, fA , ctkey ) using the correct
fA and ctkey , where fA ’s coefficients a0 , a1 are determined by the correct
values xA and kA . S can do this because now (when emulating G ∗ locally) it
has access to these secrets. In that case, S knows xA since it generates the
LEncDL
secret signing key x and receives B’s share when B calls Fzk in Step 2 in
Simulation 24, then, it computes xA = x − xB mod q; in addition S knows
kA since it generates the secret nonce k and receives B’s share when B calls
L [G,RB ,q] −1
FzkDL in Step 4 in Simulation 24, then S computes kA = k · kB .
Hybrid1 is identically-distributed to the simulation (in Figures 23,24) since
the only difference is that in the simulation G ∗ ’s random tape is used to sample
the secret key (which determines the public key) and the nonce, whereas in the
hybrid this is done by the simulator. Nevertheless, in both cases these values are
sampled from the exact same distribution. Note that G ∗ also produces signatures
on messages of the adversary’s choice, however, a signature is fully determined
by the message, the secret key and the nonce.
Hybrid1 and Hybrid2 are computationally indistinguishable in the case
of a corrupted A and identically distributed in the case of a corrupted B. As
for the former, distinguishing the two reduces to breaking the CPA-security of
the encryption scheme AHE. Indeed, consider an adversary A′ engaged in the
CPA-security game of AHE. Adversary A′ gets a random public key pk ′ , sends
two messages m0 = 0 and m1 ← Zq to the experiment, and receives back a
ciphertext ct′ ← AHE.Enc(pk, mb ). Then, A′ uses S from Figure 23 (when A is
corrupted) with the following changes:
1. In line 4 of Π2kgen , it uses pk = pk ′ and ctkey = ct′ from the CPA-security
game.
2. In line 5 of Π2kgen it uses XB = m1 · G.
3. It responds to all S’s calls to G ∗ by perfectly simulating G ∗ .
Then, if b = 0, the view of A′ is identically distributed to Hybrid1, whereas
if b = 1, the view of A′ is identically distributed to Hybrid2. Therefore,
any advantage of A′ in distinguishing the to hybrids directly translates to an
advantage in the CPA-security game. Since AHE is semantically secure (which
is equivalent to CPA-security), we conclude that the distributions of the two
hybrids are computationally indistinguishable.
Hybrid2 and Hybrid3 are computationally indistinguishable in the case
of a corrupted B and identically distributed in the case of a corrupted A.
We can reduce indistinguishability of the two hybrids to the secure function
evaluation property (Definition B.5) of the AHE scheme: Consider an A be an
adversary that distinguishes between Hybrid2 and Hybrid3 with probability
ϵ. We construct A′ that breaks the secure function evaluation property with
the same probability as follows: Run Hybrid2 as the simulator S, except that
in Step 3 under command Π2sign in Simulation 24, engage in Experiment 8 by
handing ((pk, sk), ℓ = 1, {pt = xB , η}, f (x) = fA ) to the experiment, where xB
LDL
and η are extracted by simulating Fcom−zk and fA ’s coefficients are extracted as
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 55

explained above. Receive ciphertext ctEval from the experiment and use ctA =
ctEval . Run A with the resulting simulation and respond to the experiment with
whatever bit that A outputs. Observe that if the experiment’s bit is 0 then the
resulting simulation is distributed identically to Hybrid2 and if the bit is 1
then the resulting simulation is distributed identically to distributed Hybrid3.
Therefore, A′ breaks AHE’s secure function evaluation with the same probability
as A distinguishes between Hybrid2 and Hybrid3, namely, with probability ϵ.
Since AHE has secure function evaluation, this means that ϵ ∈ neg(κ).
Finally, it is easy to see that Hybrid3 is identical to the real execution,
where S takes the role of the uncorrupted party and runs A internally. Note
that the real-execution is run in the (Fzk , Fcom )-hybrid model, hence, all zero-
knowledge proofs and commitments are perfectly simulated. We stress that this
hybrid is identically distributed to the real execution even though in Step 2 under
command Π2pres in Simulation 24 the simulator commits to zero instead of the
correct value. This holds since we use a perfectly hiding commitment scheme
Com.

J Schnorr Protocols

We adapt and modify the definition from [BMP22] and describe the general
form of Schnorr protocols. We describe the protocol in a batched form, the non-
batched form is derived by simply setting the batch size to m = 1. Hereafter, let
ϕ : H → G denote a group homomorphism from (H, +), the witness group, to
(G, ·), the associated statement group, and E ⊂ Z≥0 (zero and positive integers)
denote the challenge space. It is assumed that (the description of) the tuple
(ϕ, H, G, E) is efficiently generated by a probabilistic polynomial time algorithm
given 1κ , and that ϕ is efficiently computable as a function of 1κ .

Definition J.1 An m-batch Schnorr protocol Π for tuple (ϕ, H, G, E) consists

⃗ = (Xj )m ∈ Gm to
of the following interactive process. For a common input X j=1
m m
both P and V and secret input w ⃗ = (wj )j=1 ∈ H to P:

1. P samples α ← H and sends A = ϕ(α) to the verifier.

2. V replies with ⃗e ← E m .P
m
3. P replies with z = α + j=1 ej · wj ∈ H, s.t. for e ∈ Z and w ∈ H we have
e · w = w + . . . + w.
| {z }
e times Qm e
4. V checks that ϕ(z) = A j=1 Xj j ∈ G and z ∈ H, and outputs 1 or 0
accordingly.

For µ, ε ∈ poly(κ), we may associate the following properties to a protocol:

– µ-HVZK. If there exists {wi }m i such that wi ∈ H and Xi = ϕ(wi ) for all
⃗ A, ⃗e, z), where z ← H, ⃗e ← E m ,
i ∈ [1, m], then the simulated transcript (X,
Qm −ej
and A = ϕ(z) j=1 Xj , is statistically µ-close to the honest transcript.
56 Authors Suppressed Due to Excessive Length

– ε-Knowledge soundness. There exists a set V such that:

• Sampling E ← E m×(m+1) , it holds that Pr[E ∈ V ] ≥ 1 − neg(κ).
• There exists a PPT extractor E such that given (1κ , X, ⃗ A, E, Z) where
⃗ A, ⃗ej , ⃗zj ) = 1
E = (⃗e1 , . . . , ⃗em+1 ) and Z = (⃗z1 , . . . , ⃗zm+1 ) such that V(X,
for all j ∈ [1, m + 1], and E ∈ V , then,
h i
Pr ϕ(w) ⃗ = X, ⃗ w
⃗ ∈H|w ⃗ ← E(1κ , X, ⃗ A, E, Z) ≥ 1 − ε.

It is easy to see that completeness and honest-verifier zero-knowledge for

the batched version are guaranteed as long as they are guaranteed for the non-
batched version.

K Batched Zero-Knowledge Proof for LDComEval

We apply the batched Schnorr protocol from Definition 4.1. The batched statement
consists of m statements as in Eq. 7, namely, (ctEval ⃗
k , Ck ; Ak , ρk , ηk ) ∈ LDComEval [pk, pp, ct]
Eval
such that ctk = ⃗v∆ · Ak ⊙ ⃗c ⊕ AHE.Enc(0; ηk ), Ck = Compp (Ak ; ρk ), and
Ak ∈ [0, ∆)d×(ℓ+1+ℓω ) , for each 1 ≤ k ≤ m.
When batching m statements, the challenge space E is adjusted to be [0, m ·
2κ+3 ). When m = 1, the knowledge extraction required two accepting transcripts,
where e ̸= ê, which happens with probability 2−κ . The analogous requirement
for the batched protocol, would require an (m + 1) × (m) matrix, where each
row corresponds to a uniformly sampled challenge ⃗ek ← E m , augmented with
a column of ones, to be invertible. This is the definition of the set V for ε-
extractability. In Corollary K.2, we show that the probability that the determinant
2
is zero is bounded by |E| .
In addition, the statistical zero-knowledge parameter is also adjusted, and
instead of 2s we use m · 2s . Therefore, the set S is adjusted to be [0, 2∆m2 · d(ℓ +
1 + ℓω )2κ+s )d×(ℓ+1+ℓω ) × Rpp × Rpk . This comes from the fact that the batched
protocol is essentially a sum of m statements, therefore the statistical distance
increases by a factor of m which we cancel out by adjusting s. Note however that
the statistical distance of an m-tuple of non-batched protocols from an m-tuple
of simulated protocols is also bounded by m · 2s .
As a result, we now require q > ∆m · (d(ℓ + 1 + ℓω ) · 2κ+s + 2κ ). The protocol
proceeds as follows:

1. P samples

B ∈ [0, 4∆ · m · d(ℓ + 1 + ℓω ) · 2κ+s )d×(ℓ+1+ℓω ) , ν ∈ Rpp , ξ ∈ R∗pk ,

computes
– ctU = ⃗v∆ · B ⊙ ⃗c ⊕ Enc(0; ξ),
– CU = Compp (B; ν),
and sends
LRange [pp,0,∆]
– (prove, C; A, ρ) to Fzk−batch , and
– (ctU , CU ) to V.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 57

Range L [pp,0,⌈q⌉]
2. Upon receiving (ctU , CU ) from P and (proof, C) from Fzk−batch (with
the same C in both messages), V sends random challenges e1 , . . . , em ←
[0, 2κ ) to P.
Eval Com
3. P responds with P (Z, z , z d×(ℓ+1+ℓ
), where:
ω)
– Z=B+ P e
k k · A k ∈ Z ,
Eval
– z = ξ + Pk ek ηk ∈ Rpk , and
– z Com = ν + k ek ρk ∈ Rpp .
4. V verifies the following equations:
!
M
Eval Eval
⃗v∆ · Z ⊙ ⃗c ⊕ Enc(0; z ) = ctU ⊕ ek ⊙ ctk (24)
k
!
M
Com(Z; z Com ) = CU ⊕ ek ⊙ C k (25)
k

In addition, V verifies that:

– z Com ∈ Rpp , z Eval ∈ Rpk , C, CU ∈ Cpp , c⃗t, ctEval , ctU ∈ Cpk , and
– Z ∈ [0, ∆m · (d(ℓ + 1 + ℓω ) · 2κ+s + 2κ ))d×(ℓ+1+ℓω ) .

Completness. This follows directly from the completeness of the underlying

protocol with m = 1, the homomorphic properties of AHE.Enc and Com, and
the adjusted range check for Z.
Pk̄
HVZK. Denote σk̄ = B + k=1 ek · Ak , where B is sampled from [0, ∆ · m ·
d(ℓ + 1 + ℓω ) · 2κ+s )d×(ℓ+1+ℓω ) , and ek is sampled uniformly from [0, 2κ ), as in the
real execution of the batched protocol. Then σ0 is the simulated transcript, σm
is the real execution, and σ1 is the real execution for a single statement. Then
1
by the HVZK property of the underlying protocol, SD[σ0 , σ1 ] ≤ m·2 s . Therefore,

by induction:

SD[σ0 , σm ] = SD[σ0 , σm−1 + em · Am ] ≤ SD[σ0 , σm−1 ] + SD[σ0 , σ0 + em · Am ]

1 1
≤ (m − 1) + = 2−s
m · 2s m · 2s
In the following we demonstrate that knowledge soundness is implied by the
knowledge soundness of the non-batched proof system.
 T
Knowledge soundness. Define V such that E T = ⃗e1 . . . ⃗em+1 ∈ V if and
only if ⃗ek ∈ E m and
 
⃗e1 ∥1
det  ...  ̸= 0 mod q, p1 , p2
 

⃗em+1 ∥1

where N = p1 p2 is the Paillier modulus. By Corollary K.2, Pr[E ∈ V |E ←

E (m+1)×m ] ≤ 2−κ+1 · 3 (by union bound on the primes q, p1 , p2 ).
58 Authors Suppressed Due to Excessive Length

Next, we construct a PPT extractor E such that given m + 1 accepting

 T
transcripts (ctU , CU , ⃗ek , Zk , zkEval , zkCom ) for 1 ≤ k ≤ m such that ⃗e1 . . . ⃗em+1 ∈
V , and (proof, A, ρ) such that Com(A; ρ) = C, outputs (Ak , ρk , ηk )m k=1 such that
(ctEval
k , Ck ; A , ρ
k k k, η ) ∈ LDComEval [pk, pp, ⃗
c t] for all
 1 ≤ k≤ m.
⃗e1 ∥1
E works as follows. It sets the matrix E =  ...  ∈ [0, 2κ )(m+1)×(m+1) .
 

⃗em+1 ∥1
Then for each session 1 ≤ k ≤ m + 1 it holds that:
m
!
M
Compp (Zk ; zkCom ) = ek,k′ ⊙ Ck′ ⊕ CU (26)
k′ =1
 
⃗e1 − ⃗em+1
..
Let ∂E =   ∈ E m×m , ∂Zk = Zk − Zm+1 and ∂zkCom = zkCom − zm+1
Com
 
.
⃗em − ⃗em+1
for all 1 ≤ k ≤ m. Also, denote by ∂ek,k′ := ek,k′ − em+1,k′ the (k, k ′ ) entry of
∂E. By subtracting Eq. 26 where k = m+1 from Eq. 26 for any other 1 ≤ k ≤ m,
we get
m
M
Com
Compp (∂Zk ; ∂zk ) = ∂ek,k′ ⊙ Ck′ (27)
k′ =1
We can write this system of equations in a matrix-form as follows:
Compp (∂Z1 ; ∂z1Com )
   
C1
..  . 
 = ∂E ⊙  ..  (28)
 
 .
Com
Compp (∂Zm ; ∂zm ) Cm
where the RHS is a matrix-vector product. Since E ∈ V and det(∂E) = det(E),
we have that det(E) ̸= 0 modulo q and N . Thus, we can compute (∂E)−1 in Zq
such that (∂E)−1 · ∂E = id. By multiplying (∂E)−1 on both sides of Eq. 28 we
get

Compp (∂Z1 ; ∂z1Com ) Compp (A′1 ; ρ′1 )

   

LHS = (∂E)−1 ⊙  .. ..
 := 
   
. . 
Com ′ ′
Compp (∂Zm ; ∂zm ) Compp (Am ; ρm )
   
C1 C1
−1  ..   .. 
RHS = (∂E) · ∂E ⊙  .  =  . 
Cm Cm
and so we get that
 ′    ′  Com 
A1 ∂Z1 ρ1 ∂z1
 ..  −1  ..   ..  −1  . 
 .  := (∂E) ·  .  and  .  := (∂E) ·  .. 
A′m ∂Zm ρ′m Com
∂zm
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 59

are vectors, whose k th entries correspond to a valid decommitment for Ck , for

all 1 ≤ k ≤ m. Therefore, it must hold that A′k = Ak for each 1 ≤ k ≤ m (for Ak
extracted from the range proof), otherwise one could use E to break the binding
property of Com.
Multiplying by ∂E, we get ∂E · Ak = ∂Zk mod q. Therefore, there exist
some Ik ∈ Zd×(ℓ+1+ℓω ) such that

q · Ik = ∂E · Ak − ∂Zk

holds over the integers. Next, take the ∥ · ∥∞ norm to bound the the absolute
value of entries on the RHS, and use the triangular inequality to get:

∥∂E·Ak −∂Zk ∥∞ ≤ ∆m·2κ +∆·m·(d(ℓ+1+ℓω )2κ+s ) = ∆m·(d(ℓ+1+ℓω )·2κ+s +2κ ) < q

By picking q to be that large, we conclude that ∂E · Ak = ∂Zk holds over

the integers, for all 1 ≤ k ≤ m. It therefore also holds modulo N , which enables
us to extract the ηk ’s in what follows, for the Paillier encryption.
Since all m+1 transcript are accepting, we know that for every 1 ≤ k ≤ m+1:
m
!
M
⃗v∆ · Zk ⊙ ⃗c ⊕ Enc(0; zkEval ) = ek,k′ ⊙ ctk′ ⊕ ctU
k′ =1

Subtracting (⊖) Eq. 24 for k = m + 1 from all other equations in 24, we get:
m
M
⃗v∆ · ∂Zk ⊙ ⃗c ⊕ Enc(0; ∂zkEval ) = ∂ek,k′ ⊙ ctEval
k′ (29)
k′ =1

where ∂zkEval = zkEval − zm+1

Eval
.
Now denote ct0k := ⃗v∆ · Ak ⊙ ⃗c, and subtract the following:

m
M m
M m
M
∂ek,k′ ⊙ ct0k′ = ∂ek,k′ ⊙ (⃗v∆ · Ak ⊙ ⃗c) = ⃗v∆ · (∂ek,k′ · Ak ) ⊙ ⃗c
k′ =1 k′ =1 k′ =1
m
!
M
= ⃗v∆ · ∂ek,k′ · Ak ⊙ ⃗c = ⃗v∆ · ∂Zk ⊙ ⃗c
k′ =1

   
A1 ∂Z1
(since ∂E ·  ...  =  ...  is established above over the integers) from both
   

Am ∂Zm
sides of Eq. 29 and get:
m
M
Enc(pk, 0; ∂zkEval ) = ∂ek,k′ ⊙ (ctEval 0
k′ − ctk′ )
k′ =1
60 Authors Suppressed Due to Excessive Length

In matrix notation, we get:

Enc(pk, 0; ∂z1Eval )
 Eval
ct1 − ct01
  
.. ..
 = ∂E ⊙ 
   
 . . 
Eval
Enc(pk, 0; ∂zm ) ctEval 0
m − ctm

Now, each equation involves multiple ciphertexts, so we need another step

in order to use Lemma 5.1. We cannot compute an inverse for ∂E over the
ciphertext domain since it is of unknown order, and computing such value is
equivalent to factorization. However, to use the lemma, it is sufficient to compute
a matrix F such that F · ∂E = δ · id, meaning, it is enough to get a scalar matrix
(even a diagonal matrix actually). This can be done using Gaussian elimination
adj(∂E)
over the integers without division, or alternatively, we can use (∂E)−1 = det(∂E)
(over Q), and set F = adj(∂E) and δ = det(∂E). Note that δ ̸= 0 in Zp1 nor in
Zp2 (where N = p1 p2 ), since E ∈ V . Also note that adj(∂E) and det(∂E) can
be computed in polynomial time over the integers. Therefore,

Enc(pk, 0; adj(∂E) · ∂z1Eval )

 Eval
ct1 − ct01
  
.. ..
 = det(∂E) ⊙ 
   
 . . 
Eval
Enc(pk, 0; adj(∂E) · ∂zm ) ctEval 0
m − ctm

We may now use Lemma 5.1 to extract the all randomizers ηk , and get ctEval
k =
⃗v∆ · Ak ⊙ ⃗c + Enc(0; ηk ).

Lemma K.1 Let k0 , m ∈ N s.t. k0 < m, and let ⃗e1 , . . . , ⃗ek0 ∈ [0, 2κ )m+1 be
linearly independent over Zq , then the probability that ⃗e1 , . . . , ⃗ek0 +1 are linearly
independent over Zq̂ where ⃗ek0 +1 is uniformly chosen from [0, 2κ )m+1 with ⃗ek0 +1,m+1 =
1
1 is at least 1 − 2κ(m+1−k0)
.

Proof. We bound the probability that ⃗ek0 +1 ∈ span(⃗e1 , . . . , ⃗ek0 ). Consider ⟨⃗e1 , . . . , ⃗ek0 ⟩⊥ ,
the linear subspace of all vectors perpendicular to ⃗ei for all i ∈ {1, . . . , k0 }. Let
{f⃗′ k0 +1 , . . . , f⃗′ m+1 } be a Gaussian-eliminated basis of ⟨⃗e1 , . . . , ⃗ek0 ⟩⊥ . A vector
is in span(⃗e1 , . . . , ⃗ek0 ) if and only if it is perpendicular to f⃗′ i for each i ∈ {k0 +
1, . . . , m + 1}. The challenge is that the distribution of ⃗ek0 +1 is over [0, 2κ )m+1 ,
1
and not the whole space Zm+1 q (in which case the probability is exactly qm+1−k 0
).
Let pvi be the first non-zero entry of f⃗ )i , so pvk0 +1 > . . . > pvm+1 . W.l.o.g, we
′

will assume that pvi = i, for convenience.

Let ⃗u be a vector from [0, 2κ )m+1 such that ⃗u ⊥ f⃗′ i for each i ∈ {k0 +
1, . . . , m + 1}. Let

S⃗u = {⃗u′ = (u′0 , . . . , u′m+1 ) ∈ [0, 2κ )m+1 | ∀ 1 ≤ i ≤ k0 : u′i = ui ∧

∃ k0 + 1 ≤ i ≤ m + 1 : u′i ̸= ui }

Then observe that |S⃗u | = 2κ(m+1−k0 ) − 1, and that for any u⃗′ ∈ S⃗u , u⃗′ ̸∈
span(⃗e1 , . . . , ⃗ek0 ).Indeed, there exist some pivot entry i > k0 such that u′i ̸= ui .
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 61

Therefore, ⟨u⃗′ , f⃗′ i ⟩ = ⟨⃗u, f⃗′ i ⟩ + (u′i − ui ) · 1 ̸= 0. Indeed, ⃗u ⊥ f⃗′ i , and ⃗u, u⃗′ only
differ in the last m + 1 − k0 entries. However fj′ = 0 for i ̸= j > k0 because f⃗′ is
after Gaussian elimination. Finally, since q is prime, u′i − ui ̸= 0 and fi′ ̸= 0, the
product is also non-zero, as desired.
Therefore, for every choice of non-pivot coordinates (i ≤ k0 ) in [0, 2κ ), the
probability over the choice of pivot coordinates (i > k0 ) that ⃗u ⊥ f⃗′ i for all
1
i ∈ {k0 + 1, . . . , m + 1} is bounded by 2κ(m+1−k 0)
. Therefore:

Pr [⃗ek0 +1 ∈ span(⃗e1 , . . . , ⃗ek0 )] = Pr[∀m+1 ek0 +1 ⊥ f⃗′ i ]

i=k0 +1⃗
X
= Pr[∀i ≤ k0 : ek0 +1,i = ui ] · Pr[∀i > k0 : ⃗ek0 +1 ⊥ f⃗′ i | ∀i ≤ k0 : ek0 +1,i = ui ]
{v1 ,...,vk0 }∈[0,2κ )
X 1 1
≤ Pr[∀i ≤ k0 : ek0 +1,i = ui ] · =
2κ(m+1−k0 ) 2κ(m+1−k0 )
{v1 ,...,vk0 }∈[0,2κ )

Corollary K.2 For uniformly chosen matrix E ∈ [0, 2κ )(m+1)×(m+1) , such that
the first column is all ones, Pr[det(E) ̸= 0] =.

Proof. Denote the columns of E by ⃗e1 , . . . , ⃗em+1 , then det(E) ̸= 0 iff ⃗e1 , . . . , ⃗em+1
are linearly independent. Let Lk0 for 1 ≤ k0 ≤ m + 1 be the event that ⃗ek0 ∈ /
span(⃗e1 , . . . , ⃗ek0 −1 ), then by Lemma K.1:

Pr[det(E) ̸= 0] = Pr[L1 ] · Pr[L2 | L1 ] · Pr[L3 | L1 ∧ L2 ] · . . . · Pr[Lm | L1 ∧ . . . ∧ Lm+1 ]

   
1 1 1 1 1
≥ 1 · 1 − κm · . . . · 1 − κ ≥ 1 − κ · −κ
≥ 1 − κ−1
2 2 2 1−2 2

L Instantiating Fzk for the Remaining Languages

Below we specify the parameters for the other Schnorr based languages:
– Knowledge of the discrete log of an elliptic-curve point.

LDL [(G, G, q)] = {(P ; x) | P = x · G}

The homomorphism is ϕ : H = Zq → G, x 7→ x · G.
– Knowledge of decommitment.

LDCom [pp] = {C; m, ρ | C = Com(m; ρ) ∧ m ∈ Mpp ∧ ρ ∈ Rpp ∧ C ∈ Cpp }

The homomorphism is ϕ : H = Mpp × Rpp → Cpp , (m, ρ) 7→ Com(m; ρ).

– AHE encryption of a discrete log.

LEncDL [pk, (G, G, q)] = {(ct, X; x, η) | ct = AHE.Enc(pk, x; η)∧X = x·G∧x ∈ [0, ⌈q⌉)}

To prove this language, we enhanced it with a homomorphic commitment on

x. The homomorphism is ϕ : H = Z × Rpk × Rpp → Cpk × G × Cpp , (x, η, ρ) 7→
(AHE.Enc(x; η), x · G, Com(x; ρ)). In addition, R = [0, q) × Rpk , and S =
[0, q2s ) × Rpk .
62 Authors Suppressed Due to Excessive Length

– AHE encryption of a tuple.

LEncDH [pk, ctx ] = {(cty , ctz ; y, ηy , ηz ) |cty = AHE.Enc(pk, y; ηy ) (30)

∧ ctz = AHE.Eval(pk, f, ctx ; ηz ) s.t. f (x) = y · x mod q}

The homomorphism is ϕ : H = Z × R2pk × Rpp → Cpk 2

× Cpp , (x, ηy , ηz , ρ) 7→
(AHE.Enc(y; ηy ), AHE.Eval(pk, f (x) := y·x, ctx ; 0, ηz ), Com(y; ρ)). In addition,
R = [0, q) × R2pk × Rpp and S = [0, q2s ) × R2pk × Rpp .

The languages LDComDL and LDComRatio cannot be directly derived, since they
articulate relations between the coefficients ⃗a of f . Nevertheless, these are typical
Schnorr arguments for which you can find proofs in e.g. [Ban05, Mau15]:

– Commitment of discrete log.

LDComDL [pp, (G, G, q)] = {C, Y ; m, ρ | C = Compp (m; ρ) ∧ Y = m · G}

The homomorphism is ϕ : H = Mpp ×Rpp → Cpp ×G, (m, ρ) 7→ (Compp (m; ρ), m·
G).
– Ratio between committed values is the discrete log. (Recall that Mpp = Zq .)

LDComRatio [pp, (G, G, q)] = {C1 , C2 , X; m, x, ρ1 , ρ2 |X = x · G

∧ C1 = Compp (m, ρ1 )
∧ C2 = Compp (x · m, ρ2 )}

To prove this language, we do a little trick. We use Pedersen commitments:

Compp (m; ρ) := Ped.ComG,G,H,q (m, ρ) = m · G + ρ · H

Therefore:

C2 = Ped.ComG,G,H,q (x · m, ρ2 ) = Ped.ComG,X,H,q (m, ρ2 )

Hence, equivalently, we prove relation to the following language:

LDComRatio [pp, X] = {C1 , C2 ; m, ρ1 , ρ2 |C1 = ComG,H (m, ρ1 )

∧ C2 = ComX,H (m, ρ2 )}

The homomorphism is ϕ : H = Z3q → G2 , (m, ρ1 , ρ2 ) 7→ (ComG,H (m; ρ1 ), ComX,H (m; ρ2 )).

Note that knowledge of x can be proven separately.

We also note that in LDComEval used in our protocol, we build on Com to

specifically be a Pedersen commitment over the ECDSA group G, with the
generator G being also the message base for the commitment. However, as all
other languages, we can enhance LDComEval with an additional homomorphic
commitment, on which the range proofs are proven. To simplify the presentation
of the proof technique, we chose not to do it in Section 5.2.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 63

M Three Rounds Threshold ECDSA

As mentioned, the key generation and signing protocol remain intact. In what
follows, we present the 2-round presign protocol, its simulation, and prove indistinguishability.

M.1 2-Round Presign

As mentioned earlier, we don’t aggregate the proofs. Instead, each party sends
its own proof and validates the proofs from all other parties. Moreover, in the
first round, each party commits to ki · G, Enc(ki ), but already starts to work
on encrypted values, and sends Enc(γi ) and Enc(γi · xB ). In the second round,
since Enc(γ) is already known, parties can immediately send Enc(ki γ). At the
same time, they can decommit to ki · G and Enc(ki ), and proof validity with a
zk proof that ties ki · G, Enc(ki ) together via LEncDL , and Enc(ki ), Enc(ki γ) via
LEncDH [Enc(γ)].

M.2 Simulation

We define the following hybrids where Hybrid1 coincides with the simulation
(Figure 26) and Hybrid7 coincides with the real execution. Note that in Hybrid1
all the ciphertexts ctkey , cti1 , cti2 , cti3 , cti4 are decrypted to zero. These values are
gradually replaced with correct values as we transit from Hybridi to Hybridi+
1. The correct values are known to the simulators in the hybrids as the simulator
takes the role of G ∗ instead of using it as an oracle. This does not change the
distribution of the values as the simulator samples the key and the presignature
as well as computes the signature exactly the same as G ∗ would. In more detail:

1. Hybrid1 is similar to the simulation in Figure 26, except that S emulates

G ∗ locally (instead of using G ∗ as an oracle).
2. Hybrid2 is similar to Hybrid1 except that, S encrypts the correct value
xB instead of zero in Step 3c in Simulation 17.
3. Hybrid3 is similar to Hybrid2 except that in Step 2(a)ii in Simulation 26,
j
S picks its own γi ∈ [0, q), computes and uses cti1 = AHE.Enc(γi ; ηmask 1
)
instead of an encryption of zero.
4. Hybrid4 is similar to Hybrid3 except that in Step 2(a)ii in Simulation 26, S
computes and uses cti2 = AHE.Eval(pk, fi , ctkey ; ηmask
i
2
) where fi (x) = γi · x,
instead of an encryption of zero.
5. Hybrid5 is similar to Hybrid4 except that in Step ?? in Simulation 26,
j
S computes and uses cti3 = AHE.Enc(k; ηmask 3
), instead of an encryption of
zero.
6. Hybrid6 is similar to Hybrid5 except that in Step 2(b)v in Simulation 26,
S computes and uses cti4 = AHE.Eval(pk, fi′ , ct1 ; ηmask
i
4
) where fi′ (x) = ki ·x,
instead of an encryption of zero.
7. Hybrid7 is similar to Hybrid6 except that in Step 4b in Simulation 19, S
computes pt4 = γkB mod q and ptA = kA · γ(r · x + m) mod q.
64 Authors Suppressed Due to Excessive Length

For all i = 1, . . . , 7 we have that Hybridi is indistinguishable from Hybridi+

1 as distinguishing the two reduces to breaking the CPA-security of the encryption
scheme, either directly or by breaking the secure function evaluation. Since AHE
is semantically secure (which is equivalent to CPA-security), we conclude that
the distributions of the two hybrids are computationally indistinguishable.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 65

SIMULATION
15 G ∗ -Simulation for Πkgen and Πpres - All parties Bi are

corrupted

All parties Bi are corrupted by the adversary A:

S runs A internally, and responds to the following invocations

– Πkgen ((G, G, q)):

LDL
1. Simulate Fcom−zk by sending (receipt, pidA ) to A.
2. Only on first execution: Simulate FTAHE by receiving (keygen, sid) from A on
behalf of all Bi ’s. Run (pk; sk) ← AHE.Gen(1κ ), send pk to the adversary and
receive the adversary’s response (continue, U ′ ). If U ′ = U ′ ∩ [n] is empty then
send (pubkey, sid, pk) to A, otherwise, send (pubkey, sid, ⊥, U ′ ) to A and
abort (simulating a later abort by party A).
LEncDL
3. Simulate Fagg−zk by receiving (prove, sid, pidi , Xi , cti ; xi , ρi ) from A on behalf
of every Bi . Let M ⊆ [n] be the set for which cti ̸= AHE.Enc(pk, xi ; ρi ) or
Li ̸= xi · G. If M = ∅ then send (proof, sid, XB , ctkey ) to A where ctkey =
X
i∈[n] cti , otherwise send (malicious, sid, M ) to A and abort (simulating a
later abort by party A).
4. Query G ∗ on input keygen and obtain X; then set XA = X − XB .
LDL
5. Simulate Fcom−zk by sending (decom–proof, pidA , XA ) to A.
6. Record (keygen, XB , X, ctkey , pk) and output whatever A outputs.
– Πpres ((G, G, q), sid)
1. Query G ∗ on input pres and obtain R.
2. Compute KA = Com(0, ρ1 ) for some ρ1 ← Rpp .
3. First round:
L
(a) Simulate FzkDCom by sending (proof, sid||pidA , KA ) to A.
LDL
(b) Simulate Fagg−zk by receiving (prove, sid, pidi , Ri ; ki ) from A on behalf of
every Bi . Let M ⊆ [n] be the set for which ki · G ̸= Ri . If M = ∅ then
send (proof, sid, RB ) to A, otherwise send (malicious, sid, M ) to A and
abort (simulating a later abort by party A).
LEncDH [pk,ctkey ]
(c) Simulate Fagg−zk by receiving (prove, sid∥γ, pidi , cti1 , cti2 ; γi , ηmask
i
1
i
, ηmask 2
)
i
from A on behalf of every Bi . Let M ⊆ [n] be the set for which ct1 ̸=
i
AHE.Enc(γi ; ηmask 1
) or cti2 ̸= AHE.Eval(pk, fi , ctkey ; ηmask
i
2
) where fi (x) =
γi · x. If M = ∅ then send (proof, sid∥γ, ct1 , ct2 ) to A, otherwise send
(malicious, sid, M ) to A and abort (simulating a later abort by party A).
LEncDL
(d) Simulate Fagg−zk by receiving (prove, sid, pidi , Ri , cti3 ; ki , ηmaski
3
) from
A on behalf of every Bi . Let M ⊆ [n] be the set for which
cti3 ̸= AHE.Enc(pk, ki ; ηmask i
3
) or Ri ̸= ki · G. If M = ∅ then send
(proof, sid, R, ct3 ) to A, otherwise send (malicious, sid, M ) to A and
abort (simulating a later abort by party A).
4. Second round:
LEncDH [pk,ct1 ]
(a) Simulate Fagg−zk by receiving (prove, sid∥k, pidi , cti3 , cti4 ; ki , ηmask
i
3
i
, ηmask 4
)
from A on behalf of every Bi . Let M ⊆ [n] be the set
for which cti3 ̸= i
AHE.Enc(pk, ki ; ηmask3
) or cti4 ̸=
AHE.Eval(pk, fi′ , ct1 ; ηmaski
4
) where f ′
i (x) = k i · x. If M = ∅ then
send (proof, sid∥k, ct3 , ct4 ) to A, otherwise send (malicious, sid∥k, M )
to A and abort (simulating a later abort by party A).
5. Record (presign, sid, RB , R, ct1 , ct2 ; γ, kB , ρ1 ), where ct1 and ct2 are encryptions
of γ and γ · xB , and output whatever A outputs.
66 Authors Suppressed Due to Excessive Length

G ∗ -Simulation for Πsign ) - All parties Bi are corrupted

SIMULATION 16

– Πsign ((G, G, q), sid, msg):

1. Retrieve R from the record (presign, sid, RB , R, ct1 , ct2 ; γ, kB , ρ1 ), if such a
record does not exist then abort.
2. Query G ∗ on input (sign, msg, R), obtain σ = (r, s) and set m = H(msg).
3. Set ctA ← SEval (pk, sA ) where sA = (γkB ) · s mod q and SEval is the simulator
associated with the AHE scheme (Def. 2.1).
4. Compute UA = Com(0, ρ2 ) for a random ρ2 , then compute C1 = (r ⊙ UA ) ⊕
(m ⊙ KA ) and C2 = r ⊙ KA .
5. Simulate zero-knowledge proofs:
L [pp,G,q]
– Simulate FzkDComDL by sending (proof, sid||pidA , KA , R, RB ) to A.
LDComRatio [pp,G,G,q]
– Simulate Fzk by sending (proof, sid||pidA , KA , UA , XA ) to
A.
L [pp,pk,ct1 ,ct2 ]
– Simulate FzkDComEval by sending (proof, sid||pidA , ctA , C1 , C2 ) to
A.
6. Output whatever A outputs.

SIMULATION
17 G ∗ -Simulation for Πkgen - Parties A ∪ {Bj }j∈[n]\{i} are

corrupted

Parties A ∪ {Bj }j∈[n]\{i} are corrupted (controlled by adversary A):

S runs adversary A internally, and responds to the following invocations

– Π2kgen ((G, G, q)):

1. A’s first message:
LDL
(a) Simulate Fcom−zk by receiving (com–prove, pidA , XA ; xA ).
∗
2. Query G on input keygen and obtain X and set XB = X − XA .
3. B’s first message:
LDL
(a) Fcom−zk by sending (receipt, pidA ) to A.
(b) Only on first execution: Simulate FTAHE by receiving (keygen, sid) from
A on behalf of all Bj ’s. Run (pk; sk) ← AHE.Gen(1κ ), send pk to
the adversary and receive the adversary’s response (continue, U ′ ). If
U ′ = U ′ ∩ [n] is empty then send (pubkey, sid, pk) to A, otherwise, send
(pubkey, sid, ⊥, U ′ ) to A and abort (simulating a later abort by party A).
LEncDL
(c) Simulate Fagg−zk by receiving (prove, sid, pidj , Xj , ctj ; xj , ρj ) from A
on behalf of every Bj . Let M ⊆ [n] be the set for which
cti ̸= AHE.Enc(pk, xi ; ρi ) or Xi ̸= xi · G. If M = ∅ then send
(proof, sid, XB , ctkey ) to A where ctkey = AHE.Enc(pk, 0; η) for a randomly
chosen η; otherwise send (malicious, sid, M ) to A and abort (simulating
a later abort by party A).
4. A’s second message:
LEncDL
(a) Simulate Fagg−zk by sending (prove, pidB , ctkey , pk, XB ) to A (directed to
party A; recall that ctkey is an encryption of 0).
(b) Simulate FTAHE by receiving (certify, pk′ ) from A. If pk′ = pk from above
then respond with 1, otherwise respond with 0.
LDL
(c) Simulate Fcom−zk by receiving (decom–proof, pidA , XA ) from A (party
A), and abort if XA ̸= xA · G. Otherwise, send (decom–proof, pidA , XA )
to A (parties Bj ’s).
5. Record (keygen, XA , XB , X, ctkey , pk; sk) and output whatever A outputs.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 67

SIMULATION
18 G ∗ -Simulation for Πpres - Parties A ∪ {Bj }j∈[n]\{i} are

corrupted

– Π2pres ((G, G, q), sid)

1. A’s message:
L
(a) Simulate FzkDCom by receiving (prove, sid, pidA , KA ; kA , ρ1 ) from A. Abort
if KA ̸= Com(kA , ρ1 ).
2. Query G ∗ on input pres and obtain R.
3. Set RB = kA · R (implying R = (kA )−1 · RB as required).
4. B’s message:
(a) First round:
L
i. Simulate FzkDCom by sending (proof, sid||pidA , KA ) to A.
LDL
ii. Simulate Fagg−zk by receiving (prove, sid, pidj , Rj ; kj ) from A on
behalf of every Bj . Let M ⊆ [n] \ {i} be the set for which kj · G ̸=
Rj . If M = ∅ then send (proof, sid, RB ) to A, otherwise send
(malicious, sid, M ) to A and abort (simulating an abort by party
Bi ).
LEncDH [pk,ctkey ]
iii. Simulate Fagg−zk by receiving
(prove, sid∥γ, pidj , ct1 , ctj2 ; γj , ηmask
j j
1
, η j
mask2 ) from A on
behalf of every Bj . Let M ⊆ [n] \ {i} be the set
for which ctj1 ̸= AHE.Enc(γj ; ηmask j
1
) or ctj2 ̸=
j
AHE.Eval(pk, fj , ctkey ; ηmask2 ) where fj (x) = γj · x. If M = ∅,
i i i
pick ηmask 3
, ηmask 4
← Rpk , compute ct1 = AHE.Enc(pk, 0; ηmask 1
) and
i
ct2 = AHE.Enc(pk, 0; ηmask2 ), and send (proof, sid∥γ, ct1 , ct2 ) to A.
Otherwise send (malicious, sid, M ) to A and abort (simulating an
abort by party Bi ).
LEncDL
iv. Simulate Fagg−zk by receiving (prove, sid, pidj , Rj , ctj3 ; kj , ηmask j
3
) from
A on behalf of every Bj . Let M ⊆ [n] \ {i} be the set
for which ctj3 ̸= AHE.Enc(pk, kj ; ηmask j
3
) or Rj ̸= kj · G. If
i i
M = ∅ then pick random ηmask3 , ηmask4 ← Rpk , compute ct3 =
i i
AHE.Enc(pk, 0; ηmask 3
) and ct4 = AHE.Enc(pk, 0; ηmask 4
) and send
(proof, sid, R, ct3 ) to A, otherwise send (malicious, sid, M ) to A and
abort (simulating an abort by party Bi ).
(b) Second round:
LEncDH [pk,ct1 ]
i. Simulate Fagg−zk by receiving
(prove, sid∥k, pidj , ct3 , ctj4 ; kj , ηmask
j j
3
, η j
mask4 ) from A on
behalf of every Bj . Let M ⊆ [n] be the set for
which ctj3 ̸= AHE.Enc(pk, kj ; ηmask j
3
) or ctj4 ̸=
′ j ′
AHE.Eval(pk, fj , ct1 ; ηmask4 ) where fj (x) = kj · x. If M = ∅ then send
(proof, sid∥k, ct3 , ct4 ) to A, otherwise send (malicious, sid∥k, M ) to
A and abort (simulating an abort by party Bi ).
5. A’s verification
L
(a) Simulate FzkDL by sending (proof, sid||pidB , RB ) to A.
EncDH L [pk,ct
key ]
(b) Simulate Fagg−zk by sending (proof, sid, ct1 , ct2 ) to A.
6. Record (presign, sid, RB , {γj }j∈[n]\{i} , R, KA , ct1 , ct2 , ct4 ; kA , ρ1 ) and output
whatever A outputs.
68 Authors Suppressed Due to Excessive Length

SIMULATION
19 G ∗ -Simulation for Πsign - Parties A ∪ {Bj }j∈[n]\{i} are

corrupted

– Π2sign ((G, G, q), sid, msg):

1. Set m = H(msg).
2. A’s message:
(a) Receive from A the following proofs (abort if any of these is not received):
L [pp,G,q]
– (prove, sid||pidA , KA , R, RB ; kA , ρ1 ) by simulating FzkDComDL .
– (prove, sid||pidA , KA , UA , XA ; kA , xA , ρ1 , ρ2 ) by simulating
L [pp,G,G,q]
FzkDComRatio .
– (prove, sid||pidA , ctA , C0 , C1 ; a0 , a1 , α1 , α2 , η) by simulating
L [pp,pk,ct1 ,ct2 ]
FzkDComEval .
(b) Abort if any of the following is incorrect:
• (KA , R, RB ; kA , ρ1 ) ∈ LDComDL [pp, G, q].
• (KA , UA , XA ; kA , xA , ρ1 , ρ2 ) ∈ LDComRatio [pp, G, G, q].
• (ctA , C0 , C1 ; a0 , a1 , α1 , α2 , η) ∈ LDComEval [pp, pk, ct1 , ct2 ] where α1 =
r · ρ2 + m · ρ1 and α2 = r · ρ1 .
• There are records (presign, sid, RB , {γj }j∈[n]\{i} , R, KA , ct1 , ct2 , ct4 ; kA , ρ1 )
and (keygen, XA , XB , X, ctkey , pk; sk).
• C0 = (r ⊙ UA ) ⊕ (m ⊙ KA ) and C1 = r ⊙ KA , where r = R|x−axis .
3. Query G ∗ on input (sign, msg, R), and obtain σ = (r, s).
4. Bi ’s verification and output:
(a) Simulate zero-knowledge proofs:
L [pp,G,q]
– Simulate FzkDComDL by sending (proof, sid||pidA , KA , R, RB ) to
A.
L [pp,G,G,q]
– Simulate FzkDComRatio by sending (proof, sid||pidA , KA , UA , XA )
to A.
L [pp,pk,ct1 ,ct2 ]
– Simulate FzkDComEval by sending
(proof, sid||pidA , ctA , C1 , C2 ) to A.
(b) Pick a random γ̃, k̃B ∈ [0, q) and compute pt4 = γ̃ · k̃B mod q and ptA =
s · pt4 mod q.
(c) Simulate FTAHE by receiving (decrypt, pk, ctA ) and (decrypt, pk, ct4 )
from A on behalf of all Bj ’s. Send (decrypted, pk, ct4 , pt4 ) and
(decrypted, pk, ctA , ptA ) to the adversary. If the adversary responds
with continue = 1 or U ′ ∩ U = ∅ on both of them then output
(decrypted, pk, ct4 , pt4 ) and (decrypted, pk, ctA , ptA ) again to the
adversary (this time directed to parties Bj ’s).
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 69

PROTOCOL 20 Two-Party Key-Generation Π2kgen : KeyGen(G, G, q)
The protocol is parameterized with a group description (G, G, q), computational
security parameter 1κ , and with a session id sid. The parties do as follows:

1. A’s first messages:

(a) A samples a random xA ← Zq and computes XA = xA · G.
LDL
(b) A sends (com–prove, pidA , XA ; xA ) to Fcom−zk .
2. B’s first message:
LDL
(a) B receives (receipt, pidA ) from Fcom−zk .
(b) B samples a random xB ← Zq and computes XB = xB · G.
(c) B runs (pk, sk) ← AHE.Gen(1κ , aux) where aux its randomness, and ctkey =
AHE.Enc(pk, xB ; η) where η ← Rpk .
L
(d) B sends (prove, pidB , pk; aux) to FzkGenAHE .
L
(e) B sends (prove, pidB , XB , ctkey ; xB , η) to FzkEncDL .
3. A’s second message:
L
(a) A receives (proof, pidB , XB , ctkey ) from FzkEncDL , if not, it aborts.
LGenAHE
(b) A receives (proof, pidB , pk) from Fzk , if not, it aborts.
LDL
(c) A sends (decom–proof, pidA ) to Fcom−zk .
4. B’s verification.
LDL
(a) B receives (decom–proof, pidA , XA ) from Fcom−zk , if not, it aborts.
5. Output.
– A outputs X = XA + XB and record (keygen, XB , X, ctkey , pk).
– B outputs X = XA + XB and record (keygen, XA , X, ctkey , pk; sk).

PROTOCOL 21 Two-Party Presigning Π2pres : Presign ((G, G, q), sid)
Let ssid be a fresh sub-session identifier agreed upon by A and B. The parties proceed
as follows:

1. A’s message:
(a) A samples a random kA ← Zq and computes KA = Com(kA ; ρ1 ).
L
(b) A sends (prove, sid, pidA , KA ; kA , ρ1 ) to FzkDCom .
2. B’s message:
L
(a) B receives (proof, sid, pidA , KA ) from FzkDCom , if not, it aborts.
(b) B samples a random kB ← Zq and computes RB = (kB )−1 · G.
∗

L [G,RB ,q]
(c) B sends (prove, sid, pidB , G; kB ) to FzkDL .
3. A’s verification
L [G,RB ,q]
(a) A receives (proof, sid, pidB , G) from FzkDL , if not, it aborts.
4. Output
(a) A records (presign, sid, RB , R; kA ), where R = (kA )−1 · RB .
(b) B records (presign, sid, RB , KA ; kB ).
70 Authors Suppressed Due to Excessive Length

PROTOCOL 22 Two-Party Signing Π2sign : Sign ((G, G, q), sid, msg)
Inputs:

1. A has (X, ctkey ) from the key-generation protocol and (sid, RB , R; kA ) from the
presign protocol.
2. B has (X, ctkey ; sk) from the key-generation protocol and (sid, RB , KA ; kB ) from
the presign protocol.
3. A and B locally compute m = H(msg) and verify there is a record of sid being
used in a presign protocol which was not used before in a sign protocol.

The protocol:

1. A’s message:
(a) A computes r = R|x−axis mod q.
(b) A samples ρ2 ∈ Rpp and computes UA = Com(kA · xA ; ρ2 ).
(c) A sets a0 = r · kA · xA + m · kA and a1 = r · kA .
(d) A homomorphically evaluates ctkey , on its private function fA (x) := a0 + a1 · x:
– ctA ← AHE.Eval(pk, fA , ctkey ; η)
(e) A sends the following proofs:
L [pp,G,q]
– A sends (prove, sid, pidA , KA , R, RB ; kA , ρ1 ) to FzkDComDL .
– A sends (prove, sid, pidA , KA , UA , XA ; kA , xA , ρ1 , ρ2 ) to
L [pp,G,G,q]
FzkDComRatio .
– A computes C0 = (r ⊙ UA ) ⊕ (m ⊙ KA ) and C1 = r ⊙ KA , and sends
(prove, sid, pidA , ctA , C0 , C1 ; a0 , a1 , r · ρ2 + m · ρ1 , r · ρ1 , η) to
L [pp,pk,ctkey ]
FzkDComEval .
2. B’s verification and output:
(a) B receives the following proofs, otherwise, it aborts.
L [pp,G,q]
– (proof, sid, pidA , KA , R, RB ) from FzkDComDL .
LDComRatio [pp,G,G,q]
– (proof, sid, pidA , KA , UA , XA ) from Fzk .
L [pp,pk,ct ]
– (proof, sid, pidA , ctA , C0 , C1 ) from FzkDComEval key
.
(b) B aborts if any of the following is incorrect:
– There are records (presign, sid, RB , KA ; kB ) and
(keygen, XA , X, ctkey , pk; sk) for some X and sk; that is, the values
used in the proofs are consistent with values obtained in the key
generation and presign sub-protocols;
– C0 = (r ⊙ UA ) ⊕ (m ⊙ KA ) and C1 = r ⊙ KA , where r = R|x−axis .
(c) B computes pt = AHE.Dec(sk, ctA ).
(d) B computes s′ = kB · pt mod q and s = min{s′ , q − s′ } (to ensure uniqueness
of the signature).
(e) B outputs σ = (r, s).
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 71

SIMULATION
23 G ∗ -Simulation for Π2ecdsa = (Π2kgen , Π2pres , Π2sign ) - Party A is

corrupted

Party A is corrupted (controlled by A):

S runs A internally, and responds to the following invocations

– Π2kgen ((G, G, q)):

LDL
1. Simulate Fcom−zk by receiving (com–prove, pidA , XA ; xA ).
∗
2. Query G on input keygen and obtain X.
3. Set XB = X − XA .
4. Run (pk, sk) ← AHE.Gen(1κ ) and ctkey = AHE.Enc(pk, 0; η) for a randomly
chosen η.
L
5. Simulate FzkEncDL by sending (prove, pidB , ctkey , pk, XB ) to A.
LDL
6. Simulate Fcom−zk by receiving (decom–proof, pidA , XA ).
7. Verify that XA = xA · G, if not then abort.
8. Record (keygen, XA , X, ctkey , pk; sk) and output whatever A outputs.
– Π2pres ((G, G, q), sid)
L
1. Simulate FzkDCom by receiving (prove, sid, pidA , KA ; kA , ρ1 ) from A.
∗
2. Query G on input pres and obtain R.
3. Set RB = kA · R (implying R = (kA )−1 · RB as required).
L
4. Simulate FzkDL by sending (proof, sid||pidB , RB ) to A.
5. Record (sid, KA ; ·) and output whatever A outputs.
– Π2sign ((G, G, q), sid, M ):
1. Receive from A the following proofs (abort if any of these is not received):
L [pp,G,q]
– (prove, sid||pidA , KA , R, RB ; kA , ρ1 ) by simulating FzkDComDL .
– (prove, sid||pidA , KA , UA , XA ; kA , xA , ρ1 , ρ2 ) by simulating
L [pp,G,G,q]
FzkDComRatio .
– (prove, sid||pidA , ctA , C0 , C1 ; a0 , a1 , α1 , α2 , η) by simulating
L [pp,pk,ctkey ]
FzkDComEval .
2. Aborts if any of the following is incorrect:
• The values A provided to Fzk satisfy languages LDComDL [pp, G, q],
LDComRatio [pp, G, G, q] and LDComEval [pp, pk, ctkey ]; for the latter, in particular
verify that α1 = r · ρ2 + m · ρ1 and α2 = r · ρ1 .
• There are records (sid, RB , KA ; ·) and (keygen, XA , ·, ctkey , pk; ·);
• C0 = (r ⊙ UA ) ⊕ (m ⊙ KA ) and C1 = r ⊙ KA , where r = R|x−axis .
3. Query G ∗ on input (sign, M, R), obtain and output σ = (r, s).
72 Authors Suppressed Due to Excessive Length

SIMULATION
24 G ∗ -Simulation for Π2ecdsa = (Π2kgen , Π2pres , Π2sign ) - Party B is

corrupted

Party B is corrupted (controlled by A):

S runs A internally, and responds to the following invocations

– Π2kgen ((G, G, q)):

LDL
1. Simulate Fcom−zk by sending (receipt, pidA ) to A.
L
2. Simulate FzkEncDL by receiving (prove, pidB , XB , ctkey , pk; xB , η) from A. If
ctkey ̸= AHE.Enc(pk, xB ; η) or XB ̸= xB · G then abort. Otherwise:
(a) Query G ∗ on input keygen and obtain X.
(b) Set XA = X − XB .
(c) Simulate Fcom−zk by sending (decom–proof, pidA , XA ) to A.
(d) Record (keygen, XB , X, ctkey , pk) and output whatever A outputs.
– Π2pres ((G, G, q), sid)
1. Query G ∗ on input pres and obtain R.
2. Compute KA = Com(0, ρ) for some ρ ← Rpp .
LDCom
3. Simulate Fcom−zk by sending (proof, sid||pidA , KA ) to A.
L [G,R ,q]
4. Simulate FzkDL B
by receiving (prove, sid||pidB , G; kB ) from A. If kB ·
RB ̸= G then abort.
5. Record (sid, RB , R) and output whatever A outputs.
– Π2sign ((G, G, q), sid, M ):
1. Retrieve R from the record (presign, sid, ·, R; ·), if such a record does not exist
then abort.
2. Query G ∗ on input (sign, M, R), obtain σ = (r, s) and set m = H(M ).
3. Set ctA ← SEval (pk, s′ ) where s′ = s · (kB )−1 mod q and SEval is the simulator
associated with the AHE scheme (Def. 2.1).
4. Simulate zero-knowldege proofs:
L [pp,G,q]
– Simulate FzkDComDL by sending (proof, sid||pidA , KA , R, RB ) to A.
LDComRatio [pp,G,G,q]
– Simulate Fzk by sending (proof, sid||pidA , KA , UA , XA ) to
A.
L [pp,pk,ctkey ]
– Simulate FzkDComEval by sending (proof, sid||pidA , ctA , C0 , C1 ) to
A.
5. Output whatever A outputs.
 2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC 73

PROTOCOL 25 2-Round Presigning Π2r−pres : Presign2r ((G, G, q), sid)
The protocol interacts with B1 , . . . , Bn where everyone has pk and ctkey as input. Before
proceeding, all parties verify that sid has never been used before. Then each party Bi :

1. First Round:
i i
(a) Samples γi ∈ [0, q), ηmask 1
, ηmask 2
, and computes
i i
i. ct1 = AHE.Enc(pk, γi ; ηmask 1
),
ii. cti2 = AHE.Eval(pk, fi , ctkey ; ηmask
i
2
) where fi (x) = γi · x,
L [pk,ct ]
and sends (prove, sid, pidi , cti1 , cti2 ; γi , ηmask
i
1
i
, ηmask2
) to FzkEncDH key
.
∗ i
(b) Samples ki ← Zq , and ηmask3 .
(c) Computes Ri = ki · G and cti3 = AHE.Enc(pk, ki ; ηmask i
3
) and sends
i i LEncDL
(com–prove, sid, pidi , Ri , ct3 ; ki , ηmask3 ) to Fcom−zk .
2. Second round:
(a) Receives for each party index j:
L [pk,ctkey ]
i. (proof, sid, pidj , ctj1 , ctj2 ) from FzkEncDH ,
ii. (receipt, sid, pidj ) from Fcom−zk ,
(b) Computes ct1 := ⊕j ctj1 , ct2 := ⊕j ctj2 .
LEncDL
(c) Sends (decom–proof, sid, pidi ) to Fcom−zk .
i
(d) Samples ηmask4 ∈ Rpk ,
(e) Computes cti4 = AHE.Eval(pk, fi′ , ct3 ; ηmask i
4
) where fi′ (x) = ki · x.
i i i i L [pk,ct1 ]
(f) Sends (prove, sid, pidi , ct3 , ct4 ; ki , ηmask3 , ηmask4 ) to FzkEncDH .
3. Proof verification:
Bi aborts if one of the following is not received:
(a) (decom–proof, sid, pidj , Rj , ctj3 ) from Fcom−zk ,
L [pk,ct ]
(b) (proof, sid, ctj3 , ctj4 ) from FzkEncDH 1

4. Output:
Bi records (presign, sid, R, ct1 , ct2 , ct4 ), where:
(a) R = R1 + . . . + Rn .
(b) ct1 is an encryption of γ mod q.
(c) ct2 is an encryption of γ · xB mod q.
(d) ct4 := ⊕i cti4 is an encryption of γ · kB mod q.
74 Authors Suppressed Due to Excessive Length

SIMULATION
26 G ∗ -Simulation for Π2r−pres - Parties {Bj }j∈[n]\{i} are

corrupted

– Π2r−pres ((G, G, q), sid)

1. Query G ∗ on input pres and obtain R.
2. B’s message:
(a) First round:
i i i
i. Sample ηmask 1
, ηmask2
, ηmask 3
.
i i
ii. Compute ct1 = AHE.Enc(pk, 0; ηmask 1
), cti2 =
i i i
AHE.Enc(pk, 0; ηmask2 ), ct3 = AHE.Enc(pk, 0; ηmask3 ).
L [pk,ct ]
iii. Simulate FzkEncDH key
and send (proof, sid, pidi , cti1 , cti2 ) to A.
LEncDL
iv. Simulate Fcom−zk and send (receipt, sid, pidi ) to A.
(b) Second round:
i. For each party index j ̸= i, receive from A (on behalf of Bj ):
A. (prove, sid∥γ, pidj , ctj1 , ctj2 ; γj , ηmask
j
1
j
, ηmask2
) by simulating
L [pk,ct ]
FzkEncDH key
.
LEncDL
B. (com–prove, sid, pidj , Rj , ctj3 ; kj , ηmask j
3
) by simulating Fcom−zk .
j j j j
ii. Let M ⊆ [n] \ {i} be the set for which (ct1 , ct2 ; γj , ηmask1 , ηmask 2
) ̸∈
LEncDH [pk, ctkey ]. If M ̸= ∅ send (malicious, sid, M ) to A and abort
(simulating an abort by party Bi ).
iii. Compute ct1 := ⊕i cti1 , ct2 := ⊕i cti1 .
LEncDL
iv. Simulate Fcom−zk and send (decom–proof, sid, pidi , Ri , cti3 ) to A.
i
v. Sample ηmask 4
and compute cti4 = AHE.Enc(pk, 0; ηmask i
4
).
LEncDH [pk,ct1 ] i i
vi. Simulate Fzk and send (proof, sid, ct3 , ct4 ) to A.
vii. For each party index j ̸= i, receive from A (on behalf of Bj ):
LEncDL
A. (decom–proof, sid, pidj ) by simulating Fcom−zk .
j j j j
B. (prove, sid, pidj , ct3 , ct4 ; kj , ηmask3 , ηmask4 ) by simulating
L [pk,ct ]
1
FzkEncDH
viii. Let M ⊆ [n] \ {i} be the set for which (Rj , ctj3 ; kj , ηmask j
3
) ̸∈
j j j j
LEncDL or (ct3 , ct4 ; kj , ηmask3 , ηmask4 ) ̸∈ LEncDH [pk, ct1 ]. If M ̸= ∅, send
(malicious, sid, M ) to A and abort (simulating an abort by party Bi ).
3. Record (presign, sid, R, {γj }j∈[n]\{i} , ct1 , ct2 , ct4 ) and output whatever A
outputs.