[Cryptography] Lava Lamps Can Actually Create Secure File Encryptions - Here's How

Jon Callas jon at callas.org
Tue Mar 10 19:12:39 EDT 2026



> On Mar 8, 2026, at 06:55, Charles Jackson <clj at jacksons.net> wrote:
> 
>> 
>> On 3/4/26 2:30 PM, Jon Callas wrote:
>>> The effect works better in the dark, of course because when there's a lot of light it washes out the noise. Nonetheless, it's easy to adjust ISO, use ND filters (or even better, IR filters). You just want sensor noise, that's all.
> I don’t think that is quite right.  Light is often modeled as a poisson process with the intensity of the light corresponding to the average value of the poisson process during the exposure time.  The noise has a standard deviation equal to the square root of the intensity.  So, as the intensity increases the ratio of the signal power to the noise power increases—but the noise increases also.  A moderately illuminated grey card imaged with a modern camera could easily be adjusted so that the mean value was 10 bits (1024).  In this case the lower 5 bits should be quite random.  If you xored bits 1, 2, and 3 you would probably get a highly reliable random 0-1 value.  I think that a modern camera, say a Nikon Z8, shooting raw would be a good random number generator if used in this fashion.  
> 
> That said, the above quoted statement is correct in the sense that an image of a bright scene will saturate.  In some cases it will just yield the max number possible (say 2^14 - 1) at most or all pixels.  In other cases it will yield a number related to the size of the electron well at each pixel sensor.  So, if the choice is between maximum dark and maximum bright, go with maximum dark.  There would be good chance that the lowest one or two bits would be random.  


We're talking about different things, but they're related. Also, I've conflated a few things and digressed in a non-rigorous manner, for which I apologize. I'm not sorry, there's method in my madness, but I do apologize.

For clarity, I'm presuming that in all discussion below, we're taking an image sample and hashing it with some reasonable 512-1204 bit function. SHA-2 or better, basically. And then we're going to use that in some total RNG pipeline. I think this also applies to an analog sensor (e.g. film, cyanotypes, tintypes, etc.), not just a digital one, but the analog-to-digital conversion is left as an exercise for the reader. I am also assuming some reasonable path by which the sample is securely put into the RNG pipeline and destroyed.

In your description above, remember that a "pixel" is typically a value for three sensors, RGB. Each one of those is somewhere in the eight to fourteen bits range, and there's bleed across them and even into non-visible spectrum. So you're getting thrice the data you think, even with a gray card -- which for these purposes really ought to be a 50% gray card, not 18%, because this is not a visual thing we're doing, it's just sampling photons. A good camera is going to get you 14 bits-per-pixel, a cheap one is going to have fewer raw pixels, but they will be more -- uhhh -- unique. (I was thinking that a Kodak Charmera is better as an RNG than a Z8, myself.)

One thing I was talking about is quantum-effect sensor noise. In this case, a model of our device is a sensor in a black box. This is related, because one type of it, virtual particles or quote-quote cosmic rays (quote-quote because there's also ambient IR radiation, too, and likely more) hitting the sensor, is very, very dim and thus in a low-ISO environment. CCD and CMOS sensors are used in physics experiments, and while a consumer-grade sensor might not be good enough to do high-quality physics experiments, the low-quality physics experiment of hashing a sample from the sensor (see how I cleverly managed to avoid the word photograph) is going to have randomness in it that is what we glibly call entropy. Obviously, there are ways to do this experiment wrong. But if you do something like turn the ISO of the sensor to max and let it roll, it's a quantum RNG. 

Another thing was about image complexity. If one believes that a photo of a wall of lava lamps is random, then there's plenty of other things. There's a wall of a building covered in ivy and morning glories just outside where I type that. I believe it's just as good as the lava lamps, just from leaves and flowers and vines moving in a breeze. Someone up-thread (apologies for not chasing it down) said that a picture of dead leaves would be fine, and I concur; it's the same point, that image complexity is easy to find. My larger point here is that I think we underestimate how much complexity is there in the totality of taking a picture. I don't think this argument changes in a completely deterministic, Newtonian universe, either.

In between here, there are other physical aspects to taking a photo that I believe add unpredictable elements to the photo. These range from manufacturing differences in the whole system from the sensor to lenses to coatings, alignments in housings, dust on physical things or in the air, smudges and fingerprints, reflections internal and external, motion blur, shutter artifacts, aperture artifacts including depth-of-field, and more. In a digital camera there's a photo processing pipeline that may or may not be used (like internal conversion to JPEG, along with the advanced stuff), and that that pipeline does not meaningfully change the unpredictability of the result except in the obvious ways (e.g. JPEG uses an 8x8 cell of pixels). (I am unable to stop myself from adding in that if you remove the IR/UV cut filters from a sensor, things get even better.)

In short, I think that taking any old picture is going to have usable unguessability in it for some RNG pipeline. I think this holds even in a classical-physics universe, and we fool ourselves with the word "entropy" which sucks our brains out every bit as much as the word "quantum" does.

Getting back to your thought experiment, I think you shouldn't go XOR anything. Just take a hash of the image! XOR is lossy -- A xor B is the same as B xor A, but hash(A,B) is not equal to hash(B,A). In any event, I'm willing to accept 5 bits per pixel, because if I want 1204 bits of randomness, then 256 pixels is more than enough, and if we accept 5 bits per *channel*, then we really only need 80-some pixels.

And that is really my whole point -- just take a photo and hash it. Even a photo with the lens cap on. No lava lamps needed.

	Jon




More information about the cryptography mailing list