The Futility of Lava Lamps: What Random Means | Hacker News Reader

The Futility of Lava Lamps: What Random Means

loup-vaillant.fr

77 pointsbirdculture57 comments

Lotta speculation about it's value but seems cloudflare does legitimately use this source.

https://blog.cloudflare.com/lavarand-in-production-the-nitty...

They even mention it's origins in Lavarand (and LavaRand) the former which has an actual patent: https://patents.google.com/patent/US5732138A/en

Yes there's a bit of theater here, and they admit to using the sensor noise as well, it's also not their only source of physical entropy. While you could do just as much with less interesting sources the wall of lava lamps is a perfectly cromulent source of randomness, also is kinda fun.

Lava lamp entropy embiggens us all.

As far as cryptographic security theater goes, it's hard for me to get angry about lava lamps.

They're very calming

I don't remember their initial post about the lava lamps, but I had assumed that was a marketing gimmick more than anything... a neat visual way to convey what entropy is in a way normal humans can comprehend.

It's certainly not a scalable solution for entropy, and there are so many ways for it to fail as a sole source, as well.

I'm dead sure they aren't using them for anything.

This is SF. If they were really used for anything, a random dude in a black hoodie and white SUV can just smash the glass and take down the internet, and the SF police wouldn't do a thing.

If you look up videos on YouTube, you'll see that they allow visitors to stand between the lava lamps and the cameras (sometimes even entire groups!). And I've always wondered: doesn't that reduce entropy, since people usually wear monotone clothing? And if the lamps are so important, why would they allow that? Maybe the lamps do contribute something, but their system most likely already generates enough entropy with or without the lamps...

It also depends on how often samples are taken. If it only occurs every hour, Fred in his white shirt is highly unlikely to be standing in the exact same spot still.

Remember, these are only seed values, a pseudorandom number generator will run indefinitely, but from what I understand, CF re-runs these periodically with different seed values, to stop people finding the pattern.

Smashing the glass wouldn't make it less effective. The sensor itself has noise, and the camera output is fed into an HMAC with a key based on the current nanosecond before being combined with a traditional entropy source before it ever went anywhere. Even then, it was only used as a seed for the entropy pool on the actual server.

> and the camera output is fed into

snip snip ?

If your attack vector is breaking and entering, that's a pretty effective cybersecurity mechanism.

But even if it happened, this is one of many additive entropy mechanism, removing or controlling only one source would not be sufficient for any attack.

You still wouldn't be about to distinguish the output from noise unless you know the key or you've broken the cryptography, even if you know every bit of the message. Isn't it neat?

And yes, as the other comment points out it's only one source among multiple.

It's been quite a while since I first heard about it, but IIRC they were seeding cryptographic PRNGs with entropy from multiple sources, one of which was allegedly this art installation.

Seeding PRNGs with sufficiently unpredictable data was a real security concern for a while. New cloud instances have a small entropy pool space for attackers to enumerate due to lack of a real source of randomness. (See the Debian/OpenSSL issue for what can happen when your entropy pool is too small/predictable)

One fun fact about XOR is that anything XOR'd with a uniform random distribution results in a uniform random distribution, so there isn't any harm in mixing additional non-attacker-controlled entropy sources in as long as at least one of them is sufficiently unpredictable. The lava lamps provide a potentially hard-to-predict source of entropy for this, but if it's not available then it certainly doesn't "take down the internet". They'll still use packet arrival timing, interrupt timing, etc to seed their CSPRNGs.

If you want entropy ot is trivial to construct a white noise source that gives you flat white noise over a range of a few MHz using the reverse avalanche breakdown of a zener diode. The harder part is then reading that out in a way that doesn't introduce bias and makes use of the bandwidth, but if tou want random it is right there in electronic quantum processes.

article has a section dedicated to "how to obtain starting seed" with a list of examples and somehow fails to include wall of lava lamps in said list of examples

They kind of do if you play 6 degrees of wikipedia...

The 'hardware random number generator' link in the list in the article goes to https://en.wikipedia.org/wiki/Hardware_random_number_generat..., and then in the see also section on that article there's a link to the page for a different lava lamp wall, with a photo of the cloudflare one: https://en.wikipedia.org/wiki/Lavarand

They don't actually do anything, but I think it's hard to tell a story where they make things worse, given that Cloudflare is a cryptographically competent org. It's just getting mixed into the already-secure conventional CSPRNG they're using (almost certainly: just the Linux kernel RNG).

> I think it's hard to tell a story where they make things worse [...] mixed into the [...] CSPRNG

I think it's easy to tell a story where it's slightly worse. I mean, for any budget of storage bits and CPU cycles, any "inferior" random data necessarily pushes out "better" stuff.

It's all hashed together. The whole LRNG design assumes most of its inputs are structured or poorly randomized.

I'm not sure what you mean, deterministic hashing does not create more entropy than you started with. Lower-quality inputs means lower-quality results. You only want to use low-quality sources if the good stuff is too scarce or expensive.

Imagine that tomorrow some reaction caused all those lava-lamps to cloud over into pure, constant, and uniform milky white. What effect would that have? It would make the system at least somewhat less secure, no matter how many hash functions were already scattered around the place.

In the immortal words of a cryptographic folk hero, if H(x, y) produces a good random number, H(x, y, z) will produce a number at least as good.

Perhaps you missed where I mentioned a constant "budget of bits." Your second h(x,y,z) is implicitly using more bits in the calculation, rather than "sharing" with x.

In other words, these are the two functions that should be compared:

    h(content, very_random_bits(32))

    h(content, very_random_bits(16) + slightly_random_bits(16))

The point of CSPRNG constructions is that there isn't a "budget bits" of seed. Again: this idea is pretty core to the design of the LRNG.

Neither of your constructions is secure.

To paraphrase how I see things going so far, plus one:

1. tptacek: "It's hard to imagine how Cloudflare's lava-lamps could ever make the cryptography worse."

2. Terr_: "Well, technically it could make it worse, if 'hey look we're using a cool lava-lamp wall' comes at the expense of opportunities to insert higher-quality entropy from some other source."

3. tptacek: "It doesn't matter because they can just add it to everything else."

4. Terr_: "I didn't say adding, I said substituting."

5. tptacek: "A CSPRNG algorithm always lets you add more passes and bits. You don't have to make that choice."

6. Terr_: "But Cloudflare does have to make that choice because sensors and computers and CPU-cycles and budgets are all limited! Those constraints are the entire reason we're even using a CSPRNG in the first place."

I'm sorry, I've lost track of what you're trying to argue. The point is that in practice, any sane design is just going to hash "lava lamp" information in with all the other low-quality entropy inputs that drive the LRNG. I wasn't making a subtle or complicated point here.

I'm not making a subtle or complicated point either. I think the start of it is that we had different ideas of what "worse" was being compared to.

You're saying "It's hard to tell a story where the wall is making things worse [compared to replacing it with nothing]." If the initially-unspoken bracketed condition is added, then yes, I agree with you.

My response was: "There might be a story where the wall is making things worse, compared to other things."

The issue is that your “compared to other things” essentially requires CloudFlare to be incompetent which, sure, that could be a thing. But then there are bigger problems.

None of your concerns hold up to scrutiny. Using lava lamps instead of better sources of entropy implies incompetence. CloudFlare is also not so resource limited that they can’t dump the lava lamp entropy in with the rest of their entropy sources. Or else, again, incompetence.

The entire premise of modern CSPRNGs is that you feed into them whatever entropy sources you have, wherever it's from, the more the better.

The point of disagreement here, about whether or not it's possible that they'd be choosing to use the lava lamps to the exclusion of some better source, doesn't make any sense against that framing.

The lava lamps aren't being used as a CSPRNG, rather they constitute part of the seed for the CSPRNG.

Yes, I get that.

Seems needlessly angry about what is ultimately a decent if imperfect source of entropy, and a good illustrative example for the general public

Nothing is random enough for an arbitrary audience. There's always the possibility that some alien spaceship will land and some creature will emerge, take a glance at your RNG, and say: "next one's 6598489811, try it" and they'll be right.

We can only say that something is random enough given a certain audience's beliefs about what kind of predictions are possible. If it takes lava lamps to convince that audience, well then ok.

Why would beliefs matter?

Because the judgment of what counts as ‘enough’ is tied to beliefs

Beliefs drive our actions, even when they're about unknowable things. Whether or not something is random is unknowable, so belief is all we have.

We may discover tomorrow that events which we previously thought were random, like the timing of a single atom's radioactive decay, are actually perfectly predictable. If we believe that such a discovery is unlikely then we might trust radioactive decay as an entropy source, and if we believe its very likely then we probably won't.

> And before you go on objecting that a physical true RNG remains better than a could-theoretically-be-broken CSPRNG, understand that your random output often must have no detectable bias to be secure. That means a distribution so uniform you can’t detect a bias even after analysing 2^64 samples.

Why not, actually? I would think simple and trivially auditable HW RNG with, say, only 0.9 bits of entropy per output bit (raw! no whitening) is preferable to "perfect" but fragile algorithm.

Anything that requires the randomness in practice has enough overhead so that the 90% good entropy is not a problem. Failures caused by wrong assumptions and complications are.

The very end of the article says “They can keep them for decoration but servers must generate their own random numbers.” I thought the lava lamps were for this purpose.

there is probably more entropy coming from the sensor noise of the camera facing the wall of lava lamps than in the random flow inside them.

if you block the camera you will get even more entropy.

I suspect the author hasn't heard of physical unclonable functions.

Obligatory Dilbert reference:

https://www.americanscientist.org/sites/americanscientist.or...

How about electrodes attached to a mushroom

> And if it is broken… then you’re screwed, sorry. See, both your encryption and your CSPRNG relies on a cipher. If either is broken, then so is your whole system.

Not necessarily. The CSPRNG state could in theory be leaked via sidechannels. Your cipher key could be leaked via sidechannels too, but symmetric encryption keys tend to be shorter lived.

Another "why on earth are HN users downvoting this?" moment...

With a one-time pad being, as I understand it, the only really good encryption, I am surprised there is not a market for pairs of matched hard drives—the pair having the same "one time pad" stored on them (how you generate those numbers is left as an exercise for the company marketing them).

A simple app could be used by parties on both ends of the message—an app that relies on an associated drive to act as the pad.

If you become aware that one of the two matched drives has been compromised (stolen perhaps by an outside party), you destroy its partner.

(Perhaps too you can design the drive in such a way as to make it non-trivial to copy—you more or less need possession of the drive itself. That makes it unlikely for there to be a 3rd drive the two parties are unaware of.)

I've heard it said that such systems may be used by militaries, where they have an organizational structure naturally-suited to large keystream distribution.

Unlike e-commerce, it's no problem to physically send the proverbial officer handcuffed to a briefcase to the nuclear submarine before it submerges for 6 months.

Also the messages to be secured are, um, short and... infrequent.

I kind of assumed the "customer" here would in fact be government agencies…

Conventional symmetric cryptography is already very secure and easy, even in the face of future threats like quantum computers. (Asymmetric cryptography is the type of cryptography that cryptographers spend more time worrying about.) Not that you should do it yourself, but it's relatively easy to whip up a secure symmetric encryption scheme if you have a hash function that meets certain basic security properties (which even hash functions with known weaknesses like MD5 and SHA-1 still meet!). The only real hard part of symmetric cryptography is key management (making sure both ends of each conversation have the matching keys ready to use), and one time pads only make that harder by making the keys very large and stateful. I think there are few use-cases where the potentially increased security makes up for the more difficult key management (especially if it means you're also swearing off all asymmetric cryptography).

I think that post quantum encryption methods might be in this category but I am not knowledgeable enough to say either way.

One issue though with making a one time pad trivial to copy - how do you authenticate that you are allowed to read? How do you know the client isn’t copying?

the reason why there isn't a market for such drives is that someone who needs that level of security rightfully wouldn't trust any entity to

1. generate truly random data, which is required for OTP to be perfect

2. not store a copy of the data to be handed over to bioluminescent individuals at the drop of a hat

>bioluminescent individuals

Brilliant.

Surely if you were that security conscious you'd never trust some third party to put the keys on the drives and not keep a copy for themselves - you'd just buy two regular drives and put the key on there yourself.

That's fine. I'm just not aware that even this is being done. But it seems to be pretty secure to being decrypted if captured in transit.

One time pads are the only solution that is secure from an information theoretic perspective. In practice, however, that is not important. You would essentially be securing yourself against a weapon that no one has, and most experts think cannot actually exist.

Russian one time pads were frequently broken. How? They were inconvenient to distribute, so people reused them.

Symmetric cryptography is safer because one key can easily protect as much data as you need.

I would think that a 10TB one-time pad (for example) would probably never get "used up".

One-time pad has 2 problems:

(1) The key can only be used once. If you use the same key for multiple different messages it's not secure anymore.

(2) The key has to be the same length as the message.

With those 2 restrictions, OTP is not really that feasible for practical applications.

> (1) The key can only be used once.

Sure, and I'm contemplating something like 10 TB of random data as key (I mean hard drives are large these days).

> (2) The key has to be the same length as the message.

I thought that was just a matter of indexing through the (10 TB) of data with each message—picking up in the byte stream where you left off from your previous message.

Reply on news.ycombinator.com