# Webcam random number generator

I have a question about random number generators.

I have read from a real random number generator, based on a webcam ("randcam"). My problem is, that I do not really understand how the generation of the random numbers works. Has anyone heard of this principle before and can give some hints how it could be implemented? And how randomly is this method, I've read it should give real random numbers, but is this true? I've found an implementation in C++, but I did not really understand how this implementation works, I am not that familiar with C++.

-
I've never heard of this randcam thing, and wouldn't recommend using it. Instead, I recommend using a standard random-number source, such as /dev/urandom, CryptGenRandom(), or similar (depending upon what platform your code is running on). –  D.W. Dec 1 '12 at 20:06
@D.W. Sensor noise is a nice source of entropy. Obviously you still need to feed it into a standard PRNG. –  CodesInChaos Dec 2 '12 at 8:32
@CodesInChaos, nonetheless, I stand by my comment. End users of cryptography shouldn't be rolling their own PRNG; they should use a standard system PRNG, and let the system designers take care of ensuring it has sufficient entropy. (Let the system designers choose to use webcam data if that is appropriate and improves security, but most users of cryptography should not be making decisions like this.) –  D.W. Dec 3 '12 at 3:47
@D.W. Yes, but if we can't get creative, this site might end up repeating itself endlessly. In any case, if a person can't differentiate between what "sounds good" and what is "time-honored, proven cryptography", he shouldn't be allowed near cryptographic source code anyway (sadly we all know how often that occurs). –  Thomas Dec 5 '12 at 8:39
@D.W. I think we all know that here. But dismissing an interesting question on the basis of "never heard of it - stick to best practices" doesn't help the OP who was looking for an explanation of how entropy was being extracted from webcam noise. The OP never even said he wanted to use it in a real life application, maybe he is just curious - so it's nice to give the OP a heads up about sensible cryptography practices, but it is ultimately off-topic advice. –  Thomas Dec 5 '12 at 10:05

A quick web search for "randcam" showed me this german page Zufallszahlen aus der Webcam ("random numbers from the web cam"). (All other hits on the first Google result page are about an unrelated Pistonless rotary engine).

This page is about a program available from the same site, which tries to gather entropy from a web cam and produce "real" random numbers from this.

From the linked page (I didn't try to read the source code), the program tries to extract the electrical noise from the photo sensors by calculating differences between following frames, then assembles the difference bytes to blocks and hashes each of them with MD5. The size (and thus number) of these blocks is adjusted for each difference frame from the measured entropy (but it isn't described how this is measured) and also dependent on some adjustable factor.

The idea to use electronic noise from a web cam as entropy input sounds good. Of course, I would like to see a more theoretic analysis of the entropy which can be gathered, not just statistic tests (there are cryptographically awful RNGs which pass all statistical tests), and I would use a more sound cryptographic processing of the data.

From the cryptographic side, I wouldn't use MD5 for this, but a newer hash function like one of the SHA-2 family. While the broken collision resistance of MD5 is not a problem here, other then when your adversary can plug in its own device and feed arbitrary bits instead of the images, it is just bad for your reputation to use MD5 for anything security-relevant.

I would use an entropy pool design cryptographic random number generator. The entropy from the web cam would be added to the entropy pool, this pool mixed using pseudo random functions, and then the random numbers extracted by another pseudo random functions. There are standardized constructions for this.

But as D.W. said, there is still missing quite some analysis (how much entropy do we actually get from the differences?, for example), and justifications for the crypto around this. So I wouldn't yet recommend using this for any productive use.

-
Better yet, make the webcam interface with the operating system's entropy pool, that way you don't even need to do any work except feed it into some function. –  Thomas Dec 2 '12 at 0:42
I would want to see a lot more detailed analysis than that the idea "sounds good" before recommending this to users of cryptography. In other words: I don't think this is good advice to end users. I don't think it does a service to users to encourage them to roll their own entropy sources like this; I think giving users this kind of advice is likely to lead to increased incidence of poorly seeded crypo. Instead, I think it is better to stick to advising them to use standard, well-vetted crypto PRNGs provided by the system. –  D.W. Dec 3 '12 at 3:49
Among the risks associated with the technique is that the output of the webcam could be accessible to an adversary using a built-in legitimate feature of the webcam driver, not to mention a backdoor thereof. Also, a crash of the webcam driver has a good chance to degenerate into no available entropy. –  fgrieu Dec 3 '12 at 21:17
"...calculating differences between following frames..." is a common fallacy. You can't subtract two JPEG images to isolate the true difference between the original photo detected views due to the nature of the compression algorithm. Well you can actually, but you'll vastly overestimate the difference. In my opinion you have to deal with the JPEG files directly and forget that they're images at all. I take my tutelage from Marcus Aurelius, “This thing, what is it in itself, in its own constitution?” Treat the camera as a bit fixing entropy source. They're 99% entropy anyway. –  Paul Uszak Aug 30 at 1:18
I meant to type 90% entropy. –  Paul Uszak Aug 30 at 4:23

A video camera can obtain entropy, but only at a fairly low rate and only if allowed to see "unusual" scenes… like someone making funny faces, unusual movements, etc. Of course, this only works in a room with no video bugs.

Theoretical explanations…

Depending on your knowledge-range, the following sources may be able to explain ways webcams can be used for random number generation:

Getting more practical…

If the above is too theoretical for you and you want a more practical explanation of how it can be done, there's a cool "how-to" article at inventgeek.com that shows how to create an "alpha radiation visualizer" from scratch within an hour… using a webcam and a regular smoke-alarm device as radiation source.

-

Yes absolutely. I believe that web cams make excellent true random number generators, but. The camera has to be operated within a visually managed environment. This is necessary to determine and control entropy of the resultant images for quality control purposes. The trick is not to rely on the scene the camera sees, but the image noise. Only God himself can predict this noise, hence true entropy. Consider this - all low light web cam images generated in the world are unique.

As mentioned, they can be slow. A webcam's no beam spitter. I estimate that you'll get 0.5Mb/s of true randomness from a VGA camera. That's still orders of magnitude faster than /dev/random. It's probably the simplest way to generate true entropy though. Your subsequent issue will be randomness extraction. This means converting the image noise to bytes ranging uniformly between 0 - and 255. There are those that will tell you to shove it up a cryptographic function, which will work but is boring. There are other ways.

Also ignore the majority of comments regarding susceptibility to attack. Those scenarios are bandied about as in the writer's department of a Hollywood blockbuster. Those scenarios have near zero probability of enactment unless you're guarding the nation's strategic defence.

-
Can you give any reasoning for the 0.5Mb/s you mention? Wouldn't it depend on framerate and compression (if any)? –  otus Aug 30 at 12:31