Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Science

Radioactive Random Number Generator 19

Posted by michael from the clickety-click dept.
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! "
This discussion has been archived. No new comments can be posted.

Radioactive Random Number Generator More

Radioactive Random Number Generator

Comments Filter:
  • But why not use a really hot cup of tea, and Brownian motion? I suppose that the hardware's a little more difficult...
  • reminds me of a project that generated random numbers based upon webcams looking at lava lamps. a really close to random number based on the near randomness of normal things in life, a neat way of approaching randomness, i think.
  • 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!)

  • The problem with noise sources (thermal noise, semiconductor junction noise) is that it can be difficult to keep external signals out of the circuit. The power supply must be clean and the circuit must be shielded. The output of the noise generator must be carefully tested to detect any biases and correlations. Engineers have told me that this is a tough problem. A radioactive decay detector has the advantage of not being affected by these problems.

  • 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

  • I built one of these with an Aware Electronics [aw-el.com] 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.
  • 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

  • OK, I should have written "detected" somewhere in there. Real World != Ideal World, you know... I haven't done a lot of lab-work on radioactive materials, but in the work I did do, how things turn out never ceased to amaze me. Once, the emission from a source jumped to about 10000 times what we expected for no apparent reason. The comment of the lab technician was just that "yeah, well, things like that happen, strange things happen all the time."
  • It is a very nice idea, well presented, and interesting.

    However, the only applications I can think of that would require this quality of random numbers (ignoring the shortfall) are cryptographic ones. And you certainly don't want to get your crypto numbers of the Internet. (Note- I *do* trust the guy, it's the principle of the thing. Plus, theres eavesdropping and I'm certain many other interesting caveats...)
  • 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.

  • "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."

    That's not really a shortfall of pseudo-random number sequences. Maybe of some poorly implemented sequences, but it's not hard to implement a sequence that repeats only after around 2^1024 elements (Numerical Recipes, Knuth's Art of Computer Programming, etc.). Repetition after such a long time is unlikely to adversely affect any actual use of the sequence. If it does, I would like to borrow your CPU.

    The real shortfall of pseudo-random number sequences is that they contain patterns of various kinds. E.g., some of them show up as alignments of points when the pseudo-random elements are used as coordinates of points in a multidimensional space. There are solutions for this (Art, Recipes). Basically, if the patterns in the generator have no relation to your use of the generator, you don't care about them. And for modeling work, that's fine.

    However, if you are using the numbers for cryptography, you may care about the distinction between random and pseudo-random, because if you do not have a truly random key, somebody else might be able to find it. E.g., if you generate a key using the current time as part of a seed, somebody might be able to try all keys that could have been generated around the time they think you generated the key. A truly random sequence protects you from this. In such a situation, it is sufficient to generate enough random bits that nobody has the processing power to try many of the possibilities. Those bits can be used as a seed to generate as many pseudo-random numbers as you want, provided your generator and your application do not leak information. So a small quantity of random bits can be useful.

    Another interesting method to generate random numbers is to use lava lamps [sgi.com].

  • 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.
  • You dont need radioactive decay to cause a truly random number. Just increase the dimension. hear me out:

    anyone remember QBASIC programs that were started with the RANDOMIZE TIMER statement. This means that the RNGenerator was based on the # of seconds past midnight, adding the element of timing to the equation.

    No cracker/hacker would EVER want to get into the element of time when trying to crack a random code.

    Maybe a good, secure compromise would be a radioactive decay that catalyzed a Time based RNGenerator.

  • Agreed, you need to be careful about the external signals affecting your bit stream -- what is usually suggested is:

    (a) don't collect your bits too quickly (to avoid correlations between bits);

    (b) collect 10-20 times as many bits as you need and hash them with something like MD5, which tweaks them all nicely.

    As a nuclear physicist I think the radioactive decay RNG is really cool, but when it comes to something to put in every computer, avalanche noise from a reverse-biased transistor is MUCH easier (and smaller and cheaper :v), and does a fine job. Heck, add a PIC controller that converts the data into a serial bitstream and you can connect a 'RNG box' onto any computer you want...

  • 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?
  • Of course not seconds, you could have nanoseconds. and the number of possibilities resulting would be PERFECTLY FINE for _catalyzing_ a radioactive process.

  • Tell me again why radioactive decay must be catalyzed by a timing device. Hint: it doesn't.
  • 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
  • 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.

    It's easy to imagine, but it's also wrong (have you been reading any creationist literature lately, or what?). Though maybe the measuring equipment can be affected.

Slashdot Top Deals

Cobol programmers are down in the dumps.

Close