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.
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...
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.
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.)
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.
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?)
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.
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).
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.)
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.