# Drand: Cryptographic Background This document provides an overview on the cryptographic building blocks that drand uses to generate publicly-verifiable, unbiasable, and unpredictable randomness in a distributed manner. The drand beacon has two phases (a *setup phase* and a *beacon phase*) which we describe below. Generally, we assume that there are $n$ participants out of which at most $f < n$ are malicious. drand heavily relies on [threshold cryptography](https://en.wikipedia.org/wiki/Threshold_cryptosystem) primitives, where (at least) a *threshold* of $t=f+1$ nodes have to work together to successfully execute certain cryptographic operations. Threshold cryptography has many applications as it allows to avoid single points of failure. One such application are cryptocurrency multi-sig wallets, where $t$-of-$n$ participants are required to sign a transaction using a threshold signature scheme. **Note**: This document is intended for a general audience and no deep cryptographic background knowledge is necessary to understand the presented concepts. ## Setup Phase The purpose of the drand setup phase is to create a *collective private and public key pair* shared among $n$ participants. This is done through a $t$-of-$n$ [Distributed Key Generation (DKG)](https://en.wikipedia.org/wiki/Distributed_key_generation) process at the end of which each of the $n$ participants obtains a copy of the collective public key together with a *private key share* of the collective private key such that no individual node knows the entire collective private key. Each private key share can then be used to perform cryptographic threshold computations, such as generating threshold signatures, where at least $t$ contributions produced using the individual private key shares are required to successfully finish the collective operation. A DKG is performed in a fully distributed manner avoiding any single points of failure. We give an overview of the different sub-components of the drand [DKG implementation](https://github.com/dedis/kyber/tree/master/share/dkg/pedersen) in the following subsections. ### Secret Sharing [Secret sharing](https://en.wikipedia.org/wiki/Secret_sharing) is an important technique that many advanced threshold cryptography mechanisms rely on. Secret sharing allows to split a secret value $s$ into $n$ shares $s_1, \dots, s_n$ such that $s$ can only be reconstructed if a threshold of $t$ shares is available. [Shamir's Secret Sharing](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing) (SSS) scheme is one of the most well-known and widely used secret sharing approaches and it is a core component of drand. SSS works over an arbitrary finite field but for simplicity we use the integers modulo $p$ denoted by $\mathbb{Z}_p$. Let $s \in \mathbb{Z}_p$ denote the secret to be shared. **Share Distribution**: To share $s$, a *dealer* first creates a polynomial $q(x) = a_0 + a_1x + \dots + a_{t-1}x^{t-1}$ with $a_0 = s$ and (random) $a_i \in \mathbb{Z}_p$ for $i = 1, \dots , t-1$ and then creates one share $s_i$ for each participant $i$ by evaluating $q(x)$ at the integer $i$ and setting $s_i = (i, q(i))$. **Secret Reconstruction**: To recover the secret $s$, one first collects at least $t$ shares, then uniquely reconstructs $q(x)$ via [Lagrange interpolation](https://en.wikipedia.org/wiki/Lagrange_polynomial), and finally obtains $s$ as $s = a_0 = q(0)$. Note that any subset of $t$-of-$n$ shares can be used to perform Lagrange interpolation and uniquely determine $s$. Having any subset of less than $t$ shares does not allow to learn anything about $s$ though. ### Verifiable Secret Sharing Shamir's Secret Sharing scheme assumes that the dealer is honest but this assumption might not always hold in practice. A [Verifiable Secret Sharing](https://en.wikipedia.org/wiki/Verifiable_secret_sharing) (VSS) scheme protects against malicious dealers by enabling participants to verify that their shares are consistent with those dealt to other nodes ensuring that the shared secret can be correctly reconstructed later on. drand uses [Feldman's VSS](https://ieeexplore.ieee.org/abstract/document/4568297) scheme, an extension of SSS. Let $\mathbb{G}$ denote a cyclic group of prime order $p$ in which computing discrete logarithms is intractable. A cyclic group means there exists a generator $g$ such that any element $x \in \mathbb{G}$ can be written as $x = g^a$ for some $a \in \{0, \dots , p-1\}$. **Share Distribution**: In addition to distributing shares of the secret to the participants, the dealer also broadcasts commitments to the coefficients of the polynomial $q(x)$ of the form $(A_0, A_1, \dots, A_{t-1}) = (g^s, g^{a_1}, \dots, g^{a_{t-1}})$. These commitments enable each participant $i$ to verify that their share $s_i = (i, q(i))$ is consistent with respect to the polynomial $q(x)$ by checking that $g^{q(i)} = \prod_{j=0}^{t-1}(A_j)^{i^j}$ holds. **Secret Reconstruction**: The recovery of secret $s$ works as in regular SSS with the difference that *verified to be valid* shares are used. ### Distributed Key Generation Although VSS schemes protect against a malicious dealer, the dealer still knows the secret itself. To create a collectively shared secret $s$ such that no individual node gets any information about it, participants can utilize a [Distributed Key Generation](https://en.wikipedia.org/wiki/Distributed_key_generation) (DKG) protocol. drand uses [Pedersen's DKG](https://www.cs.cornell.edu/courses/cs754/2001fa/129.PDF) scheme which essentially runs $n$ instances of Feldman's VSS in parallel on top of some additional verification steps. **Share Distribution**: Every participant $i$ creates a (random) secret $s_i \in \mathbb{Z}_p$ and shares it with all other participants using VSS by sending a share $s_{i,j}$ to each participant $j$ and broadcasting the list of commitments $(A_{i,0}, A_{i,1}, \dots, A_{i,t-1})$ to everyone. **Share Verification**: Each participant verifies the shares it receives as prescribed by Feldman's VSS scheme. If participant $j$ receives an invalid share $s_{i,j}$ from participant $i$, then $j$ broadcasts a *complaint*. Afterwards, participant $i$ must reveal the correct share $s_{i,j}$ or is considered an *invalid* dealer. **Share Finalization**: At the end of the protocol, the final share of participant $i$ is $s_i = \sum_{j} s_{j,i}$ for all participants $j$ that are *valid*, i.e., for all those $j$ not excluded during the verification phase. The collective public key associated with the valid shares can be computed as $S = \sum_{j} A_{j,0}$ for all valid participants $j$. **Note**: Even though the secret created using Pedersen's DKG can be biased, it is safe to use for threshold signing as shown by [Rabin et al.](https://link.springer.com/content/pdf/10.1007%2F3-540-48910-X_21.pdf) ## Beacon Phase In the previous section, we gave an overview on how to produce a collective distributed key pair via a DKG protocol. In this section, we describe how to use this collective key pair to generate publicly-verifiable, unbiasable, and unpredictable randomness in a distributed manner. We first give an overview of [pairing-based cryptography](https://en.wikipedia.org/wiki/Pairing-based_cryptography) (PBC) which has become quite popular lately and is used in many modern consensus protocols or zero-knowledge proofs such as [zk-SNARKs](https://z.cash/technology/zksnarks/). Afterwards we show how drand uses PBC in the randomness beacon generation phase for [threshold Boneh-Lynn-Shacham (BLS) signatures](https://en.wikipedia.org/wiki/Boneh–Lynn–Shacham). Finally, we explain how drand links the generated threshold BLS signatures into a randomness chain. ### Pairing-Based Cryptography Pairing-based cryptography is based on *bilinear groups* $(\mathbb{G}_1, \mathbb{G}_2, \mathbb{G}_t)$ where $\mathbb{G}_1$, $\mathbb{G}_2$, and $\mathbb{G}_t$ are cyclic groups of prime order $p$ with generators $g_1$, $g_2$, and $g_t$, respectively, and a *pairing* operation $e: \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_t$ with the following properties: **Bilinearity**: $\forall a,b \in \mathbb{Z}^{\ast}_p, \forall P \in \mathbb{G}_1, \forall Q \in \mathbb{G}_2$, we have $e(aP,bQ) = e(P,Q)^{ab}$. **Non-degeneracy**: $e \neq 1$. **Computability**: There exits an efficient algorithm to compute $e$. drand currently uses the [BLS12-381 curve](https://electriccoin.co/fr/blog/new-snark-curve/) ### Randomness Generation To generate publicly-verifiable, unbiasable, distributed randomness, drand utilizes [threshold Boneh-Lynn-Shacham (BLS) signatures](https://en.wikipedia.org/wiki/Boneh–Lynn–Shacham). Below we first describe regular [BLS signatures](https://www.iacr.org/archive/asiacrypt2001/22480516.pdf) followed by the threshold variant. #### BLS Signature BLS signatures are short signatures that rely on bilinear pairings and consist only of a single element in $\mathbb{G}_1$. They are *deterministic* in the sense that a BLS signature depends only on the message and the signer's key unlike other signature schemes, such as [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm), which require a fresh random value for each signed message to be secure. Put differently, any two BLS signatures on a given message produced with the same key are identical. In drand we utilize this property to achieve unbiasability for the randomness generation. The BLS signature scheme consists of the following sub-procedures: **Key Generation**: To generate a key pair, a signer first chooses a private key $x \in \mathbb{Z}^{\ast}_p$ at random and then computes the corresponding public key as $X = g_2^x \in \mathbb{G}_2$. **Signature Generation**: Let $H: \{0,1\}^{\ast} \rightarrow \mathbb{G}_1$ denote a cryptographic hash function that maps arbitrary bit strings to elements of $\mathbb{G}_1$. To compute a BLS signature $\sigma$ on a message $m$, the signer simply computes $\sigma = xH(m) \in \mathbb{G}_1$. **Signature Verification**: To verify that a BLS signature $\sigma$ on a message $m$ is valid, the verifier checks if $e(H(m), X) = e(\sigma, g_2)$ holds using the signer's public key $X$. It is easy to see that this equation holds for valid signatures since $e(H(m), X) = e(H(m),g_2^x) = e(H(m),g_2)^x = e(xH(m),g_2) = e(\sigma,g_2)$. #### Threshold BLS Signature The goal of a threshold signature scheme is to collectively compute a signature by combining individual partial signatures independently generated by the participants. A threshold BLS signature scheme has the following sub-procedures: **Key Generation**: The $n$ participants execute a $t$-of-$n$ DKG to setup a collective public key $S \in \mathbb{G}_2$, and private key shares $s_{i} \in \mathbb{Z}^{\ast}_p$ of the unknown collective private key $s$, as described above. **Partial Signature Generation**: To sign a message $m$ each participant $i$ uses his private key share $s_i$ to create a *partial BLS signature* $\sigma_i = s_iH(m)$. **Partial Signature Verification**: To verify the correctness of a partial signature $\sigma_i$ on $m$, a verifier uses the public key share $S_i$, which is generated during the DKG, and verify that $e(H(m), S_i) = e(\sigma_i,g_2)$ holds. **Signature Reconstruction**: To reconstruct the collective BLS signature $\sigma$ on $m$, a verifier first needs to gather $t$ different and valid partial BLS signatures $\sigma_i$ on $m$ followed by a Lagrange interpolation on them. **Signature Verification**: To verify a collective BLS signature $\sigma$, a verifier simply checks that $e(H(m), S) = e(\sigma,g_2)$ holds where $S$ is the collective public key. Thanks to the properties of Lagrange interpolation, the value of $\sigma$ is independent of the subset of $t$ valid partial signatures $\sigma_i$ chosen during signature reconstruction. Additionally, Lagrange interpolation also guarantees that no set of less than $t$ signers can predict or bias $\sigma$. In summary, a threshold BLS signature $\sigma$ exhibits all properties required for publicly-verifiable, unbiasable, unpredictable, and distributed randomness. ### Chained Randomness The drand randomness beacon operates in discrete rounds $r$. In every round, drand producess a new random value using threshold BLS signatures which are linked together into a chain of randomness. To extend this chain of randomness, each drand participant $i$ creates in round $r$ the partial BLS signature $\sigma^{r}_i$ on the message $m = H(r \parallel \sigma_{r-1})$ where $\sigma_{r-1}$ denotes the (full) BLS threshold signature from round $r-1$ and $H$ a cryptographic hash function. Once at least $t$ participants have broadcasted their partial signatures $\sigma^{r}_i$ on $m$, anyone can recover the full BLS threshold signature $\sigma_r$. **At that point, the random value of round $r$ is simply its hash $H(\sigma_r)$**. Afterwards, drand nodes move to round $r+1$ and reiterate the above process. For round $r=0$ drand participants sign a seed fixed during the drand setup. This process ensures that every new random value depends on all previously generated signatures. Since the signature is deterministic, there is also no possibility for an adversary of forking the chain and present two distinct signatures $\sigma_r$ and $\sigma'_r$ in a given round $r$ to generate inconsistencies in the systems relying on public randomness. In a nutshell, this construction of using the hash of a BLS signature can be considered as a [Verifiable Random Function](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Pseudo%20Randomness/Verifiable_Random_Functions.pdf) because of the uniqueness of the signature output combined with the usage of the random oracle (the hash function). When the input is unpredictable, the output of the random oracle is indistinguishable from a uniform distribution. ## Conclusion To summarize, drand is an efficient randomness beacon daemon that utilizes pairing-based cryptography, $t$-of-$n$ distributed key generation, and threshold BLS signatures to generate publicly-verifiable, unbiasable, unpredictable, distributed randomness. To learn more about the background of drand, we refer to the corresponding [slides](https://docs.google.com/presentation/d/1t2ysit78w0lsySwVbQOyWcSDnYxdOBPzY7K2P9UE1Ac/edit?usp=sharing). Finally, for more formal background on public randomness, we refer to the research paper titled "Scalable Bias-Resistant Distributed Randomness" published at the [38th IEEE Symposium on Security and Privacy](https://www.ieee-security.org/TC/SP2017/) (see [paper](https://eprint.iacr.org/2016/1067.pdf). The threshold scheme described here is described and proven in the following [paper](https://www.iacr.org/archive/pkc2003/25670031/25670031.pdf) from Boldyreva.
Last changed by  
 
Nicolas Gailly
2938

Read more

Groth16 aggregation with public input trick

Regular Groth 16 CRS Random $\tau$ chosen during trusted setup as well as $\alpha$, $\beta$ $n$ is number of gates. $u_i$, $v_i$ and $w_i$ are the QAP polynomials created from the R1CS circuit $SRS = {g_1^\alpha, g_1^\beta, g_1^\delta, {{ g_1^{\tau^i}}, {g_1^{\alpha \tau^i}}, {g_1^{\beta \tau^i}}}{i=0}^{n-1}, {g_1^{\beta u_i(\tau) + \alpha v_i(\tau) + w_i(\tau)}}{i=0}^n}, {g^{\frac{\tau^it(x)}{\delta}}}{i=0}^{n-1},\g_2^\beta, g_2^\delta, {g_2^{\tau ^i}}{i=0}^{n-1}}$ Prover Settings:

4/15/2023
Efficient threshold BLS & Encryption

This post explains an inherent tension between threshold BLS signature and Elgamal encryption for onchain verification, and then presents a way to augment such threshold network such that a smart contract can efficiently verify a signature and decrypt/verify encryption onchain. 21/03/23, Nicolas Gailly, Cryptonet team, Protocol Labs. Introduction For encryption/decryption and signing, we (usually) require a group, i.e. a single elliptic curve. However, using pairings, we have to choose between $\mathbb{G_1}$ and $\mathbb{G_2}$ (and even $\mathbb{G_t}$), each group have their pros and cons depending on the cryptographic protocol we want to use. In practice, $\mathbb{G_1}$ is usually preferred given it is much shorter and faster to compute in it, than its counter-parties. This choice of group comes up when designing threshold networks. Indeed, there is a distributed key lying in a group $\mathbb{G}$ which could be any of the three groups aforementioned. In particular, when using pairing equipped curves, a threshold network can be used to create threshold BLS signatures but it can also be used as a decryption oracle. In the latter, users encrypts towards the threshold network and push the encryption on-chain. This posts shows the pros and cons of using $\mathbb{G_1}$ and $\mathbb{G_2}$ for each and shows there is a tension between the two. This posts then shows a simple solution to get the best of both worlds. The technique is heavily inspired by a post by Kobi Gurkan on efficient multisignature verification onchain, translated to the threshold setting.

3/21/2023
Trusted Setup: KZG and PST

KZG trusted setup First Player First player has secret $s$ and generates $$ [s]_1, [s^2]_1 ... $$ as well as the "check" point $$ [s]_2 $$

1/31/2023
DKG Share Recovery

DKG in a few lines Each node $i$: has a private polynomial $$f_i(x) = a_0 + ... + a_{t-1}x^{t-1}$$ From that get the public poly $$F_i(x) = f_i(x) * G$$ generate shares for others $$s_{i,j} = f_i(j)$$ then sum each share it receives (from QUALified participants) + its own: final share is $$s_i = \sum_j s_{j,i}$$ final public polynomial $$F(x) = \sum_i F_i(x)$$

10/27/2022
Read more from Nicolas Gailly
Published on HackMD