Slashdot Mirror
More Random Randomness
jfleck writes "According to the American Institute of Physics' Physics News Update, Kent State physicist James Gleeson has developed a technique for generating numbers approaching true randomness. His trick is to shine light through a liquid crystal, taking advantage of its turbulence and avoiding the inevitable risk of predictability in deterministic random number number algorithms."
wouldnt avoiding predictability be a bit predictable?
So it's a crystal and a light...a mechanical solution, in other words. Someone tell me how this is different from flipping a coin? True randomness has always been available in the physical world (hence the allure of horse racing). It's only in mathematics, and therefore computing science, that randomness cannot be achieved. And small though this "solution" may be, it doesn't quite count as an algorithm.
Karma: Good (despite my invention of the Karma: sig)
I'm going to build a hardware random number generator which contains an actual coin. Sure, I/O waiting for the device to flip the coin is slow, but the numbers are truly random.
cpeterso
Didn't the Commodore have a 'true random number generator' that used white noise from the sound card?
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
Anonymous only to avoid "-1 Redundant", I seem to get those when people miss the joke.
...LAVARAND?
-- SIGFPE
Could this technology be used to moderate slashdot posts, in a manner even more astonishingly random than before?
I mean, it's obviously in use in story-submission already. May as well be efficient.
It's fairly easy to generate truly random numbers in small quantities, but getting a sizable quantity of cryptographically true, cryptographically secure, cryptographically random numbers has always been a bit difficult. You almost have to do it in hardware, and you almost have to use something which is both isolated from external interference (so others can't load your dice) and doesn't bleed its information externally (so you can be sure you are the only one who knows the number). The first requirement rules out most things which rely on the external environment for input (like EM radiation). Add to this a third requirement for lots of randomness, (which rules out things like thermal junctions, or number of NT bluescreens per day) and a simple problem becomes hard.
Remember, in this context the common definition of "random" meaning "I don't understand how it works" doesn't cut it. You need true "completely unpredictable by anyone" randomness for many security applications.
The thing about things we don't know is we often don't know we don't know them.
Didn't someone do a similar thing with a lava lamp and a webcam type setup a year ago?
the only problem is that most of your variables won't change in matters of seconds, so theoretically the same number would come up a lot of times in a very short period of time.
If you use a LOT of variables you approach a good version of randomness, but if someone knows the input data to your system (e.g. by taking separate measurements for themselves) and your algorithim, they can predict your number with 100% accuracy, which is bad in the crypto-security world.
This randomness is distinguishable from so-called "hidden variable" interpretations.
Not quite. There's a hidden flaw in the argument against hidden variables; the "proof" subtily begs the question. To see this, imagine that there were a level of "hidden variables" complex enough that each quanta (quark, lepton, what have you) could have as much "state" as the entire universe as-we-know it. With such a system you could predetermine every "interaction" over the course of the whole history of the universe--there wouldn't be any "physics," just a mind bendingly huge collection of scripted motions.
The point being, there's no way we could detect that this was the case...and thus there's know way we can prove that it isn't the case.
Now, we are free to doubt that we live in such a universe (and believe in "truly random events") but this is just a belief, without any science to back it up.
-- MarkusQ
Or ICMP, actually. Some time ago when I needed a relatively small amount (a megabyte or so) of random numbers I thought to check how random the time between sending and receiving a ICMP echo request was. Liking to tinker with this kind of things I wrote a quick-and-dirty program to collect the data.
Turned out that if the destination host was distant enough (at least a couple of hops) and only a few most insignificant bits of the number of microseconds elapsed between the request and reply was used, the method would yield a fairly random sequence of bits. In fact, I tested the randomness of the sequence with a couple different methods and got positive results from all of them.
Of course, the technique is completely impractical for generating any significant amount of random numbers, and there probably are ways to embed order into the results if you are part of the network used to relay the requests, but nonetheless I successfully used the sequence in a (one-time) commercial application.
The primary problem with this method is that it is implemented in hardware, which produces quite a few problems.
1) No known seed. One of the primary characteristics of a good random number generator is that the results are reproduceable. If I want to run the same experiment twice during some sort of simulation, I need to be able to generate the same stream of random numbers twice. Second it is always useful to have a random number generator with a [very large] full period, this obviously is not periodic, which makes it hard to determine if the system which is using the variate generation is chaotic or stable.
2) Hardware random number generators are often difficult to port to all systems, and to interface with existing programming languages. A good solid pseudo-random number generator (like a Lehmer one) is based on a mathematical algorithm which is reproducable in just about any environment.
There are many other problems with this approach as well, too numerous to name. In general hardware random number generators are a bad idea.
Random.org
They generate random numbers based on hardware, using the decay of radioactive elements.
Yeah, still hardware, but you're never going to get truly random in software. Something has to put in a bit of chaos into the system that you just don't get in a computer. Otherwise they'd just crash all the time.....wait a minute! Windows must have some super-secret random number technology!
There's a major difference between a sequence of pseudo-random numbers (as you describe) and a sequence true random numbers (leaving aside completely any proper definition of what is random).
Simply enough, it is what they are used for - in many computer applications (simulation, pysol, and the like) pseudo-random numbers are great - given the same seed they're reproducable, they have the right statistical properties - but they may be very predictable, - in cryptography building a perfect one time pad requires true randomness - and a pseudo random number sequence is not even close to working.
Random numbers are actually a very tough subject, with odd and wonderful oddnesses and wonderfulnesses. Start with Knuth (Chapter 3) (a reasonable introduction to pseudo-random numbers and go on from there (there's easily a lifetime or three of stuff on the topic).
"Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin." John Von Neumann
The problem with this is that if you have an idea of the algorithm used you can run through a subset of numbers and then find your seed value.
e.g. if I know your app is pulling from time of day and my log entries show that it was at 9:55 AM Then I can run a range of all time values between say 9:50 and 10:00 including MS. In so doing you are tying your random number to a known thing which defeats the purpose.
A truly random number would be one that can't be determined by outside factors ( especially time )
Randomness is a very complex subject with lots of odd facets. The article cited at the top of this topic may be a good way to generate more or less "true" random sequences (17 is, of course, the Only Random Number).
Random sequences based on quantum (or similar effects) are useful primarily in cryptography where "true" randomness is important. Probably in video gambling devices as well (is there any good way to tell how they generate randomness).
Random sequences based on deterministic generators are useful for lots of other things: simulation, pysol (including freecell), and a number of algorithms. These are not useless by any means and while they need to satisfy some fairly stringent statistical properties, they can be generated by well defined algorithms starting with seeds which may be reused.
Randomness, its uses, implications, theory and even philosophy is a massive subject - probably more than a single lifetime's worth.
In fact, its hard to even describe what randomness actually is and how you can tell is something is random.
For starters try Knuth Chapter 3, go on to Greg Chaitin's work, and cryptography. Then continue with the appropriate bits and pieces of quantum physics and then go back and fill in all the holes. (Don't neglect using cryptographic algorithms to generate random numbers - as well as their uses the other way around, the digits of Pi, the Riemann Zeta function and, well, a lot else) You'll have lots of fun and push your brain quite a bit.
When there's no natural source of light? Or does this work on non-natural sources. These might be a bit more predicable.
No dark labs for THESE randomizing circuits - phorm
You probably have a TRNG right on your desktop. Intel has incorporated a true hardware random number generator (TRNG) in Pentium III and Celeron chips. It's based on the quantum-mechanically random Johnson noise across an undriven resistor. Two resistors are used to eliminate any external effects. Here's a good explanation from Cryptography Research, Inc.: ftp://download.intel.com/design/security/rng/CRIwp .pdf
Here's Intel's TRNG page:
http://www.intel.com/design/security/rng/rnghow.ht m
RSA believes in it:
ftp://download.intel.com/design/security/rng/RSA_B SAFE.pdf
Of course we could just get a butterfly to flap it's wings a couple of times inside the computer. That oughta do it. :)