The Futility of Lava Lamps: What Random Means(loup-vaillant.fr) |
The Futility of Lava Lamps: What Random Means(loup-vaillant.fr) |
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.
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.
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.
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.
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.
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
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.
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.
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.
if you block the camera you will get even more entropy.
https://www.americanscientist.org/sites/americanscientist.or...
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.
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.)
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
Brilliant.
Symmetric cryptography is safer because one key can easily protect as much data as you need.
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.
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?
(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.
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.
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.
snip snip ?
And yes, as the other comment points out it's only one source among multiple.
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.
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 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))Neither of your constructions is secure.
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."
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 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.
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.