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.
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.
snip snip ?
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.
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.
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.
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.
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 '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
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.
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
(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.
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?