Entropy for Random Number Generation

[Boltar]

I want to generate very random numbers. There's a few approaches to this, such as the audio input from a de-tuned radio, hooking user input such as mouse movement and hashing the results over a period of time etc.. My idea was to get a cheap Geiger Counter and just leave it monitoring background radiation, use this in combination with a nano second resolution clock, each time a discharge event is detected, the least significant few bits of the timer is then used to extend the entropy pool. Left on for long enough and used in combination with other methods. Particularly, I need the numbers to be suitable for emulating quantum level events.

 

[jim mcnamara]

I do not know what you are asking for as help exactly, but what you describe derives from something Matt Blaze wrote circa 1995 - truerand. It's descendants are used to populate entropy pools, for example in linux: /dev/random

UNIX C code example:
www.cs.miami.edu/~burt/learning/Math609.../unix_truerand.c
I hope the link works correctly.

Note that a good entropy pool should block on read when exhausted. Most of what you are asking seems really better suited to PF's Electrical Engineering forum.

 

[fluidistic]

For 40 dollars you can get http://onerng.info/index.html which is open source hardware. It's not exactly what you had in mind but it does the job you had in mind.
On the other hand, one doesn't really need the entropy pool to be full for most cases. Even password generators don't use /dev/random, they use /dev/urandom instead (which never block). Here are some myths about /dev/urandom and /dev/random.
http://www.2uo.de/myths-about-urandom/

 

[DrClaude]

You can also have a look at what is done at https://www.random.org/

 

[nsaspook]

http://cfs.sourcearchive.com/documentation/1.4.1-19/truerand_8c-source.html

 

[jim mcnamara]

@fluidistic
I disagree about /dev/random vs /dev/urandom, plus password generators are not indicative of quality of PRNGs, IMO:
http://ieeexplore.ieee.org/document/1624027/

In fact neither /dev/random nor /dev/urandom is a really good PRNG, but these guys are promoting something else, so take it as it is:
http://dl.acm.org/citation.cfm?id=2516653

Both of these links are behind a paywall ... sorry.

 

[fluidistic]

@fluidistic
I disagree about /dev/random vs /dev/urandom, plus password generators are not indicative of quality of PRNGs, IMO:
http://ieeexplore.ieee.org/document/1624027/

In fact neither /dev/random nor /dev/urandom is a really good PRNG, but these guys are promoting something else, so take it as it is:
http://dl.acm.org/citation.cfm?id=2516653

Both of these links are behind a paywall ... sorry.

About the disagreement you have between /dev/random and /dev/urandom you mean the former should be used over the latter in most cases? The point of the document is that /dev/random is an overkill most of the time, including for SHA key generation (!). This is also the impression I gather from reading Unix Stack Overflow (for instance https://unix.stackexchange.com/questions/220228/is-it-bad-to-have-a-low-entropy-in-dev-random) and on IRC in both #linux and ##security.

About the papers you menion, one can find both of them in PDF format with google. First one is from 2006 and a huge security patch has been applied in 2012 so I highly doubt what is in the paper is still relevant. The second one has been kind of debugged by the /dev/random maintainer itself at https://news.ycombinator.com/item?id=6548893. I'm not an expert at all in these things but his arguments seems convincing...

Also there's a reason why both /dev/urandom and /dev/random are still used in practice. Note that I'm not saying that /dev/random and /dev/urandom are perfect or can't be improved. But in practice they are more than enough (/dev/urandom might not be enough on some hardware where the entropy is very low on a fresh boot up or so, apparently).

Edit : Another confirmation by an expert : https://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key. I quote:

the only instant where /dev/urandom might imply a security issue due to low entropy is during the first moments of a fresh, automated OS install

so I was wrong to state after a fresh reboot, it is after a fresh install. Probably because the seed is saved before shutting down so that when you reboot the seed cannot be predicted.

Edit 2 : And another one (see the most upvoted answer at https://stackoverflow.com/questions/5635277/is-dev-random-considered-truly-random , I quote

There are many applications which read /dev/random as a kind of ritual, as if it was "better" than /dev/urandom, probably on a karmic level. This is plain wrong, especially when the alea is to be used with classical cryptographic algorithms (e.g. to generate a SSH server public key). Do not do that. Instead, use /dev/urandom and you will live longer and happier. Even for one-time pad.

. Etc.

 

[jim mcnamara]

Based on the slightly vague query, I am guessing the OP would need to use /dev/random. It is hard to tell. I assume the OP wants to do some sort of Monte Carlo analysis - again guesswork. Maybe the OP will enlighten us. Then I can stop making a fool of myself...

 

[Boltar]

Sorry for the vagueness, I'm basically trying to create a quantum level emulator and give it various scenarios. I'm a complete newbie at all this but I'm pretty sure quantum level events are about as random as you can get, so emulating them would need a decent RNG. I've still got a long way to go (and many more questions to ask) before even 1 line of code is written however. The start scenario will probably be a dual slit experiment emulation. The goal of course being to obtain real world results using the simplest rule set.