DIY Random Number Generator 227
Compu486 writes "The guys over at Inventgeek have come up with a project and how artical on building
a random number
generator that is less than 100.00 utilizing radioactive decay. Using some
Linux based open source apps and with a little ingenuity and some parts you probably
have laying around your house you can build your own."
Typos (Score:5, Interesting)
and how to article on...
And I have to wonder...that is less than 100.00 what?
I did this in highschool (Score:3, Interesting)
I had a simple C program that just spun between 0 and 255, and when a signal came across the game port it would record the current number.
run that through a hash function of your choice and it worked great.
dont cpus today have some noise generators built into them though?
Editors? (Score:5, Interesting)
Michael (Who now sits back and waits for people to pounce on my spelling/grammatical mistakes)
Re:Here's the money graph (Score:1, Interesting)
Isn't Blum-Blum-Shub still a better choice of algo for encryption?
I seem to remember (Score:5, Interesting)
[I know, a reference would have been nice, but age does terrible things to your internal bibtex database]
Another approach (Score:3, Interesting)
Typically silly (Score:3, Interesting)
Frankly, you don't need all that much true randomness to generate random numbers. You just need to be able to continuously seed a CSPNG from a random source, and not even at a very high rate. A few bits a second is plenty.
Move along,
-Matt
We use /dev/urandom (Score:4, Interesting)
Re:More difficult Rnd() generator (Score:5, Interesting)
http://www.dangerouslaboratories.org/radscout.htm
http://en.wikipedia.org/wiki/David_Hahn [wikipedia.org]
Re:I did this in highschool (Score:3, Interesting)
Is radioactive decay really random? (Score:2, Interesting)
Re:I did this in highschool (Score:3, Interesting)
A simple 1/ megabit/sec generator for cryptography (Score:5, Interesting)
I generated a CD full of random data, which anyone is willing to have if they want it. I've tested it against the "Die Hard" tests, and almost all the 10-meg files pass. There is one test that failed now and then, so I contacted the statistics professor who wrote it. I showed him that his own random number generator, thought to be nearly foolproof, failed the same test with the same probability. It seems I found a bug in his program!
Total cost for components is $10. Anyone who is interested can have schematics for free. Contact me at bill@billrocks.org.
The theory behind it is simple... who cares if the bits from the source are completely random? It turns out you just need a LITTLE true randomness from the source. By xoring bits together that have some randomness, you quickly approach truly random. By my estimate, only God would ever know the difference for the data I generated from perfectly random data, since the board could generate data for billions of years before accumulating even one bit of non-random data in it's output.
Mathematical proof:
Two semi-random bits b1 and b2 each contain small amounts of
non-random noise which we can call d1 and d2. Note that d1 and d2 can
be correlated, and usually are. The notation P(expression) means the
probability that the expression will be 1.
I define P(b1) and P(b2) as:
P(b1) = 0.5 + d1
P(b2) = 0.5 + d2
Both d1 and d2 have a range of -0.5 to 0.5. Xoring b1 and b2 together gives:
P(b1 ^ b2) = P(b1 & !b2) + P(!b1 & b2) = P(b1)*P(!b2) + P(!b1)*P(b2)
= (0.5 + d1)*(0.5 - d2) + (0.5 - d1)*(0.5 + d2)
= 0.25 - 0.5*d2 + 0.5*d1 - d1*d2 + 0.25 + 0.5*d2 - 0.5*d1 - d1*d2
= 0.5 - 2*d1*d2
Squaring a small number makes it very small indeed. If d1 and d2 are
already 0.01, then xoring b1 and b2 together results in a random bit
noise level 0.0002. This leads to the following equation for the
amount of non-random noise defined as n(bits) given the number of bits
in the xor sum:
n(1) = d
n(2) = 2*n(1)^2 = 2*d^2
n(4) = 2*n(2)^2 = 2*(2*d^2)^2 = 2^3*d^4
n(8) = 2*n(4)^2 = 2*(2^3*d^4)^2 = 2^7*d^8
n(i) = 2^(i-1)*d^i =
Here's how you can use this equation. Lets say you believe you have
non-random noise levels of no more than d. You want the noise level
to be less than N. We want to compute the number of bits needed, i:
N = n(i) =
2*N = (2*d)^i
log(2*N) = i*log(2*d)
i = log(2*N)/log(2*d)
So, for example, if you feel your non-randomness per bit is less than 10%,
but you need less than 1 part per billion, we compute the number of bits
needed in the xor-sum:
i = log(2*10^-9)/log(2*.1) = 12.5
In other words, just xor together at least 13 bits.
Re:I did this in highschool (Score:2, Interesting)
A good way to get a nice random number is to take advantage of the inherent randomness of the user - initialize your noise generator to run continuously at a high iteration rate, wait for a keyboard, joystick, or mouse event, and then take as many samples from the noise generator as you need. The amount of time the noise generator was left actively running before the key/joy/mouse event will vary with the user's attention and reaction time, and will essentially randomize the values you get.