Bitcoin Forum

Bitcoin relies on random numbers for keys and signatures.  Clients may also rely on them for encryption (salt), and seed generation (HD wallets).

Proving a PRNG is secure is a very difficult task and is impossible when the operating system is not built from source.  Quantum mechanics are non-deterministic and thus provide an alternative method of generating randomness.

I just need to wait for a missing component to arrive.
http://i.minus.com/ibzPEHrUJ3pByt.jpg
(Stupid broken image proxy - direct link http://i.minus.com/ibzPEHrUJ3pByt.jpg (http://i.minus.com/ibzPEHrUJ3pByt.jpg) )
Bonus points if you can figure out what it is without using google.

My guess is it's a Geiger counter (I swear I did not check Google or anything else)...

Onkel Paul

 Good luck, that kind of entropy will be hard to create by machine.

Some kind of radioactive source maybe?

An example going back to 1957: http://en.wikipedia.org/wiki/ERNIE#ERNIE

The entropy isn't created by a machine it is a created by the environment.  The circuit would just record entropy which already exists.

Of course. Are you using a noise diode or a radiation source (https://www.fourmilab.ch/hotbits/)?

Nice project! Is this the first time anyone had this idea?

True they certainly aren't "new" however the availability of low cost micro controllers, design tools, and open source hardware means it is more economical to be done by a hobbyist.

Ernie 1-4 have been running monthly premium bond draws for 57 years, so not quite, no :)

Heh - almost right. Of course it's not the counter circuitry, just the detector tube...
Might be not so suitable after all - for really low radiation, the number of random bits per time unit might be too small, and for stronger radiation, I think they might have some saturation or dead time effect which prevents them to detect events that are too close together in time. But I may be wrong, this is all from very dim memory.
Commercial sources of randomness use thermal or quantum noise generated by semiconductor diodes as far as I know, those are much smaller and less fickle.
But as a fun project, this tube might be just the right thing...

Onkel Paul

That's what I would guess, or a tesla coil.

Had to google it. My coworkers and I couldn't figure it out.

Radiation source.  I am planning on using Americium (Am-241) for safety reasons (reasonably available and an alpha emitter).

I always thought that a microphone could work just as effectively for randomness.  Put a mic outside, record for 10 seconds, take the hash of that, viola!  Or just a straight sampling of it, like 10 bits, although the effective randomness would be less bits than that.

Or a radio. Record some random noise, and bingo, random numbers  ;)

Output will be low.  1000 bps would be optimistic, first version might be significantly lower than that.  The tube I picked is a great alpha detector.  Alpha particles are block even by a sheet of paper so it becomes possible to use a source with higher activity without presenting a safety risk. 

Still even low output can be useful if the results are cached.  Lets say only 100 bps.  That over one million bytes per day.  Enough to generate 4200 private keys.   Of course things like a strong HD wallet seed (to produce an infinite number of keys) is probably a better use of those "scarce" bits.

thats a neat idea. I'd assume the codec and/or file extension might not make it too random though

using radiation is risky.. it has a known half-life which a mathematician could possibly abuse to work out the base number used to then create randomness..

the best bet is to take several different events not linked at all and combine them

That is what RANDOM.org (http://random.org) uses.  All hardware RNGs can be categorized as either devices which sample a chaotic system (like radio noise) or devices which observe a quantum effect.  The chaotic systems are secure because while in theory radio noise is deterministic, at the current time simulations that large and complex are beyond our computing abilities.  Quantum observations are (at least based on our understanding of the universe) truly random in that we can not predict or explain why they occur.

One thing to watch out for in chaotic systems would be a periodic or oscillating signal.   Imagine a scenario where somewhere nearby there is a component (possibly defective) which is putting out a strong pulse at a specific interval which is picked up by the listening device.  This would result in your random numbers not being uniformly distributed.  Kind of like rolling some dice for random numbers but they are loaded and the six comes up more frequently than other numbers. 

all u gotta do is dance around the room several times, and do 10 jumping jacks and 10 push ups and 10 sit ups and that should provide enough entropy.  lol

Why not use the feed from all those public webcams? Pixel and hue variations should be random enough as data.

If implemented poorly it is.  A good RNG is designed so that the results can't be recreated.

It won't be measuring anything against a base number.  It will be measuring the time between TWO particle detections (if time between this interval is larger than prior interval that is a "1" and if it is shorter it is a "0" and if it is equal we throw it out).  Quantum mechanics tells us that while the average rate of decay can be calculated the time between each individual decay can not.  Of course our understanding of the universe may someday change but today no scientist can predict how long the next decay will occur in an unstable isotope.

Still it is a good point.  There are a lot of ways to construct a BAD random number generator.  As I get further into the project I plan to make it open source (both hardware and software) and plan to subject the output to various statistical tests for randomness.

You already have one installed: your mouse.  move your mouse around for 10 seconds, 30 or more for paranoia levels, and you'll have a nicely non-deterministic value.

My server doesn't have a mouse and even if it did nobody would be moving it. :)

how about making a deal with farmers. A couple of RasPi or Arduino and some IR detectors. Have them placed near those gigantic industrial chicken coop. their head movement would cut the beam and the timing would generate the data.

The farmers would be paid in Bitcoin for installing and maintaining those easy going Raspberry Pi with a secured WiFi connection to your website. Locations around the world for a 24/7 data stream. No radiation.

https://i.imgur.com/4HU32XO.jpg

Is it really reasonably available? I don't suppose you can order some from Overstock... You might have to buy a bunch of smoke detectors and take them apart  :)

Also, FWIW, it's not all that safe... It emits a bit of gamma as well, as do some of its decay products. Not too dangerous, but make sure not to eat it  ;D

Not safe. A clever attacker will hide a kinect in there and figure out your numbers. Nevertheless, it would certainly be the funniest RNG ever invented  ;D

I'd say it's an old LND INC 712, if I'm not mistaken.

There are ways to use securely use random numbers which are (or may be) known by other parties.  A simplistic option would be to XOR the random values with a large constant.  A more sophisticated option is to use something like HMAC with a private key only known to you to produce new numbers from the existing known stream.

your_random_number = HMAC_SHA256(<your 256 bit private key>, <the sequence of random but possibly not private numbers>)

Still not sure the CRNG (chicken random number generator) would be uniformly distributed.

Beside hacking the Raspberry themselves a camera of any sort would not work as the chicken's head are the seed providing the final calculation in the algorithm. Also it won't be in one location.

It is a fun concept would bring the farming world, RNG and bitcoin together  :)

Hardware Rngs:

http://upload.wikimedia.org/wikipedia/commons/3/37/Dice_(PSF).png

Ahh, but this assumes you already have a safe and random private key... If you had that, you wouldn't need the chicken to begin with. I call it the circular chicken paradox  ;D

Just one should be sufficient.


Well like you point out they are used unshielded in hundreds of millions of smoke detectors around the world.  The risk shouldn't be anymore than adding another smoke detector to your home.  My goal would be to have the source and detector sealed inside a metal box preferably one which can be mounted in a 3.5" drive bay and connect to the host via internal usb header.

1 uSv of Am-241 with no shielding produces an exposure of ~1.27 Sv per year assuming constant exposure at a distance of 1m.  That is less than 1/700th of the recommended annual exposure limit of 1000 uSv annually.  So "a little bit" in this case is almost zero which is why it is used in smoke detectors to begin with.

Agreed.  Alpha emitter inside your body is not a good thing. 

Ah, I hadn't realized such a small quantity will suffice to get your RNG working. This is indeed negligible. I work with beta emitters far more dangerous than that practically every day, and I'm still standing... kinda   :-\

A truly random generator is kinda impossible. Output numbers seem to be random, but there is some equation behind it.... I don't think its possible to make a truly random number. Maybe if you analyzed like something minute like the position of an atom or quantum mechanics?

Well, as OP already mentioned, radioactive decay is one of the few things in the universe that are truly random (at least as far as we understand physics today).

Well it remains to be seen but that is my hypothesis.  The reason for this specific tube (LND 712) is that it is very sensitive to alpha emissions.  The source is going to be permanently attached to a screen on the window end of the tube.  There are more sensitive tubes but they are out of what I am willing to spend on a hobby project.  Looking at the test results of other homemade geiger counters it looks like 1 uCi of Am-241 will register 100K to 120K CPM with this tube.  Assume two counts per bit that works out to ~800 to 1000 bits per second peak throughput.

The source or the tube however isn't going to be the bottleneck (at least through 1 kbps).  The hard part is going to be getting a timing circuit which can register events with sufficient accuracy.  We are talking an average interval of 500 microseconds so a timer with microseconds scale accuracy (or at least tens of microseconds) is going to be necessary.  This is beyond the capability of most micro controllers, and it probably going to mean a dedicated real time clock ( something like http://www.maximintegrated.com/datasheet/index.mvp/id/4627/ln/en ).  

As a proof of concept I am going to start out without a RTC but that means much lower timer accuracy and lower throughput first.  Something in the order of <3,000 cpm which produce ~24 bps of entropy.  Even that will depend on micro controller having true 1ms clock accuracy.  For the early test I am going to use a gas lantern mantle (thorium & beta emitter) as the particle source.

Is this a good algorithm?

I know that what seems intuitive is often wrong when dealing with things like this, so I may not be thinking this through correctly...

It would seem that while you cannot know how long it will be to the next detection, there will be an oscillating tendency

Anytime you get a "0", it implies that the time was shorter than the previous detection.  While this is not a guarantee that the time is shorter than the average, it certainly is an indicator that the time is more likely to be shorter than the average. (If you average all the intervals when you get a "0", and compare it to an average of all the intervals, the average interval when you get a "0" should be shorter than the average of all intervals, shouldn't it?)

The reverse can be said about any instance where you get a "1".  This would seem to imply that after a "1", there is a higher than average chance that your next interval will be a "0" (and vice versa).

I suppose for these purposes the bias might not be significant enough to be a problem, but I can't help but wonder if there isn't a better solution.

R u sure? Longer a particle is stable - higher chance that it will stay stable.

That is a good point.   What I wrote didn't accuracy describe the conversion method and you are right, as described it probably would lead to some alternate bit bias.  A better explanation is that each bit will require two independent intervals.  

Imagine 3 particle detections a, b, c,
Interval A is the time between a & b
Interval B is the time between b & c

if (A > B)
   then bit = 1
else if (B > A)
   then bit = 0
// if A = B then no bit is recorded

This requires two counts (events) per bit so the bitrate will be roughly CPM / 120 (CPM = counts per minute).  It will actually be less than half due to the portion of the counts which need to be dropped because the intervals match.  The amount of the reduction will depend on the accuracy of the clock relative to the average interval.  

Some ballpark numbers:
To produce a throughput of 1 kbps (about a 10MB stream of random digits per day) would require a source and tube combination capable of 120,000 CPM and a real time clock with at least 10 microsecond accuracy.   Initially I am going to try for a much lower ~100 bps using the microcontroller clock with roughly 1ms accuracy.

Ah. Ok.  This makes more sense.  Thanks for the clarification.

Is it possible to use the hash of each new block as a source of entropy?

I don't see how the codec or file extension would affect the effectiveness of the hash... I mean, sure, the headers might be known, but random audio would still be made up of random bits, regardless of what codec is used.

It's public data, so by definition, not really safe to use.  Someone else could replicate what you are doing.  The whole goal with a good RNG is that no one else can replicate it even if they see the code you are using.

Not really - see above.

Ah okay, yeah that makes sense. So a pretty useless suggestion then...

Well, at least I learned something.  :)

http://phys.org/news202456660.html (http://phys.org/news202456660.html)

... be careful, there maybe periodic signals in there ...  :D

It isn't useless, it just isn't a TRNG.  You could take block hashes and use the trailing 160 bits (to avoid bias due to leading zeros).  That would give you 160 bits per block or about 48 Mb since the genesis block.   You would now have a random uniformly distributed sequence of random bits (or at least you could test it to verify that assumption). If it is uniformly distributed (and what we know of SHA suggest it is but that could be tested) it has some use however as SpikeSgt pointed out, for cryptogrphic purposes you want uniformly distributed random values not know or reproducible by anyone else.

However by applying a little crypto you could mutate that stream into something that nobody else can reproduce.  One example would be to take a HMAC-256 hash of the sequence (in 256 bit "chunks") using the raw truncated block data and a private key you know.  Now it isn't a TRNG because if someone obtains your private key they could generate your private stream.  However this did get me thinking.  Using a programmable smart card capable of HMAC the key could remain inside the smart card.


The point of using a nonce would be to prevent someone who has access to the cards from producing previous values (i.e. the same raw block hashes would produce a different output each time they are input to the smartcard).

Still not a TRNG but a pretty cool concept regardless.  Private keys in theory can be extracted from smart cards but it is a difficult process and requires physical access to the card.  If the card is stolen then move your coins.  Don't anyone rush out and use that I am just thinking out loud.  Still in general it is an interesting concept. The blockchain is a large source of KNOWN entropy, a system which mutates that into unknown entropy is easier than one which attempts to produce unknown entropy natively.

I've always pondered if there's any use on adapting random behavior of certain natural systems as entropy sources. For example, you could use an USB microscope to record E.Coli movements on a petri dish and use frames as an entropy source, or you could even go and use a string vibrating with an electromagnet under a bridge (i know this source has harmonic behaviour, but you could use the noise in the sine wave to generate additional entropy, or even use FM as the entropy and not the amplitude). This could be recorded with a smallish system like the Electric Imp and sent to a server to seed different PRNGs regularly, resulting in a TRNG seeded PRNG. You could use the TRNGs directly, but real life sources have low bandwidth (This could be desirable for certain systems).

I think it doesn't work that way. Radioactive decay is a Poisson process, and the time interval between decay events follows the exponential distribution, which is "Memoryless (https://en.wikipedia.org/wiki/Exponential_distribution#Memorylessness)". I'm pretty sure that means that the length of one interval has absolutely no predictive value regarding the length of the next interval.




Following what I said above, I think it should be possible to use only one event per bit. Just check whether an interval is shorter or longer than the median of the exponential distribution, which is ln2 divided by the rate parameter (which can be estimated given the half-life).

What are the benefits of a random number generator? Does this have any scientific or mathematical benefits?

This is all very interesting, but just like the chicken idea above, none of this is truly random. Theoretically, the movements of E. coli are predictable. Every gust of wind in the atmosphere is predictable. Highly complex or chaotic systems may be unpredictable in practice, but they are still predictable in theory.
The only things which are theoretically unpredictable are quantum phenomena.

If you had perfect knowledge of the physical universe, plus an infinitely powerful computer on which to run your perfect simulations, you could predict which direction each E. coli will turn, but you would still have no idea when the next radioactive atom will decay. Or so the theory goes...

Although the "predictability" of E.Coli is provable, the computational power needed to predict every and each movement of an E.Coli on a petri dish would be very high, and even then, the computational power needed to predict that TRNG would probably have a lot more of the power needed to break ECDSA.

You could also use Brownian Motion [1] which is a random phenomena that also exhibits the qualities desirable on a TRNG, and has much more bandwidth than decaying atoms. (Again, low bandwidth is desirable on some TRNGs, so it is a trade-off)

[1] http://en.wikipedia.org/wiki/Brownian_motion

Sounds like a fun project.  Very cool.  But why do you need to prove randomness?
It is unlikely to provide any business advantage in my opinion.

Looks like you are doing things right so far.  Personally, I use a different tube and a chunk of thoriated welding rod, but that's because it is what I had sitting around.  After your A/B filter, you need to feed it through von Neumann's filter (1,0 -> 1; 0,1 -> 0; 0,0 ->discard; 1,1 -> discard).

Next up for your project is monitoring.  Bias creeps in.  You need to keep careful track or you'll end up with garbage.

Finally, you need security.  Ideal would be an old line printer hooked up to a totally offline box.  Every time you get enough bits, encrypt the privkey and print that along with the pubkey (or address).

I agree of course. For any practical purpose, you don't even need E. coli - any classical method of inputting external entropy (like moving your mouse around) will probably be more than enough. I was just pointing out why OP's use of radioactive decay is really cool  :)

As for Brownian motion, it is random insofar as statistical mechanics is affected by quantum phenomena. You could say that in principle, Brownian motion should be truly random, but in practice the motion of particles is affected by multiple environmental factors that could completely overwhelm the true Brownian component. When we let undergrads peek through a microscope and show them lots of little things moving around, we tell them this is called Brownian motion, but in fact much of this motion could be caused by all sorts of external forces. I suppose you'd need some kind of entirely isolated and adiabatic system to observe true Brownian motion...

Security. If your private key ain't truly random. I may be able to guess it and steal your bitcoins.

Indeed! it is very cool!


Also i'm aware that Brownian motion is completely correlated to the physical properties of the material/specimen/sample being observed, i was expanding over the fact that to obtain a "good enough" TRNG you don't have to go full Quantum (for now, what future holds, i don't know). Also, it would be nice to have a multisource TRNG that is publicly available like Random.org but for cryptocurrencies at large.

This will create independent bits but there will be a bias towards 1 or 0, depending on the details of your particular setup.  You need to compare two intervals created by the same process within the same system, instead of replacing one of them with an external constant.

That's the right way to do it. Von Neumann figured that out around 1950.

I agree the later is a better solution but using a Von Neumann filter, the bias of independent bits can be removed.  For example in the setup proposed say the system was biased toward producing 0s over 1s.  Since a 00 sequence (or 11 sequence) is discarded and a 01 and 10 sequence are equally likely the bias can be easily removed (01 = 1 and 10 = 0).  Still you end up using at least 2 counts per bit after filtering.  The actual number of counts required will depend on the amount of bias.  The more biased the source the more counts it will take to produce the "rare" 1 needed to complete the sequence.  For example if a system was biased 70%/30% in favor of zeroes then it will require on average 2.38 counts for each bit that passes out of the filter.

Lol.  No way you're going to steal my coins based on an "only" pseudo random key.
Anyway, not trying to rain on the parade here,  carry on!   ;D

I think you miss the point.  If a PRNG is secure then you have no problems.  Are you SURE your PRNG implementation is secure?  Coins have be stolen in the past due to flawed PRNG implementations.  Now it is unknown if it was just a flaw or an intentional weakness (put there by 3 letter agencies which know they can break unbreakable ciphers when they rely on weak random numbers).  Still it doesn't matter the coins were stolen just the same.

http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/

Even if it was intentionally crippled it may have been for reasons other than Bitcoin, and some Bitcoin users just ended up in the crypto crossfire.  

Of course that isn't the only example not even recently:
http://en.wikipedia.org/wiki/Dual_EC_DRBG
http://www.nytimes.com/2012/02/15/technology/researchers-find-flaw-in-an-online-encryption-method.html?
http://dl.acm.org/citation.cfm?id=1496724
http://eprint.iacr.org/2007/419.pdf

This isn't a commercial project, just something I want to do as a hobby.  If it goes anywhere I intend to make the hardware and software open source.  Hopefully that leads to other open and transparent designs.

Sure... All I was saying is that making a PROVABLY unflawed rng isn't going to
substantially help customer acquisition for reasons I won't bore you with...
Just making a business comment, hope you don't mind! 

Have you seen the Simtec Entropykey?

http://www.entropykey.co.uk/

I have a couple that I use for making sure that virtual machines have enough entropy. They appear to work really well.

Sadly I have heard people have been having lots of problems ordering from Simtec recently.

What does acquiring customers have to do with this thread?

I own one of their keys.  It does seem difficult to order more at the current time for some reason (maybe creator moved on to other projects).  However the simtec is a black box.  I am interested in an open source implementation.  

Thought you were developing it for some business purpose initially.

Btw, why do we need hardware , isn't there enough entropy on the internet that we can access?

It's public entropy, so if anyone knows what you are using, they can generate the same "random" numbers.  A true RNG would mean no one could reproduce the results.

It could be combined with the entropy of the exact time a random number request was made, along with additional pseudo random number from the server, hash the result, grab some random parameters from that, go get some random feed from online that is also changing in real time, hash that, and you have a pretty doggone random number that no one could arrive at even if they had your source code. 

That sounds awful complex.  Wouldn't a simple piece of open source software and some easy to acquire hardware be a simpler and more reliable solution?

There is certainly a market for something like the entropykey, though it may be small. Open hardware schematics that third parties can make and sell would be great.

Depends on the application.  Generally, I'd rather use a code library than worry about hardware.

That doesn't sound like it would satisfy the desired result:

Perhaps.  Don't want to get into a long debate, just suggesting there is a lot of real time entropy available through the web as well.  Cheers.

I disagree.  If someone had your source code, they could track all those sources you talk about, and the only thing they'd need to speculate on is the exact time a random number request was made.  If you're going to claim that is random enough, then just use the exact time request by itself - everything else adds no additional randomness to someone who has your source code.

Does this provide more entropy than something more common and practical, like the camera on your phone? I would imagine that if you hashed a 24-bit 10 megapixel random image you'd get a random number with pretty good entropy. After all, each pixel can be considered as an independent photon counter.

I'm a bit late to the discussion, but I'm a bit surprised that no one posted this resource for quantum generated true random numbers using optics at the Australian National University: http://photonics.anu.edu.au/qoptics/Research/qrng.php (http://photonics.anu.edu.au/qoptics/Research/qrng.php)

They have a live true random number server as well:
http://150.203.48.55/index.php (http://150.203.48.55/index.php)

The API info can be found here:
http://qrng.anu.edu.au/FAQ.php#api

No idea if it's fast enough for the intended task though...

Thanks for the links.  Very useful.

And more to the point it seems to validate D&T approach. They are only using a different source of quantum entropy. D&T model seems easier to be developed on a large scale, though.

Well to be clear this isn't "my" approach, just the one I am planning to use.  :)   I don't want people to incorrectly give credit where no credit is due.  Fourmilabs in switzerland has been providing true random numbers over the internet produced from observing radioactive decay for the better part of a decay.  The interesting thing is that micro controllers have gotten fast and cheap enough combined with a lot of open source hardware information at there that it becomes economical for a hobbyist to build their own "hotbits" device at home.

May I ask - what are you planning on using the RNG for? Because if it's for applications like generating passwords - it might not be that useful. If there are already quantumcomputers powerful enough to predict the movement of E.Coli..they will surely enough be powerful enough to just bruteforce the passwords.

Have you thought about a lavarand generator?  ;)


http://www.random.org/randomness/

What's wrong with the randomness that is used on dice sites like Just-dice?

That one is pretty random too, to be honest.

Because they are not per se truly random but instead pseudo-random being generated by a seed and combined with various other factors. So while they 'approximate' random numbers they are no truly random numbers themselves yet still good enough for the purposes of running a dice game. It's really all about how picky you want to be.

While I don't really know anything about your setup or geiger counters in general, it does seem like an expensive component. Would the cheap geiger counters on ebay not be good enough for the task?

Uhm, I don't think there will be a bias. That's exactly why I suggested the median. It's not an external constant, it's a parameter of the distribution of the measured variable. By definition, 50% of the intervals will be longer than the median and 50% will be shorter (a few may be exactly equal to the median, but you will discard them). Therefore, I don't think you'd need a von Neumann filter, nor do you need more than one count per bit.

How random is PHP math_rand(0,n) ?

Is this real life ?

But you suggested estimating the median from a known constant, not calculating it from the actual sample.
That introduces the possibility of bias.

You could use phosphorescence of fluorescence instead of radiation. They are quantum so random.

Well, yea... The half-life of 241Am is well known and measured, I don't think there's a lot of wiggle room there... But I suppose you don't know the purity of your sample, plus the sensitivity of the counter might introduce some bias...


Maybe it really is preferable to calculate from the actual sample. It's also very easy. You just let the counter run for a very long time, and calculate the average CPM (by "very long time", I mean very long relative to the average interval in the OP's setup, which OP expects to be some fraction of a millisecond. So a few hours are probably more than enough for the law of large numbers to really kick in).

Then you just take ln2 divided by the average CPM, and that's your median interval right there.

In fact, if you have the thing running all the time anyway, you could use the massive amounts of data points you collect to continuously fine-tune your measurement of the average CPM. Say, once a month you calculate the average CPM of the last month, and recalculate the median. That way you're continuously adjusting for the decay of your sample, degradation of the counter tube, and such.

I didn't want to grant you the full paternity of the idea (i.e. provide true random numbers using quantum entropy).

I just wanted to underline the fact that your idea has a potential since it could be produced on a large scale with low costs per unit.

kudos in advance :)

Isn't casting dice enough random? Maybe the only problem is that the process of collecting those numbers and generating a key is lengthy  :P

As long as the dice are fair it certainly is, so would flipping a lot of coins.  The collection of data however is manual and slow.

How about an RNG based on the blockchain?  :)

There aren't quantum computers powerful enough to predict the movement of E.Coli.

Depends on what purpose.  If someone knows exactly what time (ms) you generated a random number using it, then they could regenerate the same "random" number.  It's not 100% secure for generating things like Bitcoin addresses, but in all likelihood, you'd probably be fine using it.  A true RNG has results that are unreproducible.

Predicting movement of E. coli sounds unfeasible based on general chaos theory.

this ?

Probably.  The G-M tube selected is very sensitive to alpha radiation.  This allows a high number of events (counts per minute) without needing to use a source with high beta or gamma activity (dangerous).  It is very possible that cheaper less sensitive tube will also work depending on the radioactive source and the throughput of random bits required.  I intend the design to use a simple two pin connector for attaching the tube using soldered on leads, and an adjustable high voltage power supply so the design could be adaptable to other tubes which operate in a 300V to 500V range.

A normal photograph probably not. The pixels aren't random they are organized into all types of patterns, also subsequent photos won't be independent.  There is a project which uses a capped webcam as a source of entropy.  A perfect web cam would show a uniform black output but due to noise in the sensor it produces spots which if not random are at least a very complex chaotic system. 

http://sourceforge.net/projects/lavarnd/

It is a form of TRNG however I am more interested in the sub category of TRNG based on quantum observations.   Still there is more than one way to gather entropy.

So gonna integrate it with a hardware wallet .. like Trezor for the off-line keygen part too?

Possibly as a future project however at this point it really is just a proof of concept prototype.  It may not go beyond that.

How cheap can radioactive material be?  $50?  $20?  $10?  How about $3.99?  Went to Walmart (where else) looking for the cheapest ionizing smoke detector they had.  Found a $11.99 one and I almost missed this piece of junk on the bottom shelf.

http://i.minus.com/iooRCdj2MjLX.jpg
Sentry i9040 Smoke Alarm, Walmart price $3.99!  Score!

http://i.minus.com/iebvNWkZIH9dy.jpg

Bingo that is what we are looking for.  A quick tip about smoke detectors, most detectors in the US use Am-241 a radioactive isotope.  It might not be as common in other countries and the use of radioactive detectors may be completely outlawed.  Am-241 is chosen because it emits (mostly) alpha radiation which is blocked by even a piece of paper or about one inch of air.  The packages may say Am-241 on it or it may just was ionizing.  There are no radioactive smoke detectors which are optical based so if you see anything on the box about optical detection that is likely not the model you want.

http://i.minus.com/iY8PI0991vfKy.jpg
So there were some kind of clips holding the top on the detector I just broke them by putting a screwdriver between the top and base.  Nice thing about $3 smoke detector is the plastic was very cheap and weak.  That silver dome is the detection chamber.  It is the only part we are interested in.  So I just popped the circuit board out and cut the wires.

Safety:
Am-241 is pretty safe as far as radioactive isotopes go but don't be stupid with your health.  I recommend you wear gloves and operate on a clean and clear workspace.  Throw all the trashed components, your gloves, and any paper towels used to clean up dust into a plastic bag when complete.  Since Am-241 is primary an alpha emitted the greatest danger is if you ingest, breath in, or somehow get it into your bloodstream (i.e. cut yourself with a knife that you scrapped some Am-241 onto).

http://i.minus.com/iMWKEnHJ5ehB5.jpg
The backside of the circuit board.  Notice the board is covered in wax so if you notice white flakes coming off the board it isn't lethal radioactive material it is just wax.  You will notice there are three clips here (first one already destroyed) however that metal cap it actual held in place by the two long solder joints (one to the left of "TP2" and the other just above the arrow in the lower left).  You probably could desolder the shield and on a better made model you might have to but this is some cheap junk and after about 3 minutes with a screw driver, needle nose pliers, and some tin snips I ended up with this.  There is no exact science to this just use the minimum force necessary you don't want to damage the Am-241 slug.

http://i.minus.com/iSMXogIB9IWHC.jpg
The shield on the right covers the "white stand" which holds the Am-241.  The metal foil in the center of the photo is the top conductor.  It is attached to the top of the white stand and easy to remove with some pliers. The smaller inner/lower metal foil which is still attached to white stand is the second conductor.  When smoke particles enter the space between them they are ionized by the alpha particles emitted by the Am-241 and complete a circuit which trips the alarm.  The metal slug in the center of the white stand is what contains the Am-241.  We want to remove that as carefully as possible without damaging it.  The Am-241 is actually applied in a layer on the surface of the copper colored metal in the indention of the slug.  You want to avoid scrapping across that as you could produce dust containing Am-241.

http://i.minus.com/i3cjGPdStGzAB.jpg
I found it easiest to rip off the lower foil (needle nose pliers worked great).  The slug is wedged into the stand from the backside.  You may be able to knock it loose but I found it easier to just cut the cheap white stand down until the slug came free.  However you break it out the goal should be to destroy the material around the slug not the slug itself.  We are trashing everything else and we want to avoid disturbing the Am-241 on the surface of the slug.

http://i.minus.com/idYSfqiXrPNIx.jpg
Tada 0.9 microcuries of Am-241 for $3.99 and maybe 10 minutes of work.   1 microcurie scientific samples generally run $50 to $200 so this is quite a deal.  It would be a good idea now to clean down your workspace.  Dispose of all the other material, used gloves, and cleaning supplies. (in a sealed plastic bag).  The Am-241 doesn't need heavy lead shielding but keep out away from children and pets (consumption would be very bad).  I stored my sample in a used pill bottle and clearly marked.

DISCLAIMER:  Am-241 is relatively safe compared to other isotopes however all radioactive sources this information is provided as educational only and you accept full responsibility for your actions.  You are responsible for ensuring that the removal and/or possession of 0.9 microcuries of Am-241 is not prohibited by local law.

I really like the way you explain stuff. Can't wait to see the result ;D

Q: Why did the chicken cross the road ?

A: To generate enough entropy.

i dont get it...but its funny anyway lol...

btw you can also easily generate entropy with a microphone.

noticed this statement here.... not sure if its been mentioned already but i regularly use the latest 32-bit microcontrollers from Arduino (Due) and chipKit (Max32). they can both run an accurate microsecond counter with 10s of microsecond program loop-time. so it seems well within needed resolution. processing the timestamps using some logic statements will increase the loop-time but i think you can very likely keep it under 50us.


edit: did some tests using a fairly reliable pulse generator (AMPI master-9, stated at <4us accuracy for up to a few days of running time)
 
1) loop-time of the max32 running only a microsec counter and a digitalWrite pin (TTL output) is about 5us loop-time

2) adding a serial connection (usb) and a printTimestamp routine to print the microsec timestamp is about 10us loop-time

3) adding a digitalRead routine with a 500hz square input on the pin takes us to about 45us
- printed timestamps have about a 2us jitter over a 2 min recording

4) adding another digitalRead routine on a second pin with 60hz input has little to no effect

... after 20min of testing, seems <50us was a decent guess :)

these have been going for a long time (not sure if flawed or someone else has posted)

http://www.idquantique.com/component/content/article.html?id=9

I have no reason to believe they are flawed (they have been aproved for use by multiple gaming authorities).  Very cool stuff using single photon emitter to produce entropy quantum, however with solutions starting at $1K and being closed source it doesn't fulfill my goals.

Thanks for confirming that, I was going off of (flawed) memory.  The clocks in modern microcontrollers are better than I remembered.  I did a similar set of test last night (although I had no pluse generator so I used a second microcontroller as a poor man PG).  I got similar results.  I am confident now that if I can keep loop latency under 50 us that means shooting for an average interval period of 500 us is feasible.  That would require  a source & tube combination capable of ~120K cpm, and would give us ~900 bps of filtered entropy.   At 240k cpm might be able to push that up to ~1600 bps.

You can use an entropy preserving operation on the pixels that contain predictable patterns  bitwise exclusive OR  (XOR) is such an operation.

There is entropy to be found.    The hard problem is to figure out how much.

If you XOR the value of a sufficient number of pixels from the RAW file together from a photo,  then you are bound to collect some entropy from the noise.   Shoot in low light -- set the ISO as high as possible -- adjust the exposure settings to maximize noise.


But if you XOR every pixel together...  you just get  one random number from all that work.     Which is inefficient -------  in fact,    it's not good enough to just get entropy: in order to generate random numbers at a reasonable rate,

You need a reliable approximation of how much entropy your source is giving you,  so you know how many pixels you need to XOR together  from the RAW output of your camera  to   get   32 bits of entropy,  And so you know at what point your program needs to take another picture.



I do think an analog radio receiver is a better idea;  preferably a microwave receiver that operates around the 160 Ghz range   that can be adjusted to a frequency nobody is really transmitting at besides random interference patterns,  and can pickup maximal cosmic background noise.

Plus with analog signals... you can use a feedback loop,  or setup your circuit to have electrical anomolies, such as ground loops,  to generate even more noise.

Well you are need to be careful to avoid a situation where there is bias in the output.  So when we say random we really mean a sequence of bits which are unpredictable (both forward and backwards), is a normal distribution, can be statistically shown to not have biases, and as you say is available at a useful rate.

It is going to be so much better not to use a radioactive material, otherwise you won't have something that can form the basis of a commercial product. I realise it makes it harder but it is totally worth it to find something else that works.

It isn't intended to be a commercial product, instead an open system that one can verify is accurate and transparent.  Still the idea that a radioactive source can't be in a commercial product isn't exactly accurate.  Take a look at the smoke detector aisle in your home improvement store for some examples.

Formal introduction of concept here:
Alpharand; a do it yourself TRNG using an alpha emitter as a source of entropy (https://bitcointalk.org/index.php?topic=585742)

https://bitcointalk.org/index.php?topic=585742