# Cryptography

This document provides an overview of the cryptographic building blocks that drand uses to generate publicly-verifiable, unbiased, 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 participants, out of which at most are malicious. Drand heavily relies on threshold cryptography (opens new window) primitives, where (at least) a threshold of nodes have to work together to execute certain cryptographic operations successfully.

Threshold cryptography has many applications, as it avoids single points of failure. One such application is cryptocurrency multi-sig wallets, where -of- participants are required to sign a transaction using a threshold signature scheme.

Note: This document is intended for a general audience, and no in-depth 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 participants. This is done through a -of- Distributed Key Generation (DKG) (opens new window) process at the end of which each of the participants obtains a copy of the collective public key, together with a private key share of the collective private key. The key shares are computed 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 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 (opens new window) in the following subsections.

Secret sharing (opens new window) is an important technique that many advanced threshold cryptography mechanisms rely on. Secret sharing allows one to split a secret value into shares such that can only be reconstructed if a threshold of shares is available.

Shamir's Secret Sharing (opens new window) (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 denoted by . Let denote the secret to be shared.

Share Distribution: To share a dealer first creates a polynomial with and (random) for

The dealer then creates one share for each participant by evaluating at the integer and setting .

Secret Reconstruction: To recover the secret , one first collects at least shares, then uniquely reconstructs via Lagrange interpolation (opens new window), and finally obtains as .

Note that any subset of -of- shares can be used to perform Lagrange interpolation and uniquely determine . Having any subset of fewer than shares does not allow one to learn anything about , though.

Shamir's Secret Sharing scheme assumes that the dealer is honest but this assumption might not always hold in practice.

A Verifiable Secret Sharing (opens new window) (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 (opens new window) scheme, an extension of SSS. Let denote a cyclic group of prime order in which computing discrete logarithms is intractable.

A cyclic group means there exists a generator such that any element can be written as for some .

Share Distribution: In addition to distributing shares of the secret to the participants, the dealer also broadcasts commitments to the coefficients of the polynomial of the form .

These commitments enable each participant to verify that their share is consistent with respect to the polynomial by checking that holds.

Secret Reconstruction: The recovery of secret works as in regular SSS with the difference that verified to be valid shares are used.

# Distributed key generation (DKG)

Although VSS schemes protect against a malicious dealer, the dealer still knows the secret itself. To create a collectively shared secret such that no individual node gets any information about it, participants can utilize a Distributed Key Generation (opens new window) (DKG) protocol.

Drand uses Pedersen's DKG (opens new window) scheme, which essentially runs instances of Feldman's VSS in parallel on top of some additional verification steps.

Share Distribution: Every participant creates a (random) secret and shares it with all other participants using VSS by sending a share to each participant and broadcasting the list of commitments to everyone.

Share Verification: Each participant verifies the shares it receives as prescribed by Feldman's VSS scheme. If participant receives an invalid share from participant , then broadcasts a complaint. Afterward, participant must reveal the correct share or is considered an invalid dealer.

Share Finalization: At the end of the protocol, the final share of participant is for all participants that are valid, i.e., for all those not excluded during the verification phase.

The collective public key associated with the valid shares can be computed as for all valid participants .

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. (opens new window)

# Beacon phase

In the previous section, we gave an overview of 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, unbiased, and unpredictable randomness in a distributed manner

We first give an overview of pairing-based cryptography (opens new window) (PBC) which has become quite popular lately and is used in many modern consensus protocols or zero-knowledge proofs such as zk-SNARKs (opens new window).

Afterward, we show how drand uses PBC in the randomness beacon generation phase for threshold Boneh-Lynn-Shacham (BLS) signatures (opens new window).

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 where and are cyclic groups of prime order with generators , , and respectively, and a pairing operation with the following properties:

Bilinearity: , we have .

Non-degeneracy: .

Computability: There exists an efficient algorithm to compute .

Drand currently uses the BLS12-381 curve (opens new window).

# Randomness generation

To generate publicly-verifiable, unbiased, distributed randomness, drand utilizes threshold Boneh-Lynn-Shacham (BLS) signatures (opens new window).

Below we first describe regular BLS signatures (opens new window) 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 .

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 (opens new window), which requires 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 at random and then computes the corresponding public key as .

Signature Generation: Let denote a cryptographic hash function that maps arbitrary bit strings to elements of .

To compute a BLS signature on a message , the signer simply computes .

Signature Verification: To verify that a BLS signature on a message is valid, the verifier checks if holds using the signer’s public key .

It is easy to see that this equation holds for valid signatures since

# Signature threshold

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 participants execute a -of- DKG to setup a collective public key , and private key shares of the unknown collective private key , as described above.

Partial Signature Generation: To sign a message each participant uses their private key share to create a partial BLS signature .

Partial Signature Verification: To verify the correctness of a partial signature on , a verifier uses the public key share , which is generated during the DKG, and verifies that holds.

Signature Reconstruction: To reconstruct the collective BLS signature on , a verifier first needs to gather different and valid partial BLS signatures on followed by a Lagrange interpolation on them.

Signature Verification: To verify a collective BLS signature , a verifier simply checks that holds where is the collective public key.

Thanks to the properties of Lagrange interpolation, the value of is independent of the subset of valid partial signatures chosen during signature reconstruction.

Additionally, Lagrange interpolation also guarantees that no set of less than signers can predict or bias .

In summary, a threshold BLS signature exhibits all properties required for publicly-verifiable, unbiased, unpredictable, and distributed randomness.

# Smaller signatures for resource constrained applications

The above description of the signature threshold scheme accurately describes how we generate signatures that contain all the necessary properties for randomness under the pedersen-bls-chained and pedersen-bls-unchained schemes. Under these schemes, messages are mapped to a point on and public keys are a point on . As a result, message signatures are 96 bytes long and public keys are 48 bytes long. For systems where users are signing large messages and/or storing a lot of public keys, this trade-off makes a lot of sense: a 96 byte signature will be a small proportion of the entire message stored or transmitted. Additionally, signatures can be aggregated to save space, whereas aggregation isn't usually desirable for public keys, thus minimizing the size of the public keys is optimal for most systems. For drand however, we create a single public key at launch of the network and emit random beacons (and thus signatures) at a constant rate as long as the network is running. It is therefore more interesting to minimize the size of the signatures. As of v1.5.0 (opens new window) drand supports a new scheme, bls-unchained-on-g1, which exploits the bilinearity property of the BLS signature scheme to swap the generator groups for signatures and public keys such that signatures are created on and public keys are a point on . This reduces the storage requirements of the node operators by 50% as well as reducing latency and costs for any downstream users that require fetching and storing random beacons (such as smart contracts).

Thus for that scheme, the following operations apply:

Key Generation: The participants execute a -of- DKG to setup a collective public key , and private key shares of the unknown collective private key .

Partial Signature Generation: To sign a message each participant uses their private key share to create a partial BLS signature .

Partial Signature Verification: To verify the correctness of a partial signature of the message , a verifier uses the public key share , which is generated during the DKG, and verifies that holds.

Signature Reconstruction: To reconstruct the collective BLS signature of the message , a verifier first needs to gather different and valid partial BLS signatures of and then needs to perform a Lagrange interpolation on them using the coefficients generated during the distributed key generation.

# Randomness

Drand nodes currently support three schemes, though they can roughly be divided into two modes: chained or unchained.

The drand randomness beacon operates in discrete rounds . In every round, drand produces a new random value using threshold BLS signatures which can be linked together, or not, into a chain of randomness.

In chained mode, in order to extend the chain of randomness, each drand participant creates the partial BLS signature on the message in round , where denotes the (full) BLS threshold signature from round and is a cryptographic hash function.

Chained mode is supported by using the pedersen-bls-chained scheme.

In unchained mode, in order to produce unchained randomness, each drand participant creates the partial BLS signature on the message in round , where is a cryptographic hash function.

Unchained mode is supported by using the either the pedersen-bls-unchained or bls-unchained-on-g1 scheme.

Once at least participants have broadcasted their partial signatures on , anyone can recover the full BLS threshold signature .

At that point, the random value of round is simply its hash .

Afterward, drand nodes move to round and reiterate the above process.

For round , drand participants sign a seed fixed during the drand setup. In chained mode, 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 presenting two distinct signatures and in a given round 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 (opens new window) 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, -of- distributed key generation, and threshold BLS signatures to generate publicly-verifiable, unbiased, unpredictable, distributed randomness.

To learn more about the background of drand, we refer to the corresponding slides (opens new window).

Finally, for more formal background on public randomness, we refer to the research paper titled "Scalable Bias-Resistant Distributed Randomness" (opens new window) published at the 38th IEEE Symposium on Security and Privacy (opens new window).

The threshold scheme described here is described and proven in this paper from Boldyreva (opens new window).