SCRAPE: Scalable Randomness Attested by Public Entities

Abstract

Uniform randomness beacons whose output can be publicly attested to be unbiased are required in several cryptographic protocols. A common approach to building such beacons is having a number parties run a coin tossing protocol with guaranteed output delivery (so that adversaries cannot simply keep honest parties from obtaining randomness, consequently halting protocols that rely on it). However, current constructions face serious scalability issues due to high computational and communication overheads. We present a coin tossing protocol for an honest majority that allows for any entity to verify that an output was honestly generated by observing publicly available information (even after the execution is complete), while achieving both guaranteed output delivery and scalability. The main building block of our construction is the first Publicly Verifiable Secret Sharing scheme for threshold access structures that requires only O(n) exponentiations. Previous schemes required O(nt) exponentiations (where t is the threshold) from each of the parties involved, making them unfit for scalable distributed randomness generation, which requires $t=n/2$ and thus $O(n^2)$ exponentiations.

I. Cascudo acknowledges support from the Danish Council for Independent Research, grant no. DFF-4002-00367.

B. David—This project has received funding from the European research Council (ERC) under the European Unions’s Horizon 2020 research and innovation programme (grant agreement No. 669255).

1 Introduction

The problem of obtaining a reliable source of randomness has been studied since the early days of cryptography. Whereas individual parties can choose to trust locally available randomness sources, it has been shown that local randomness sources can be subverted [BLN16, DPSW16] and many applications require a common public randomness source that is guaranteed to be unbiased by a potential adversary. This necessity inspired the seminal work on Coin Tossing by Blum [Blu81], which allows two or more parties to generate an output that is guaranteed to be uniformly random as long as at least one of the parties is honest (and given that the protocol terminates).

The concept of a public randomness beacon that periodically issues fresh unpredictable and unbiased random values was proposed by Rabin [Rab83] in the context of contract signing and has found several other applications such as voting protocols [Adi08], generating public parameters for cryptographic schemes [BDF+15, LW15], privacy preserving instant messaging [WCGFJ12, vdHLZZ15], and anonymous browsing [DMS04, GRFJ14]. More recently, blockchain [Nak08, GKL15] applications such as smart contracts [KMS+16, B+14], sharding [CDE+16] and Proof-of-Stake based consensus protocols [KKR+16] have increased the need for randomness sources [BCG15].

Rabin’s concept of randomness beacons fits the above applications very nicely but the proposed implementation in [Rab83] relies on a trusted third party. The goal of this paper is to construct a distributed randomness beacon guaranteeing output delivery and uniformly distributed randomness for the parties that use the beacon as long as a majority of these parties are honest. Moreover, in many of the aforementioned applications, parties that do not necessarily participate in randomness generation but wish to audit the protocol execution must be able to attest a posteriori that the randomness source is reliable and unbiased. Hence, we aim at constructing a publicly verifiable randomness beacon and not only a protocol that outputs randomness to the parties actively involved in its execution.

1.1 Related Works

A natural solution for obtaining randomness beacons consists in using a coin tossing protocol as proposed by Blum [Blu81] with its messages posted to a public bulletin board for later verification (or broadcast among the parties). However, it is known that in case half or more of the parties are corrupted, the adversary can bias the output of the protocol or even prevent the honest parties from obtaining any output at all by aborting protocol execution at a given point [Cle86]. Assuming that a majority of the players are honest, it is possible to guarantee output delivery [RBO89] through threshold verifiable secret sharing (VSS) [CGMA85] given that a broadcast channel is available. Basically, given that a majority of n parties are honest, each party can secret share its input into n shares such that n/2 are enough to reconstruct the secret, sending one share to each involved party before starting the coin tossing protocol. While the adversary cannot recover any input (since it has at most n/$2-1$ shares of each input), the honest parties collective know at least n/2 shares, which they can use to reconstruct the inputs of parties who abort and then finish the protocol.

While a coin tossing protocol with guaranteed output delivery (G.O.D.) with a honest majority based on VSS provides a reliable source of randomness, this approach still has two main issues: 1. most VSS schemes require interaction between the dealer and the other parties, which hinders scalability and 2. only parties who actively participate in the protocol can verify that it was executed correctly. While non-interactive VSS [Fel87] solves the interaction problem, it does not allow the protocol execution to be independently verified by entities that did not actively participate. A natural way to allow for any entity to verify that the outputs produced by such protocols is indeed honestly generated is to substitute traditional VSS by publicly verifiable secret sharing (PVSS) schemes [Sta96], which allow for anybody to verify the validity of shares and reconstructed secrets through information that can be made publicly available without requiring direct interaction between any of the parties. Variations of this approach have been proposed in [KKR+16, SJK+16].

While [KKR+16] instantiates a plain [RBO89]-style G.O.D. coin tossing protocol requiring communication among all parties (through a public ledger), [SJK+16] reduces the communication complexity by partitioning parties into committees that internally run a protocol with publicly verifiable outputs. Later on, a client that only communicates to the leader of each committee (instead of talking to all parties) can aggregate these outputs to obtain publicly verifiable randomness. However, while the vanilla approach of [KKR+16] achieves security assuming only an honest majority (meaning that the adversary corrupts less than half of all parties), the communication efficient approach of [SJK+16] only achieves security against an adversary that corrupts less than a third of all parties. Moreover, provided that there is an honest majority, the protocol of [KKR+16] guarantees that all parties get output regardless of which parties are corrupted, while in the protocols of [SJK+16], even if only the client is corrupted, it can abort and prevent all other parties from receiving randomness.

Even though coin tossing with G.O.D. built through PVSS can potentially achieve scalability and public verifiability, current PVSS constructions [Sta96, FO98, Sch99, BT99, RV05, HV09, Jha11, JVSN14] suffer from high computational overhead. In general, the parties are required to each compute O(nt) exponentiations to verify n shares of a secret with threshold t, which translates into $O(n^2)$ exponentiations since $t=n/2$ in our randomness beacon application¹. This computational overhead arises because the main idea behind these schemes is to commit to the coefficients of a polynomial used for a Shamir Secret Sharing [Sha79] and encrypt the shares, later using the commitments to the coefficients to independently compute commitments to the shares, which are proven in zero-knowledge to correspond to the encrypted shares. This approach was originally put forth in [Sch99], which uses the Fiat-Shamir heuristic (and consequently the random oracle model) to obtain the necessary non-interactive zero-knowledge proofs. Later on, variations of this protocol in the plain model were proposed in [RV05, JVSN14], which substitute the zero-knowledge proofs by checks based on Paillier Encryption [Pai99], and in [HV09, Jha11], which propose a pairing based method for checking share validity.

Other approaches for constructing public randomness beacons have been considered in [BCG15, BDF+15, LW15, BLMR14, BGM16]. Public verifiability (or auditability) in the context of general multiparty computation protocol has been previously considered in [BDO14, SV15].

1.2 Our Contributions

We introduce SCRAPE, a protocol that implements a publicly verifiable randomness beacon given an honest majority through a PVSS based guaranteed output delivery coin tossing protocol. Our main result lies at the core of SCRAPE: the first threshold PVSS scheme that only requires a linear number of exponentiations for sharing, verifying and reconstruction, whereas previous schemes only achieve quadratic complexity. This PVSS scheme can be instantiated both under the Decisional Diffie Hellman (DDH) assumption in the Random Oracle Model (ROM) and in the plain model under the Decisional Bilinear Square (DBS) assumption [HV09]. While improving on the computational complexity of previous schemes, our PVSS scheme retains a similarly low communication overhead, making it fit for applications with large amounts of users. We remark that our new PVSS schemes can also be used to improve the performance of [SJK+16].

Model: As in previous works [BDO14], we assume that the parties can use a “public bulletin board” to publish information that will be used for posterior verification. In fact, in the applications we are interested in, a ledger where messages can be posted for posterior verification is readily available, since the Bitcoin Backbone protocol itself implements such a mechanism (i.e. the distributed ledger analysed in [GKL15]). Nevertheless, our protocols are compatible with any public ledger, not only with that of [GKL15].

Our Techniques: We improve on Schoenmakers’ PVSS scheme [Sch99] and its variants (which require O(nt) exponentiations to verify n shares) by designing a share verification procedure that only requires O(n) exponentiations (or pairings). Our procedure explores the fact that sharing a secret with Shamir Secret Sharing [Sha79] is equivalent to encoding the secret (plus randomness) with a Reed Solomon error correcting code, a fact which was first observed by McEliece and Sarwate in [MS81]. Since shares from Shamir Secret Sharing form a codeword of a Reed Solomon code, computing the inner product of a share vector with a codeword from the corresponding dual code should yield 0 if the shares are correctly computed. As in [Sch99], the dealer in our scheme shares the secret using Shamir Secret sharing, encrypts the shares $s_1,\ldots ,s_n$ in ciphertexts of the form $h^{sk_i s_i}$ (where $h^{sk_i}$ is a public key and $sk_i$ is a secret key) but also commits to all shares by computing $v_i=g^{s_i}$, where $g,h$ are two independently chosen generators of a group where the DLOG problem is assumed to be hard. The dealer also provides evidence that the shares in the ciphertexts are the same as the shares in the commitments. To verify the validity of the shares, anybody can sample a random codeword $\mathbf {\mathbf {c}^{\perp }}=(\mathbf {c}^{\perp }_1,\ldots ,\mathbf {c}^{\perp }_{n})$ of the dual code of the Reed Solomon code corresponding to the instance of Shamir Secret sharing that was used, compute the inner product of $\mathbf {\mathbf {c}^{\perp }}$ with the share vectors in the exponents of $g$ (by computing $\prod _{i} v_i^{\mathbf {c}^{\perp }_i} = g^{\sum _i s_i \mathbf {c}^{\perp }_i}$) and check that it is equal to $g^0=1$. If the shares are not valid, this check fails with large probability. To prove that the shares in the ciphertexts and in the commitments are the same, the dealer can either use a non-interactive zero-knowledge (NIZK) proof constructed using the Fiat-Shamir heuristic as in [Sch99] (resulting in a construction in the ROM under the DDH assumption) or have the parties do pairing based checks as in [HV09] (resulting in a construction in the plain model under the DBS assumption).

Concrete Efficiency: In the DDH based construction in the ROM, the dealer is required to compute 5n exponentiations in the sharing phase, while verification and reconstruction respectively require 4n and $5t+3$ exponentiations (given that all n shares are verified but only t shares are used in reconstruction). In the DBS based construction in the plain model, the dealer is required to compute 2n exponentiations in the sharing phase, while verification requires 2n pairings and reconstruction requires 2n pairings and $t+1$ exponentiations (given that n decrypted shares are verified but only t shares are used in reconstruction). Previous results required nt extra exponentiations in the verification phase, resulting in $n^2/2$ extra exponentiations in the randomness beacon application, which requires $t=n/2$. In the random oracle model construction, extra NIZK data is needed, amounting to a total of 2n group elements and $n+1$ ring elements published by the dealer. In the construction in the plain model, the dealer saves on the NIZK data and only posts 2n group elements, while requiring more expensive computation (i.e. pairings).

2 Preliminaries

In this section, we establish notation and introduce definitions that will be used throughout the paper. We denote uniformly sampling a random element x from a finite set $\mathcal {D}$ by $x \leftarrow \mathcal {D}$. We denote vectors as $\mathbf {x}=(x_1,\ldots ,x_n)$. We denote the inner product of two vectors $\mathbf {x},\mathbf {y}$ as $\langle \mathbf {x},\mathbf {y} \rangle = \sum _{1 \le i \le n} x_i\cdot y_i$. For the sake of notation, the integer n will always be considered to be even, so that n/2 is an integer. In this paper q will always denote a prime number. We denote by $\mathbb {Z}_q$ the ring of integers modulo q and by $\mathbb {G}$ a finite multiplicative group of order q. Since q is prime, $\mathbb {Z}_q$ is a finite field and $\mathbb {G}$ is a cyclic group where every element $g\ne 1$ is a generator. We denote by $\mathbb {Z}_q[x]$ the ring of polynomials in one variable with coefficients in $\mathbb {Z}_q$. We denote by $log_{g} e$ the discrete logarithm of an element $e \in \mathbb {G}$ with respect to generator $g\in \mathbb {G}$.

2.1 Coding Theory

We define a [n, k, d] code $C$ to be a linear error correcting code over $\mathbb {Z}_q$ of length n, dimension k and minimum distance d. Its dual code $C^\perp$ is the vector space which consists of all vectors $\mathbf {c}\in \mathbb {Z}_q^n$ such that $\langle \mathbf {c},\mathbf {c}^\perp \rangle = 0$ for all $\mathbf {c}$ in $C$. The dual code $C^\perp$ of an [n, k, d] code $C$ is an $[n,n-k,d^\perp ]$ code (for some $d^\perp$). In this work, we will use the following basic linear algebra fact.

Lemma 1

If $\mathbf {v}\in \mathbb {Z}_q^n\setminus C$, and $\mathbf {c}^{\perp }$ is chosen uniformly at random in $C^{\perp }$ then the probability that $\langle \mathbf {v},\mathbf {c}^{\perp }\rangle =0$ is exactly 1/q.

Proof

By linearity, a $\mathbf {c}^{\perp }\in C^{\perp }$ is orthogonal to $\mathbf {v}$ if only if it is also orthogonal to every vector in the code D spanned by $\mathbf {v}$ and $C$, i.e., if and only if $\mathbf {c}^{\perp }\in D^{\perp }$. Since $\mathbf {v}\notin C$, then the dimension of D is $k+1$ and hence the space $D^{\bot }$ has dimension $n-k-1$. Therefore if $\mathbf {c}^{\perp }$ is chosen uniformly at random in $C^{\perp }$ the probability that $\langle \mathbf {v},\mathbf {c}^{\perp }\rangle =0$ is

$$\frac{\#(D^{\perp })}{\#(C^{\perp })}=\frac{q^{n-k-1}}{q^{n-k}}=\frac{1}{q}.$$

Moreover, in this work we will always be under the assumption $n<q$ and we will use Reed-Solomon codes C of the following form

$$C=\{(p(1),p(2),\dots ,p(n)): p(x)\in \mathbb {Z}_q[x], \deg p(x)\le k-1\}$$

where p(x) ranges over all polynomials in $\mathbb {Z}_q[x]$ of degree at most $k-1$. This is an $[n,k,n-k+1]$-code. Its dual $C^{\perp }$ is an $[n,n-k,k+1]$-code, which can be defined as follows

$$C^{\perp }=\{(v_1f(1),v_2f(2),\dots ,v_nf(n)): f(x)\in \mathbb {Z}_q[x], \deg f(x)\le n-k-1\}$$

for the coefficients $v_i=\prod _{j=1, j\ne i}^n \frac{1}{i-j}.$

2.2 Shamir Secret Sharing

An (n, t) threshold secret sharing scheme allows a dealer $D$ to split a secret $s$ into n shares $\mathbf {S}=(s_1,\ldots ,s_n)$ distributed among n parties $P_1,\ldots ,P_n$ such that it is possible to reconstruct the secret given t of the shares but no information at all is revealed if less shares are known. We refer to $\mathbf {S}$ as the share vector of the secret sharing scheme. The first threshold secret sharing scheme was introduced by Shamir in [Sha79]. In order to split a secret $s\in \mathbb {Z}_q$, the dealer samples $t-1$ random coefficients $c_1,\ldots ,c_{t-1} \leftarrow \mathbb {Z}_q$ and constructs a polynomial $p(x)=s+c_1 x+c_2 x^2+ \cdots + c_{t-1} x^{t-1}$. The shares are computed as $s_i=p(i)$ for $1 \le i \le n$. A party who possesses t shares can use Lagrange interpolation to recover the polynomial p(x) and thus obtain $s$. On the other hand, a party who knows less than t shares has no information about the secret. McEliece et al. first observed that sharing a secret into n shares with Shamir Secret Sharing is equivalent to encoding the message $(x,c_1,\ldots ,c_{t-1})$ under a $[n,t,n-t+1]$ Reed Solomon code, implying that the share vector $\mathbf {S}$ is a codeword of such Reed Solomon code.

2.3 Assumptions

One of our constructions is proven in the Random Oracle Model [BR93], where it is assumed that the parties are given access to a function H(x) that takes inputs of any size and returns unique uniformly random outputs of fixed size (returning the same output every time the input is the same). Such a function can be instantiated in practice by a cryptographic hash function. In this model we prove security of our protocols under the DDH assumption, that states given $g,g^\alpha ,g^\beta$ it is hard for a PPT adversary to distinguish between $g^{\alpha \beta }$ from $g^{r}$, where $g$ is a generator of a group $\mathbb {G}$ of order q and $\alpha ,\beta ,r \leftarrow \mathbb {Z}_q$.

We assume efficient non-degenerate bilinear groups described by $\Lambda := (q,\mathbb {G},\mathbb {G}_T,e)$, where $\mathbb {G}$ and $\mathbb {G}_T$ are groups of order q and $\mathbb {G}\times \mathbb {G}\rightarrow \mathbb {G}_T$ is a bilinear map. We use symmetric pairings to describe the construction for the sake of clarity but remark that our construction can also be easily converted to asymmetric bilinear groups [AHO16], for which state-of-the-art pairing friendly curves [BN06] for which more efficient algorithms for computing pairings [AKL+11] are known. We prove our pairings based protocol secure under the Decisional Bilinear Square (DBS) assumption [HV09] that was shown in that paper to be equivalent to the Decisional Bilinear Quotient assumption [LV08] and related to the Decisional Bilinear Diffie Hellman assumption.

Assumption 1

Decisional Bilinear Square (DBS) [HV09]. Let $\Lambda := (q,\mathbb {G},\mathbb {G}_T,e)$ be a bilinear group. For a generator $g\in \mathbb {G}$, random values $\mu ,\nu ,s \leftarrow \mathbb {Z}_q$ and given $u=g^\mu$ and $v=g^\nu$, the following probability distributions are computationally indistinguishable: $D_0=(g,u,v,T_0=e(u,u)^\nu )$ and $D_1 = (g,u,v,T_1=e(u,u)^s)$.

Adversarial Model. We prove the security of our protocols in the stand alone setting against malicious adversaries, who may deviate from the protocol in any arbitrary way. We consider static adversaries, who have to choose which parties to corrupt before protocol execution begins.

Public Ledger and Broadcast Channel. We assume that the parties have access to a public ledger with Liveness, meaning that an adversary cannot prevent honest parties from adding information and agreeing on it, and Persistence, meaning that the information cannot be modified or removed a posteriori. It is known that such a ledger can be implemented by the Bitcoin backbone protocol assuming an honest majority, digital signatures and a Random Oracle [GKL15]. However, we remark that our protocols do not rely on any properties that are unique to the ledger of [GKL15], meaning that our constructions can also be instantiated over public ledgers in the plain model. Notice that access to a broadcast protocol is commonly assumed in multiparty protocols for an honest majority [RBO89] and that the same effect of broadcasting a messages can be achieved by writing it to the ledger. We also remark that the availability of a public bulletin board has been assumed in previous works on public verifiability for multiparty protocols [BDO14, SV15].

2.4 Publicly Verifiable Secret Sharing

We adopt the general model for PVSS schemes of [Sch99] and the security definitions of [RV05, HV09] (with some differences that we remark below). We consider a set of n parties $\mathcal {P}= \{P_1,\ldots ,P_n\}$ and a dealer $D$ who shares a secret among all the parties in $\mathcal {P}$. We will construct schemes for (n, t)-threshold access structures, meaning that the secret is split in n shares in such a way that knowing at most $t-1$ shares reveals no information but a collection of t shares allows for secret reconstruction. Additionally, any external verifier $V$ can check that the $D$ is acting honest without learning any information about the shares or the secret. A PVSS protocol has four phases described below:

• Setup: The dealer $D$ generates and publishes the parameters of the scheme. Every party $P_i$ publishes a public key $pk_i$ and withholds the corresponding secret key $sk_i$.

• Distribution: The dealer creates shares $s_1,\dots ,s_n$ for the secret $s$, encrypts share $s_i$ with the public key $pk_i$ for $i=1,\dots ,n$ and publishes these encryptions $\hat{s}_i$, together with a proof $PROOF_D$ that these are indeed encryptions of a valid sharing of some secret.

• Verification: In this phase, any external $V$ (not necessarily being a participant in the protocol) can verify non-interactively, given all the public information until this point, that the values $\hat{s}_i$ are encryptions of a valid sharing of some secret.

• Reconstruction: This phase is divided in two. Decryption of the shares: This phase can be carried out by any set $\mathcal {Q}$ of t or more parties. Every party $P_i$ in $\mathcal {Q}$ decrypts the share $s_i$ from the ciphertext $\hat{s}_i$ by using its secret key $sk_i$, and publishes $s_i$ together with a (non-interactive) zero-knowledge proof $PROOF_i$ that this value is indeed a correct decryption of $\hat{s}_i$. Share pooling: Any external verifier $V$ (not necessarily being a participant in the protocol) can now execute this phase. $V$ first checks whether the proofs $PROOF_i$ are correct. If the check passes for less than t parties in $\mathcal {Q}$ then $V$ aborts; otherwise $V$ applies a reconstruction procedure to the set $s_i$ of shares corresponding to parties $P_i$ that passed the checks.

A PVSS scheme must provide three security guarantees: Correctness, Verifiability and IND1-Secrecy. These properties are defined below:

• Correctness: If the dealer and all players in $\mathcal {Q}$ are honest, then all verification checks in the verification and reconstruction phases pass and the secret can be reconstructed from the information published by the players in $\mathcal {Q}$ in the reconstruction phase.

• Verifiability: If the check in the verification step passes, then with high probability the values $\hat{s}_i$ are encryptions of a valid sharing of some secret. Furthermore if the check in the Reconstruction phase passes then the communicated values $s_i$ are indeed the shares of the secret distributed by the dealer.

• IND1-Secrecy: Prior to the reconstruction phase, the public information together with the secret keys $sk_i$ of any set of at most $t-1$ players gives no information about the secret. Formally this is stated as in the following indistinguishability based definition adapted from [RV05, HV09]:

Definition 1

Indistinguishability of secrets (IND1-secrecy). We say that the PVSS is IND1-secret if for any polynomial time adversary $\mathcal {A}_{\text {Priv}}$ corrupting at most $t-1$ parties, $\mathcal {A}_{\text {Priv}}$ has negligible advantage in the following game played against a challenger.

• 1. The challenger runs the Setup phase of the PVSS as the dealer and sends all public information to $\mathcal {A}_{\text {Priv}}$. Moreover, it creates secret and public keys for all uncorrupted parties, and sends the corresponding public keys to $\mathcal {A}_{\text {Priv}}$.

• 2. $\mathcal {A}_{\text {Priv}}$ creates secret keys for the corrupted parties and sends the corresponding public keys to the challenger.

• 3. The challenger chooses values $x_0$ and $x_1$ at random in the space of secrets. Furthermore it chooses $b\leftarrow \{0,1\}$ uniformly at random. It runs the Distribution phase of the protocol with $x_0$ as secret. It sends $\mathcal {A}_{\text {Priv}}$ all public information generated in that phase, together with $x_b$.

• 4. $\mathcal {A}_{\text {Priv}}$ outputs a guess $b'\in \{0,1\}$.

The advantage of $\mathcal {A}_{\text {Priv}}$ is defined as $|\Pr [b=b']-1/2|$.

The IND1-secrecy definition is the one used in [RV05, HV09], except for the fact that we do not impose any privacy requirement after the Reconstruction phase. The difference stems from the fact that in [RV05, HV09] it was required that nobody learns the secret but the parties interacting during the reconstruction, while in our random beacon application the secret must be publicly reconstructed and published. We remark that our scheme can achieve both the relaxed definition required by the random beacon application and the stronger secrecy guarantees of [RV05, HV09] (through the use of private channels between parties or through the technique of [HV09] that requires extra data to be posted to the ledger). We also remark that our schemes can achieve the stronger secrecy notion formalized as IND2-secrecy in [RV05, HV09], which allows the adversary to choose arbitrary secrets. This is done by a black box transformation to the protocols that allows for sharing arbitrary secrets instead of random ones by using the random shared secret as a “one time pad” to encrypt an arbitrary secret, which is formally proven in [RV05, HV09].

2.5 Zero-Knowledge Proofs of Discrete Logarithm Knowledge

In our construction based on the DDH assumption in the random oracle model we will need a zero-knowledge proof of knowledge of a value $\alpha \in \mathbb {Z}_q$ such that $x = g^\alpha$ and $y = h^\alpha$ given $g,x,h,y$. We denote this proof by $DLEQ(g,x,h,y)$. Chaum and Pedersen constructed a sigma protocol to perform this proof in [CP93], their protocol works as follows:

• 1. The prover computes $a_1 = g^w$ and $a_2 = h^w$ where $w \leftarrow \mathbb {Z}_q$ and sends $a_1,a_2$ to the verifier.

• 2. The verifier sends a challenge $e \leftarrow \mathbb {Z}_q$ to the prover.

• 3. The prover sends a response $z=w-\alpha e$ to the verifier.

• 4. The verifier checks that $a_1=g^z x^e$ and $a_2 = h^z y^e$ and accepts the proof if this holds.

This proof has the properties of completeness, soundness and zero-knowledge. In our proofs, we will specifically reference the soundness property, which means that a prover cannot convince a verifier of a fake statement except with a negligible soundness error $\epsilon$. Notice that this sigma protocol can be transformed into a non-interactive zero-knowledge proof of knowledge of $\alpha$ in the random oracle model through the Fiat-Shamir heuristic [FS87, PS96]. We remark that, as in [Sch99], we need to compute this proof in parallel for n distinct pairs of values $(x_{1},y_{1})$, $\ldots ,(x_{n},y_{n})$. In this case, a single challenge e is computed by the prover as $e=H(x_{1},y_{1},\ldots ,x_{n},y_{n},a_{1,1},a_{2,1},\ldots ,a_{1,n},a_{2,n})$, where the values $a_{1,i},a_{2,i}$ are computed according to $x_{i},y_{i}$ as described above and $H(\cdot )$ is a random oracle (that can be of course substituted by a cryptographic hash function). The proof then consists of the challenge e along with responses $z_i$ computed according to each $x_{i},y_{i}$. The verifier can check the proof by computing $a^{\prime }_{1,i}=g^{z_i} x_{i}^e$ and $a^{\prime }_{2,i} = h^{z_i} y_{i}^e$, and verifying that $H(x_{1},y_{1},\ldots ,x_{n},y_{n},a^{\prime }_{1,1},a^{\prime }_{2,i},\ldots ,a^{\prime }_{1,n},a^{\prime }_{2,n})=e$.

3 PVSS Based on the DDH Assumption in the ROM

In this section, we construct a PVSS protocol secure under the DDH assumption in the Random Oracle Model. Our general approach is similar to that of Schoenmakers [Sch99] but differs significantly in the procedure used for share verification, which represents the main overhead in Schoenmakers’ scheme.

3.1 Security Analysis

Notice that the Setup and Reconstruction phases are exactly equal to those of [Sch99], while our protocol differs in the Distribution and Verification phases, where we apply our new technique. The key observation is that maliciously generated encrypted shares $\hat{s}_1,\ldots ,\hat{s}_n$ will only pass the verification procedure with probability 1/q plus the soundness error of the DLEQ proof, while $v_1,\ldots ,v_n$ reveal no information about the secret $h^s$ under the DDH assumption (by an argument similar to that of [Sch99]).

We formalize these observations below. First we consider IND1-secrecy. We remark that while we use our relaxed IND1-secrecy notion or our randomness beacon application (where no secrecy is preserved after reconstruction), Protocol $\pi _{DDH}$ achieves the original stronger IND1-secrecy notion of [RV05, HV09] (where secrecy against parties outside the qualified set is guaranteed even after the reconstruction) if the reconstruction is carried out through private channels between the parties in the qualified set.

Theorem 1

Under the decisional Diffie-Hellman assumption, the protocol $\pi _{DDH}$ is IND1-secret against a static PPT adversary (Fig. 1).

Fig. 1.

Protocol $\pi _{DDH}$

Proof

We show that, if there exists an adversary $\mathcal {A}_{\text {Priv}}$ which can break the IND1-secrecy property of protocol $\pi _{DDH}$, then there exists an adversary $\mathcal {A}_{\text {DDH}}$ which can use $\mathcal {A}_{\text {Priv}}$ to break the decisional Diffie-Hellman assumption with the same advantage. Without loss of generality we assume $\mathcal {A}_{\text {Priv}}$ corrupts the $t-1$ first parties.

Let $(g,g^\alpha ,g^\beta , g^\gamma )$ be an instance of the DDH problem. Obviously if $\alpha =0$ or $\beta =0$ then the problem is trivial, so we assume these values are nonzero. Now $\mathcal {A}_{\text {DDH}}$, using $\mathcal {A}_{\text {Priv}}$, can simulate an IND1 game as follows:

• 1. The challenger sets $h=g^\alpha$ and runs the Setup phase of $\pi _{DDH}$. For $t\le i\le n$, $\mathcal {A}_{\text {DDH}}$ selects uniformly random values $u_i\leftarrow \mathbb {Z}_p$ (these can be thought of implicitly defining $sk_i$ as $sk_i=u_i/\alpha$) and sends the values $pk_i=g^{u_i}$ to $\mathcal {A}_{\text {Priv}}$.

• 2. For $1\le i\le t-1$, $\mathcal {A}_{\text {Priv}}$ chooses uniformly random values $sk_i\leftarrow \mathbb {Z}_q$ and sets $pk_i=h^{sk_i}$ and sends this to the challenger.

• 3. For $1\le i\le t-1$, the challenger chooses uniformly random values $s_i\leftarrow \mathbb {G}_q$ and sets $v_i = g^{s_i}$ and $\hat{s}_i=pk_i^{s_i}$. For $t\le i\le n$, it generates the values $v_i= g^{p(i)}$ where p(x) is the unique polynomial of degree at most t determined by $p(0)=\beta$ and $p(i)=s_i$ for $i=1,\dots ,t-1$. Note that $\mathcal {A}_{\text {DDH}}$ does not know $\beta$, but it does know $g^\beta =g^{p(0)}$ and $g^{s_i}=g^{p(i)}$ for $1\le i\le t-1$, so it can use Lagrange interpolation in the exponent to compute the adequate $v_i$. It also creates the values $\hat{s}_i=v_i^{u_i}$. Note that then $\hat{s}_i=g^{u_i\cdot p(i)}=pk_i^{p(i)}$. From all the computed values, the challenger now creates the DLEQ proofs as the dealer does in the PVSS protocol. Finally it sends all this information together with the value $g^\gamma$ (which plays the role of $x_b$ in the IND game) to $\mathcal {A}_{\text {Priv}}$.

• 4. $\mathcal {A}_{\text {Priv}}$ makes a guess $b'$.

If $b'=0$, $\mathcal {A}_{\text {DDH}}$ guesses that $\gamma =\alpha \cdot \beta$. If $b'=1$, $\mathcal {A}_{\text {DDH}}$ guesses that $\gamma$ is a random element in $\mathbb {Z}_p$.

The information that $\mathcal {A}_{\text {Priv}}$ receives in step 3. is distributed exactly like a sharing of the value $h^\beta =g^{\alpha \cdot \beta }$ with the PVSS. Consequently, $\gamma = \alpha \cdot \beta$ if and only if the value $g^\gamma$ sent to $\mathcal {A}_{\text {Priv}}$ is the secret shared by the PVSS. It is now easy to see that the guessing advantage of $\mathcal {A}_{\text {DDH}}$ is the same as the advantage of $\mathcal {A}_{\text {Priv}}$.

The following two theorems guarantee the verifiability property of $\pi _{DDH}$.

Theorem 2

If the dealer does not construct values $(v_i,\hat{s}_i)$ of the right form in the Distribution phase (i.e. either $log_{g} v_i\ne log_{pk_i} \hat{s}_i$ for some i, or $log_{g} v_i= log_{pk_i} \hat{s}_i=s_i$ for all i but the values $s_i$ do not constitute a valid sharing of some secret in $\mathbb {Z}_q$ with the (n, t)-threshold Shamir secret sharing scheme), then this is detected in the verification step with probability at least $1-\epsilon -1/q$, where $\epsilon$ is the soundness error of the proof DLEQ.

Proof

If the verification of DLEQ passes, then we have that, except with probability $\epsilon$, for every $1\le i\le n$, there exists $s_i$ with $v_i=g^{s_i}$ and $\hat{s}_i=pk_i^{s_i}$. Now the values $s_i$ are a valid sharing with the (n, t)-threshold Shamir secret sharing scheme if and only if the vector $\mathbf {v}=(s_1,\dots ,s_n)\in C$. Suppose that $(s_1,\dots ,s_n)\notin C$. Then by Lemma 1, since $\mathbf {c}^\perp$ is sampled uniformly at random then $\langle \mathbf {v}, \mathbf {c}^\perp \rangle \ne 0$ except with probability 1/q. But then $\prod _{i=1}^n v_i^{\mathbf {c}^\perp _i}= \prod _{i=1}^n g^{s_i\cdot \mathbf {c}^\perp _i}= g^{\langle \mathbf {v},\mathbf {c}^\perp \rangle }\ne 1$. Hence if the values $s_i$ are not a valid Shamir sharing, then the check fails with probability $1-1/q$.

Theorem 3

If a party in $\mathcal {Q}$ communicates an erroneous decryption share $\tilde{s}_i$ in the Reconstruction phase, then this is detected by the verifier with probability $1-\epsilon$, where $\epsilon$ is the soundness error of the DLEQ proof.

Proof

This is straightforward by definition since an adversary that succeeds in providing a DLEQ proof for an invalid decrypted share breaks DLEQ’s soundness property.

4 PVSS Based on Pairings in the Plain Model

In this section, we construct a PVSS scheme based on the DBS assumption in the plain model (without requiring random oracles). This scheme uses the techniques of [HV09] to eliminate the need for the random oracle based NIZKs and instead use pairings to check that the encrypted shares $\hat{s}_i$ correspond to the committed shares $v_i$ and, later on, check that the decrypted shares correspond to $\hat{s}_i$. We use the same information theoretical verification procedure as in the DDH based scheme. The protocol is described in Fig. 2.

Fig. 2.

Protocol $\pi _{DBS}$

4.1 Security Analysis

As in the DDH based protocol, notice that the Setup and Reconstruction phases are exactly equal to those of [HV09], while our protocol differs in the Distribution and Verification phases. Maliciously generated encrypted shares $\hat{s}_1,\ldots ,\hat{s}_n$ will only pass the verification procedure with probability of 1/q, while $v_1,\ldots ,v_n$ again reveal no information about the secret $e(h,h)^s$ but this time under the BDS assumption. Again we remark that Protocol $\pi _{DBS}$ achieves the original stronger IND1-secrecy notion of [RV05, HV09] (where secrecy against parties outside the qualified set is guaranteed even after the reconstruction) if the reconstruction is carried out through private channels between the parties in the qualified set. The proofs of Theorems 4 and 5 are similar to those of Theorems 1 and 2, respectively, and are presented in the full version of this work [CD17].

Theorem 4

Under the DBS assumption, protocol $\pi _{DBS}$ is IND1-secret against a static PPT adversary.

Theorem 5

If the dealer does not construct values $(v_i,\hat{s}_i)$ of the right form in the Distribution phase (i.e. either $log_{g} v_i\ne log_{pk_i} \hat{s}_i$ for some i, or $log_{g} v_i= log_{pk_i} \hat{s}_i=s_i$ for all $1 \le i \le n$ but the values $s_i$ do not constitute a valid sharing of some secret in $\mathbb {Z}_q$ with the (n, t)-threshold Shamir secret sharing scheme), then this is detected in the verification step with probability at least $1-1/q$.

Theorem 6

If a party in $\mathcal {Q}$ communicates an erroneous decryption share $\tilde{s}_i$ in the Reconstruction phase, then this is detected by the verifier with probability 1.

Proof

If $\tilde{s}_i=h^a$ with $a\ne s_i$ then $e(pk_i,\tilde{s}_i)=e(pk_i,h)^a\ne e(pk_i,h)^{s_i}=e(\hat{s}_i,h)$.

Fig. 3.

Protocol $\pi _{SCRAPE}$

5 Building the SCRAPE Randomness Beacon

Publicly verifiable secret sharing schemes have a multitude of applications as discussed in [Sch99], among them universally verifiable elections, threshold versions of El Gamal encryption and threshold software key escrow. However, we are specially interested in constructing SCRAPE, a protocol that implements a distributed randomness beacon that is guaranteed to be secure given an honest majority, a PVSS scheme and a public ledger. SCRAPE is basically a coin tossing protocol with guaranteed output delivery (G.O.D.), meaning that an adversary cannot prevent honest parties from obtaining a correct output (e.g. by aborting before the execution is finished). Moreover, SCRAPE is publicly verifiable, meaning that anybody can analyse past (and current) protocol transcripts to verify that the protocol is being correctly executed. The reason we aim at guaranteed output delivery is twofold: 1. Protecting against particularly adversarial behavior and 2. Tolerating non-byzantine failures in users after the commitment phase (e.g. power outage). When used to bootstrap blockchain based consensus protocols such as in [KKR+16], $\pi _{SCRAPE}$ has to tolerate adversaries that can force a temporary loss of consensus making the users end up with conflicting random outputs or temporarily “disconnecting” users from the network or public ledger. We follow the general approach of [RBO89] to obtain guaranteed output delivery based on verifiable secret sharing, building on our PVSS schemes to achieve public verifiability for the final coin tossing protocol. More specifically, we use our PVSS protocols to instantiate the construction of [KKR+16], which proposed to combine a PVSS scheme with a public ledger to obtain publicly verifiable G.O.D. coin tossing. The protocol is described in Fig. 3. The security of $\pi _{SCRAPE}$ follows from the security of the general construction of [KKR+16] and the security of our protocols that was proven in the previous sections. We refer the reader to [KKR+16] for a detailed discussion on the general protocol.

Table 1. Concrete computational complexity in terms of numbers of exponentiations (Exp.) and pairings (Pair.) needed for each phase, considering that n shares are generated and t shares are used in reconstruction.

Fig. 4.

Execution time of the verification phases of $\pi _{DDH}$ vs. $\pi _{DBS}$ vs. Schoenmakers’ PVSS [Sch99] for a number of shares n from 1000 to 10000 and threshold $t=\frac{n}{2}$.

6 Concrete Complexity and Experiments

In this section, we discuss the concrete computational and communication complexity of our schemes, comparing them with previous work. We first start by discussing the computational complexity of our PVSS protocols, which is compared to that of the protocols of [Sch99, HV09] in terms of numbers of exponentiations and pairings required for each phase in Table 1. Notice that for our randomness beacon application we need $t=n/2$, which translates into an extra overhead of $n^2/2$ exponentiations required for the verification phase of previous protocols. Our protocols eliminate this quadratic overhead, resulting in much better scalability. For example, if 10000 users run SCRAPE based on [Sch99], 50004000 exponentiations are required in the verification phase, while our instantiation of SCRAPE would require only 50000 exponentiations, achieving a performance gain of over 100 times. In terms of communication complexity, our protocols match previous results [Sch99, HV09] in the reconstruction phase while requiring 2n group elements to be published in the distribution phase. In the randomness beacon application, this represents an overhead of only 0.5n in relation to [Sch99, HV09]. In order to evaluate the concrete performance of our proposed protocols, we have conducted experiments with implementations of $\pi _{DDH}$, $\pi _{DBS}$ and the PVSS scheme of [Sch99], all written in Haskell. The experiments were run on a single core of a Linux machine with a Intel(R) Core(TM) i7-3770K CPU @ 3.50 GHz and 32 GB of RAM. Figure 4 compares the runtime of the verification phases of $\pi _{DDH}$ and [Sch99], which represents the main improvement of $\pi _{DDH}$. Further discussion on concrete complexity and experimental results can be found in the full version of this work [CD17].