Feldman’s Verifiable Secret Sharing for a Dishonest Majority

. Verifiable secret sharing (VSS) protocols enable parties to share secrets while guaranteeing security (in particular, that all parties hold valid and consistent shares) even if the dealer or some of the participants are malicious. Most work on VSS focuses on the honest majority case, primarily since it enables one to guarantee output delivery (e.g., a corrupted recipient cannot prevent an honest dealer from sharing their value). Feldman’s VSS is a well known and popular protocol for this task and relies on the discrete log hardness assumption. In this paper, we present a variant of Feldman’s VSS for the dishonest majority setting and formally prove its security. Beyond the basic VSS protocol, we present a publicly-verifiable version, as well as show how to securely add participants to the sharing and how to refresh an existing sharing (all secure in the presence of a dishonest majority). We prove that our protocols are UC secure, for appropriately defined ideal functionalities.


Introduction
Feldman's verifiable secret-sharing scheme (VSS) [Fel87] is one of the classic verifiable secret sharing schemes in the literature, and has lately become very popular in the construction of practical threshold signing schemes.In general, the aim of a verifiable secret-sharing scheme is to ensure that all honest parties receive valid and consistent shares, even if the dealer and/or some recipients are corrupted.The way that Feldman's VSS achieves this is to augment a regular Shamir sharing with a broadcast of the sharing polynomial "in the exponent".That is, let b 0 = s and let b(x) = t−1 k=0 b k • x k .Then, in addition to sending each party their share, the dealer broadcasts B 0 , B 1 , . . ., B t−1 where each B k = b k • G.Each party P j , who is supposed to receive the share s j = b(α j ), then verifies that s j • G = t−1 k=0 (α j ) k • B k , ensuring that its shares is consistent with the single broadcasted polynomial in the exponent.Furthermore, since all parties receive the same B 0 , B 1 , . . ., B k by the security of broadcast, this ensures that they all have valid shares on the same polynomial.In the classic literature on VSS, an honest majority is considered, and the aim is also to ensure guaranteed output delivery, meaning that corrupted parties cannot prevent honest parties from obtaining output.
In this paper, we prove the security of Feldman's verifiable secret-sharing scheme (VSS) [Fel87] in the ideal/real model paradigm of secure multiparty computation for the case of a dishonest majority, achieving security with abort (meaning that honest parties may not necessarily obtain output).More specifically, as usual we consider n parties and a threshold t required to reconstruct the secret.However, we make no limitation on t, and security is guaranteed for any t ≤ n (and even t = n).Beyond the basic VSS, we consider a number of variants and additional operations that are useful in the threshold cryptography setting.In particular, we construct protocols and prove security for the following: 1. Basic Feldman VSS: This is the basic Feldman secret sharing with a dealer and n parties who participate.We stress that we do not assume an honest majority, and as such parties may abort (and some honest parties may abort while others have output).However, as with standard security with abort, it is guaranteed that the output of all honest parties who do not abort is consistent with the same valid sharing.
2. Feldman VSS with online and offline parties: In the basic VSS, all n parties send and receive messages.However, consider a setting where t-of-n parties participate in a distributed key generation protocol.In this case, t parties actually participate, and the other n − t parties just receive shares.This is sufficient since anyway any t parties can learn the key, and so it suffices for just t parties to generate the key (as we assume that strictly less than t parties are corrupted).Now, in regular Feldman VSS, it is possible to have the n − t parties be passive and merely receive their shares.However, what happens if some of those parties are offline.This can make sense if n ≫ t, or some of those n − t parties are actually just backup entities.In this case, there is no way to know if a party has received a valid share until they connect.In Appendix A.1, we show how small changes to the basic Feldman VSS protocol can be adapted to this setting.In particular, we utilize publicly-verifiable encryption [CD00] in order to essentially construct a publicly-verifiable secret-sharing scheme [Sta96,Sch99], where the t parties who are online can all verify that the shared values to the n − t offline parties are valid before the protocol terminates.This ensures that the sharing is valid, even if not all parties are connected.We note that the online parties may abort, but we achieve the guarantee that if any honest online party completes without aborting, then all honest offline parties are guaranteed to generate output and not abort.This is very significant in practice where an abort for online parties can be immediately detected and dealt with, but offline parties may discover problems a lot later, and dealing with it is more challenging.

Adding a party:
In some real-world applications where a key is shared among parties, it is necessary to be able to support the addition of new parties (without changing the threshold t).In particular, the set of parties who can approve a signing operation in a threshold signing setting may be dynamic (e.g., consider employees of a specific team at a cryptocurrency custodian).As a result, it is necessary to support adding and removing parties.Our protocol for adding a party works by having t parties subshare the new share to each other, and then send the sum of these subshareswhich constitutes a random sharing of the new share -to the new party.
4. Refresh: In order to achieve a level of proactive security where it is not possible to slowly steal shares from one party at a time, we provide a protocol that refreshes an existing secret sharing.The result of a refresh operation is that the parties all hold shares on an independent polynomial that defines the same secret.This is achieved by t parties using VSS to share polynomials that have the secret 0, and then adding all of those shares to the existing one.

Removing a party:
In the same way that it is sometimes necessary to add a party to an existing secret sharing, it is also necessary to revoke a share and remove a party from the sharing.This can be achieved simply by running the refresh operation, without providing the new share to the party being removed.This works since all other parties now hold shares on an independent polynomial, rendering the revoked party's share useless.
We remark that all of our protocols work with more general access structures than just a basic threshold.In particular, we can support any tree with AND, OR and threshold nodes, using standard methods.

Feldman's VSS for a dishonest majority:
The main differences between our protocol and the standard Feldman VSS for an honest majority are as follows: • Since we anyway achieve only security with abort, we do not need a full-blown secure broadcast of the vector (B 0 , . . ., B t−1 ), and it suffices for the parties to run a simple echo-broadcast of what they received.This ensures consistency between all honest parties that do not abort.
• In order to extract the polynomial that is shared in the proof of security when the dealer is corrupted, we need to have the dealer prove knowledge of the polynomial with a zero-knowledge proof of knowledge.In the honest majority setting (with the number of corrupted being less than half of the quorum required, so less than t/2 here) this is not needed since the polynomial can be extracted by the simulator receiving enough shares to reconstruct directly.This is because the number of honest parties in that setting is greater than the degree of the polynomial, something that isn't guaranteed in our setting (where up to t − 1 parties may be corrupted).
• Standard Feldman VSS has a "complaint" phase where parties can complain that they received an incorrect value and this is fixed by the dealer.In our case with no honest majority, if this occurs then a party will just abort, and so we do not need to "fix" anything.Importantly, as described above, we do ensure that all honest parties receive the same vector (B 0 , B 1 , . . ., B t−1 ), and this guarantees that all shares are on the same degree-(t − 1) polynomial.In the standard VSS setting, this would require a full-blown secure broadcast (since guaranteed output delivery is needed), whereas in our setting we can use a simple echo-broadcast with just one round where all parties send each other the vector they received.If a party did not receive the same output from everyone, then we just allow it to abort.This ensures that all honest parties who do output something have received the same vector from all other parties.The overall number of rounds is just two (over point-to-point channels).
On the security of Feldman VSS: Secret sharing schemes have the property that nothing about the secret s being shared may be revealed.However, in Feldman's secret sharing, the value S = s • G is revealed (this value is broadcast as B 0 ; see above).Thus, the basic Feldman VSS is not actually "fully secure" within itself, unless the value being shared is a hard-core bit of s and not s itself.This is often considered to be a "flaw" in Feldman's VSS.Nevertheless, in the context of elliptic-curve threshold cryptography where the sharing is of an elliptic curve key, the secret s being shared is either a private key or a share of the private key.In such cases, the public key, which is exactly s • G is supposed to be revealed.In addition, when VSS is used for distributed key generation, then each party shares some s i and the resulting private key is s = s i .In standard distributed key generation protocols, each s i • G is also revealed.Thus, Feldman VSS can be used without any loss or compromise in security.Indeed, for these applications, revealing s i • G is exactly what is needed in order to tie the shared values back to the actual key.As a result, in this context, the fact that s • G is revealed is a feature and not a bug, and simplifies protocol design.
Our formalization of security actually bypasses this issue by having the ideal functionality itself provide the exponents of the polynomial (B 0 , . . ., B t−1 ) to all parties.Thus, the security guarantees provided by the functionality are primarily those of correctness and consistency (all honest parties are guaranteed to have valid shares on the same polynomial).In terms of "hiding", this is only suitable for applications where the shares in the exponent can all be revealed.As discussed, this suffices for applications like elliptic-curve threshold cryptography, which is growing in use today.

On the use of Feldman VSS for key generation:
In general, VSS protocols reveal nothing about the shared value.As a result, the classic way of running key generation via VSS is for each party to share a secret in parallel, and to then sum the result.Of course, in the case that one also needs to obtain the public key, it is necessary to compute that while ensuring that it indeed matches the sum of the shared values.When using Feldman VSS, this latter task is trivial: as described above, each party's sharing reveals its associated "public key share", and the public key is just the sum of these values.However, when using Feldman VSS, if all parties just share their secret in parallel, then it is possible for the adversary to bias the result.This is because they can see the public shares of the honest parties (i.e., B 0 , . . ., B t−1 ) before they send their own shares.As a result, in order to obtain distributed key generation with full simulation, each party first sends an (extractable and equivocal) commitment to their VSS sharing.After receiving all commitments, the parties decommit, and simply sum the result.This prevents corrupted parties from biasing the result since they are committed to their sharings before learning anything about the honest parties' sharings.

Rounds of communication and asynchronous computation:
In some settings, and in particular in the threshold signing setting, it is possible that some parties involved in the operations (distributed key generation, adding a party, and so on) are humans with their personal devices.In these cases, protocols with many rounds of interaction are problematic, since ensuring that everyone is online together can be challenging.As a result, we aim for a minimal number of rounds.All of our protocols have two rounds, making it sufficient for each party to "connect" twice.That is, a human can connect and participate in the first round, and at a later time connect and participate in the second round, meaning that the connections can be asynchronous (except for knowing that the first round has completed).We also support having parties offline and later receiving their output, as described above.In this paper, we call parties asynchronous if they can be online to carry out computations, but we cannot require them to be online at the same time.As a result, they can each connect, download information from some "coordinator machine", prepare a message to be sent to other parties that is sent to the coordinator, and then disconnect.
In the specific case of refresh, in Appendix A.2 we also provide a variant with just a single round.This is due to the fact that distributed key generation, adding a party, and removing a party, are all less common tasks.In contrast, refresh is something that should be run periodically, and here having two rounds can be problematic.Clearly, it is impossible to achieve consensus with only a single round of communication (each party sending something).However, if there are also some "fully online parties" then we show that it's possible to run the consensus between these fully online parties only.The security guarantee is weaker (requiring at least one honest fully online party) but enables us to achieve practical refresh with asynchronous parties.

Security model and composition:
We prove security for the stand-alone definition of secure multiparty computation [Can00,Gol04] for security with abort (where some honest parties may have output and some may abort) and with no honest majority.In this model, all parties send their inputs to the ideal functionality (computed by a trusted party).The ideal functionality then sends the (ideal-model) adversary the corrupted parties' outputs, and the adversary then instructs the ideal functionality as to which honest parties should receive output.In some cases, the functionality may be interactive, with the adversary interacting with the functionality.This is used to model issues like the fact that the adversary may be able to influence the secret sharing polynomial, but in no way that affects security.For example, it can choose its sharing as a function of the corrupted parties' shares from the honest parties' sharings.This is inconsequential, but must be included in the functionality definition.
Although we prove security in the stand-alone model that guarantees security under sequential composition only, we are really interested in UC security [Can01]; i.e., security under concurrent general composition.This is achieved by all our protocols, since they are all perfectly secure with straight-line simulation (i.e., no rewinding).As shown in [KLR10], this implies UC security.We remark that the actual VSS protocol is only perfectly secure in the ideal zero-knowledge hybrid model.However, this suffices since it means that as long as the zero-knowledge proof of knowledge is instantiated with a UC-secure protocol, then everything is UC secure.

A note on novelty:
To the best of our knowledge, a formal description and proof of security for Feldman's VSS in the case of a dishonest majority has not appeared previously in the literature.Our protocols are based on well-known techniques, but have not previously been formalized and proven.This has value, for example, to ensure that zero-knowledge proofs are used in the sharing (something not always done in naive implementations).In addition, our simple protocols for adding a party and refreshing a sharing have also, to the best of our knowledge, not appeared previously.

Preliminaries
Group and field: We work over an additive group G of order q, with group generator G.We denote scalars in Z q with lower-case characters, and group elements of G with upper-case characters.For the secret sharing, we consider polynomials over the field F q (i.e., the same q which is the order of G).

Lagrange interpolation:
Let α 1 , . . ., α n be distinct field elements.We denote the Lagrange basis polynomials with respect to a set I ⊆ [n] by L I i i∈I where L I i (x) = j∈I\{i} x−αj αi−αj .The standard Lagrange interpolation works by the fact that for any set of t distinct points {(α i , β i )} i∈I , it holds that f (x) = i∈I β i • L I i (x) is the unique degree-(t − 1) polynomial such that f (α i ) = β i for every i ∈ I.

Zero-knowledge:
We describe and prove our protocols secure with an ideal functionality for a (batch) zero-knowledge proof of knowledge of the discrete log of a series of group elements in the group G with generator G.The relation is formally defined by: We denote an ideal zero-knowledge proof of knowledge functionality for this functionality by F BatchDL zk (we omit the parameterization of the group G and generator G from here on).This can be realized with UC security in the random-oracle model by applying the Fischlin transform [Fis05] to the standard Sigma protocol for discrete log by Schnorr [Sch89], in parallel for each value.The functionality is a pairwise functionality, and so the prover to party P j if the proof is valid, and sends prove, sid, i, j, Practically, we realize this by having each P i generate a non-interactive proof and simply send it to each party separately.We stress that this means that the functionality does not guarantee that all parties receive the same proof.In our protocols this does not matter, since we anyway guarantee that the statement being proven is the same for all parties, and this suffices.

Ideal Functionality Definitions
In this section we define the ideal functionalities for each of the operations we support.We do not define a "remove party" functionality since, as we have described, this is easily carried out by just running refresh without including the party to be removed.

Honest parties' outputs:
As described above, we consider a setting of security with abort, where some honest parties may abort while others receive output.This is modeled by having the adversary send the trusted party/ideal functionality the set of honest parties to receive output.This can be modeled within the instructions of the adversary, or as part of the ideal-model execution.We choose the latter, with the understanding that these are equivalent.We denote the list of honest parties sent by the ideal adversary/simulator in the ideal execution that should receive output by O h .

VSS
We define a VSS functionality F vss for sharing a secret s via a degree-(t − 1) polynomial s(x).The functionality also sends all of the polynomial coefficients "in the exponent" . These additional values help to enforce correct behavior (in the dishonest majority setting).Recall that, as we have discussed, releasing S = s • G is not "leakage" per se in our application, since we use this functionality for the case that s is an EC private key (or a share of an EC private key).In this case, S is its associated public key which is supposed to be public.

Functionality F vss :
• Upon receiving input from party 7. Send (share, sid, B, s j ) to party P j for j = 1, . . ., n A more minimal functionality?The F vss functionality reveals to the parties not only S = B 0 = s • G, but also all of the polynomial coefficients in the exponent B 1 , . . ., B t−1 for all parties.In our uses of F vss , the value S = B 0 = s • G is always revealed, as it is the public key and s is the private key (or they are shares of the public/private keys but also revealed).However, the additional B 1 , . . ., B t−1 need not be revealed in principle.As such, it may seem that this formulation reveals more information than necessary, and it would be better to have the functionality send only (share, sid, S, s j ) where S = s • G for the secret s.However, it is easy to see that the basic Feldman secret sharing does not securely compute a minimal functionality where parties only receive (share, sid, S, s j ) from the ideal functionality.This is because the distinguisher sees all outputs -of both honest and corrupted parties.Now, in the real execution, the corrupted parties see the polynomial "in the exponent" and so can compute S 1 , . . ., S n where S j = s j • G for all parties, including the honest parties.In contrast, in an ideal execution where less than t parties are corrupted, the simulator cannot compute s j • G for an honest P j , given only the points of the corrupted parties.Thus, this more minimal functionality cannot be computed in this way, and any application using Feldman VSS will have to be proven secure for the above functionality, where B 0 , . . ., B t−1 (or equivalently, S 1 , . . ., S n ) are all revealed.Fortunately, for applications like distributed key generation and the like, this additional information can be simulated by choosing a random polynomial "in the exponent", and so it is inconsequential.
Observe also that a corrupted party sends s(x) and not just s (like an honest dealer) since in the real protocol, nothing forces a corrupted dealer to use a random polynomial.It is possible to securely realize a stronger functionality where a corrupted dealer sends s to F vss and the functionality chooses s(x), like for an honest dealer.Realizing this functionality would require a type of coin tossing where the dealer commits to a sharing of s and all other parties commit to a sharing of 0, and then all parties decommit and the sharing is the sum of all sharings.However, this is not needed in applications of secret sharing we are familiar with, and so would add unnecessarily complexity and cost.
Public verifiability: Publicly-verifiable secret sharing enables anyone to verify that each party's (encrypted) share is valid.This can be achieved canonically (with Feldman's VSS) by simply having the dealer encrypt each party's share under the recipient's public key using publicly-verifiable encryption.Then, given the coefficients of the sharing polynomial in the exponent, it is possible for anyone to compute any party's share in the exponent, and then verify its validity in the encryption.We do not model public verifiability any differently in the definition.Rather, we use it as a way of computing the standard F vss with only a quorum t of actively participating parties.In particular, we do not need the n − t additional parties to be online during the secret sharing itself.This is achieved by having the t online parties verify that the encrypted shares of all parties are valid, without the n − t additional parties needing to be online.We remark that public verifiability does not guarantee output delivery.However, it does provide us with a weaker version of guaranteed output delivery that is very meaningful.In particular, we achieve the property that if any honest online party does not abort then it is guaranteed that all offline honest parties do not abort.
More general access structure: Our protocols all support access structures of a more general form of any tree of AND, OR and threshold nodes.The extension of the sharing to access structures of these types is straightforward.We therefore focus on the basic threshold case only; the proof remains essentially the same for the general case.

Add Party
We also define a functionality F add for adding a new party to the sharing.This involves computing s(α n+1 ) for a new P n+1 .

Verify that s
Reconstruct s(x) to be the unique polynomial such that s(α i ) = s i for all i ∈ I 5. Compute s n+1 = s(α n+1 ) 6. Send (add, sid, B) to the adversary 7. Send (add, sid, B, s n+1 ) to P n+1 We remark that in the protocol computing this, P n+1 is a passive recipient only.

Refresh
Finally, we define a functionality F refresh for refreshing the sharing.This involves interactively computing a sharing of a new random polynomial s ′ for the sharing, with the constraint that s ′ (0) = s(0).As we will see below, this works by having all parties choose a random sharing of 0, and then defining the refreshed sharing to be the sum of the original sharing plus all the new ones.This is clearly a new sharing of the same value.A naive definition of this functionality would be for F refresh to simply reconstruct the secret and choose a new random polynomial with the same secret.However, securely realizing this functionality would be difficult since it would require the result to be a completely random polynomial.As such, all parties would have to commit to their sharings of 0 and then decommit (to ensure that no sharing is chosen as a function of the other sharings).However, there is no real need for the polynomial to be truly random.Therefore, we enable the ideal model adversary to receive the new sharing chosen by F refresh and to then send a sharing of 0 to be added to it.This models the adversary's ability to bias the sharing polynomial in the real protocol by first seeing the shares of the honest parties and only then sending its sharing.This does not negatively impact security since adding a known polynomial to a secret random polynomial does not leak any information about the secret.Functionality F refresh : • Upon receiving (refresh, sid, B, s i ) from t parties I: 1. Verify that all received B are the same 2. Parse B = (B 0 , . . ., B t−1 )

Verify that s
8. Compute ŝj = ŝ(α j ) for all j = 1, . . ., n 9. Send refresh, sid, {ŝ(α i )} i∈Ic , B to the adversary, where I c denotes the set of corrupted parties, and await the adversary's response • Upon receiving (refresh, sid, s(x)) from the adversary after sending it refresh, sid, {ŝ(α i )} i∈Ic , B (if before that, then ignore): 1. Verify that s(x) is a degree-(t − 1) polynomial and that s(0) = 0 ) for j = 1, . . ., n 6. Send refresh, sid, B ′ , s ′ j to party P j for j = 1, . . ., n 7. Send (refresh, sid, B ′ ) to the adversary We remark that in the protocol computing this, all parties P j with j / ∈ I are passive recipients, receiving messages only.

Securely Computing F vss with n Online Parties
Intuition: The protocol works by the dealer computing Shamir shares of the secret, and then sending each party its share as well as the coefficients of the polynomial "in the exponent" (in elliptic-curve notation, this means that each coefficient b k is given as Since groups support multiplication by a scalar and addition, it is possible for any party to compute the polynomial in the exponent (meaning compute f (a) • G for any a) given a and the coefficients in the exponent (even without knowing f itself).Thus, each party verifies that its share is consistent with the polynomial in the exponent, as well as running an echo-broadcast on the coefficients to ensure that they all received the same polynomial.This ensures that all honest parties hold shares on the same degree-(t − 1) polynomial, as required.
Parties: P 1 , . . ., P n with P i being the dealer Common input: sid ∈ {0, 1} * , parameters t, n ∈ N with t ≤ n, and unique non-zero values α 1 , . . ., α n ∈ F q P i 's private input: s ∈ F q The protocol: 2. Round 2 -each P j with j ̸ = i: Upon receiving (share, sid, B, s j ) from P i and (prove, sid, . ..) from F BatchDL zk (a) Parse B = (B 0 , . . ., B t−1 ) (b) Verify that all B k are valid group elements (they are allowed to be the identity) Proof.Let I = [n] denote the set of all parties, let I c ⊆ I denote the set of corrupted parties, and let I h def = I \ I c denote the set of honest parties.If I c is empty, then simulation is trivial; we therefore assume that there is at least one corrupted party.We separately consider the case that the dealer P i is honest, and the case that the dealer P i is corrupted.
Case 1 -the dealer P i is corrupted: The simulator for this case works simply by running the honest parties (this is easy since they have no secret input) and seeing which would abort or not, and by extracting the polynomial from the adversary via the zero-knowledge proofs of knowledge to send to the ideal functionality F vss .Let A be the real-world adversary.We construct an ideal world adversary/simulator S, as follows: 1. S invokes A with sid and receives the messages prove, i, j, sid, intended for F BatchDL zk and (share, sid, B j , s j ), for all j ∈ I h .

For every j
for every k = 0, . . ., t − 1 in the prove message for P j (b) If yes (to both), S simulates P j sending B j to all parties (c) Else, S simulates P j sending abort to all parties, and sends abort to F vss (and after simulating all honest parties sending their message in this round, S simulates all honest parties aborting) 3. S receives the message B ℓ j j∈Ic from A for every ℓ ∈ I h , where B ℓ j is the vector sent from the corrupted party P j to honest party P ℓ (note that P j may send different vectors B j to different honest parties) 4. For every ℓ ∈ I h to an honest party, or sends an incorrect s j to an honest party, then in the real execution all honest parties abort (since they instruct all honest parties to abort).Likewise, in the ideal execution, S sends abort to F vss and so all honest parties abort in the ideal execution.Next, if A sent a share message with different sets B and B ′ to two different honest parties, then all honest parties abort in the output phase, in both the real and ideal executions.This holds since all honest parties receive different B and B ′ in the second round.If none of the above happens, then it is guaranteed that all honest parties received the same set B, and they all received a valid share s j such that Thus, any honest party not aborting will output (share, sid, B, s j ) with the same set S, as in the ideal execution (since F vss computes B in the same way based on s(x)).Finally, note that if any corrupt party sends a different B ′ value to an honest party in the last step, then that party will abort in both the real and ideal executions.Thus, the distribution over the adversary and honest party's outputs are identical in both cases.
Case 2 -the dealer P i is honest: The simulation in this case works by simulating the messages that the corrupted parties would receive, using the shares received from F vss .Let A be the real-world adversary.We construct an ideal world adversary/simulator S, as follows: 1. S receives (share, sid, B, s j ) from F vss , for every j ∈ I c , where B = (B 0 , . . ., B t−1 ) 2. S invokes A with sid and simulates F BatchDL zk sending it prove, sid, i, j, {B k } t−1 k=0 for every j ∈ I c , and the honest dealer P i sending it (share, sid, B, s j ) for every j ∈ I c 3. S simulates all honest parties sending B to all corrupted parties in round 2 4. S receives the messages B ℓ j ℓ∈I h that A sends for every j ∈ I c to all honest parties ℓ ∈ I h 5.For every ℓ ∈ I h , if A sends B as received to the honest party P ℓ from every corrupted P j , then S adds ℓ to O h (the set of honest party to receive output, initially empty) 6. S sends O h to F vss to indicate which honest parties receive output

S outputs whatever A outputs
In order to see that the distribution over the messages in the real and ideal executions is identical, observe that the honest dealer in the real protocol chooses the polynomial s(x) identically to the way that the functionality F vss chooses the polynomial (given only s) in the ideal execution.Furthermore, the only impact that the corrupted parties can have in this execution is to send incorrect B values.These are easily simulated perfectly by S, as they only impact who receives output and who aborts.This completes the proof.
Observe that the simulator S in the proof of Theorem 2 is straight line (it does not rewind A).Since perfect security with a straight-line simulator implies UC security, as proven in [KLR10], we have the following corollary: Corollary 1. Protocol Π vss UC realizes with abort the functionality F vss in the F BatchDL zk hybrid model, in the presence of a static malicious adversary corrupting up to t − 1 parties, for any t ≤ n.
Securely computing F vss with t online Parties and n − t offline parties: In Appendix A.1, we show how a small change to Protocol Π vss enables t online parties to verifiably share values to n parties, n − t of them whom are offline, with the property that if any online party is (semi-)honest, then all offline parties are guaranteed to receive correct output.This can be important for cases that the offline parties may only connect much later on, and discovering that their sharing is not valid at that time will make recovery difficult.

Adding a Party
We describe this protocol directly for t online parties, with the new party being added being a passive recipient only.The protocol requires each of the t parties to send and receive a message to the quorum, and to then prepare a final message for the new member.Thus, in the case of asynchronous parties, each party has to connect twice.

Idea:
The idea behind this protocol is as follows.Let I ⊆ [n] be a set of online parties with |I| = t, with respective shares {s i } i∈I on a polynomial s(x).The aim of the parties is to generate s(α n+1 ) for the new party.By Lagrange interpolation, we have that ).Thus, each party P i with i ∈ I can simply send the new party P n+1 the value ), and P n+1 can compute the sum s n+1 = i∈I s n+1 i = s(α n+1 ).Unfortunately, this simple solution is insecure, since P n+1 can also compute i∈I thereby revealing the secret itself.As a result, instead of each party directly sending s i • L I i (α n+1 ) to P n+1 , the parties first subshare their shares amongst each other.Each party then locally sums the shares they receive, and the result is sent to P n+1 .With this method, P n+1 receives a random additive sharing of s(α n+1 ) which reveals nothing beyond that value, as required.
The simple way to implement this is for each P i to generate additive shares of s i • L I i (α n+1 ) to P n+1 to all the participating parties.Each party can then sum up the sub-shares that it receives, and send to P n+1 .By the fact that ), it is immediate that P n+1 receives a random additive sharing of s n+1 as required.Our actual protocol works differently, since this would require that all parties know who the participating parties are ahead of time.In practice, we wish to enable the first t parties to connect to participate (asynchronously), and so we therefore have each P i generate Shamir shares of s i .By multiplying by the appropriate Lagrange coefficients, the same effect is achieved.

Parties: A set of t parties {P i } i∈I with I ⊆ [n], and a new party P n+1
Common input: sid ∈ {0, 1} * , parameters t, n ∈ N with t ≤ n, and unique non-zero values α 1 , . . ., α n+1 ∈ F q P i 's private input: (B, s i ), as output from F vss (The protocol assumes that all parties have the same B and that s i is the correct share as defined by B.

If this may not be the case, then parties need to begin by echo-broadcasting B (to ensure that all honest parties hold the same vector), and each party needs to locally verify that s
The protocol: 1.Each party P i subshares its share: (a) P i chooses a random polynomial s i (x) of degree-(t − 1) such that s i (0) = s i (b) For every j ∈ I, P i computes s i→j = s i (α j ) (c) P i sends (sid, s i→j ) to party P j , for every j ∈ I.
Note that if the set of participating parties I ⊆ [n] is not known ahead of time, then each P i subshares to all parties, and the first t parties to connect only will continue to the next round.
2. P i generates the new party's subshare: upon receiving (sid, s j→i ) from t − 1 parties P j (a) (If P n+1 is not online, then this message is encrypted under P n+1 's public key, and signed with P i private signing key, using secure signcryption.)

. , B t−1 ), and aborts if not (d) P n+1 outputs (B, s n+1 )
Correctness: Before proving security, we show (for the sake of clarity) that the protocol output is correct.Observe that In the protocol, each s j→i is generated by s j→i = s j (α i ) where s j (0) = s j .Thus, i∈I s j→i • L I i (0) = s j where s j = s(α j ) is a point on the original sharing polynomial s(x) for which s(0) = s (and s is the original shared secret).Thus, as required.

Security:
We prove the security of the protocol under the assumption that all parties begin with consistent and valid input.That is, each party P i is given input (B, s i ) where , and all parties are given the same vector B. This makes sense in practice since this input is the output of a previous VSS execution.However, as described in the protocol, if this may not be the case, then it needs to be separately verified.If the above holds, then we say that the input is consistent and valid.2Theorem 4. Assume that the parties' inputs are consistent and valid.Then, protocol Π add realizes functionality F add with perfect security-with-abort, in the presence of a static malicious adversary corrupting up to t − 1 parties, for any t ≤ n.
1. S sends (add, sid, B, s j , α n+1 ) to F add for every j ∈ I c (These inputs are consistent and valid by the assumption in the theorem.) 2. S sends the round 1 messages that A should receive from the honest parties: (a) S chooses s j→i randomly for all j ∈ I h and i ∈ I c (b) S simulates each honest party P j sending s j→i to each corrupted party P i

S verifies that the sum of the messages sent by A is correct:
(a) Compute the sum of messages from A: i. S receives from A messages (sid, s i→j ) for all i ∈ I c and j ∈ I h ; all the messages sent by corrupted parties to honest parties in round 1 of the protocol ii.S receives from A the messages (B, s n+1 i ) for all i ∈ I c that the corrupted parties send to the honest Compute the sum of messages when playing corrupted parties honestly: i. S runs the corrupted parties I c honestly, given the correct inputs {s j } j∈Ic and the first round messages {s j→i } j∈I h ,i∈Ic that it generated in Step 2b of the simulation above (and using fresh randomness for the corrupted parties) ii.Let {ŝ j→i } j∈Ic;i∈I h be the round 1 messages and let ŝn+1 i i∈Ic be the round 2 messages sent by the corrupted parties in the execution by S where it runs all corrupted parties honestly iii.S computes ŝc = j∈Ic i∈I h ŝj→i Completion of simulation: (a) If ŝc = s c then S instructs F add to provide the output to P n+1 ; else, it instructs F add to provide abort / not provide output to P n+1 (b) S outputs whatever A outputs It is immediate that the distribution over the messages {s j→i } j∈I h ,i∈Ic received by the corrupted parties from the honest parties is identical in the real and ideal executions.This holds since these values are less than t secret shares on a random degree-t polynomial.It remains to show that the honest party P n+1 outputs (B, s n+1 ) in a real execution if and only if it outputs (B, s n+1 ) in an ideal execution.Since the adversary can decide to cause an abort or not depending on the values sent by the honest parties in the first round, we also need to ensure that the joint distribution over the messages from the honest parties and whether or not P n+1 aborts or not is also identical.However, under the assumption (that we prove below) that S detects accurately whether or not P n+1 aborts, this follows from the fact that the adversary (with randomness fixed at the beginning of the execution) is fully determined by the honest parties' messages.Thus, the view of the adversary fully determines whether or not P n+1 aborts.We now conclude by showing that S accurately predicts if P n+1 would abort or not.Intuitively, this holds since once the honest parties' round 1 messages are fixed, the sum of what the corrupted parties send must be a fixed value.This is due to the fact that otherwise P n+1 would not receive the correct s n+1 (in which case it certainly aborts).Formally: and so Observe that s n+1 is a fixed value (determined fully by the input sharing polynomial), albeit unknown to S. In addition, (j,i)∈I h ×I h s j→i • L I j (α n+1 ) is fully determined by the messages s j→i sent by S to A in the simulation of the round 1 messages, albeit again unknown to S. This holds because4 (j,i)∈I h ×Ic is fully determined by the messages sent from the honest parties to the corrupted parties in round 1 (by definition {s j→i } (j,i)∈(I h ×Ic) is the set of all s j→i messages sent by the honest to the corrupted, and the Lagrange coefficients depend only on the set of participating parties).Next, we have is fully determined by the input values and first message from the honest parties to the corrupted parties.
In order to see that (j,i)∈I h ×I s j→i • L I j (α n+1 ) • L I i (0) is fully determined from the input, observe that the t values {s j→i } with j ∈ I h and i ∈ I define a polynomial s j (x) with s j (0) = s j .This implies that where the second equality is simply because L I j (α n+1 ) is independent of i ∈ I, and the third equality is by the definition of Lagrange interpolation.All the values L I j (α n+1 ) and s j (0) are fully determined for all j ∈ I h , and thus the entire sum depends only on the input.
We conclude that the left-hand side 1) is fixed and independent of the messages sent by the adversary.This implies that after fixing the messages {s j→i } (j,i)∈(I h ×Ic) from the honest parties to the corrupted parties in round 1, the simulator S can choose all random values {s i→j } (i,j)∈Ic×I from the corrupted parties (independently of what A sends) and recompute using the input values {s i } i∈Ic and these chosen random values, playing the corrupted parties "honestly".If this sum equals the sum of values received from the corrupted parties, then the output will be correct for P n+1 and so S instructs F add to provide output.Otherwise, it instructs F add to not provide output to P n+1 .This completes the proof.
Observe that the simulator S in the proof of Theorem 4 is straight line (it does not rewind A).Since perfect security with a straight-line simulator implies UC security, as proven in [KLR10], we have the following corollary: Corollary 2. Assume that the parties' inputs are consistent and valid.Then, protocol Π add UC realizes with abort the functionality F add in the presence of a static malicious adversary corrupting up to t − 1 parties, for any t ≤ n.

Secure Refresh in the F vss -Hybrid Model
Intuition: The refresh protocol works by the parties generating a random secret sharing of 0 and adding it to the initial secret sharing.This clearly generates a random polynomial with the same constant term.In order to generate a random secret sharing of 0, we simply use F vss , verifying that each secret sharing is of 0 (this is easy to do, since s • G is revealed, and so all that is needed is to verify that this equals the identity point O).

Parties: A set of t online parties I ⊆ [n] (I denotes the online parties)
Common input: sid ∈ {0, 1} * , parameters t, n ∈ N with t ≤ n, and unique non-zero values α 1 , . . ., α n ∈ F q P i 's private input: (B, s i ), as output from F vss (The protocol assumes that all parties have the same B and that s i is the correct share as defined by B.

If this may not be the case, then parties need to begin by echo-broadcasting B (to ensure that all honest parties hold the same vector), and each party needs to locally verify that s
The protocol: 1. Phase 1 (2 rounds) -each (online) party P i (i ∈ I) deals a sharing of zero: We remark that Protocol Π refresh can be instantiated with Π vss or Π off vss for F vss , thereby yielding two variants with all online or only t parties online.This works since the parties only run local operations (to compute output) after the VSS output is received.

Security:
We prove the security of the protocol under the assumption that all parties begin with consistent and valid input.That is, each party P i is given input (B, s i ) where and B = (B 0 , . . ., B t−1 ), and all parties are given the same vector B. This makes sense in practice since this input is the output of a previous VSS execution.However, as described in the protocol, if this may not be the case, then it needs to be separately verified.If the above holds, then we say that the input is consistent and valid.Theorem 6. Assume that the parties' inputs are consistent and valid.Then, protocol Π refresh realizes functionality F refresh in the F vss -hybrid model with perfect security-with-abort, in the presence of a static malicious adversary corrupting up to t − 1 parties, for any t ≤ n.
Proof.Let I ′ ⊆ [n] denote the set of t online parties, let I c ⊆ [n] denote the set of corrupted parties, and let I h = [n] \ I c denote the set of honest parties.If I c is empty, then simulation is trivial; we therefore assume that there is at least one corrupted party.Since not all parties are online and participate in the protocol, we denote by I ′ c and I ′ h the respective sets of online corrupted and honest parties (i.e., I ′ c = I ′ ∩ I c and I ′ h = I ′ ∩ I h ).The idea behind the simulation is as following.The ideal functionality F refresh chooses a new random sharing, and provides the ideal adversary with its shares.The adversary can then choose to add any valid zero-sharing of its choice in order to determine the final polynomial.This reflects the fact that the real adversary can see the VSS shares of the honest parties before choosing its own shares.Thus, the sharing received by the ideal adversary/simulator S from F refresh reflects the sum of the original sharing and what the honest parties share.Thus, the simulator S subtracts the original sharing from the sharing received to receive a sharing of zero, and then simulates the honest parties sharings such that they sum to this sharing of zero.Finally, after receiving the corrupted parties' sharings from A, the simulator sums them up and sends them as the polynomial to be added to the sharing by the ideal functionality.
We construct a simulator S as follows: 1. Prepare values for simulating honest parties' sharings: i i∈Ic the sum of the honest parties' shares sent to the corrupted parties by s h i = ŝi − s i for every i ∈ I c , where ŝi is the new share received from F refresh and s i is the corrupted party's previous share (Note that for every i ∈ Ic it holds that (Note that S can always find such a polynomial.If t − 1 parties are corrupted, then this polynomial is fully determined from sj→i values and the fact that bi (0) = 0.) iii. S computes Sj ′ →i = sj ′ →i • G for j ′ ∈ I ′ h specified above, and for every i ∈ I c .S then interpolates "in the exponent" to find a random polynomial Bj ′ = Bj ′ 0 , . . ., Bj ′ t−1 such that Bj ′ 0 = O (the additive identity) and for every i ∈ I c it holds that Sj (As above, S can always find such a polynomial since at most t − 1 parties are corrupted and so at most t points are fixed, and since Lagrange interpolation can be computed "in the exponent" (i.e., on the group elements).)

Simulate the refresh protocol:
(a) S simulates the protocol playing F vss using the Bj and sj→i values for all j ∈ I ′ h computed above (including aborting if any invalid messages are sent, as specified in the protocol and in the F vss description) (b) Let {(share, sid∥i, s i (x))} i∈I ′ c be the messages the adversary A sends as the online corrupted parties sharings sent to F vss .If for any i ∈ I ′ c it holds that s i (0) ̸ = 0, then S simulates all honest parties aborting the protocol, and outputs whatever A outputs.
(If not all sharings are sent, then S just waits.)

S interacts with F refresh :
(a) S computes s(x) = i∈I ′ c s i (x) and sends s(x) to F refresh (the s i (x) polynomials are from the sharings sent by A to F vss above) (b) S instructs F refresh to provide output to an honest party P j if and only if A instructs F vss to provide output to P j in all sharings of 0 from corrupted parties 4. S outputs whatever A outputs, and halts If the distribution over the polynomials Bj j∈I ′ h and values {s j→i } j∈I ′ h ;i∈Ic is the same as in a real execution, then it is clear that the output distribution is identical.This is due to the fact that the rest of the simulation merely follows the instructions of the protocol, and due to the fact that the resulting sharing is guaranteed to match the output from the ideal functionality by how these values are chosen.However, since all sj→i values are chosen at random under the constraint that they sum to the correct value, and since all other values are derived from these, the distribution of values seen by the adversary in the real and ideal executions is the same.Furthermore, the sum of the values chosen by the simulator match exactly the output received from the ideal functionality, as required.
Observe that the simulator S in the proof of Theorem 6 is straight line (it does not rewind A).Since perfect security with a straight-line simulator implies UC security, as proven in [KLR10], we have the following corollary: Corollary 3. Assume that the parties' inputs are consistent and valid.Then, protocol Π refresh UC realizes with abort the functionality F refresh in the F vss -hybrid model in the presence of a static malicious adversary corrupting up to t − 1 parties, for any t ≤ n.

Refresh with offline parties and a coordinator machine:
In the case of asynchronous parties communicating via a coordinator machine that receives all (encrypted and signed) messages and forwards them to their appropriate destination, the refresh protocol can be implemented using Π off vss .This protocol guarantees that if any honest online party does not abort and if the coordinator machine is semi-honest, then all offline parties are guaranteed to not abort.However, in this protocol, each online party only needs to connect twice: in the first connection it plays the dealer, and in the second connection it receives the shares, signs the bundles and sends them to the coordinator.This can be a challenge for asynchronous parties, and we present a proposal for dealing with it in Section A.2.
Refresh with some fully online parties: In Appendix A.2, we show how with a few fully online parties, it is possible to achieve refresh where asynchronous parties need to send a single message only, as long as at least of one of the fully online parties is (semi-)honest.

A.1 Securely Computing F vss with t Online Parties and n−t Offline Parties
Intuition and security goal: Our above protocol considers a scenario where all n parties are online and interacting.However, given that we only obtain security for up to t − 1 corrupted parties (since we want to be able to reconstruct with any t parties), it actually suffices to have only t parties interact in an online manner in the VSS, and to have the remaining n − t parties be passive and merely receive output.This can be achieved naively by simply having the dealer send its round 1 message to only the online parties, and then having all online parties send their round 2 messages (and the dealer send its round 1 messages) to the offline parties as well (encrypted under each offline party's public encryption key).Upon receiving all of the messages from online parties, the offline parties can just verify that everything is consistent and output their share if yes.The above simple extension has a disadvantage in practical settings.In particular, offline parties in practice may take a long time until they come online.The desired property would be that whenever they come online, they should be able to receive their share and join any needed computation.However, if the dealer or one of the online parties sends an offline party an incorrect value, then the offline party would abort.Given that this may happen a long time after the shares were generated, dealing with this at that time is costly and painful.As such, we would like to ensure that the offline parties can successfully obtain their shares later.This is of course a problem since in the setting of a dishonest majority, it is impossible to achieve guaranteed output delivery.In particular, in our VSS sharing protocol above, it suffices for a corrupted party to send a different B ′ vector in round 2 and all honest parties will abort.This is in some sense unavoidable.However, it is possible to achieve a guarantee that if any honest online party accepts then so will all honest offline parties later on.This can be achieved by having all parties sign on the public B, and then each online party sends each offline party all the signatures.If there are t valid signatures on some B then the offline party accepts that as the value.This prevents a corrupted party sending an invalid B ′ in round 2. However, this still does not solve the problem that the dealer may send an offline party an incorrect share s j .This can be prevented by having the dealer send a publicly-verifiable encryption of the share for each offline party.Such an encryption has the property that it's possible to efficiently verify that some ciphertext is a valid encryption of the discrete log of some group element.This enables all online parties to verify all offline party shares, and to sign on these ciphertexts together with B.

Publicly-verifiable encryption:
As mentioned above, in the context of our applications here, publicly-verifiable encryption is an encryption scheme with an additional property that it is possible to verify (in zero knowledge) that the encrypted value is the discrete log of a given point.That is, such a scheme has standard encrypt and decrypt functionality, denoted c = vencrypt pk (x) and x = vdecrypt sk (c), along with a verification function enc-verify(pk, c, X) that outputs 1 if and only if c is an encryption of the discrete log of X under public key pk.A simple and canonical construction of such a scheme (that works with any encryption scheme) can be found in [CD00].The following ideal functionality, denoted F PVE , models publicly-verifiable encryption and runs with parties P 1 , . . ., P n : • Init: after receiving init from all parties P 1 , . . ., P n (for setting up a PKI), proceed.
(Before receiving all init messages, ignore all other messages.) • Encrypt: upon receiving (vencrypt, i, j, m) from a party P i with m ∈ Z q 1. Compute M = m • G 2. Store (i, j, m, M ) the coordinator receives all (share, sid, B, V, σ j ) at the end of round 2, and prepares the message share, sid, B, V, {σ k } k∈Ion which it sends to all offline parties.This therefore simplifies the protocol, and all online parties need to only connect once and then later download their output.We stress that if the coordinator is malicious, then the only thing that can go wrong is for the parties to abort.
A.2 Refresh with ℓ Fully Online Parties, t−ℓ Asynchronous Online Parties, and n − t Offline Parties Aim: Our aim is to construct a refresh protocol that requires asynchronous online parties to only connect once, since connecting more than once for an operation that should happen regularly (like refresh) is very problematic.Clearly, if we assume that all participating parties are asynchronous, then this cannot be achieved.In particular, there is no way to ensure consensus between the values shared by the parties in a single round.However, if we assume that there are some fully online parties (we call them fully online parties to differentiate them from the asynchronous online parties who connect and disconnect), and we assume that at least one of these fully online parties is semi-honest then the consensus can be verified by them.We remark that the consensus could also be verified by the coordinator, and recall that in Π off vss we also had the assumption that the coordinator was semi-honest.However, that protocol had the guarantee that if the coordinator was malicious, then the only bad thing that can happen is that parties abort.In contrast, here, if the coordinator verifies the consensus and it is malicious, then parties may output shares that are not consistent (i.e., do not lie on the same degree-(t − 1) polynomial).Therefore, rather than relying on a single machine, we assume that there are some ℓ fully online parties, and as long as one of them is semi-honest -and not all of them malicious, security (and even output delivery) is guaranteed. 5We do stress, however, that if all fully online parties are malicious, then security is not guaranteed.(Although it is hard to separate correctness and privacy in secure computation, the aspect that breaks is only that of correctness.This means that the parties may end up having inconsistent shares, and so will not be able to operate.However, this can only happen if all fully online parties are corrupted.)Protocol: The above discussion yields the following protocol for refresh.
Protocol 9 (Π ′ refresh ).Parties: A set of ℓ fully-online parties {P i } i∈Iperm-on , a set of t − ℓ asynchronous online parties {P i } i∈Iasync-on , and n − t offline parties {P i } i∈I off .The sets I perm-on , I async-on , I off are disjoint, and their union is [n].
Common input: sid ∈ {0, 1} * , parameters t, n ∈ N with t ≤ n, and unique non-zero values α 1 , . . ., α n ∈ F q P i 's private input: (B, s i ), as output from F vss (The protocol assumes that all parties have the same B and that s i is the correct share as defined by B. If this may not be the case, then parties need to begin by echo-broadcasting B (to ensure that all honest parties hold the same vector), and each party needs to locally verify that s i • G = The protocol:

Phase 1 (single round) -each asynchronous online party P i shares a zero-sharing:
(a) Each online P i computes the first round of Protocol Π off vss for a sharing of zero, and with the offline parties defined to be all in [n] (i.e., all parties' shares are encrypted using publicly-verifiable encryption) (b) Each online P i signs their sharing values, and sends them to the fully-online parties 2. Phase 2 -fully-online parties: (a) Each fully-online party runs rounds 2 and 3 of Protocol Π off vss : the parties check all values and ZK proofs, echo-broadcast among themselves to verify consistency of all sharings, and gather signatures (of the fully-online parties and the asynchronous online party who shared) (b) Each fully-online party sends the bundle to the coordinator, for all parties to download 3. Output: (a) Each party (asynchronously-online or offline) downloads the bundle from the coordinator (b) Each party verifies that the bundle has the signature of all the fully-online parties, that the bundle contains t sharings of zero (i.e., verifying that each B 0 = O), and that each sharing is signed by a different asynchronous-online party.(c) For each of the t sharings, each party decrypts their publicly-verifiable encryption and verifies its consistency with the sharing polynomial vectors B (d) Each party runs phase 2 (generate output) in Π refresh , and outputs the result Security: The proof of security of Protocol Π ′ refresh is essentially the same as that of Theorem 6, with the only difference being which subset of parties carries out the consistency checks.
(a) S verifies that the B vectors received by P ℓ are all the same (based on the B j values computed for the honest parties, and the B ℓ j values received for P ℓ ) (b) If yes, S adds ℓ to O h (the set of honest party to receive output, initially empty) 5. S defines s(x) = t−1 k=0 b k • x k and sends (share, sid, s(x)) to F vss , together with the list of honest parties O h to receive output 6. S outputs whatever A outputs If A sends an incorrect proof to F BatchDL zk (a) S invokes A upon input {(refresh, sid, B, s i )} i∈I ′ c (These inputs are consistent and valid by the assumption in the theorem.)(b) S sends {(refresh, sid, B, s i )} i∈I ′ c to the trusted party computing F refresh , and receives back refresh, sid, {ŝ i } i∈Ic , B ; let B = ( B0 , B1 , . . ., Bt−1 ) (c) S computes B h = Bh 0 , Bh 1 , . . ., Bh t−1 , the public sum of the "honest parties' sharings", by Bh k = Bk − B k for k = 0, . . ., t − 1, where Bk is from B received from F refresh and B k is from B in the input (d) S computes s h e) S chooses random {s j→i } j∈I ′ h ;i∈Ic under the constraint that for every i ∈ I c ,j∈I ′ h sj→i = s h i (f) S finds random polynomials Bj j∈I ′ hunder the constraint that they sum to B h and that for every j ∈ I ′ h and i ∈ I c it holds that sj→i• G = t−1 k=0 (α i ) k • Bj k , as follows: i.Let j ′ ∈ I ′ hii.For every j ∈ I ′ h \ {j ′ }, S chooses a random degree-(t − 1) polynomial bj (x) such that bj (0) = 0 and for every i ∈ I c it holds that bj (α i ) = sj→i .S sets Bj = ( Bj 0 , . . ., Bj t−1 ) by Bj k = bj k • G where bj (x) = t−1 k=0 bj k • x k .
i ) k • B k where B = (B 0 , . . ., B t−1 ).) send abort to all parties and abort (d) If the message from F BatchDL BatchDL zk is not the same as B, then send abort to all parties and abort (f) Send B to all P ℓ with ℓ ∈ [n] (In practice, it suffices to send H(B), where H is a collision-resistant hash function.)3. Output -each P j : upon receiving B 1→j , . . ., B n→j (where B ℓ→j denotes the set B that P j received from party P ℓ ) (a) Abort unless B 1→j = • • • = B n→j = B (b) Output (share, sid, B, s j ) Security: We now prove the security of the protocol for up to t − 1 corrupted parties.Since t is the minimum quorum size (and t can even equal n), this is the setting of a dishonest majority (i.e., security as long as at least one party is honest).Protocol Π vss realizes the functionality F vss in the F BatchDL zk -hybrid model with perfect security-with-abort, in the presence of a static malicious adversary corrupting up to t − 1 parties, for any t ≤ n.

Phase 2 -each (offline and online) party
Each online P i sends F vss the message (share, sid∥i, 0) (b) Every (online and offline) P i receives share, sid∥j, Bj , sj→i i∈I , where Bj = Bj 0 , Bj 1 , . . ., Bj t−1 and sj→i is P i 's private share in the secret sharing from P j 2. P i (i ∈ [n]) generates output: (a) If not all t outputs share, sid∥j, Bj , sj→i i∈I are received (i.e., if any aborts), then output abort and halt (b) Let Bj = Bj 0 , Bj 1 , . . ., Bj t−1 and let B = (B 0 , . . ., B t−1 ) (c) Abort if any Bj 0 ̸ = O (i.e., if any of the secret sharings are not to zero)