Radioactive Random Number Generator

Imabug writes "Everybody ought to know that radioactive decay is a random process. Someone's gone and used that fact to create a true random number generator based on the time interval between two decay events. Hardware is pretty simple. Geiger counter interfaced through RS-232 to a 486. There are even diagrams of how it was put together. Forget Intel's RNG...this sounds more fun! "

Comments

Excellent!

[StJefferson]

But why not use a really hot cup of tea, and Brownian motion? I suppose that the hardware's a little more difficult...

I'm not sure how practical this is

[hubie]

First off, the link to the page that describes how the process works contains an excellent description of nuclear decay. The author should be congratulated.

The only problem with this method that I see is it is not suited for providing very large numbers of random numbers. The shortfall to the pseudo-random number sequences you get from your computer is that the numbers are not truely random because they repeat after a (very long) sequence. This is a problem when one is running a very long simulation program that is using many many calls to a random number generator. For instance, you might be running a Monte Carlo particle detector model that simulates a million events, and each event requires thousands and thousands of random number function calls. The nuclear decay random number generator would take a very long time to generate that many random numbers. The link mentioned that you can build up a buffer of random numbers, but all this means is that it would require a long time between when you could run your model.

The method is a beautiful use and demonstration of nuclear physics, but in my opinion it appears only useful for when you only need small numbers of random numbers, and in these cases the random numbers you get from your computer are probably quite good enough.

(Of course one way to generate more abundant random numbers using the nuclear decay method would be to use "hotter" sources, but then I wouldn't want one of those things sitting by my computer!)

Re:I'm not sure how practical this is

[Temkin]

But you could use the small number of truly random numbers to seed your pseudo-random number generator, and have a much larger pool of numbers to use in your simulation. Not perfect but somewhat better.

It shouldn't be too hard to include something like this into the /dev/random device drivers now used by several flavors of u*ix and spice the entropy pool.

Temkin

Re:I'm not sure how practical this is

[Imabug]

A 5-10 microcurie Cs-137 check source ought to produce a count rate of a few kcounts/sec if you place it right up against the geiger tube. This would give you maybe 1-2kbits worth of random data in less than a second. Probably a little longer than using rand() or something similar. Going with a hotter source will give you a higher count rate. Most geiger counters ought to be able to handle a count rate of 10-30 kcounts/sec quite easily before getting paralyzed, if random numbers are needed faster. And the source can be pretty easily shielded. Go to the nuc med dept of any major hospital and see if they'll give you some of their extra lead pigs (containers). Most departments I know usually have them in abundance.

Easy to Build

[Detritus]

I built one of these with an Aware Electronics RM-60 radiation monitor, a radiation source extracted from a cheap ionization smoke detector and a small program to collect the bits. The data rate isn't high but it is fine for generating keys and one-time-pads. The RM-60 is cheap, small, and is powered by the voltage on the RS-232 interface.

Monte Carlo and Random Numbers

[Robert Link]

The standard of "randomness" required by applications like Monte Carlo calculations is much less stringent than that required by cryptographic applications. Random numbers for MC calculations need only be "random" in the sense of uncorrelated. A well-constructed PRNG should be sufficient for these applications. (See, for instance, Numerical Recipes.)

Cryptographic applications, on the gripping hand, require random numbers that are "random" in the sense of unguessable. A PRNG won't do for this because the random output of a PRNG is entirely determined by the seed, and if you can produce a truly random seed, then the output of the PRNG is superfluous; you could just use the seed itself.

So, the situation is just the opposite of what you conclude. The random numbers you get from a PRNG are "random enough" for MC calculations, and you can generate them in sufficient quantity. For cryptography you need "more random" numbers, but you don't usually need as many (a 4096 bit key is usually plenty). It is this latter case that the radioactive device is meant to address.

-rpl

Re:Monte Carlo and Random Numbers

[Signail11]

The PRNG given in Numerical Recipes is not very good. The following references assume that you are using NR/C or NR/F77. ran1 is slower than implementations of contemporary PRNGs that produce much higher quality sequences (Mersenne Twister, L'Ecuyer's ME-CF structure) and has a much shorter period. ran2 is even slower than ran1 and still has noticable statistical defects (it is too even in its lower bits; this shows up well on a low-dimensional, matched paits random walk). ran3, Knuth's/Marsaglia's subtractive generator, is faster but also produces numbers that have abysmal hyperplane spacing, as the SWB/Fibonaci recursions generators merely act as an alternate implementation of a LCG with a very large modulus. ran4 is slow and must not be used for cryptographic purposes despite its misleading name of psdes; I know of no significant statistical defects of this general, but there are obvious differential properties of the F function that make me uneasy about such a short iteration count. The generators in NR/F95 are quite a bit better. Marsaglia's shift register-like Tausworthe recursions have excellent statistical properties and operate on their iterants in entirely different ways than LCGs or other arithmetical methods like LCGs and FRSGs.

Re:PRNG

[Signail11]

Never *ever* seed a nominally secure random number generator using the above poster's method. The Security Gods will have you taken out back and shot for blatant incompetence. Do you know how many seconds are in a day? 86400. That's about 2^16.5. Do you know what 2^40 is? 1099511627776. Do you know what 2^56 is? 72057594037927936. Do you know what 2^128 is? About 3.4028236692093846346337460743177e+38. Any more questions?

Not unproblematic

[KjetilK]

Well, it is a nice thing, but certainly not a new idea. The problem is that the rate of radioactive decay depends of an awful lot of things, environmental parameters. Now, I don't know how sensitive the RNG will be in this case, but it is easy to imagine the rate of decay being dependent on e.g. temperature. So, if you power up your computer in the morning and start counting decays, the CPU heats up, and you always get veeery interesting results in the evening, well, your "this-is-too-good-to-be-true"-alarm should be ringing... :-) Besides, radioactive decay is a Poisson process, and Poisson processes are not always nice... Kjetil