Harnessing chaos in Cloudflare offices

From lava lamps to office-wide entropy

Cloudflare’s LavaRand system has expanded far beyond its original wall of lava lamps in San Francisco. What began in 2017 as a single physical entropy source has grown into a distributed collection of chaotic installations across multiple offices, all feeding into the randomness that helps secure connections made through Cloudflare’s infrastructure.

Cloudflare’s servers handle upwards of 55 million HTTP requests per second, the vast majority secured via TLS. Cryptographic protocols like TLS depend on secure randomness — outputs that are both statistically random and unpredictable to any computationally-bounded adversary. This is typically achieved by seeding a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) with truly random data, but the quality of that initial seed is critical. For years, Cloudflare’s servers relied on local entropy sources like packet arrival timing and keyboard events; LavaRand was introduced as an external hedge, allowing servers to periodically refresh their entropy pools with randomness derived from physical systems.

New sources of chaos

Cloudflare’s Places team has ensured that several larger offices feature installations of physical entropy systems, and these have been progressively integrated into LavaRand over time.

London’s double pendulums

Visitors to the London office encounter a wall of double pendulums whose swings are captured as an entropy source. The shadows cast by the rotating arms — which shift with changing light conditions — add an extra layer of chaos to the captured images. Even if the motion is considered completely deterministic, double pendulums are mathematically chaotic: highly sensitive to initial conditions, each setup produces a unique path until the system comes to rest and is reset by an employee.

Austin’s rainbow mobiles

The Austin office, which recently marked its first anniversary, contributes a suspended installation of translucent rainbow mobiles above its entrance. These mobiles twirl and cast colored patterns on surrounding walls, responding to door movements, HVAC changes, and ambient light. The changing scene is periodically photographed and fed into the LavaRand stream.

How the chaos is captured

The incorporation of new sources follows the same process used for the original lava lamps. At repeated intervals, a camera captures an image of the installation’s current state. Since the underlying physical systems are unpredictable, the images contain true randomness — shadows, lighting variations, and even image sensor noise all contribute. At a base level, image sensors are often noisy enough that even lens-capped captures could serve as entropy sources.

Each still image is reduced to a fixed-size output via hashing.

The resulting random bytes are combined with the previous seed and local system entropy through a Key Derivation Function (KDF), producing a new seed for a CSPRNG. This stream of randomness is exposed via an internal API that clients can query for fresh bytes.

seed = KDF(new image || previous seed || system randomness)
rng = CSPRNG(seed)
…
rand1 = rng.random()
rand2 = rng.random()

Private and public randomness

Applications use secure randomness in two distinct ways.

Private randomness is reserved for values that must remain secret: passwords, cryptographic keys, user IDs. Cloudflare’s servers periodically request fresh private randomness from LavaRand to update their entropy pools, which means LavaRand-sourced randomness is effectively available to the outside world through Cloudflare’s infrastructure. Developers can tap into this via the Web Crypto API’s getRandomValues function running in a Cloudflare Worker, or use an existing implementation such as csprng.xyz.

Public randomness consists of unpredictable, unbiased values published for everyone to see — lottery numbers, sporting event coin flips. Because they are public, they must never be used to generate cryptographic keys. Public randomness also needs to be trustworthy; consumers must be confident the values weren’t manipulated. Historical cases, such as the state lottery employee who subverted a random number generator for personal gain, illustrate what happens when that trust breaks down.

A fundamental challenge with public randomness is that users must trust the producing authority. For some applications, relying on a well-known body like NIST may be acceptable, but for others — particularly those where decentralization matters — that trust model proves problematic. This is where publicly verifiable randomness, which allows consumers to confirm outputs were faithfully produced, becomes valuable.

Public randomness from a distributed beacon

Trust in a single source of randomness is a known weakness, so Cloudflare joined with seven other independent organizations in 2019 to form the League of Entropy and launch a public randomness beacon built on the drand protocol. Each member contributes its own entropy source — Cloudflare feeds in randomness from LavaRand — and the collective pool seeds the network.

What started as an experimental project has matured into a production Internet service with guidance from the drand team at Protocol Labs. Applications now rely on it for distributed file storage, online gaming, timestamped proofs, and timelock encryption. The League of Entropy has also expanded from its original eight members to 18 organizations across four continents.

The drand beacons (each configured with its own parameters, such as randomness frequency and whether values are chained) are both decentralized and verifiable. Decentralization means no small group of actors can bias the output; verifiability means anyone can confirm that a random value was produced per the protocol with participation from a threshold — usually more than half — of the network’s nodes.

Distributed key generation and threshold signatures

At beacon setup, nodes run a distributed key generation (DKG) protocol based on the Pedersen commitment scheme. Each node ends up with a share of a distributed group key that remains fixed for the beacon’s lifetime. To sign a message, at least a threshold of nodes (for example, 7 of 9) must cooperate to construct a BLS threshold signature. The group information for the quicknet beacon on the League of Entropy mainnet is shown below:

curl -s https://drand.cloudflare.com/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/info | jq
{
  "public_key": "83cf0f2896adee7eb8b5f01fcad3912212c437e0073e911fb90022d3e760183c8c4b450b6a0a6c3ac6a5776a2d1064510d1fec758c921cc22b0e17e63aaf4bcb5ed66304de9cf809bd274ca73bab4af5a6e9c76a4bc09e76eae8991ef5ece45a",
  "period": 3,
  "genesis_time": 1692803367,
  "hash": "52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971",
  "groupHash": "f477d5c89f21a17c863a7f937c6a6d15859414d2be09cd448d4279af331c5d3e",
  "schemeID": "bls-unchained-g1-rfc9380",
  "metadata": {
    "beaconID": "quicknet"
  }
}

(The hex value 52db9b… in the URL is the hash of the beacon’s configuration. All beacons supported by Cloudflare’s mainnet drand nodes are listed at https://drand.cloudflare.com/chains.)

Nodes on the network are scheduled to periodically (every 3 seconds for quicknet) produce a signature over an agreed-upon message, such as the current round number plus the previous round’s signature. Each node generates a partial signature over that round message and broadcasts it. Once enough partial signatures are collected, a node aggregates them into a group signature for that round.

curl -s https://drand.cloudflare.com/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/public/13335 | jq
{
  "round": 13335,
  "randomness": "f4eb2e59448d155b1bc34337f2a4160ac5005429644ba61134779a8b8c6087b6",
  "signature": "a38ab268d58c04ce2d22b8317e4b66ecda5fa8841c7215bf7733af8dbaed6c5e7d8d60b77817294a64b891f719bc1b40"
}

The group signature for a round is the randomness; the output value is the SHA-256 hash of the signature for applications that prefer fixed-size output. The signature cannot be predicted in advance as long as at least a majority of nodes are honest and don’t collude. Anyone can validate a round’s signature against the beacon’s group public key. Developers should use the drand client libraries or CLI to verify every value they pull from the beacon.

Chained vs. unchained randomness

The League of Entropy’s first-generation beacons (launched in 2019) signed messages that included the previous round’s signature, creating a chain back to a genesis round. Chained randomness offers useful properties for single-source beacons and is part of NIST’s spec for interoperable public randomness beacons.

In 2022, the drand team introduced unchained randomness, where the message to be signed is predictable — not dependent on prior rounds — and demonstrated it offers the same security guarantees as chained randomness for drand (both require an honest threshold of nodes). In quicknet’s implementation, the message is simply the round number.

# chained randomness
signature = group_sign(round || previous_signature)

# unchained randomness
signature = group_sign(round)

Unchained randomness improves usability: a consumer need not reconstruct the whole chain back to genesis to validate a single round. Only the current round number and the group public key are required, letting clients consume rounds at their own pace without continuously following the chain.

Because the messages to be signed are known in advance (they’re just round numbers), unchained randomness also enables timelock encryption.

Timelock encryption

Timelock (or “timed-release”) encryption hides a message until a predetermined amount of time passes. Rivest, Shamir, and Wagner described two fundamental approaches:

• Time-lock puzzles: computational problems that require a computer to run continuously for at least a specified duration.
• Trusted agents: parties who promise not to reveal information until a specified date.

Trusted agents raise the obvious issue of ensuring trustworthiness, which secret sharing schemes can mitigate. A drand network is exactly that: independent agents using secret sharing, where the “certain information” is the per-round randomness. Timelock encryption works on top of a drand network with unchained randomness, using bilinear groups and pairings-based cryptography. For the full details, see tlock: Practical Timelock Encryption from Threshold BLS by Nicolas Gailly, Kelsey Melissaris, and Yolan Romailler.

How to timelock your secrets

First, identify the randomness round that, once revealed, will allow decryption. Since drand networks produce randomness at fixed intervals, each round is tied to a specific timestamp — computable from the beacon’s genesis timestamp plus round number multiplied by the beacon’s period.

With the target round chosen, properties of bilinear groups let you encrypt a message to that round using the beacon’s group public key.

ciphertext = EncryptToRound(msg, round, beacon_public_key)

After the drand nodes cooperate to derive the randomness for the round (the signature on the round number using the group secret key), anyone can decrypt the ciphertext.

random = Randomness(round)
message = Decrypt(ciphertext,random)

For practicality, the timelocked message is the secret key of a symmetric scheme. The actual message is encrypted with that symmetric key, and the key itself is timelock-encrypted for future decryption.

For a live demonstration, one of Cloudflare’s engineers built a tool on top of Cloudflare Workers; the source code is public.

# 1. Create a file
echo "A message from the past to the future..." > original.txt

# 2. Get the drand round 1 minute into the future (20 rounds) 
BEACON="52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971"
ROUND=$(curl "https://drand.cloudflare.com/$BEACON/public/latest" | jq ".round+20")

# 3. Encrypt and require that round number
curl -X POST --data-binary @original.txt --output encrypted.pem https://tlock-worker.crypto-team.workers.dev/encrypt/$ROUND

# 4. Try to decrypt it (and only succeed 20 rounds x 3s later)
curl -X POST --data-binary @encrypted.pem --fail --show-error https://tlock-worker.crypto-team.workers.dev/decrypt

Where things go from here

Chaos powers the encryption that secures the Internet. LavaRand will keep converting the chaotic beauty of the physical world into a stream of randomness — even as new entropy sources are added — for applications we haven’t yet imagined.

And she gazed at the sky, the sea, the land
The waves and the caves and the golden sand.
She gazed and gazed, amazed by it all,
And she said to the whale, “I feel so small.”