Introduction

On the morning of November 18, 2025, we woke up to the temporary shutdown of thousands of websites used on a daily basis. What turned out to be an issue with Cloudflare proved that Cloudflare is truly part of the infrastructure of the internet: 81 million HTTP requests per second on average, according to their 2025 Radar. See Cloudflare Radar 2025 Year in Review.

But probably one of the most impressive things is something I saw years ago and did not pay attention to until now: the lava lamp wall they use for encryption. Through some research, I understood that they make use of nature's randomness to transform chaos into keys, which led me to the idea of simulating the process visually through a small web app that I will walk you through building in this blog.

The Concept

Why do we need lava lamps to compute encryption? Or a better question: what is encryption? And then the most important one: why aren't computers alone capable of providing secure encryption?

Encryption, in its simplest definition, is a reversible mathematical transformation. For a deeper reference, see Introduction to Mathematical Cryptography.

It takes a message, combines it with a key, and returns an encrypted message readable only by the holder of the correct key. There are many forms of this transformation, usually involving arithmetic and prime numbers.

To simplify things, we can represent the algorithm as a transformation $E$ that takes $M$ (message) and $K$ (key) and returns an encrypted result:

This becomes interesting when you focus on the key. The message is variable and the algorithm is public. This is by design, known as Kerckhoffs's principle: a system should not rely on the secrecy of its algorithm. Security lives entirely in the key. And that is where randomness becomes critical.

But you may ask: since computers can generate random numbers, where is the problem? That is what we will discuss next.

Computers and Number Generation

We consider computers to be deterministic machines. A deterministic machine takes an input and produces the same output every time. Every output is reproducible.

Encryption keys become vulnerable if they rely only on the computer's random number generator, which is in fact a PRNG, a pseudo-random number generator. As the name implies, it is not truly random. It is an iterative function based on a previous state, which means it can be reproduced if patterns are perceived. This is not theoretical: the Netscape SSL vulnerability in 1994 was exploited exactly this way.

Real randomness comes from the physical world, with its non-deterministic nature and unpredictable physical processes. That is why computers evolved to use TRNGs, true random number generators, which capture physical entropy such as atmospheric noise, thermal noise, and hardware timing jitter to produce the high-quality entropy we are looking for.

The drawback of TRNGs is that they are slow. This led to a hybrid approach: a TRNG generates a truly random seed, which is then fed into a CSPRNG, a cryptographically secure pseudo-random number generator, that expands it into a stream computationally indistinguishable from real randomness while remaining fast.

That is essentially what Cloudflare does.

The Lava Lamps and Keys

In this system, lava lamps act as a source of entropy, a source of real physical randomness. Many lamps are placed on a wall facing a camera that captures their state continuously. These states are then used to compute an entropy seed, which is fed into the CSPRNG we discussed.

This works by taking images from the camera and transforming the pixel matrix, each pixel encoded in RGB, into a byte sequence. The sequence is hashed to extract entropy without bias, since images can contain patterns. The result is then used as an input to the CSPRNG.

Cloudflare does not rely only on image entropy. It also mixes in time jitter, system entropy, and additional environmental noise.

The Simulation

To implement this, I needed to build two components: a lava lamp simulation, and a pipeline to extract entropy from rendered frames.

To create a research-grade simulation, I would need to solve the Navier-Stokes equations, which is computationally intensive, especially in a browser, and requires a fluid dynamics background I do not have.

Instead, I approximated the behavior using a simplified force model:

• Gravity
• Drag force
• Temperature gradients, with bottom heating and top cooling
• Buoyancy force
• Boundary forces to keep blobs inside the lamp

I applied Newton's laws and Euler integration to compute acceleration, velocity, and updated positions of the blobs. To differentiate lamps that share the same equation parameters, I introduced a term using trigonometric oscillations based on lamp IDs.

Rendering is done using a marching cubes field composition, which is the most computationally expensive part of the application and explains any performance issues you encounter. Users can capture frames and process them through the entropy pipeline to generate a key, which is not secure and should not be treated as such, as explained throughout this work.

More details on the physics formulas can be found in the dedicated sub-page.

You can also explore the full project page here.

Conclusion

First, I clearly need a fluid dynamics course.

On a more serious note, the way interdisciplinary engineering produces such remarkable systems is fascinating. A camera watching wax move in oil ends up inside the encryption handshake of millions of HTTPS connections. Everything is connected, from the electrical components of the computer I am typing on to the abstract layers of software that process physical randomness into cryptographic security.

Feel free to explore the simulation and interact with the agent if you want deeper explanations, though it runs under infrastructure constraints, so keep expectations reasonable.

Notes

• The project was built using Three.js, React Three Fiber, and Next.js
• Infrastructure: Vercel, Cloudflare D1, and Vectorize
• Agent system: LangGraph with inference via Cloudflare Workers AI
• The application was developed with detailed prompt tracking. See PROMPTS.md on the GitHub repository
• Tone, formulation, and text by me, refined with Claude's structural edits