Encryption Lava Lamps (2017) | Hacker News Reader

Encryption Lava Lamps (2017)

atlasobscura.com

107 points1cvmask92 comments

I remember using lava lamps for SSH random number generation from the 90's. However, they may have yielded this entire area of security:

So-called "physically unclonable functions" https://en.wikipedia.org/wiki/Physical_unclonable_function

I am immensely skeptical of these, but they have some academic and other obscure traction.

Before anyone else looks into PUFs as a mechanism for generating entropy (like the lava lamps are), they don't. It's kind of the opposite kind of randomness. Lava lamps create new randomness every time whereas a PUF generates the same randomness always.

The skepticism I have of PUFs is that since they don't generate random numbers, they may just be another open loop unfalsifiable concept in security that reduces to "it's complicated, take my word for it."

The relationship to lava lamps is PUFs are a physical instead of a logical source of data, conceptually not unlike a quartz crystal in a clock, or radio active decay for random numbers, or even biometrics for authentication. You take something physically natural then sample it at a given interval to get logical data within certain parameters.

The security of such a system is not in the mystery of the physical object, but the sampling scheme. Apropos of the news, just like it isn't important so much who people vote for, it's who counts the votes that matters. The security of both lava lamp RNGs and PUFs are subject to an analogous sampling dynamic. So are biometrics.

The version of PUF I’ve read about in a decade or so ago was you make a cryptographic chip, except you leave the key field blank, but let manufacturing variances “generate” the key by itself, and mathematically declare that it is so impossibly unlikely that two of its examples end up having the same bit patterns.

IIRC major challenges included ensuring and proving randomness, stability of bit patterns over time, and general longevity of the whole chip.

The alternative to it is to just generate the key and write it at some point in the chip production line, and that’s generally considered good enough, so...

You can look all over the universe for entropy. Lava lamps make for a cool PR showpiece, and apparently easy fodder for fluff pieces like this article. I just hope none of my relatives read it and ask me about it. The reality is much more interesting but would probably bore most people to death.

What's the best entropy bang--for-your-buck < $100?

Flip a penny twice, if you get heads followed by tails, write down 0. If you get tails, followed by heads, write down 1. Otherwise ignore the two flips. Rinse and repeat until you have enough bits.

The purpose of flipping twice is that it offsets any potential static bias (caused eg by weight difference) between the two sides.

Common ways to generate entropy in a way that’s friendly to computers include: measuring noise from a zener (or other electronic component), delta between two or more oscillators, or timing between external events (eg keystrokes, packets, etc). These are all super cheap to manufacture (~$1). If you want to go high end, you can spent ~$1000 and get a generator based on some quantum property (photon spin or background radiation detector).

Computers will typically combine two or more sources of entropy. In newer tls version handshakes, the entropy from both, the server and client comes into play. So there’s ways to build defense in depth.

Truerng claims this on 100MB of generated data:

Entropy = 7.999998 bits per byte.

If you can fit this quality on a usb, why didn’t motherboards contain a circuit like that?

Maybe they do on server boards?

That's what RDRAND is - well, it's not the same physical mechanism as TrueRNG, but it is a fast hardware random number generator built into the CPU.

Wasn’t there a paper that showed it is basically impossible to load a physical coin?

AKA von Neumann debiasing, or the von Neumann trick.

There is a fun generalization of the game. Assume the penny has (unknown) bias p. You want to output a new flip with bias some function f(p). So f(p)=1/2 is what you described, ie how to get a fair flip. For some functions it can be even easier, e.g. f(p)=p^2 - definitely only requires two flips.

How about:

f(p)=p^2/(p^2+(1-p)^2)

f(p)=2p(1-p)

f(p)=3p(1-p)

f(p)=sqrt(p)

The last two are tricky, I took them from a paper "functions arising from coin flipping" by Wastlund. (The quantum generalization is even more fun, but this text box is too small to contain it.)

Two are close I think.

A capped webcamera, CCDs pick up enough stray electrons to be reliable source of entropy.

A old cheap radio tuned to static plugged into your microphone port.

https://www.mentalfloss.com/article/81946/7-sources-randomne...

This is not a good idea for the uninitiated and is on par with rolling your own encryption algorithm to send highly sensitive data around the world.

For the price GP mentioned there's a dozen vetted opensource commercial options in the bottom half of that range.

The uninitiated have zero business sending highly sensitive data around the world in general.

And yet they still do it daily. This is why secure-by-default should always be the norm.

> webcamera, CCDs pick up enough stray electrons to be reliable source of entropy.

Ironically, this is the same setup as the lavalamps, but without having to pay for the lava lamps.

I believe they figured out the lens cap hack when there was a lava lamp failure.

I’m trying to envisage what different lava lamp failures might look like, and I’ve gotta say, there are some entertaining possibilities in that idea.

Both the radio and the CCD seem like something a determined actor could undermine. Transmitting a directional pop of radio static at just the right moment, or whatever causes CCDs to show static (x-rays?)

If the bad guys can point an X-Ray gun at your stuff, random numbers are probably not going to be your biggest issue. :)

If your attacker can stage a sophisticated attack on your entropy source and your budget is $100, you are screwed regardless.

$0, your base server or laptop, and getrandom.

Maybe this? https://www.amazon.com/dp/B01ENG4UX4/

Read the voltage drop across a high-value resistor at room temperature. There are random fluctuations proportional to the temperature and resistor value. You can use these fluctuations to generate unifromly distributed random numbers. https://en.m.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_nois...

Just set stuff on fire I suppose.

> bang--for-your-buck

Testing for randomness is impossible in the YES/NO sense, so the best we have is statistical test batteries like NIST's 800-22, DieHarder and TestU01.

I own a Truerng and a Onerng, both are under $50. They performed better on Dieharder than my computer's Intel RNG. Not by a huge margin, but still. All 3 passed the minimum requirements of course.

A set of casino dice and a 5 gallon bucket.

What's the bucket for?

To throw the dice into!

Fair enough :)

I guess we're still well within budget.

Just hang a microphone outside your window and pick up all the birds chirping and other street noises?

I bet you could find some patterns in street noises, but I'm also not 100% sure what entropy is

I wonder if you could do this in a silent room with a cheap mic and just use the static white noise

I know someone who used that technique at one of the worlds largest banks, back in the 1990s.

Dice? https://www.eff.org/dice

Multi-colored so your own biases don't affect the order you read the dice in. E.g., and I'm just guessing, some people might notice the higher numbers first and read those out.

Casino grade dice

An ADC, the shittier the better. Turn the gain all the way up. Don't bother plugging a microphone into it. XOR all the bits together. Done.

Dice - for not too many bits, and a low data rate.

Hardware or /dev/urandom (or Windows equivalent) and downstream library calls - many bits, high data rate

It seems like you could probably just aim a typical camera at a potato and get enough sensor noise in the pixel data to be a perfectly fine RNG. I doubt anyone could hope to demonstrate a bit for bit match of any two pictures using a modern digital camera (maybe even if the lens is closed).

Pointing the camera at a lavalamp has the same noise, AND movement aswell.

So lava lamps produce higher entropy than a potato everything else being equal.

But the difference is vanishingly unlikely to matter.

I know, I just enjoyed having the opportunity to compare lava lamps to potatoes in a somewhat meaningful context.

The point is that there is no possible scenario where CCD noise alone is inadequate, but CCD noise + lava lamps is adequate.

A Tom Scott video on this: https://www.youtube.com/watch?v=1cUUfMeOijg

Should have a reference to the original concept: https://en.wikipedia.org/wiki/Lavarand

I've seen the original Lavarand lamps, which are currently decorating an apartment in Seattle. It was a gift from Landon Noll.

There's a plaque on the wall next to the lava lamps that explains the connection.

I mean the article should mention it!

It's a shame the article doesn't give credit to the people they copied.

They should give credit to LavaRand classic, invented at SGI by Bob Mende & Sanjeev Sisodiya (Mende's passing still feels recent to me https://www.legacy.com/obituaries/dailyrecord/obituary.aspx?...) or its sequel LavaRnd (https://www.lavarand.org/news/lavadiff.html) invented by Landon Curt Noll and Simon Cooper.

These lava lamps were also a key plot point in an NCIS episode (a popular crime procedural on CBS).

[spoiler below]

https://twitter.com/ncis_cbs/status/1044751471927947264?lang...

Well, those lava lamps are cool looking, but that's about their only value. A 256-bit seed is enough to generate all the random bytes you'll ever want: just use Chacha20 with fast key erasure, and you're done. (Fast key erasure crash course: start with an encryption key and a stream cipher. Encrypt 512 bytes worth of zeroes. The first 32 bytes of the ciphertext are your new key. The rest can feed /dev/urandom. Once a byte is served, erase it. Once you run out of bytes, generate 512 more bytes. New generators can be forked off by simply requesting 32 random bytes.)

From https://blog.cr.yp.to/20140205-entropy.html

  how can anyone simultaneously believe that:
  - we can't figure out how to deterministically expand one
    256-bit secret into an endless stream of unpredictable
    keys (this is what we need from urandom), but
  - we _can_ figure out how to use a single key to safely
    encrypt many messages (this is what we need from SSL,
    PGP, etc.)?

I don't. Those lava lamps are cool looking, but that's about their only value. We don't need that many random bits.

Cloudflare themselves have gone into significantly more detail in a blog if you're interested beyond the curio in the main link: https://www.cloudflare.com/en-gb/learning/ssl/lava-lamp-encr...

Yeah - they admit that they're mixing it with two other sources of entropy... All I could think when I saw this was "not enough entropy - what the heck..."

My guess is they have a couple of quantum HRNGs in those "Linux systems" they discuss that are actually doing the majority of the entropy.

Cool gimmick though.

Or they could just use stock Intel or ARM boards and SOCs and just use getrandom, which works and scales just fine.

The throughput for RDRAND isn't that great and often getting worse as mitigations get rolled out. For cloudflare scale using dedicated hardware makes a lot of sense.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Rd...

https://www.reddit.com/r/crypto/comments/h07u2q/rdrand_perfo...

In what sense do you need RDRAND to scale? You seed an RNG infrequently, and spool off arbitrary amounts of random bytes from it in each interval.

> In what sense do you need RDRAND to scale?

Personally? Not at all, I do it for fun. On windows it's all you have because adding anything to the entropy pool BCryptGenRandom draws from is a no go, it was possible ten years ago, a simpler time. Now you have to do it yourself and xor different sources at the application layer if so concerned. On Linux it's trivial.

Cloudflare? Well, besides their obvious immediate needs, they are openly positioning themselves as an entropy provider for high security purposes, which requires good sources and throughput. What Intel or AMD is offering out of the box is not going to cut it by itself.

Not saying they're broken, they work fine for nearly all purposes, instead here positing that if your entire existence and everything you owned depended on it would you truly just use the inbuilt CPU RNG on your computer and call it day? It's a small amount of time to add additional sources and not lose your shirt/dignity.

https://www.cloudflare.com/en-gb/leagueofentropy/

"Entropy provider" is not a thing, nor is "good sources and throughput". I've been cagey about writing about this but this thread is now old so I'll just be direct (and boring): there is a misconception that running cryptography primitives somehow burns through entropy as if it were fuel. But that's not how it works at all. You need enough entropy to seed your CSPRNG, and enough to periodically re-seed it to have some safety margin against compromises, but in the interval in between, you have effectively limitless "entropy" to spend.

The lava lamps aren't doing anything for Cloudflare's security. They're a marketing gimmick. A very good one! They got articles like this written! I'm not begrudging them the win! But this is not in fact how you engineer cryptography.

> "Entropy provider" is not a thing

And yet you rely on one daily. Random oracles will likely be big business one day. I'm happy CF has put forward their posture on this. It's a good thing for the internets.

> nor is "good sources and throughput"

So you can provide entropy with high quality guarantees at 10GB/s? Sign me up mate. What's your price?

> I've been cagey about writing about this but this thread is now old

Who the fuck cares? Is this thread about actual discussion of the issue at hand or petty HN posturing? Couldn't care less what influencers and randoms here think. Simply stating thoughts and experiences.

> there is a misconception that running cryptography primitives somehow burns through entropy

Certainly agree, that's not what I meant though. A broken seed is nearly always exploitable in practice. It doesn't matter in the slightest how strong your primitives are when they are deterministic.

> The lava lamps aren't doing anything for Cloudflare's security. They're a marketing gimmick. A very good one!

Yeah, of course it's marketing, but with purpose, exposing devs to this stuff is worthwhile, means to an end and all that. XOR'ing sources is as cryptograhpically strong as the best source provided, why not do it if you have much at stake and 20 mins to spare.

I don't think you're following. You can encrypt petabytes of data under a single AES key, which is essentially what you're doing when you generate random bytes. Work out the math to figure out how often you need to rekey.

Far better solution IMHO built after industry discussion of "lava wall" years ago: https://bit.ly/3naYEBP Of course, by now we got hardware rng RPi, TrueRNG, security enclave rng - largely a solved problem on most of practical systems. just setup right, seed right and use `/dev/urandom`

> It may seem bizarre that Cloudflare would allow average people to affect the video footage, but that’s actually intentional. External disturbances like human movement, static, and changes in lighting from the adjacent windows all work together to make the random code even harder to predict.

well what if you show up with a white blanket and putit in front of the camera?

Unless you could hold the blanket perfectly still and prevent outside light from reflecting off of it, it probably makes zero difference. The cameras don't need large amounts of contrast or even big variances in hue, just small amounts of randomness in the ripples in the fabric you are holding up is enough.

then why would they use so many lava lamps?

Because it looks cool and makes for lots of stories in the media like this one. People have reliably used webcams with the cap on to create entropy suitable for effectively true random numbers.

...it’s a marketing tactic.

fine, black blanket then ?

You’d need like Vantablack or something similar.

Even then, there will be plenty of electrical noise to provide entropy.

Low bits make just as much difference to a hash as high bits.

Even so, a good RNG will make attempts to verify the quality of the entropy. For example, Intel's RNG will statistically observe bit patterns from their RNG. Eg, it fills up a FIFO and checks for the counts of certain bit patterns. If they aren't sufficiently random, it will throw away the data. Even if they dont have sufficient RNG data, unless you can predict how a PRNG is seeded it should be safe for quite some time without new true entropy.

A key property of cryptography is that a good entropy source XOR'd with a poor (biased) entropy source does not degrade the quality of the final result.

Maybe point a strong laser at the cam instead so its "blinded" and all pixels have max brightness. Or even destroy the sensor with a laser, that way it may permanently produce non-random data.

Lava lamps optional.

Really, the least-significant-bit noise from any camera chip, even pointed at nothing, fed through e.g. SHA-256, gives high-quality cryptographic random numbers at as high a rate as you are likely to want. (If you need better random numbers, you also have no need to read this.)

You can get similar quality from hashing the low bits of a mic input.

Hashing already-connected noise is actually better than resistor or diode noise, that is tricky to get right -- although feeding output of one of those through a good hash forgives a lot of bias.

Discussed at the time: https://news.ycombinator.com/item?id=16041295

I was thinking: instead of using atmospheric noise for entropy, one could use a variety of different things taken directly from the user, like mouse movements (Veracrypt uses the mouse to seed random values for example). You could even use things like the user's timezone, HTML5 Canvas fingerprint, even the order/arrangement of icons on the desktop. There's so many sources!

Random fluctuations and butterfly effects aside, couldn’t you actually predict the lava lamp flows from fluid dynamics? Or does it just so happen that the math here is actually harder than breaking the encryption?

as far as i can tell, true randomness doesn't work except from in the quantum world. Everything else is random insofar as "we don't know it and it's unpractical to predict". Coin tosses are also not random: they all depends on the system initial conditions.

Random fluctuations, butterfly effects and hairy heat transfer effects with resulting gradients of dynamically changing material properties aside, probably yes.

But that's one whopping reservation, and even if, you could only predict exactly to the extent fluid dynamics exactly models interacting particle physics involving mind-boggling numbers (for the scales of interest).

Also, I have no background solving complex fluid dynamics problems, but my understanding is that the differential equations involved generally have to be solved with iterated numerical approximations (if anyone here knows more certainly, please do chime in). In the short term that's probably one of the smaller problems, but it is at least somewhat connected to why we don't get get highly reliable 3-week weather forecasts, and possibly never will.

If you assume you can ignore the hard parts, the problem becomes easier, I guess. You still need to know initial conditions to impossible accuracy.

I recall a while back someone was actually being paid to roll dice.

And record the results on punchcards?

So, Hitchhiker's guide to the galaxy, Heart of Gold and Infinite Improbability Drive.

Exactly, all you really need is a fresh cup of really hot tea

Wouldn't a plasma lamp (or whatever they are called) provide the same thing at a lower power cost? They work faster as well, meaning you could probably sample more often.

I’m left wondering how they protect the camera and the data cable coming from the camera.

It's done for fun, and not really a critical security measure, so it doesn't matter.

Would be even more fun though if it was secure. And fun does matter.

This is, of course, all pretty silly. Collecting entropy for a fleet of services is not a real cryptographic engineering challenge, and it would be alarming to learn that Cloudflare actually somehow pipes output from these things into all their systems.

Reply on news.ycombinator.com