Lava Lamps and Cryptographic Entropy: Inside the Wall of Entropy

A wall of lava lamps in a corporate lobby is the most photographed piece of cryptography infrastructure in the world. It is also one of the least understood. This is the engineering walk-through — what entropy actually is, why predictable randomness ends deployments, how Cloudflare’s lava-lamp wall slots into a much larger entropy pipeline, and where the same architectural pattern sits inside the secure-element silicon underneath every FIDO token, V2X OBU, eSIM, and smart card you have ever used.

Primary reference: Cloudflare — What is the lava lamp wall? (Cloudflare Learning Center). Everything factual about LavaRand below traces back to that page and Cloudflare’s own engineering posts; this piece is an independent treatment that puts the lava lamps in the context of the broader entropy stack engineers actually rely on.

What randomness means in cryptography

Two terms get used interchangeably in casual writing and matter a lot in production. Pseudo-random output is generated by a deterministic algorithm from a seed; given the seed, every subsequent bit is predictable. True random output is generated by sampling a physical process whose state is computationally infeasible to predict from outside observation. Cryptography needs both, in a specific order: a true-random source seeds a pseudo-random generator, and the generator does the bulk of the work.

The reason for that order is entropy economics. Sampling a thermal noise source can give you a few thousand bits per second on a small silicon area; a pseudo-random generator seeded with 256 bits of entropy can produce gigabits per second of cryptographically indistinguishable output. The TRNG provides the unpredictability; the CSPRNG provides the throughput. Both are mandatory.

The systems that depend on this pipeline are everywhere:

• TLS session keys. Every connection starts with random nonces from each side and ephemeral ECDH contributions; both have to be drawn from a strong source.
• Device certificates. An X.509 or IEEE 1609.2 certificate’s private key is generated once and used for years. Predictable means clonable.
• Secure boot. Anti-rollback counters and challenge values use random seeds in their construction.
• FIDO / WebAuthn. The authenticator picks a fresh credential keypair per relying party. Weak randomness yields cross-RP keypair correlations that defeat the privacy property.
• eSIM provisioning. The eUICC’s ECDH contributions during SGP.22 / SGP.32 mutual authentication are random per session.
• V2X security. Butterfly Key Expansion needs a high-entropy seed; the caterpillar key is generated inside the OBU’s secure element from its on-chip TRNG.
• PKI signature schemes. ECDSA signing reuses a private key per signature, but the per-signature nonce k must be unique and unpredictable; a biased k recovers the private key in a few signatures.
• OTP generators. HOTP / TOTP seeds are random secrets shared between device and verifier.
• Smart cards. Every challenge-response, every session-key derivation, every random GET CHALLENGE APDU rests on the on-card TRNG.

Predictability anywhere in this pipeline ends the security guarantee of everything that depends on it. This is not theoretical. The Debian OpenSSL package shipped between 2006 and 2008 with a removed line that effectively reduced the keyspace of generated keys to 32 768 possibilities — trivially brute-forceable. The 2012 "Mining Your Ps and Qs" research paper found tens of thousands of TLS and SSH keys on the public internet that shared prime factors because they had been generated on freshly-booted devices with almost no entropy. Both incidents were entropy failures, not cryptography failures.

The entropy problem in deterministic machines

A CPU is, by design, a deterministic state machine: given identical inputs, identical state, and identical instructions, it produces identical outputs. That is exactly what software needs and exactly what cryptography cannot tolerate. The challenge in randomness engineering is to bridge the gap between deterministic execution and the physical world’s thermodynamic noise.

The traditional sources every operating system has tried:

• Interrupt timings. The exact instant a network packet arrives or a disk completes a read carries some entropy from the unpredictable scheduling of physical devices. Useful on busy hosts; near-zero on fresh boot.
• Mouse and keyboard input. A user’s motor variability adds bits per event. Useful on desktops; absent on servers and headless embedded devices.
• Thermal noise across a resistor. The Johnson–Nyquist noise of a resistor is genuinely random at the quantum level. Easy to sample with a comparator. The basis of most discrete-component TRNGs.
• Oscillator drift. Two free-running oscillators with slightly different frequencies will phase-drift in ways that depend on local temperature, voltage, and process variation. Sampling the higher-frequency clock at the lower-frequency edge yields bits whose value is unpredictable. The basis of most on-die silicon TRNGs.
• Avalanche noise across a reverse-biased diode. Quantum tunneling produces unpredictable current spikes. Used in standalone TRNG modules.
• Radio noise. Atmospheric radio receivers at the right frequency pick up the cumulative noise of cosmic sources, used historically by the random.org service.
• Radioactive decay. Genuinely random at the quantum level; impractical for most deployments because of the physical isotope.

What every infrastructure-scale operator learns: any single source can fail, drift, or be tampered with. The defensible architecture combines multiple sources, mixes them through cryptographic extractors, and tests the output continuously. The lava lamps are one card in a deck that the engineers running the pipeline keep stacking.

Cloudflare’s Wall of Entropy

The setup, as Cloudflare describes it publicly: roughly a hundred lava lamps are mounted on a wall in the lobby of Cloudflare’s San Francisco headquarters. A camera photographs the wall periodically. Each photograph is digitised, hashed, and the hash output is added to Cloudflare’s entropy pool. The same pool is used to seed cryptographic operations across Cloudflare’s production fleet.

Two properties make the wall a useful entropy source:

• The wax dynamics are chaotic. Convection in a heated viscous fluid is the textbook example of sensitive dependence on initial conditions. A tiny temperature gradient now produces a wildly different blob arrangement seconds later. An attacker who photographed the wall ten minutes ago cannot predict what the photograph at the current instant will look like.
• The camera adds independent noise. Image-sensor read noise, photon shot noise, ambient light fluctuations, people walking past the lobby — every one of these adds bits to the captured frame that have nothing to do with the lava itself.

The conceptual flow:

// Cloudflare LavaRand — conceptual pipeline

   ┌────────────────────────────┐
   │   Lava-lamp wall (physics) │   ← chaotic convection
   │   + ambient lighting       │     + camera sensor noise
   └─────────────┬──────────────┘
                 │ camera capture
                 ▼
   ┌────────────────────────────┐
   │   Raw image bytes          │   ← high entropy per frame,
   │   (multi-MB per frame)     │     but uneven distribution
   └─────────────┬──────────────┘
                 │ cryptographic hash
                 ▼
   ┌────────────────────────────┐
   │   Fixed-width digest       │   ← entropy compressed,
   │   (e.g. SHA-256: 32 bytes) │     bias removed
   └─────────────┬──────────────┘
                 │ mix into pool
                 ▼
   ┌────────────────────────────┐
   │   Entropy pool             │   ← combined with TRNG output
   │   (continuously updated)   │     from many other sources
   └─────────────┬──────────────┘
                 │ seed
                 ▼
   ┌────────────────────────────┐
   │   CSPRNG                   │   ← produces the bulk
   │   (ChaCha20 / AES-CTR DRBG)│     cryptographic output
   └─────────────┬──────────────┘
                 │
                 ▼
        TLS keys · session
        nonces · token IDs · etc.

Two clarifications worth stating up front. First, the lava-lamp wall is one input among many; Cloudflare also describes additional chaotic physical installations at other offices, and the production entropy pool is mixed with output from the operating system’s standard hardware-RNG inputs, including modern CPU TRNG instructions. Removing the lava lamps would not make Cloudflare’s cryptography insecure; their job is to be one defensible source in a deep stack.

Second, the lava lamps are not a per-handshake input. Production cryptography happens at speeds the lamps cannot match. What the wall contributes is high-quality seed material that periodically refreshes a much faster CSPRNG — the same architectural pattern every TRNG-plus-CSPRNG system uses, just with a more photogenic upstream source.

How raw entropy becomes a key

The pipeline above hides four engineering steps that every defensible entropy stack performs in some form. Skipping any of them is how shipped systems end up with predictable keys.

1. Extraction

A raw physical source rarely produces uniformly distributed bits. The camera frame of a lava-lamp wall has way more bits than its entropy content; thermal noise samples drift with temperature; oscillator-jitter samples have a known bias. An extractor — in practice a cryptographic hash function or a CBC-MAC construction — concentrates the entropy into uniformly distributed output bits. NIST SP 800-90B formalises this requirement: the extractor must produce output indistinguishable from uniform random by any computationally bounded distinguisher.

2. Pooling

Multiple sources are mixed into a single entropy pool, typically by hashing them together. The Linux kernel maintains /dev/random-style pools that accept contributions from interrupt timings, hardware TRNGs, and any application that calls add_random. Pooling means that if any one source is compromised, the others still keep the pool unpredictable. This is the defensive property the Wall of Entropy buys: even an adversary who controlled every other input would still face the lava lamps.

3. Seeding a CSPRNG

The pool seeds a Cryptographically Secure Pseudo-Random Number Generator. Modern Linux uses a ChaCha20-based DRBG (after the merge that replaced the old random_get mechanism); HSMs and many embedded systems use AES-CTR-DRBG as specified in NIST SP 800-90A. The CSPRNG is what handles the throughput — gigabits per second of cryptographically indistinguishable output, from a 256-bit seed.

4. Health monitoring

Every shipped TRNG runs continuous tests on its output: repetition-count, adaptive-proportion, ChiSquare. A source that suddenly produces all zeros or stops varying is failed and the pool is marked degraded. This is the part that catches a sensor that has frozen, a camera with its lens covered, or an attacker holding a strong magnet near a circuit.

Hardware-backed entropy in deployed devices

Step out of the datacentre and into the field, and the lava lamps are not available. A FIDO authenticator on a desk, a V2X OBU in a vehicle, an eUICC inside an IoT sensor — none of them has space for a wall of chaotic lamps, and none of them can call out to a remote entropy service when generating a key. The answer is the same architectural pattern, miniaturised: an on-chip TRNG circuit inside the device’s secure element, sampling silicon-level physical noise, mixed through an on-chip extractor and exposed to applets through standard interfaces.

// On-chip entropy inside a secure element

   ┌─────────────────────────────────────────┐
   │  Tamper boundary (CC EAL5+ silicon)     │
   │                                         │
   │   ┌──────────────┐    ┌──────────────┐  │
   │   │  TRNG core   │    │  Health      │  │
   │   │  • thermal   │───►│  monitors    │  │
   │   │  • osc. drift│    │  (continuous │  │
   │   │  • metastab. │    │   tests)     │  │
   │   └──────┬───────┘    └──────┬───────┘  │
   │          │                   │          │
   │          ▼                   ▼          │
   │   ┌──────────────────────────────────┐  │
   │   │  AES/SHA-based extractor         │  │
   │   │  (whitening, bias removal)       │  │
   │   └──────────────┬───────────────────┘  │
   │                  │                      │
   │                  ▼                      │
   │   ┌──────────────────────────────────┐  │
   │   │  On-chip CSPRNG                  │  │
   │   │  (DRBG, periodically reseeded)   │  │
   │   └──────────────┬───────────────────┘  │
   │                  │                      │
   └──────────────────┼──────────────────────┘
                      │ APDU: GET CHALLENGE,
                      │ GENERATE KEY PAIR, ECDH...
                      ▼
              host MCU / applet

This is the architecture that ships inside discrete secure-element silicon used across the smart-card, FIDO, eUICC, and IoT-trust-chip product classes. The TRNG core is part of what Common Criteria evaluations test at chip level; an EAL5+ certified secure element has had its TRNG subjected to the AIS-31 test battery (the German BSI evaluation suite that NIST 800-90B largely parallels). The same applies to TPM 2.0 modules per the TCG specification, and to HSMs evaluated under FIPS 140-2 or FIPS 140-3, where the entropy source is one of the gating items in the certification.

Modern CPU instruction sets expose hardware TRNGs to userspace directly — Intel’s RDSEED and RDRAND, ARM’s RNDR and RNDRRS. The Linux kernel mixes these into the kernel pool alongside its other inputs, which is one reason cloud providers can run cryptography at scale on commodity hardware without each tenant needing its own wall of lava lamps.

Where this lands for hardware-rooted device identity

Every cryptographic claim AmbiSecure’s products rest on traces back to the quality of the entropy used at key-generation time. This is not promotional — it is the architectural floor. Three concrete cases:

• FIDO credential generation. When a OnePass Card or OnePass USB Key creates a per-relying-party credential, the keypair is generated inside the secure element from the on-chip TRNG. The unpredictability of that keypair is what makes the credential non-phishable; an attacker who could predict the private key from publicly visible factors defeats the authenticator regardless of how strong the rest of the FIDO protocol is.
• V2X Butterfly Key Expansion. The caterpillar key the OBU sends to the Authorisation Authority during Pseudonymous Certificate batch issuance is generated inside the secure element. The privacy property the V2X PKI rests on — that the AA cannot link a PC batch back to the requesting device — depends on the caterpillar key being unpredictable. A weak TRNG yields linkable PCs and breaks the architecture pseudonymous certificates were designed to provide.
• eSIM SGP.32 mutual authentication. The eUICC’s ECDH contribution during the SM-DP+ profile-download handshake is a fresh random scalar drawn from the on-chip TRNG. Weak entropy at the eUICC end gives a man-in-the-middle attacker a window to derive session keys.

The architectural pattern is the same across all three: a small piece of silicon, a TRNG circuit inside a tamper boundary, an extractor and a CSPRNG, and a stable APDU interface to the applet that needs randomness. That is the field-deployable equivalent of Cloudflare’s wall. The chaotic physical source is different; the engineering shape is identical. Secure elements is the broader treatment of this on the site.

Why entropy quality matters more at internet scale

The two structural changes of the last decade make the entropy story more important, not less.

Massively automated attacks. An attacker with a botnet running modern hardware can attempt key recovery on hundreds of millions of keys in a campaign. The "Mining Your Ps and Qs" survey from 2012 was conducted by academic researchers with limited budget; equivalent surveys today, conducted by adversaries with cloud-scale compute, find weak keys faster than operators rotate them.

Scale of TLS handshakes. A large-edge provider terminates trillions of TLS sessions per day. Each one consumes randomness for nonces, ephemeral key contributions, and IV generation. The CSPRNG is what makes that throughput feasible; the TRNG-quality seeding it depends on is what makes the output unguessable. The wall of lava lamps is, in part, a public commitment that the entropy floor is being taken seriously.

Post-quantum migration. The migration from ECDSA / RSA to lattice-based signatures (CRYSTALS-Dilithium, FALCON) and key-encapsulation mechanisms (CRYSTALS-Kyber) does not change the threat model for randomness. Lattice-based key generation needs strong entropy; lattice-based signing needs fresh per-signature randomness exactly as ECDSA does. The post-quantum world ships with the same TRNG dependency.

Nation-state operator concerns. The Dual_EC_DRBG incident (a NIST-standardised CSPRNG whose constants are widely believed to have contained a backdoor) is the cautionary tale that drove deployment of multi-source entropy as a defensive architectural property, not just a belt-and-braces choice. The defensive posture: do not let any single party have visibility into every input to your randomness pipeline.

Can lava lamps alone secure the internet?

No, and that is the point. The wall is one entropy source in a layered architecture. Its job is to be defensible, observable, and independent of the other sources mixed alongside it. Three reasons the layered design matters:

• No single source is unfailable. A camera lens that fogs over, a sensor that develops a stuck pixel, an oscillator that drifts — each is a single-point failure. Mixing means the pool stays strong even when a source goes bad.
• No single source is unobservable. An attacker who could photograph the lobby wall through the window still cannot predict the lava lamps’ future state, but combining sources defeats even hypothetical adversaries who could compromise one.
• Entropy is the seed; cryptography is the engine. The lava lamps do not encrypt anything. They contribute bits that, once mixed with the rest of the pool, seed the CSPRNG that does the actual work. The cryptographic primitives downstream — ChaCha20, AES, SHA-256, the ECDH curves — are what carry the bulk of the security budget. The entropy stack is the foundation that those primitives stand on.

The right mental model for the Wall of Entropy is "trust anchor, demonstrably independent, hard to compromise covertly" — the same role a CC EAL5+ certified TRNG plays inside a secure element, just at a different scale.

Comparison: entropy sources by property

Order of magnitude only — specific TRNG silicon varies widely. The comparison is intended to show the trade-offs, not to rank sources absolutely.

Security begins with unpredictability

The lava-lamp wall is a beautiful piece of infrastructure to point at when someone asks where the random numbers come from, but the engineering story it stands for is much broader. Every cryptographic operation on the internet today depends on entropy that came, eventually, from a physical process: thermal noise in a CPU, oscillator drift in a secure-element die, atmospheric photons captured by a sensor, blobs of wax moving slowly inside a glass tube in San Francisco. The cryptographic primitives that protect TLS sessions, FIDO credentials, V2X messages, eSIM profiles, and smart-card transactions are the machinery; the entropy underneath them is the fuel.

What the Wall of Entropy demonstrates publicly is a discipline every engineer who ships hardware-rooted security has to apply privately: multiple independent sources, cryptographic extraction, continuous health monitoring, and the assumption that any single component will eventually fail. The same discipline applies to the on-chip TRNG inside the secure element that holds your FIDO credential, the V2X OBU’s caterpillar-key generator, and the eUICC’s session-key derivation. Take entropy seriously upstream and the cryptography downstream has a chance to do its job. Cut corners on the entropy side, and no amount of algorithmic strength makes the difference.

Related reading

• Cloudflare — What is the lava lamp wall? (primary external reference)
• Why software-only device trust fails — the threat model that drives hardware-rooted identity, including the entropy floor.
• Secure elements in connected vehicles — the silicon class that ships the TRNG circuits this piece refers to.
• How V2X PKI works · Pseudonymous certificates and privacy — where the caterpillar-key randomness underpins the privacy property.
• Device identity at manufacturing scale — the factory-side provisioning step that depends on TRNG output inside the SE.
• Secure elements technology page · IoT Security Co-Processor · IEEE 1609.2 reference · GSMA SGP.32 reference.
• Standards: NIST SP 800-90A (DRBG mechanisms), SP 800-90B (entropy sources), SP 800-90C (construction guidance), BSI AIS-31 (evaluation methodology for physical RNGs), RFC 4086 (Randomness Requirements for Security).