drand and the League of Entropy is LIVE

Kudelski Security is happy to announce together with its partners the creation of the League of Entropy, whose goal is to provide a secure source of distributed public randomness for anybody to use freely !

At the core of the League of Entropy, you’ll find the drand project, an open source software which stands for “distributed randomness” and provides collective, publicly verifiable, unbiased, unpredictable random values at fixed intervals. Currently this interval is set to 60 seconds, which means you can get as many as 1440 random 512-bit values per day!

Currently the League is comprised of a team including: Cloudflare, Protocol Labs researcher Nicolas Gailly, University of Chile, École polytechnique fédérale de Lausanne  (EPFL), Kudelski Security, and EPFL researchers, Philipp Jovanovic and Ludovic Barman. As you can see, the team is currently distributed all over the world.

The League of Entropy: with ChaChaRand, InterplanetaryRand, LavaRand, Seismic Girl and URand, our League is ready for any random challenge! (Image courtesy of Cloudflare)

You can try the League of Entropy randomness now! See at the end of this post for an example.

Public Randomness

Generating public randomness is the primary functionality of drand, so let us dive a bit into what that means.

Public randomness is generated collectively by drand nodes and is publicly available by querying any node in the drand quorum.
Here are some of the challenges that drand tries to address when generating collective randomness:

  • no party involved in the process should be able to predict the final output before the consensus has been reached;
  • no party should be able to bias the final output;
  • the process has to be tolerant to byzantine faults, in our case, this means that we can have up to n/2 malicious nodes and still meet our security goals; (notice this is not true for availability: the system is currently relying on a threshold t=n-2, which means we can currently tolerate a failure of at most 2 nodes at the same time.)
  • the final result has to be verifiable by any third party.

The applications in which publicly verifiable randomness is useful include lotteries, sharding, parameter generation in certain security protocols, and many other, including many blockchain applications. Typically randomness has been a long term issue for smart contracts in the Ethereum ecosystem, because of the decentralized, trustless nature of blockchain technologies and having solutions to obtain actual distributed yet trusted and verifiable randomness pave the way to new possibilities in this ecosystem.

Next on the list of features offered by drand, one can find “private randomness generation”. This means that clients can request private randomness from some or all of the drand nodes which will then extract it locally from their entropy pools and send it back in an encrypted form. This can be useful to gather additional randomness from different entropy sources, for example in embedded devices.

While drand is still technically in its “beta” stage, its underlying cryptographic components and its design are sound, and while formal reviews, and audits are yet to be performed, we encourage you to try it and even to benchmark it to review the quality of its randomness.

The Entropy Sources

One of the nice features of drand, is that it is easy to connect it to a custom entropy source. For instance, among the different members of the League of Entropy, Cloudflare‘s LavaRand is using their lava-lamps as a cool entropy source, while UChile‘s Seismic Girl is relying on a combination of seismic measurements within Chile, along with radio emissions and a custom RNG device in order to gather the required entropy.

On Kudelski Security side, while we would have loved ChaChaRand to use the bubbles of an aquarium in our lobby to provide the randomness source, or the way ink dissolves in water, or any other cool Brownian motion system to provide some entropy, but sadly we discovered it would literally be vulnerable to an evil maid attack, since during aquarium’s cleaning the entropy depleted to an unacceptable level. ;)

So we decided instead to rely on our system RNG to provide a random seed that we pass to a custom DRNG (deterministic random number generator) based on the streamcipher Chacha20, along with a secret key that guarantees nobody else could regenerate the same randomness even if they could predict the seed provided by our system.

ChaChaRand! (Image courtesy of Cloudflare)

BTW, let’s note that since the 4.8 kernel, the Linux PRNG provided by both /dev/random and /dev/urandom are also based on Chacha!

Previous work

While drand and the League of Entropy can look like a brand new creation, it is important to realize we are standing on the shoulders of giants.

Previous work include works done by different parties (including EPFL) such as the recent RandHound, which is closely related to drand, and goes back to years and years of research, as one can see in the 2000 paper “Random Oracles in Constantinople” through its even earlier references.

Among the notable applications of distributed, or “shared” randomness, the famous Tor network comes to mind, since shared randomness is used there in order to help protect the anonymity of its hidden services! But in their case, the system is relying on a more naive approach that does not prevent bias, unlike drand.

While the League of Entropy and drand are not the first distributed randomness project, there is an actual need for distributed, verifiable randomness out there.

Behind the scenes

The drand beacon uses bleeding edge cryptography, with bilinear pairings and threshold cryptography in order to achieve its goals.

For instance, BLS is used in drand in order to allow leaderless, unstructured operation. This is possible because BLS signatures supports “threshold signing”: it suffices to have a subgroup of size t among the n parties to generate a valid group signature. And even better it supports “single-phase” threshold signing, which means each party can simply wait until it has received the threshold number of signatures from the other parties, combining the subgroup signatures until it reaches the threshold, and gossiping with the other members of the group to share the signatures it received so far. This allows to make drand simpler and more dynamically robust to network and node failures.

One of the other key components behind drand is secret sharing, basically. But we will soon have more details about the inner workings of drand, stay tuned!

Conclusion

Want to try it? Well, you can query any node using the public API, or you could use the drand command line, as you prefer. Here is an example using our node and the API: open https://drand.kudelskisecurity.com/api/public and you can currently see this output:

{"round":18690,"previous":"0b2741eed1d6b5819f4462b16ddb54e81bbb8e6efbedd8cb69e86e48744392a9111f49fa30096be40910a79f83999f289779de86ddb3cfbf0e5d927582fc6268","randomness":{"gid":21,"point":"48d884b44503a7940313f7f33a9bc03b64dda9f90069e30cbd2333c0f56f48926c22ac70d270ebbcdc81b6c50ba71b93fa0e7cc4b719b4645efffea662fe0959"}}

Which corresponds to the round 18690, which allows you to deduce this has been now running for almost 13 days already, at a rate of one round every 60 seconds! You can also directly query a specific round, shall you wish to see a specific one: https://drand.kudelskisecurity.com/api/public/18690

Don’t forget to read the Cloudflare blog post about the League of Entropy, to visit the League’s website on leagueofentropy.com, or to check out the drand Github page!

(All images, courtesy of Cloudflare. Thanks to their awesome graphic team.)

Leave a Reply