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++.
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 &amp; 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…


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.
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).
“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.
Always “Combine &amp; 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 &amp; 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. */
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.