What does acquiring customers have to do with this thread?

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.

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.

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.

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.

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.

Math and probability.  Extraordinary claims require extraordinary evidence.

Anything is possible but the odds make it so incredibly improbable that in the absence of extraordinary evidence it is far more likely that there is another possibility.

Nothing in life is certain. Quantum mechanics tells us there is a chance that you could just walk through a wall.  As Danny example points out, by random chance all the air molecules may move away from your head and cause you to suffocate and die before you finish reading this post.  All these things are possible yet we generally consider them impossible because the odds are so incredibly small.  We aren't talking about winning the lottery small, or getting stuck by lightning small, or getting eaten by a shark small.  We aren't even talking about winning the lottery while getting struck by lightning just after getting attacked by a shark small.  

We are talking about probabilities on a scale so unlikely that they are essentially zero.  The odds of an address collision are 2^160.  That is something on the order of the number of atoms in our solar system.  Imagine each key is a single atom somewhere in the solar system picked at random.  The odds that the same atom would be picked again at random is essentially zero.  It doesn't matter if billions or even quadrillions of addresses are in use.  It doesn't matter if you tried millions of billions of key.  The odds are so small that ~0% * a quadrillion * a billion =~ 0%.

Of course these same odds apply to other public key cryptographic systems.  Lets say your gmail account is hacked.  How do you know a hacker didn't just randomly slam a bunch of keys on his keyboard and produce a private key which could decode all your communications with google.  It could happen.  Maybe the reason you got hacked is because a hacker has been doing this for years?  Of course probability tells us the odds of that happening as so low that in normal conversation it can be considered to be zero.  Baring some extraordinary evidence it is far more likely you got hacked by another method.

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. 

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.

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

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.

That is what 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. 

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.

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

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.

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

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.

(Stupid broken image proxy - direct link http://i.minus.com/ibzPEHrUJ3pByt.jpg )
Bonus points if you can figure out what it is without using google.

It is still applicable today however the core client should be more user proof. Maybe not more user friendly but more user secure.

The client does a few things implicitly which should be explicit.

Scenario: If there is no wallet file the client simply creates one.  Most applications don't work this way and it is counterintuitive to most users.
Fix:  Don't make a wallet by default.  Have the user create a wallet file (or import an existing one).  User should be able to select a different location for the wallet file.  In windows system make a folder under Documents called Bitcoin and store the wallet there.  Have user provide a name for the file and use extension .wallet.  (i.e. Johns_Bitcoins.wallet in the Bitcoin user folder is more intuitive than hiding a dat file in among other dat files in a system folder).

Scenario: Clients by default are not encrypted.  This undermines future security even if encryption is later added if an attacker obtains an unencrypted copy of the wallet.
Fix:  Make encrypted wallets the default at the point wallet is created and make user opt out by choosing an strongly worded warning.

Scenario:  Users may make a mistake at the time the wallet passphrase is created
Fix:  Take steps when possible to ensure user knows the passphrase and it is the correct one.  Detect if caps lock key is on when typing passphrase and if so prevent entering passphrase.  For the first few (say three) times the client starts after creating a new wallet prompt the user with the option to test/verify their passphrase.   Do the same for the first couple times user requests a bitcoin address (make sure user will be able to spend those coins BEFORE letting them receive those coins).  

Scenario:  Users are bad at making secure passwords
Fix: Use password strength algorithm to warn users on the likelihood that the passphrase will be insufficient to protect them from theft.

Scenario: Users are bad with making backups so make it part of the wallet creation.
Fix:  At the time of wallet creation prompt the user for a location to store a backup. By default recommend a non-system disk. For encrypted wallets offer the option to save directly to dropbox or google drive if those applications are installed.  Have the client setup transparent backups in the background.  Use the date in the filename and use a different extension (i.e. Johns_Bitcoins_Backup_2014_04_07.wallet.backup ).  At the same time make the default keypool size larger.  Even 500 keys takes a negligible amount of space and provides more safety for users which don't make frequent backups).  To some extent this issue is reduced by the use of HD wallets but we have been hearing about HD wallet in the core client for over a year now.  Even w/ HD wallet it is a good idea to periodically have user check that they have a good backup.

The sad part is that many users self described themselves as not knowing anything about Bitcoin, so they already admitted "I don't know" on the question of their knowledge of Bitcoin yet advocated an action anyways.   Either for or against in that situation is equally bad.  For those who indicated they know "a little" and advocated a ban well they are probably woefully under informed but they at least believe they have enough information to make a decision.  I have at least some respect for their opinion (as wrong as it may be).