
A wall of lava lamps helps encrypt the internet - prando
https://www.atlasobscura.com/places/encryption-lava-lamps
======
patcheudor
My lesson from my personal experiments with Lavarand: you must have more than
one lamp, not necessarily for more entropy, but for fail-over and uptime. At
approximately ~30 hours, my vintage 70's lamp 'gives up' \- the fluid
temperature becomes pretty even between the bottom and the top. It's all
essentially superheated as far as the wax is concerned and it simply stays in
one place as a dome at the bottom, barely moving. This isn't good for creating
random data. By using multiple lamps, it's possible to power cycle them.
Ideally, every ten hours or so, remaining off for a couple hours.

~~~
LeoPanthera
Would attaching a heat sink to the top of the lamp solve that problem? So
there's always a heat gradient.

It would probably work better in a colder room, too.

~~~
s0rce
Put a TEC on the top with a heatsink if your room is warm.

------
oppositelock
We did this exact thing at SGI 20 years ago.
[https://en.wikipedia.org/wiki/Lavarand](https://en.wikipedia.org/wiki/Lavarand)

I wonder if Cloudflare was inspired by that.

~~~
tptacek
Yes, they were; they mentioned it explicitly.

~~~
erric
The article doesn’t actually mention SGI.

~~~
vonseel
It’s tptacek. He’s probably spoken with Cloudflare directly or consulted for
them.

~~~
tptacek
(1) No.

(2) No love lost there.

(3) That is a weird comment to write.

~~~
vonseel
Thanks! I try!

------
samuel
I might be prejudiced, but this looks like a big PR stunt/done for the cool
factor kind of thing. Aren't there simpler/saner alternatives for getting good
randomness?

~~~
Houshalter
What would be an easier way? A wall of lava lamps seems pretty easy to set up.

~~~
comboy
busy streets webcams?

~~~
MBCook
That would be susceptible to traffic patterns.

~~~
comboy
Cars don't look exactly the same and are not in the exact same places.
Lighting changes. People look very different and walk different paths. It's
going through PRNG so even very small pixel differences (which you can find
even on an empty street thanks to changing weather, litter, wind and so on)
are good enough if they are unpredictable. In other words, when you compare
pictures of the same lava lamp with pictures of some random cars, I think you
will be able to find more patterns in the lava lamp movement. You would also
likely be able to predict it better (well that's the same thing I guess).

~~~
Quenty
My guess is there’s still enough noise it doesn’t matter.

------
ceph_
There's a good Tom Scott video on this too. Like most of his stuff, it's well
worth the watch.

[https://youtu.be/1cUUfMeOijg](https://youtu.be/1cUUfMeOijg)

------
schoen
A lot of confusion in this discussion thread and other promotions of this idea
stems from the intuition that you can "run out" of entropy in your random
number pool if you don't periodically replenish it with a physically
unpredictable source. I have had this intuition too. Two things that feed it
are the Linux random(4) man page and the behavior of GPG when generating a new
private key.

tptacek tried to explain some of the problems in this intuition at
[https://sockpuppet.org/blog/2014/02/25/safely-generate-
rando...](https://sockpuppet.org/blog/2014/02/25/safely-generate-random-
numbers/), which relates to why he's so annoyed at some things people have
said in this thread (and when discussing CSPRNG seeding in other places).

I like the idea of feeling physically unpredictable data into the CSPRNG, but
for most purposes it's a misconception that doing so on an ongoing basis is in
any way required by the design or that heavy users of randomness like
CloudFlare would "run out of entropy" or "exhaust their entropy pool" if they
didn't do so. The design of existing CSPRNGs would let CloudFlare use
/dev/urandom for as long as it likes after securely seeding it just once, and
there's no known cryptanalytic attack to which this practice would be
vulnerable.

~~~
Bromskloss
I've read that post now and previously (though not its references) and I feel
that it never gets to the point where it explains how urandom can be equally
safe as random.

Is the idea not that it is information-theoretically safe, but rather that the
computational requirements are too great to figure out the state of the
random-number generator even after a large amount of observed output?

~~~
JdeBP
Then you might find that Thomas Hühn's approach helps you.

* [https://www.2uo.de/myths-about-urandom/](https://www.2uo.de/myths-about-urandom/)

The "another crypto expert" mentioned by schoen is Daniel J. Bernstein, quoted
directly by Hühn.

~~~
Bromskloss
I guess this kind of, maybe, explains it, though in an oblique way, and even
that only because I was already on the lookout for something about
information-theoretical security vs. computational security.

It mostly brings up misconceptions I never had, and attacks those. For
example, why would it matter that /dev/random gets its output from the same
CSPRNG as /dev/urandom (or any other CSPRNG)? Shouldn't the output of the
CSPRNG, assuming its state is large enough, contain as much entropy as its
input?

The focus on giving me orders about what I should do, rather than telling me
why, also gets old somewhere around the first time.

------
jgrahamc
The Cloudflare blog posts that go into this in detail:

[https://blog.cloudflare.com/lavarand-in-production-the-
nitty...](https://blog.cloudflare.com/lavarand-in-production-the-nitty-gritty-
technical-details/)

[https://blog.cloudflare.com/randomness-101-lavarand-in-
produ...](https://blog.cloudflare.com/randomness-101-lavarand-in-production/)

------
wkandek
More details on how it is implemented here:
[https://blog.cloudflare.com/lavarand-in-production-the-
nitty...](https://blog.cloudflare.com/lavarand-in-production-the-nitty-gritty-
technical-details/)

------
RKearney
Previous discussions:

[https://news.ycombinator.com/item?id=15048655](https://news.ycombinator.com/item?id=15048655)

[https://news.ycombinator.com/item?id=15114275](https://news.ycombinator.com/item?id=15114275)

------
Negative1
I did something similar a few years back, except instead of Lava lamps, I used
a Geiger counter module connected to an Arduino (scrap from a project I was
working on to make something economical for civilian use after the Fukushima
Daiichi nuclear disaster). Basically, the background radiation is used as the
PRNG number (not just as the seed). I found out later that someone at Sparkfun
already did this:
[https://www.sparkfun.com/tutorials/132](https://www.sparkfun.com/tutorials/132)

------
nickpsecurity
This is pretty cool use of tech that goes back to SGI. It's definitely not the
practical solution to TRNG's. There are analog solutions that use basic
physics and EE techniques to generate noise fast, cheap, in tiny footprint if
you want, and with a lot of potential diversity in supply chain. Here's an
example of an open one:

[https://github.com/waywardgeek/infnoise/blob/master/README.m...](https://github.com/waywardgeek/infnoise/blob/master/README.md)

------
chiph
If Cloudflare ever open another office, they could use a wall full of Drinky
Birds for randomness.

[https://en.wikipedia.org/wiki/Drinking_bird](https://en.wikipedia.org/wiki/Drinking_bird)

------
Kequc
That's approximately 100 lava lamps each at 100W = 10,000W = 10kW/h * 20.4
cents = $2.04/h * 24 = $48.96/day $1,489.20/month.

Ignoring the fact that is very little money in Silicon Valley. Lava lamps
consume a large amount of electricity in order to generate the heat they need.
There are cheaper better ways to generate randomness, this is purely for
spectacle clearly.

It makes me nervous more than anything. If that's the front they put up,
inside is there a Rube Goldberg machine that triggers DDoS protection?

~~~
ams6110
IIRC a standard size lava lamp used much less than a 100W bulb. So your costs
are maybe half that.

~~~
adzm
40W on mine fwiw

~~~
hinkley
As someone else pointed out, they overheat. So if you want to run them all day
you might go down to a 30 or 25 watts.

But there are probably a bunch of other Brownian motion machines you could use
that take a lot less power. Like those glitter lamps. You’d need a higher res
camera.

~~~
JdeBP
Infinite improbability is just around the corner, eh? (-:

------
jlgaddis
Cloudflare's own blog posts about this:

[https://blog.cloudflare.com/lavarand-in-production-the-
nitty...](https://blog.cloudflare.com/lavarand-in-production-the-nitty-gritty-
technical-details/)

[https://blog.cloudflare.com/randomness-101-lavarand-in-
produ...](https://blog.cloudflare.com/randomness-101-lavarand-in-production/)

------
xg15
Assuming this is not a PR stunt: Wouldn't different lighting conditions
throughout the day lead to patterns in the randomness?

~~~
firethief
Another pattern is the bases of the lamps rarely change. Patterns are OK; the
important thing is that unpredictable components are present.

------
bmm6o
One of my common daydreams is designing entropy-generating setups like this.
Just last week I went on a brewery tour (Bell's) and stared at the bottling
plant for a while, admiring the chaos of the bottles bumping into each other
as the path turns and narrows.

------
olivierva
A variation on Brownian Motion:
[https://en.wikipedia.org/wiki/Brownian_motion](https://en.wikipedia.org/wiki/Brownian_motion)

------
JoeDaDude
If you can't afford that many lava lamps, NIST provides an alternative, free
service:

[https://beacon.nist.gov/home](https://beacon.nist.gov/home)

~~~
bhhaskin
WARNING: DO NOT USE BEACON GENERATED VALUES AS SECRET CRYPTOGRAPHIC KEYS.

So probably not a good idea.

~~~
foodstances
Using the values directly is not the same thing as feeding the values into a
RNG.

~~~
kvakil
No, the reason you aren't supposed to use it to generate cryptographic keys is
because it's public: so it effectively provides no (or nearly no) entropy.
It's the same reason you shouldn't use the current time as a seed for a PRNG.

NIST Beacon is more intended for things like lottery drawings, where you want
to prove that you're generating the random numbers in an unbiased manner.

------
natch
How do they prevent the camera or its outgoing feed from being hacked or
replaced by the NSA?

Edit: I see this is addressed partially by wkandek's link elsewhere in this
discussion.

------
lalos
Reminded me about the dice-o-matic

[https://news.ycombinator.com/item?id=14806986](https://news.ycombinator.com/item?id=14806986)

------
minimaxir
It's worth nothing that the lava lamps are visible street side through large
glass windows, so it serves as an eye-catching artpiece for passerbys.

------
amelius
So how many bits does it produce per second per lamp?

------
solotronics
I bet they combine this with /dev/urandom or something to just add an element
of chaos to something a computer generates

------
goblins
I like this. Seems like a simple analog solution to fairly difficult digital
problem; true randomness that is.

------
tempestn
Cool. Would have been nice if the article at least devoted 1-2 sentences to
explaining PRNG seeds though.

------
angel_j
I prefer cosmic background radiation.

------
saagarjha
> Since computer codes are created by machines with relatively predictable
> patterns, it is entirely possible for hackers to guess their algorithms,
> posing a security risk.

That’s not what “computer codes” and “algorithms” mean.

------
xir78
Do they have the distribution posted somewhere?

------
booleanbetrayal
Hack the Planet = Hack a Camera?

~~~
booleanbetrayal
Ah, apparently, based on one of the detailed links just posted, it just
provides one feed of entropy to the mix -- not the sole source.

------
diyseguy
SGI did it first

------
maxsavin
But is it really random? #conspiracy

------
sgt101
The issue with this is the nature of devices (cameras) and device drivers -
which both have non random characteristics.

------
jorgec
Generating a random number by using microseconds as a seed is more than enough
for practically every single case. It still hasn't been cracked or predicted.

Some people say that, in theory, it could be cracked however, i tried and its
impossible, modern computers are so complex and fast that it gives enough
entropy.

~~~
minitech
That’s dangerously wrong. If you generated a password using only microseconds
as a seed, an attacker who knew the day you did it could crack (an MD5 hash
of) the password within a few minutes, for example.

------
anonu
Seems like a waste of energy... I can imagine putting a weather station on the
roof would be more useful (albeit less cool). Use multiple sensors for
rainfall, UV, wind speed, wind direction, temperature, pressure and aggregate
the signals from each... Surely the combination of localized weather readings
would provide enough randomness.

~~~
jonknee
It's ~100 lamps for entropy that covers ~10% of the internet, energy
consumption is a ridiculous complaint.

~~~
tptacek
This isn't how entropy works. They have more than enough "entropy" for "10% of
the Internet" without the lava lamps.

------
cryptoz
It's open to the public‽ Seems like a bad idea to let a potential spy in there
to set up a camera and de-randomize this source of random info. Also, the
headline on HN declares it a fact that the lava lamps are assisting in the
encryption, but the article is careful to say "maybe", "might", etc.

This seems wildly insecure and much more likely to represent a weak link than
to actually aid in randomness.

~~~
ejcx
Even if the data is not random it doesn't weaken your kernel prng by writing
non-random data to urandom.

Don't overcomplicate your threat model with non-existent risks

~~~
schoen
Didn't DJB somewhere describe a PRNG model in which this is not true and you
shouldn't let an adversary give you PRNG seeds?

(I don't have any problem with what CloudFlare is doing.)

Edit: While I was writing this comment, drewbug linked to the exact DJB post I
was thinking of. Thanks!

~~~
tedunangst
Someone observing the lava lamps still can't control their appearance.

