Encryption Lava Lamps (2017)(atlasobscura.com)
atlasobscura.com
Encryption Lava Lamps (2017)
https://www.atlasobscura.com/places/encryption-lava-lamps
40 comments
> number sequences which are used as symmetric encryption keys to create virtually unbreakable ciphertexts
Why should the average reader be expected to know the distinction between keys, ciphertexts, and number sequences. They're just codes.
This is AtlasObscura intended for travelers, not an academic journal.
It's like learning about functional programming and the gatekeepers explain a monad as being "a monoid in the category of endofunctors".
Why should the average reader be expected to know the distinction between keys, ciphertexts, and number sequences. They're just codes.
This is AtlasObscura intended for travelers, not an academic journal.
It's like learning about functional programming and the gatekeepers explain a monad as being "a monoid in the category of endofunctors".
The marketing story that keeps on giving. When I first saw it upon introduction, I didn't think it would be this brilliant of a stroke. Nice idea, yeah, but no technical improvement over the status quo, especially when considering the excess power consumption. Turns out, it's a nice graphic method to introduce a wider audience to a topic that they would otherwise not know about, making it perfect to keep retelling it as a fun thing that someone might not know. I wonder if they knew when building this setup how much of a life of its own this would go on to lead.
My understanding was that the devices lavarnd went on to sell resulted from a lamp going out. The realized the entropy had actually gone up. Apparently a cheap webcam sensor in a dark shielded box makes for something extraordinarily chaotic.
Non-technical people absolutely love this story, and also spitballing all kinds of wacky things you can measure for entropy.
Technical people always give exceeding lame answers, like read 16 bytes from a HWRNG to seed a CSPRNG like Fortuna and then be done with it.
Technical people always give exceeding lame answers, like read 16 bytes from a HWRNG to seed a CSPRNG like Fortuna and then be done with it.
[deleted]
The second lamp isn't contributing any entropy. Though, from the description, the lamps don't need to be hacked to control the entropy, just the camera, possibly by simply covering it.
> the lamps don't need to be hacked to control the entropy, just the camera, possibly by simply covering it
Hm, I wonder if that would be sufficient. You wouldn't be able to achieve "perfect blackness" as in the resulting image coming from the camera being pitch-perfect black (or rather, all pixels returning exactly rbg(0,0,0)) as everything analog in the camera have small but vital imperfections.
I'd posit taking a camera and putting it in a perfectly dark room / covering the lens with a totally black sheet would still be able to generate some sort of entropy to be used.
Hm, I wonder if that would be sufficient. You wouldn't be able to achieve "perfect blackness" as in the resulting image coming from the camera being pitch-perfect black (or rather, all pixels returning exactly rbg(0,0,0)) as everything analog in the camera have small but vital imperfections.
I'd posit taking a camera and putting it in a perfectly dark room / covering the lens with a totally black sheet would still be able to generate some sort of entropy to be used.
The Lava Lamps That Help Keep The Internet Secure from Tom Scott (2017)
https://youtu.be/1cUUfMeOijg
https://youtu.be/1cUUfMeOijg
Or, you know, just read it from the source? https://www.cloudflare.com/learning/ssl/lava-lamp-encryption...
I would be surprised if this feed is still used. It's extra work for no benefit.
The benefit is in the PR. Besides that, it's a good demonstration of a "nothing up my sleeve" sort of RNG.
The difference in PR whether or not the wall of lava lamps is still hooked up into the RNG is not significant.
Given the huge infrastructure costs they already maintain, I cannot imagine running a wall of lava lamps is a meaningful expense.
There is a difference between just maintaining the wall of lava lamps and maintaining the lava lamps and the entirety of LavaRand. Maintaining the lava lamps is much easier and doesn't have any long lasting maintanence concerns or security concerns compared to the rest of the infrastructure and services for making sure that randomness makes its way into every cloudflare server.
There certainly is a difference between keeping LavaRand operational or not. But I would submit that the difference is worth it. I mean c'mon, it's super cool!
Also, from a different angle, think about the potential blowback if they were to shut it down... That sounds like a PR nightmare waiting to happen.
> making sure that randomness makes its way into every cloudflare server.
This does not hinge on LavaRand. The machines' local entropy sources would ensure secure randomness even if LavaRand were compromised.
Also, from a different angle, think about the potential blowback if they were to shut it down... That sounds like a PR nightmare waiting to happen.
> making sure that randomness makes its way into every cloudflare server.
This does not hinge on LavaRand. The machines' local entropy sources would ensure secure randomness even if LavaRand were compromised.
>think about the potential blowback if they were to shut it down...
I honestly don't think it would be bad PR. It will just get the lava lamp story in the news cycle again.
>This does not hinge on LavaRand.
My point is that there is extra services to maintain that offer 0 technical benefit to you.
I honestly don't think it would be bad PR. It will just get the lava lamp story in the news cycle again.
>This does not hinge on LavaRand.
My point is that there is extra services to maintain that offer 0 technical benefit to you.
> I honestly don't think it would be bad PR.
It would be terrible PR, and would re-ignite all the old conspiracy theories regarding Cloudflare.
> My point is that there is extra services to maintain that offer 0 technical benefit to you.
The benefit isn't zero, LavaRand is a hedge against attacks against the local CSPRNG.
More details here: https://blog.cloudflare.com/lavarand-in-production-the-nitty...
It would be terrible PR, and would re-ignite all the old conspiracy theories regarding Cloudflare.
> My point is that there is extra services to maintain that offer 0 technical benefit to you.
The benefit isn't zero, LavaRand is a hedge against attacks against the local CSPRNG.
More details here: https://blog.cloudflare.com/lavarand-in-production-the-nitty...
Imagine all the word of the mouth marketing they have gotten since they did it in 2017. I think it has been beyond worth it.
The marketing happens with or without that camera feed working. There is no reason to spend extra money that you don't need to.
Every time I see these lava lamps mentions I wonder if there is a more energy efficient way to do this.
How about a bucket of mixed colored beads that is periodically vibrated ? A number could be derived from the order and colors of the beads.
How about a bucket of mixed colored beads that is periodically vibrated ? A number could be derived from the order and colors of the beads.
you can amplify noise from various electrical junctions to produce randomness for orders of magnitude less energy than anything involving macroscale materials moving around.
there’s no problem left to solve.
there’s no problem left to solve.
Random.org uses atmospheric data, which is pretty cool.
`RANDOM.ORG offers true random numbers to anyone on the Internet. The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs`
`RANDOM.ORG offers true random numbers to anyone on the Internet. The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs`
Measuring nuclear decay comes to mind.
Unfortunately, one service utilising this method, Hotbits, recently shut down their nuclear randomness service.
https://www.fourmilab.ch/hotbits/
Unfortunately, one service utilising this method, Hotbits, recently shut down their nuclear randomness service.
https://www.fourmilab.ch/hotbits/
You guys all make excellent suggestions, but maybe I should have specified. More energy efficient, but still having a bit of tangibly physical charm to it like the lava lamps.
Solar panels on the roof and a battery.
(not an original though, but repeating here)
Thought experiment: Suppose you had a computer that didn't have a good entropy source. You need this computer to have good entropy because it needs to connect to some service, and the connection needs to be cryptographically secured and resilient to replay attacks (ie attacks where an adversary, not necessarily the service, sends an old message in response to a fresh request). Suppose further that you had a separate service that exposes a camera feed of some lava lamps—perfect for fixing your entropy problem. How do you suppose you will connect to that camera feed?
Thought experiment: Suppose you had a computer that didn't have a good entropy source. You need this computer to have good entropy because it needs to connect to some service, and the connection needs to be cryptographically secured and resilient to replay attacks (ie attacks where an adversary, not necessarily the service, sends an old message in response to a fresh request). Suppose further that you had a separate service that exposes a camera feed of some lava lamps—perfect for fixing your entropy problem. How do you suppose you will connect to that camera feed?
To answer the questions in this thread: having a preshared key (PSK) doesn't save you. The problem remains replay attacks: even if you have a PSK, if you don't have a fresh session, then an adversary can replay old messages back to you.
The only solution to the replay problem is to have the poor-entropy machine keep a strikelist of all the messages (or hashes thereof) it has ever received from the entropy service. Thus, when receiving a new message, it can make sure it's not a replay. Of course, this means that you've turned a stateless protocol into a stateful one, and require non-volatile storage on the device for a potentially long period of time.
As far as I know, nobody actually does this.
The only solution to the replay problem is to have the poor-entropy machine keep a strikelist of all the messages (or hashes thereof) it has ever received from the entropy service. Thus, when receiving a new message, it can make sure it's not a replay. Of course, this means that you've turned a stateless protocol into a stateful one, and require non-volatile storage on the device for a potentially long period of time.
As far as I know, nobody actually does this.
I needed an entropy source for an ssl connection from a VxWorks box before Intel added the RNG instructions. Boy was that a pain in the ass. I had previously thought the server provided the random data for the AES key. Turns out that’s not true for reasons that were obvious in hindsight but inconvenient for our network topology.
Ended up having to feed every low entropy source we could get our hands on into the CSPRNG. And the whole time the vendor kept trying to offer their own binary arithmetic to cook down the inputs. No, let SHA1PRNG do its job. This is what secure hash algorithms were born to do
Ended up having to feed every low entropy source we could get our hands on into the CSPRNG. And the whole time the vendor kept trying to offer their own binary arithmetic to cook down the inputs. No, let SHA1PRNG do its job. This is what secure hash algorithms were born to do
I'd connect to the camera feed service using a PRNG, get the true random, reconnect to the camera feed service using that true random. I don't care if someone is able to connect to the camera feed.
The adversary synchronizes their clock with yours, and hits the unsecured camera feed at the exact same time. (Alternatively they poll the camera source, possibly interpolating or doing some kind of fuzzy search in a much smaller space than your keyspace.) They recover the image you used to seed your CSPRNG and are able to recover the keys you use to connect to other services.
I am not a cryptographer. There's probably a fatal mistake in my post. (Do let me know if you've spotted it! I've found & fixed a couple but you know what that say, anyone can come up with a cryptosystem they can't break, and I can barely break a Caesar cipher.)
You'll need to cheat somehow and give the service either entropy or a keypair out of band. You can't bootstrap your entropy from absolutely nothing via a remote service, unless you trust the adversary can't compromise the connection between the foo service & the camera service (which is equivalent to the foo service having a good local entropy source to begin with, it's just that part of your motherboard's bus extends over Ethernet to the camera service).
The simplest way would be for the foo and camera services to have keypairs, which you exchange manually/out of band, & communicate with classic asymmetric key cryptography. (You could come up with a similar protocol using symmetric encryption as well, using something like AES-GCM combined with a challenge-response protocol. You could also bootstrap the foo service with entropy out of band & use Diffie-Hellman to establish a shared key rather than moving keys out of band. Probably the better option in practice since there's less coupling. [Actually this doesn't quite work because it doesn't achieve authentication.])
The important part is that it's both authenticated and encrypted. You need to encrypt it so that adversaries tapping your connection don't know what image you're using to seed your CSPRNG. But if you allow unauthenticated connections to your entropy service, they don't need to tap your connection, they'll just connect to the camera service at the same time & pull down the same image that you do. And if they can't get it perfectly at the same time, well, a known image of a lava lamp taken around the same time as a secret image of a lava lamp gives us a lot of information about the state of that lava lamp, and we could conduct a search to discover the secret image (we record the encrypted traffic, and we fiddle with the image, and attempt to decrypt the traffic. When we get valid data instead of gibberish, we've found the right image.)
Let's say we've done all that. Great, we can actually lose the authentication requirement now. We can create an entropy service which does all of this song and dance, and seeds a CSPRNG. The entropy service accepts a public key, uses a CSPRNG to generate some entropy, encrypts it with the public key, and returns the result. Only the client is able to use their private key to retrieve the entropy. Because we've moved away from a camera system, past outputs are no longer correlated with future outputs, and concurrent requests always get different outputs. So we can leave this service unsecured. It's dependent services still need to be bootstrapped with a keypair out of band, however.
You'll need to cheat somehow and give the service either entropy or a keypair out of band. You can't bootstrap your entropy from absolutely nothing via a remote service, unless you trust the adversary can't compromise the connection between the foo service & the camera service (which is equivalent to the foo service having a good local entropy source to begin with, it's just that part of your motherboard's bus extends over Ethernet to the camera service).
The simplest way would be for the foo and camera services to have keypairs, which you exchange manually/out of band, & communicate with classic asymmetric key cryptography. (You could come up with a similar protocol using symmetric encryption as well, using something like AES-GCM combined with a challenge-response protocol. You could also bootstrap the foo service with entropy out of band & use Diffie-Hellman to establish a shared key rather than moving keys out of band. Probably the better option in practice since there's less coupling. [Actually this doesn't quite work because it doesn't achieve authentication.])
The important part is that it's both authenticated and encrypted. You need to encrypt it so that adversaries tapping your connection don't know what image you're using to seed your CSPRNG. But if you allow unauthenticated connections to your entropy service, they don't need to tap your connection, they'll just connect to the camera service at the same time & pull down the same image that you do. And if they can't get it perfectly at the same time, well, a known image of a lava lamp taken around the same time as a secret image of a lava lamp gives us a lot of information about the state of that lava lamp, and we could conduct a search to discover the secret image (we record the encrypted traffic, and we fiddle with the image, and attempt to decrypt the traffic. When we get valid data instead of gibberish, we've found the right image.)
Let's say we've done all that. Great, we can actually lose the authentication requirement now. We can create an entropy service which does all of this song and dance, and seeds a CSPRNG. The entropy service accepts a public key, uses a CSPRNG to generate some entropy, encrypts it with the public key, and returns the result. Only the client is able to use their private key to retrieve the entropy. Because we've moved away from a camera system, past outputs are no longer correlated with future outputs, and concurrent requests always get different outputs. So we can leave this service unsecured. It's dependent services still need to be bootstrapped with a keypair out of band, however.
(2017)
[deleted]
> which converts the randomness into a virtually unhackable code
> Why use lava lamps for encryption instead of computer-generated code?
Pet peeve: Non-technical people using the term "code" overly broadly. Binary numbers are a code. Morse code is a code. Encryption is a code. Machine instructions are a code. Passwords are codes. One-time nonces delivered over SMS are authentication codes. And so on and so forth.
This article would be clearer to me if the author wrote that the lava lamps help to generate random number sequences which are used as symmetric encryption keys to create virtually unbreakable ciphertexts. Not random codes for encryption codes to create unbreakable codes.