Encryption Lava Lamps (2017)
atlasobscura.com
atlasobscura.com
> 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.
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".
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.
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.
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.
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.
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...
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.
there’s no problem left to solve.
`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`
Unfortunately, one service utilising this method, Hotbits, recently shut down their nuclear randomness service.
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?
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
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.
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.