Webcam random number generator

Question

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++.

Answer 1

A quick web search for "randcam" showed me this german page “Zufallszahlen aus der Webcam”, which translates to “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. commented, 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.

Answer 2

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:

• Patent US 5732138 A — "Method for seeding a pseudo-random number generator with a cryptographic hash of a digitization of a chaotic system."
  Inventors: Robert G. Mende, Landon Curt Noll, Sanjeev Sisodiya
  Original Assignee: Silicon Graphics, Inc., Filing date: 1996-01-29, Publication date: 1998-03-24

• Random Numbers Generated from Audio and Video Sources
  2013, I-Te Chen, Department of Healthcare Administration & Medical Informatics, Taiwan

• Random Number Generated from White Noise of Webcam
  Jer-Min Tsai, I-Te Chen, Jengnan Tzeng
  2009 Fifth International Conference on Intelligent Information Hiding and Multimedia Signal Processing
  ISBN: 978-0-7695-3762-7

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.

---

EDIT

Sometimes I stumble upon a wave of disinformation wobbling through the internet (and I’m not talking about Crypto.SE in this case, which seems to have escaped this particular wave so far). Most of the time I manage to keep my mouth shut, but this is one of those rare occasions where I felt the urge to draw a clear line between amateur chit-chat and actual cryptographic security. After all, when creating your own “randomness” thingy, you do not want to step into the most obvious pitfalls… do you?

Always remember that it only takes a tiny glitch to make your “randomness” thingy as insecure as leaving your key stuck in your front-door.

For example: I repeatedly have to disagree with people telling the world it‘s OK to rely on JPEGs provided via their webcam software, which are auto-stored on their disks and later fetched to extract “randomness” from those images. Let’s be clear on something: when doing so you are actively ignoring several issues, both from a cryptographic as well as from an infosec point of view.

Time to dive into some stuff, just for the fun of providing some food for thought…

1. Trust

   How trustworthy is that 3rd-party webcam software you are relying on?

   Think about it for a second before we simply skip this rather tin-foil hatted question, assuming you absolutely trust your webcam software because (for example) you coded it yourself.

   To further limit the scope of my edit, I’m also skipping the talk about the potential issues arising from storing those images to HDs, USB sticks, or whatever storage medium you might be using. Besides the fact that this would quickly wander off into InfoSec realms, only you can know if we can or should assume your disks and system to be safe from any 3rd party access at all times because (for example) you’re the best sysadmin known to humanity and never sleep anyway.

2. JPEG is not even close to raw signal data!

   Do not just jump for the next image format available, unless you know what the specific image format (read: file format) actually contains, how that format may influence the security of your implementation, and how potential implications of individually chosen image/file formats can be secured.

   If you don‘t plug into the webcam hardware directly, at least be smart enough to use as much raw signal data as you can get… and one thing is for sure: using JPEG is not the smartest choice. Remember that JPEGs (like most image formats) introduce a repeated and predictable data block (the image header), and lose some of the wanted entropy (due to the lossy data compression – among other things) while all that post-processing takes time. To lift related issues, you‘ld have to post-process the already software-processed “random data” which created the (to stay with the example) JPEGs. By now, your own logic should already be screaming at you that using raw image data extracted directly from your webcam hardware is the smarter, safer, and faster choice.

   Personally, I’ld advise you to either use raw signal data (available via hardware modification), or to grab raw image data directly from your webcam (using appropriate software and/or drivers).

3. “Webcams only offer JPEG” and “Webcams don’t offer raw image data” are blunt lies!

   Sooner or later, you will stumble upon some people that try to tell you it’s not possible to grab raw image data from webcams and that webcams only provide JPEG output. While I somewhat admire the boldness of people pushing out such balony into the digital voids, I honestly can’t help feeling the need to explicitly state that they are absolutely wrong.

   What those people are forgetting (or actively ignore) is the fact that it‘s not the webcam itself, but the webcam software which produces those JPEG images from raw image date that software grabs from the webcam. Besides potential licensing restrictions related to individual hardware, there is no reason why you wouldn’t be able to do the same raw image data such webcam proggies use – without applying JPEG compression or other image processing.

   For your convenience, here are some hints of software projects which are able to grab raw image data from webcams… just in case you ever feel like proving such claims wrong:

   • fswebcam (quote: RAW - Reads images straight from a device or file.)
   • AviRaw - read raw webcam AVIs (which is – among other things – used to look at the stars)
   • An Image Grabber for the Creative WebCam Go

   Please feel motivated to do your own research. Search engines tend to spit out truckloads of alike software solutions and sourcecodes which practically enable you to grab the raw image data from various webcams and related systems.

   From this point on, be confident that anyone claiming it can‘t be done is either not informed, or bluntly hiding his/her ignorance behind an easy to uncover lie. Don’t waste your time on such people – simply turn around, take a deep breath, and try to find someone smarter to talk to.

4. Always “Combine & Hash”

   It doesn’t take a 3-letter agency sitting in a black-windowed van to ruin your “randomness”. In fact, even that old microwave oven your neighbour uses might be that ill-placed that it influences the noise which you hope to gain from your hardware. Badly shielded speakers also tend to do their badness. And 3rd-party wifi activity as well as mobile phones outside of your home also have a good chance to skew your noisy pattern. Shielding your webcam as well as the rest of your hardware might be an option, but to keep it short: one should always assume raw signal data can and will be messed with actively and/or passively… and it’s pretty unlikely you will be able to detect such influences ad-hoc, if at all.

   Due to that, I heartly recomend to generally push the captured (raw) signal data – preferrably combined with additional random data from other sources – through a cryptographically secure hash. Sure, a cryptographically secure hash takes its time to be computed… but it‘s much better to invest time in a good hash than in some superfluous image format processing (and post-processing to lift related issues) as described above in #2.

   Depending in your individual setup and scenario, a HMAC might be even more applicable as it can help protect you in some of the extremer “failing randomness” situations where a regular (cryptographically secure) hash might fail to protect you.

   Or you could get a bit crazy like I did when I created something related as a hobby project a few years decade ago. I ended up feeding some randomness sources to AES in CTR mode, while pulling random IVs and keys from a hashed combination of other randomness sources… think: encrypting combined random sources with IVs and passwords generated from hashes of other combined random sources, where all random sources are absolutely independent of eachother. Most of you will surely agree that this setup was more of a “crypto-overkill”… still, it was able to blow “blindly trusting what webcam & co. provided” out of the water. To my defence: I was young and über-motivated… ever since, I’ve learned to create smarter things with less overhead. ;)

   Cryptography is only as smart as you implement it.

   It should be noted that hashing data (either via a hash or a hmac) surely won’t save you from breaking your neck in every potential scenario, but when you watch your steps by combining raw webcam data with other independent randomness sources, hashing the lot holds the potential to increases the chances of (cryptographic) survival of your home-made “randomness” thingy.

   Nevertheless, things like “still images” hold the potential of providing not enough entropy. Which is one of the main reasons why you shouldn’t generally assume ”any pic is OK” and – whenever possible – mix randomness extracted from your webcam with other randomness providers (either hardware or software based). If you don’t know what other randomness source to use, here’s a hint: at the time of writing, all major operating systems provide their own way of extracting cryptographically secure data via software. If that’s news to you, RTFM.

   ^{/* Nota Bene: Since point #4 might inspire some cool Crypt.SE questions, I’ll leave it standing as unspecific as-is. */}

5. To build a new car, you don’t have to reinvent the wheel.

   Be sure not to get caught up in an “I‘ll create my own…” mantra just because you‘re fiddling with your own hardware. There are dozens of well-vetted solutions in the realms of cryptography that may be able to fit your individual setup, implementation, and/or needs – which practically means there might be no need for you to “create your own”. In case of doubt, click that “ASK” link and throw in your question with a short but on-point description of what you’re trying to achieve. There are ample experts around here at Crypto.SE who are able to answer near to any crypto-related question you might have. It’s always better to ask for help and infos, than to be sorry later on.

Answer 3

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. The following shows proper web cam entropy, with a blown up and equalised view too. You don't need to, indeed shouldn't, pull funny faces at the camera:-

An entropy generator based on this exact web cam principle is now on line here. The three channel lines represent about ~11 bits of total entropy, based on a very very conservative measure.