Ranjit Kumaresan (UMD) Arpita Patra C. Pandu Rangan (IITMadras) The Round Complexity of Verifiable Secret Sharing: The Statistical Case The title of my talk is … I am …. And this is joint work with … 20s Ranjit Kumaresan (UMD) Arpita Patra C. Pandu Rangan (IITMadras)

Verifiable Secret Sharing (VSS) Two-phase protocol A dealer shares a secret among a set of n parties (t of which are malicious) in the sharing phase The secret is recovered in a reconstruction phase Verifiable… also known as … is typically described as a … The first phase, known as a sharing phase, allows a dealer to The second phase is a reconst… where the dealer’s secret is reconstructed 25s

Verifiable Secret Sharing (VSS) Two-phase protocol A dealer shares a secret among a set of n parties (t of which are malicious) in the sharing phase The secret is recovered in a reconstruction phase If the dealer is honest No information about the secret is leaked in the sharing phase All honest parties recover the dealer’s secret Perfect Privacy What properties do we want from VSS First, since it is a secret sharing protocol, we want an honest dealer’s secret to remain private in the sharing phase. We call this requirement perfect privacy We also want that an honest dealer’s secret to always be reconstructed correctly… we call this “…” 30s Perfect Correctness

Verifiable Secret Sharing (VSS) Even if the dealer is dishonest The view of the honest parties in the sharing phase defines a value s such that each honest party outputs s in the reconstruction phase Perfect Commitment We also require some form of commitment that is verifiable when the dealer is dishonest… This is captured by requiring that the view of the honest … defines…, and this value is reconstructed. We call this property “perfect commitment” 30s

Verifiable Secret Sharing (VSS) Building block in honest majority MPC constructions Critical Parameter: Round Complexity Perfect VSS possible iff t < n/3 What about t < n/2 ? Relaxation: Statistical VSS VSS is an important primitive and is primarily used as a building block in MPC in the honest majority setting A critical parameter therefore would be the round complexity … Previous literature has extensively focused on reducing the round complexity of the sharing phase in particular… so usually when we refer to round complexity of a VSS protocol, we refer to the round complexity of the Sharing phase. It is well known that perfect VSS as described in the first few slides is possible iff t<n/3 . Since we are in the IT setting, a natural threshold would be t<n/2… and a natural question would be whether we can achieve something similar to VSS… A potential relaxation would be to consider a statistical variant of perfect VSS 1m

Statistical Verifiable SecretSharing Relax any requirement of Perfect VSS to hold with all but negligible probability Privacy Correctness Commitment Improves round complexity even for t < n/3 [PCRR09] Achievable for t < n/2 assuming broadcast channel [RB89, CDDHR99] So we could relax any of the 3 requirements of perfect vss to hold with all but… A recent crypto result from Patra et al., has shown that this relaxation helps us even in the t<n/3 setting. They achieve optimal round complexity of this relaxed statistical notion when t<n/3 setting. A look at prior work reveals that **assuming a broadcast channel** stat vss is indeed achievable for t<n/2 … this follows from the work of RB, CDDHR. 50s

Statistical VSS (in this work) If the dealer is honest No information about the secret is leaked in the sharing phase All honest parties recover the dealer’s secret except with negl. prob. Even if the dealer is dishonest The view of the honest parties in the sharing phase defines a value s such that each honest party outputs s in the reconstruction phase except with negl. prob. Perfect Privacy Statistical Correctness In this work, we use the following notion of Stat vss… we do not relax the privacy requirement However, we do relax the other two, that is, we ask only for stat corr and stat com, instead of perf corr and com. So an honest dealer’s secret is reconstructed only with 1-negl prob, and a dishonest dealer is committed to an unique secret only with 1-negl prob 40s Statistical Commitment

Prior Work On Round Complexity Perfect VSS: Long line of work BGW88, GIKR01, FGGRS06,… 3 round sharing is optimal (with only one broadcast round [KKK08]) Statistical VSS for t < n/3 2 round sharing is optimal [PCRR09] Statistical VSS for t < n/2 3 round sharing is necessary [PCRR09] What is the optimal round complexity? As we mentioned earlier, round complexity is an important metric for VSS protocols. There’s been a long line of work in the perfect VSS setting, starting from BGW and continuing on to GIKR who settled the round complexity of vSS with an exponential protocol, and then to Fitzi et al., who gave an efficient protocol with optimal round complexity. Later Katz et al also show optimal use of the broadcast channel in a 3-round VSS protocol. For statistical VSS when t<n/3, Patra et al., in their crypto result show that 2 round sharing is optimal In the same work, they also show that for the t<n/2 case, 3 round sharing is necessary! One obvious open question from their paper is to give a 3 round VSS protocol or to prove impossibility! Here, we resolve this open question 70s

Best Known Prior Work Perfect VSS (t< n/3) Stat VSS (t< n/3) Sharing Phase 3 [GIKR01] [FGGRS06] 2 [PCRR09] > 5 [CDDHR99] Recon Phase 1 2 Here we highlight the best known prior work in various settings… 3 round sharing with one round reconstruction is optimal for the case of perfect vSS , and 2 round sharing is optimal when t<n/3 in the statistical setting. However for the case of t<n/2, cramer et al’s result is the best known, and they achieve VSS in a protocol that takes at least 5 rounds! 50s

Our Results Perfect VSS (t< n/3) Stat VSS (t< n/3) Stat VSS (t<n/2) Stat VSS (t<n/2) Sharing Phase 3 [GIKR01] [FGGRS06] 2 [PCRR09] >5 [CDDHR99] 3 (exp) [optimal] 4 (efficient) Recon Phase 1 2 Settles the question of optimal round complexity of Statistical VSS for t < n/2 For t < n/3, settled by [PCRR09] In this work, we give a 3 round exponential protocol for stat VSS when t<n/2. Round complexity wise this is the best one can achieve. In addition, we also give a 4 round efficient protocol 20s

Organization of the talk Building Block: Multi Verifier ICP Definition & Properties 9th min – 5.5m, 6.5 The talk is organized as follows: First we describe a building block for our protocol, namely Multiverifier ICP. We start by giving its definitions and properties

Organization of the talk Building Block: Multi Verifier ICP Overview of 4 round efficient VSS protocol Next we give an overview of our 4 round VSS construction.

Organization of the talk Building Block: Multi Verifier ICP Overview of 4 round efficient VSS protocol 3 round inefficient VSS protocol Generalizing Multi Verifier ICP Construction Finally, we look at our 3 round construction. On the way we also show how to generalize Multiverifier ICP and describe our construction based on this primitive. 70s 8th min – 6.5m

Multi verifier ICP: definition & Properties ICP - Information Checking Protocol Well known constructions by [Rab94, CDDHR99] Use to get Statistical VSS for t < n/2 2 phase protocol run by D (with input s) and INT and every other player as verifier [PCR09] Sh(D, INT, s) Rec(D, INT, s) INT holds D’s signature σD,INT(s) on s Our building block Is a primitive called Information checking protocol or ICP in short. There are well known constructions of ICPs by Rab 94, Cramer et al. One main use of an ICP protocol has been to obtain stat vss protocols for t<n/2. We note that traditionally the notion is used with a single verifier protocol. Extension… Formally speaking, the ICP protocol has two phases, the dealer has input s and there’s a special player called the intermediary. Here, we consider an extension from Patra et al., where every player acts as the verifier/ we get Mvicp We need, At the end of the sharing phase, INT to hold D’s signature on s, called sigma d int (s). Later during the reconstruction, INT reveals sigma d int (s), and each verifier either accepts or rejects the signature. 90s INT reveals σD,INT(s), Verifiers accept/reject

Properties of Multi Verifier ICP Honest D w.h.p. σD,INT(s) revealed only as s Honest INT w.h.p. every verifier accepts σD,INT(s) Adversary does not learn any information about s when D is honest Round Complexity of construction [PCR09]: Sh takes 3 rounds Rec takes 2 rounds We require certain properties from a multiverif icp prot… when D is honest, a corrupt INT should not be able to forge D’s signature on some other secret! next, when INT is honest, we want every verifier to accept the signature he possesses immaterial of whether the dealer is honest or not And when both are honest, we want the secret to be kept private from the adversary. We use the construction of Patra et al as a building block. In their construction for mvicp, the sharing phase takes 3 rounds and the rec takes 2 50s

Efficient 4-Round Stat VSS Protocol High level idea: Build on [CDDHR99] (based on bivariate polys) Use ICP to sign points on the polynomial Adapt round efficient Multi Verifier ICP into [CDDHR99] Construction Techniques: Random pad sent to D Enables D to cross-check and broadcast shares when necessary Early reveals Deal with overlapping Sh and corresponding Rec executions 13.5 min? 12.75m, 9.5m We give a brief overview of the construction of our 4-round vss protocol We build on the construction of Cramer et al. which is based on bivariate polynomials. They use single verifier ICP extensively to sign points on the polynomial. Our main idea is to replace the single verifier icp by the mvicp from Patra et al., and we hope to get a better round complexity Unfortunately directly plugging the ICP construction is not good enough, so we employ certain additional techniques. One is to send to D the random pad used for consistency checking. So Now D can also crosscheck and broadcast the disputed point if required. Another technique that we employ is of early reveals. So sometimes the rec phase of ICP starts before the corresponding Sh phase completes, and stuff like that. As a result, our protocol and its analysis is also slightly complicated ;) 80s

Using MVICP as a subprotocol Both D and INT are corrupt With D’s help, INT can reveal any value in Rec “Weak” commitment until last round In the last round of Sh, a corrupt D could arbitrarily change the secret Say that D conflicts with INT “Weak” reconstruction Decision to accept a signature reveal is based on a voting mechanism To obtain a 3 round vss, it appears that we need a base primitive stronger than MVICP… To see why let’s look at some “issues” that can arise in a MVICP execution. First, as you may recall, the MVICP does not provide any guarantees when both D and INT are corrupt. In particular now a dishonest INT could reveal any value in Rec and not be detected Next, the commitment to the secret provided in the early stages of the ICP protocol is very weak. To achieve the properties of ICP we actually allow the dealer to broadcast his secret in the last round if required. However, while using ICP as a subprotocol, this step can hurt us when the dealer is dishonest. He can now arbitrarily change the secret to whatever he likes in the last round. And This could potentially ruin all the consistency type checks which we performed in the earlier rounds. Lastly, the design of the reconstruction phase is excellent to guarantee ICP properties, but we should not forget that is interactive and hence in some sense weak. Honest players now need to make decisions based on dishonest votes. This may lead to problems, when we plug Icp as a subprotocol elsewhere as we will see later

Generalizing Multi Verifier ICP Have multiple INTs which receive the same value Let U represent the set of INTs If U contains t players, then can we ask for more? Specifically, want All players in U to be committed to one reveal (say, v) at the end of SetSh(D, U, u) even when D is corrupt u = v, for honest D Adversary does not have any information about u at the end of sharing phase unless either D or some player in U is corrupt Be here in 15th min (16.5!) 14.5, 13 In order to attempt a 3 round construction, we start by modifying our basic building block, that is MVICP to make it stronger. ICP’s properties as such is very powerful, but there are certain problems when we run it as a subprotocol, as we saw in the earlier slide. For ex when both d and int are corrupt, we are not guaranteed anything. a corrupt int can reveal any value as the dealer’s value and still get it’s reveal accepted during reconst So how should we modify our icp to attempt a resolution to the above problem. One way would be to have multiple ints receive signatures on the same value from D. Lets say If U is the set of INTs and if we guarantee that U has at least one honest player by making it size t, can we get more properties? Specifically the type of properties that we are looking for is 1… 2… 3…. Observe that these 3 properties are very similar to the VSS properties of commitment, correctness and privacy. In fact, if we iterate over all possible subsets as U, then we will get a direct construction of VSS! This actually is our main idea. 2m10s Directly gives us VSS!

Towards A 3-Round Protocol SetSh(D, U, u) : For each Pi in U: Round 1: D sends σD,i(u) to Pi For random rij, Pi sends σi,j(rij) to each Pj in U Round 2: Pi broadcasts aij = u+rij, bij= u+rji for all j Round 3: If aij ≠ bji, D broadcasts u If Pi conflicts with Pj, then broadcast entire view (i.e., including MVICP polynomials associated with σD,i(u)) ` 15m In the sharing phase of generalized version of Mvicp, we have that for each pi in U, D sends its signature on the secret small u associated with the set capital u. in parallel, pi and pj exchange random pads In the second round, pi broadcasts its share masked with the random pads to and from pj Note that aij = bji if both pi and pj are honest. In the case that these values do not match up, we ask d to broadcast the secret small u. Recall that we say pi conflicts with pj in an icp execution on rij, we might have problems. If this event happens inside the Shset protocol, we ask pi to broadcast his entire view in this Shset execution. Single conflict is not bad. An interesting case is when both pi and pj bc their entire view. We call this a mutual conflict. Note that when this happens then a dishonest pi or a dishonest pj is no longer bound to the random pads that was used in round 2! 2m -2m If both Pi and Pj broadcast their entire view we call it a mutual conflict

Towards A 3-Round Protocol SetRec(D, U, u) If D broadcasted u, then output u and terminate If no mutual conflict, then ask players to Reveal signatures Prove consistency with their broadcasts If any player passes the tests above, accept his value of u and terminate reconstruction Dealing with mutual conflicts is tricky… ` The reconst phase RecSet proceeds by the players checking if d bc-ed u during the sh phase. This is the easy case, everyone outputs u and terminates. If there was no mutual conflict in the sh phase, then we ask players to demonstrate that they behaved honestly in the sharing phase. Specifically we ask them to reveal all their signatures and prove that their round 2 masked bc-s are consistent with their reveals. If a player succeeds this test then his signature on u is accepted and all players terminate reconstruction. Of course there could be mutual conflicts… and this is where things could get tricky Recall that in a mutual conflicts two parties conflicted over the random pads, and are no longer required to show consistent behavior w.r.t the masked bc-s. Moreover, if the d is corrupt, then corrupt players involved in a mutual conflict could potentially reveal different secrets. We kind of partially fixed this by asking them to reveal their entire view at the end of the sharing phase, but even then, things could go wrong in the reconstruction phase! 90s

Dealing with Dishonest Verifiers Dishonest external verifiers could either Vote for corrupt party’s reveal Two successful reveals on different secrets! Abort Only one successful reveal Technique: Share Verification Info via SetSh! Non-mutually conflicting executions are good Require mutually conflicting reveals to pass all good verification points 18m This is where dishonest verifiers come into the picture as a non-trivial issue! A dishonest… two successful reveals… or he could abort, in which case we have only one successful reveal. It is not clear how to resolve this issue, and it looks like dishonest external verifiers have the liberty of choosing between these two options in the reconst phase, and obtaining commitment seems hard. 000000 Fortunately, we overcome this hurdle by sharing even the verification info via shset! We use only non-mut.. Which we call good exeuction. Note that in a good execution, check points are essentially committed and cannot be revealed incorrectly. We fixed the mutually conflicting reveals earlier, and now we have even fixed what those reveals are going to be checked against! Now we also require every mutually conflicting reveal of the secret to pass all the good verification points! This is because we might have very little number of honest verification points 2m

3-Round Construction: High Level Sharing: For all t-sized U: SetSh(D, U, u) For all t-sized V: SetSh(D, V, verV(u)) Reconstruction: For all t-sized U: If no mutual conflict, execute SetRec(D, U, u) Else, reconstruct check points from non-mutually conflicting SetSh(D, V, verV(u)) Flip Side: Exponential communication complexity MVICP poly F used in SetSh is of degree O(2 t) Need to increase field size for security Verification info for u held by V So the 3-round construction goes like this. We have a sharing phase for each subset, where the dealer shares the secret with the players in the subset We also share the verification points associated with this subset’s secret to every other subset V In the reconst phase, we do one of two things depending on whether there was a mutual conflict or not. If there was no mutual conflict then we do the regular recset In the other case, we reconst check points from non-mutually conflicting verification points So this is our 3 round construction This construction unfortunately is not without flip sides. First there is the issue of …, Next even the ICP poly used in Shset is of degree … Consequently we also have to increase the field size for security So there is definitely room for improvement 2m -2m

Recap 4-round sharing 2-round reconstruction efficient statistical VSS protocol 3-round sharing 2-round reconstruction inefficient statistical VSS protocol Open: 3-round efficient protocol? Just a brief recap of the talk First we showed there exists a 4-round sharing… Then we showed that there also exists a 3-round… We leave open the obvious question of constructing a 3-round efficient protocol. 40s

Thank You! Thank you… 20s -2m