Real Random Numbers
Hi Folks,
I have been assigned a task to generate series of random numbers which should be real in nature. For those who are not aware of this concept, I would like to explain that real numbers are basically of two types: (1)pseudo random numbers, and (2)real random numbers.
Real random numbers are ones which have their seed generated through some random event which ensures that all numbers generated in series MUST be unique, i.e. real in nature. While, pseudo RN are ones which have fixed seed to be generated every time.
Purpose of RRN in my assignment is generate numbers for prepaid scratch cards for some stock trading application. This application has some very crucial security implications which need to be done in initial phase.
I have written a very basic demo application to do so. It picks up clock ticks and generate numbers. So far so good, but I am not been able to generate every number as unique. Major problem is that the series i am generating, which has 19 digits, are not totally unique. I mean, starting 7 digits of every number is same and rest are different.
My client is saying that upon analyzing through some intelligent mechanism, a correlation can be found among large set of such random nos and through that correlation, system can be hacked. This is a very crucial security requirment and needs to be done in such a way that they will generate 100,000 nos every month for circulation of scratch cards.
Can anyone of you have some idea how to do this? Real random number is a very interesting domain for me as of now. Lets do some brain storming in it.
Good day.
[1661 byte] By [
rak78a] at [2007-11-26 17:35:12]
# 1
Google [ [url= http://www.google.com/search?q=true+random+number+generator]true random number generator[/url] ].
# 2
> Real random numbers are ones which have their seed
> generated through some random event which ensures
> that all numbers generated in series MUST be unique,
> i.e. real in nature.
Not true! Given a source of 'real' random number that are uniformly distributed between 0 and N-1 and that are independent then by definition all numbers drawn from this distribution cannot be unique. If you draw N+1 samples then you must get two the same.
The 'birthday paradox' indicates that there is an even chance of getting two or more samples the same after drawing approximately sqrt(N) samples.
> While, pseudo RN are ones which
> have fixed seed to be generated every time.
Not true! The java.util.Random random number generator is a pseudo random number generator based on the Congruence method and using it's default constructor it is seeded differently every time using the current time. Obviously if one constructs two within the same clock resolution one will get the same seed but in general this does not happen.
The default Java SecureRandom is a pseudo random number generator that is seeded at random but it is still a pseudo random number generator.
I think you need to formally specify the distribution you need for your generator because at the moment you seem confused.
# 3
> Obviously if one constructs two within the same clock
> resolution one will get the same seed but in general
> this does not happen.
Since Java 5 the default constructor uses both the current time and a static counter to initialize the seed. So even if you construct two objects during the same clock cycle their seeds will (most likely) be different.
# 4
> > Obviously if one constructs two within the same
> clock
> > resolution one will get the same seed but in
> general
> > this does not happen.
>
> Since Java 5 the default constructor uses both the
> current time and a static counter to initialize the
> seed. So even if you construct two objects during the
> same clock cycle their seeds will (most likely) be
> different.
:-) I learn something new every day!
# 5
Is it possible if we try to take input from cpu usage and virtual memory to generate seed for random nos?
# 6
> Is it possible if we try to take input from cpu usage
> and virtual memory to generate seed for random nos?
Sure that's possible. But Java isn't the best pick then: you'll need C/C++ (or some other language to call "native" functions) to read memory/CPU usage. This cannot be done in (pure) Java.
Do hold in mind the classic quote from mr Von Neumann: "any one who considers arithmetical methods of producing random digits is, of course, in a state of sin".
# 7
> Is it possible if we try to take input from cpu usage
> and virtual memory to generate seed for random nos?
Sure, but the resultant random number are still pseudo random number. You seem to be trying to duplicate the functionality of class SecureRandom.
If you want real random number then you will probably have to use a hardware random number generator.
# 8
You have not yet replied to some of the earlier requests/suggestions that you revise your specifications to some that are not contradictory.
You have stated an interest in "Real" vs "Psuedo" random numbers. The prefered way to get real random numbers is to introduce some external physical process, like a radioactive source and a counter, or a lava lamp with a video camera, or some kind of flakey diode that you read. That is a random source and it isn't psuedo.
Anything that you do inside of the computer via computation is almost by definition psuedo. Asking questions about reading memory to find the "seed" is all about psuedo. Real random number generators ain't got no seed.
Also you stated that you require uniqueness. As others pointed out, random numbers - regardelss of whether they are real or psuedo - repeat themselves. A die that when you roll it generates first 2 then 3 then 4 then 1 then 6 then 5 is anything but random. By definition a random process has no memory of what it did in the past and can thus do it again.
If you actually want uniqueness then what you are talking about in NOT random, neither real nor psuedo, it is a shuffle and in order to obtain it, you need a mechanism that will provide the function of the history. With a deck of cards the deck itself is the history. A psuedo random number keeps its history by deterministically generating the next number from the previous number thus determining a single unique path through a set of integers.
I will assume from you question about a seed that you are not really interested in "real" random number generators. I think that I can give you a system that is not too complicated that will generate a sequence of 19 digit long number that will not have any repetition (untill you actually generate 10^19 of them) with the additional feature that they will also not be the output of a LCM psuedo random number generator and thus will not be subject to the simple LCM attack.
Read the thread http://forum.java.sun.com/thread.jspa?forumID=426&threadID=765851 which has code for a simple 16 decimal digit LCM and make the obvious modifications to pump it up to 19 digits. Also modify the code so that you can pass in bigInts rather than just regular ints.
Build two of them using different multipliers. You now have rand1 and rand2. Think of them NOT as random number generators but as look up tables. Given a single 19 digit number as input, rand1 will convert that 19 digit number deterministically into another one. By its construction this is a one to one map, different inputs will always generate different outputs. rand2 does the same thing.
Now to generate your first 100,000 numbers in month one, feed the numbers 1 to 100,000 first into rand1 and then into rand 2. ie.
for(int i = 0; i<1000000; i++){publish(rand2(rand1(i))};
In the next month stuff in the numbers from 100,000 to 200,000 and so on.
What you are doing is this, you are handing the used the output from rand2 but you are shuffling the order in which you return the values from rand2 to an order chosen by rand1.
And of course, if you want to be extra paranoid, you don't need to have only 2 LCMRNGs in the chain (but be sure that they are all maximal period or else you will not get the uniqueness)
This trick of shuffling the output of one random number generator with a different random number generator is also discussed in Knuth, the undisputed authority on all things LCM.
Your concerns about how you choose the seed are not well placed. A truely gnarly method for choice of seed does not enhance the system at all. Your security comes from your selection of how many of these things you chain together and what numbers you used to construct them.
Also, for the record, your concerns or your bosses concerns about the "crackability" of a psuedo random number generator are probably also groundless. It is true that a simple LCM is NOT a good choice for encryption because it can be cracked, but that comment needs to be understood in its proper context which is HOW you go about cracking an LCM.
IF you are given a sequence from an LCM where you know that n1 was followed by n2 which was followed by n3 ... you can set up a system of equations because you know that n2 = a*n1 + c mod m.
The cracking REQUIRES that you know the sequence. If you just hand someone n1, n2 and n3, and a hundred thousand other such number WITH NO INDICATION OF THEIR SEQUENCE, you have robbed them of the sequential information that is used in decoding an LCM.
Nothing in what you said indicated that you will ever hand out all your little numbers in any kind of order. While an attacker may be able to collect a bunch of the numbers that you produced in a month, if they are unable to recreate the sequence in which those numbers were produced it is unlikely that they can reconstruct your LCM constants.
LCMs are unsuitable for encryption where they will be used sequentially one byte after the next in a message for thousands of bytes. That doesn't mean that they are unsuitable for some other application where sequence is not revealed.
Enjoy
# 9
>
> If you want real random number then you will probably
> have to use a hardware random number generator.
What does that mean? Are you saying that there is NO way one can generate true random numbers through **** piece of code!!
Come on, I can't believe that. There must be some way or this idea is rubbish to find some hardware to generate 100,000 nos every month. It doesn't sound realistic, isn't it?
During the course of researching this topic, I have heard of monte carlo method to generate such random nos. Can any shed some light over it? It would be helpful if someone point out some useful resource on it.
# 10
> What does that mean? Are you saying that there is NO
> way one can generate true random numbers through ****
> piece of code!!
That is correct. Peolpe who think or say otherwise are, like Von Neumann said: "in a state of sin".
> Come on, I can't believe that. There must be some way
> or this idea is rubbish to find some hardware to
> generate 100,000 nos every month. It doesn't sound
> realistic, isn't it?
http://en.wikipedia.org/wiki/Hardware_random_number_generator
# 11
Marlin314, Excellent exaplanation of the topic. Thanks.
However, still there are some things that i need to clarify from you.
>Also modify the code so that you can pass in bigInts rather than just regular ints.
Why you want this? I mean, i saw your code and I found it pretty straight to pass simple integers. Any specific reasons?
> (but be sure that they are all maximal period or else you will not get the uniqueness)
This might be the stupid question, but i need to understand "maximal period". (I think i need to acquire my copy of Dr. Knuth's book)
>In the next month stuff in the numbers from 100,000 to 200,000 and so on.
Shouldn't we start with 100001 for next month? I can see that the initial value is again same for the next month and it might close the possibility of any one number to be non-unique.
Thanks once again.
# 12
> During the course of researching this topic, I have
> heard of monte carlo method to generate such random
> nos. Can any shed some light over it?
Monte Carlo is a method to generate predictions for a system's state through simulations which use random numbers - rather than being a method to generate random numbers. It doesn't necessarily (or even preferrably) use true random number generators.
> It would be
> helpful if someone point out some useful resource on
> it.
Google should find them easily for you.
Lokoa at 2007-7-9 0:03:13 >
# 13
The code I supplied in the other thread could get away with integer input because there was only one stage. If you use two stages, the output of the first RGN which is a 19 digit number is fed into the second RGN. This means that you need to allow inputs that are 19 digits long so that means eaither BigInts or Strings or something like that.
Yes, the number range that you choose in the second month must not overlap anything in the first month or you get duplicates. All you are doing is deterministicly transforming each integer that you feed in. Whatever 19 digit number you got when you first stuffed in the value 3 you will get exactly that same number whenever you stuff in the value 3.
The maximal period means that every single possible 19 digit long number shows up on the list. This means that every different input yields a different output. If you have a multi stage device and if any one stage in the chain is NOT of maximal period than the result of the stages will not be maximal period.
It is easy to understand maximal period if you look at an example that is NOT maximal. Suppose for your multiplier preA you have the value 2 and for your additive constant preC you have the value 4. These are bad choices. Why because I selected them so that whatever number you stuffed in originally the result is always even. Clearly not every number is covered. Every possible 19 digit long input does get transformed to yet another 19 digit long output but because I don't get them all it means that some pair of inputs gave me identical outputs.
If If you build a multi stage map, as long as each stage covers the entire range of 10^19 that the entire system covers that range. If any single stage reduced that range, like by only giving even outputs, then even if latter stages obscure that and generate out output, you still have reduced yourself to a system that can NOT generate the entire range of 10^19 and if you can't generate the entire range, the fact that you can have 10^19 possible input values and less that that as output values, means that the system must be able to produce duplicates.
This is why you want maximal period maps and that is why you follow the rules listed in the other thread when you build your random number generators. It is the maximal period that prevents duplicates.
If you do implement this system as I suggest, I also strongly suggest that you reduce everything down to something much smaller. Reduce the generators to being only 4 digits in length. Generate blocks of numbers and look at whether the results behave the way that you want them to. Get some confidence that it is doing the right thing before you crank it up to numbers so large that it becomes highly unlikely that you will notice a defect.
This is just prudence, for all you know, I am the guy that is intending to crack your system once you get it up and I just handed you the trojan horse. Or even worse I am a totally honest guy and I just made a simple mistake like copying one of Knuth's rules incorrectly.
Lastly, Von Neuman was right. psuedo is psuedo. It is easy to fall into the trap of thinking that if you just did something really clever it would actually be random. Your computer is deterministic, your algorithm is deterministic and deterministic is not random it is at best psuedo random.
However, it should be clear that it is also entirely possible to delude your self that some real world system is random when it is in fact not. Hook up a counter to a radioactive source. Read it. It is pretty random IF you read it at a rate that is much slower than the time it takes the counter to overflow and reset. If you read it at a much faster rate than the rate at which you expect decay, you could read hundreds of values that are all the same number, and then it goes up by one (at some random time) . This is not a random stream of numbers.
It should be understood that Von Neuman's comment was not an injunction against psuedo random number generators, rather his comment was an injunction against feeling smug about your design.
Go forth and live in sin. It's really not that bad. :)
# 14
> You have stated an interest in "Real" vs "Psuedo"
> random numbers. The prefered way to get real random
> numbers is to introduce some external physical
> process, like a radioactive source and a counter, or
> a lava lamp with a video camera, or some kind of
> flakey diode that you read. That is a random source
> and it isn't psuedo.
A lava lamp seems like a pretty crappy random number generator. The guy next to me has one and it hardly ever does anything. Mostly has a few main globs that are basically in the same place every time I look at it.
One way I was just thinking to build a random number generator would be to replicate the double slit experiment with a detector on one slit and shoot photos at it one at a time. The photon would go always travel through one or the other, never both and should have a complete even distrubution. This could be streamed as on/off signals.
# 15
> My client is saying that upon analyzing through some
> intelligent mechanism, a correlation can be found
> among large set of such random nos and through that
> correlation, system can be hacked. This is a very
> crucial security requirment and needs to be done in
> such a way that they will generate 100,000 nos every
> month for circulation of scratch cards.
My understanding (which may be flawed) is that by definition cryptographically strong random number generator is not susceptible to such attacks (assuming that technology does not take a giant leap ahead.)
The SecureRandom class is purported to be cryptographically secure. Even if the seed were determined one month, it's not going to tell them the numbers for the next month as long as you don't have the generator execute on a timer. Make it something that a person must activate. Hell, give them a yatzee cup and make them enter in a number from the dice each time.
I would caution against using things like CPU usage or human input. This kind of thing might make it easier to crack, not harder.
# 16
> A lava lamp seems like a pretty crappy random number
> generator.
It was very hip in its day. As you can see these folks thought it was so hip they used the name and now must spend time explaining how what they are doing does not actually use lava lamps like the original one and only lava lamp RNG did.
http://www.lavarnd.org/what/index.html
Never used it, never read the original article, just heard about it and passed it on.
# 17
Crypto RNGs basically do the following. You generate random numbers using nearly any wretched method that you want and then you encrypt them.
To use the random numbers, you do NOT decrypt, instead you just use the encrypted stream.
The theory is that if your crypto is any good at all, it smears all the data bits randomly and unpredictabley among all the encrypted bits and thus the encrypted output looks just like a random stream. In fact, if your crypto is any good at all, any input whatsoever looks like a random stream once it has been encrypted.
What cryptographically strong random number generation does not address is the issue of uniqueness. Unless your crypto just happens to work in blocks of 19 decimal digits, you will get repetitions in your stream of random numbers, just as you should for any random number generator.
Everything I suggested was predicated on the assumption that the OP did NOT in fact want random numbers, but rather wants to generate unique certificates (not probably unique but actually unique) with a low probability that anyone can generate an honest certificate either by chance or by examining existing certificates.
Of course, the OP has yet to weigh in on which of his conflicting requirements he actually cares about.
# 18
> > A lava lamp seems like a pretty crappy random
> number
> > generator.
>
> It was very hip in its day.
I know. It strikes me as one of those moments that define the dot-com era. I guess it supposedly works but just because something seems really random (like a lava-lamp) doesn't mean it actually is. Also chaotic systems are not random there seemed to be some confusion there with that. Our solar system is a chaotic system but I can tell you it's probably going to be warm here in July.
> As you can see these
> folks thought it was so hip they used the name and
> now must spend time explaining how what they are
> doing does not actually use lava lamps like the
> original one and only lava lamp RNG did.
>
> http://www.lavarnd.org/what/index.html
It appears they actually use a similar methodology as the original. They just don't use a lava-lamp.
> Never used it, never read the original article, just
> heard about it and passed it on.
I didn't mean to imply that you were advocating it or anything. You were just the second person to mention this and I felt the need to spout off about it.
# 19
Some OS kernels provide random stuff:
http://www.die.net/doc/linux/man/man4/random.4.html
The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. The generator also keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created.
When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.
A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.
# 20
> > Obviously if one constructs two within the same
> clock
> > resolution one will get the same seed but in
> general
> > this does not happen.
>
> Since Java 5 the default constructor uses both the
> current time and a static counter to initialize the
> seed. So even if you construct two objects during the
> same clock cycle their seeds will (most likely) be
> different.
Not necessarilly. If the two are created from different classloaders (or indeed different JVMs) you can still get the same sequence.
# 21
> > You have stated an interest in "Real" vs "Psuedo"
> > random numbers. The prefered way to get real
> random
> > numbers is to introduce some external physical
> > process, like a radioactive source and a counter,
> or
> > a lava lamp with a video camera, or some kind of
> > flakey diode that you read. That is a random
> source
> > and it isn't psuedo.
>
> A lava lamp seems like a pretty crappy random number
> generator. The guy next to me has one and it hardly
> ever does anything. Mostly has a few main globs that
> are basically in the same place every time I look at
> it.
>
That is in fact random behaviour. Given an infinite number of identically constructed (not taking construction defects into account) lava lamps there can very well be a finite number among them displaying the behaviour you describe.
An infinite number though will display other behaviour.
> One way I was just thinking to build a random number
> generator would be to replicate the double slit
> experiment with a detector on one slit and shoot
> photos at it one at a time. The photon would go
> always travel through one or the other, never both
> and should have a complete even distrubution. This
> could be streamed as on/off signals.
quantum mechanics dictates that the photon may travel through both slits, or through neither :)
It might even reach the detectors without ever passing through the slit.
# 22
> > > You have stated an interest in "Real" vs
> "Psuedo"
> > > random numbers. The prefered way to get real
> > random
> > > numbers is to introduce some external physical
> > > process, like a radioactive source and a
> counter,
> > or
> > > a lava lamp with a video camera, or some kind of
> > > flakey diode that you read. That is a random
> > source
> > > and it isn't psuedo.
> >
> > A lava lamp seems like a pretty crappy random
> number
> > generator. The guy next to me has one and it
> hardly
> > ever does anything. Mostly has a few main globs
> that
> > are basically in the same place every time I look
> at
> > it.
> >
>
> That is in fact random behaviour. Given an infinite
> number of identically constructed (not taking
> construction defects into account) lava lamps there
> can very well be a finite number among them
> displaying the behaviour you describe.
> An infinite number though will display other
> behaviour.
So getting the same number every time one thousand or a million times in a row is your idea of random behavior.
> > One way I was just thinking to build a random
> number
> > generator would be to replicate the double slit
> > experiment with a detector on one slit and shoot
> > photos at it one at a time. The photon would go
> > always travel through one or the other, never both
> > and should have a complete even distrubution.
> This
> could be streamed as on/off signals.
>
> quantum mechanics dictates that the photon may travel
> through both slits, or through neither :)
> It might even reach the detectors without ever
> passing through the slit.
Not if there is a detector on one of the slits. This is a really crucial aspect of the two-slit experiment but is often ignored in popular literature. The interference pattern no longer appears when a detector is placed on one of the slits. This is a result of decoherence.
# 23
> > > > You have stated an interest in "Real" vs
> > "Psuedo"
> > > > random numbers. The prefered way to get real
> > > random
> > > > numbers is to introduce some external physical
> > > > process, like a radioactive source and a
> > counter,
> > > or
> > > > a lava lamp with a video camera, or some kind
> of
> > > > flakey diode that you read. That is a random
> > > source
> > > > and it isn't psuedo.
> > >
> > > A lava lamp seems like a pretty crappy random
> > number
> > > generator. The guy next to me has one and it
> > hardly
> > > ever does anything. Mostly has a few main globs
> > that
> > > are basically in the same place every time I
> look
> > at
> > > it.
> > >
> >
> > That is in fact random behaviour. Given an
> infinite
> > number of identically constructed (not taking
> > construction defects into account) lava lamps
> there
> > can very well be a finite number among them
> > displaying the behaviour you describe.
> > An infinite number though will display other
> > behaviour.
>
> So getting the same number every time one thousand or
> a million times in a row is your idea of random
> behavior.
>
The chance of it happening is quite small (unless the range from which the number is selected at random is very small, like 1), but not zero.
I'd seriously question the validity of the algorithm if it were to happen, but I'd realise that it COULD in theory happen.
> > > One way I was just thinking to build a random
> > number
> > > generator would be to replicate the double slit
> > > experiment with a detector on one slit and shoot
> > > photos at it one at a time. The photon would go
> > > always travel through one or the other, never
> both
> > > and should have a complete even distrubution.
> > This
> > could be streamed as on/off signals.
> >
> > quantum mechanics dictates that the photon may
> travel
> > through both slits, or through neither :)
> > It might even reach the detectors without ever
> > passing through the slit.
>
> Not if there is a detector on one of the slits. This
> is a really crucial aspect of the two-slit experiment
> but is often ignored in popular literature. The
> interference pattern no longer appears when a
> detector is placed on one of the slits. This is a
> result of decoherence.
Well known principle in quantum physics, the very act of observation changes that which is being observed.
Schreudinger's cat, Heisenberg's uncertainty principle.
# 24
> The chance of it happening is quite small (unless the
> range from which the number is selected at random is
> very small, like 1), but not zero.
> I'd seriously question the validity of the algorithm
> if it were to happen, but I'd realise that it COULD
> in theory happen.
If the lava lamp hardly moves, you can pretty much guarantee that it will produce predictable results. How is that an effective random number generator?
> Well known principle in quantum physics, the very act
> of observation changes that which is being observed.
> Schreudinger's cat,
The principle is well know and mostly misunderstood. The fact is that cats can never really be in the superposition of being dead and alive and that the Schrdinger's cat thought experiment is vastly less interesting that it is made out to be.
> Heisenberg's uncertainty
> principle.
That's not really relevant. The crucial phenomenon here is decoherence:
http://en.wikipedia.org/wiki/Quantum_decoherence
# 25
> > The chance of it happening is quite small (unless
> the
> > range from which the number is selected at random
> is
> > very small, like 1), but not zero.
> > I'd seriously question the validity of the
> algorithm
> > if it were to happen, but I'd realise that it
> COULD
> > in theory happen.
>
> If the lava lamp hardly moves, you can pretty much
> guarantee that it will produce predictable results.
> How is that an effective random number generator?
>
ah, but it HARDLY moves. The movement there is is likely to be brownian, pretty random.
Whether you will be able to detect that movement reliably enough to make it useful as a random number generator depends on your detection system, not the lamp :)
> > Well known principle in quantum physics, the very
> act
> > of observation changes that which is being
> observed.
> > Schreudinger's cat,
>
> The principle is well know and mostly misunderstood.
> The fact is that cats can never really be in the
> superposition of being dead and alive and that the
> Schrdinger's cat thought experiment is vastly less
> interesting that it is made out to be.
>
> > Heisenberg's uncertainty
> > principle.
>
> That's not really relevant. The crucial phenomenon
> here is decoherence:
>
> http://en.wikipedia.org/wiki/Quantum_decoherence
both show that observation changes that which is being observed, which is all I was trying to get across.
No cats were unnecessarilly hurt in the execution of this experiment.
# 26
> ah, but it HARDLY moves. The movement there is is
> likely to be brownian, pretty random.
> Whether you will be able to detect that movement
> reliably enough to make it useful as a random number
> generator depends on your detection system, not the
> lamp :)
If that is the case, the lava lamp isn't providing anything special. Which is exactly my point. The lava lamp is an unecessary complexity that smacks of dot-com era foolishness. The patented and marketed form doesn't use a lava lamp. But it's clear the original experiements were meant to tap into the chaotic nature of lava lamps. The fact that 'chaotic' doesn't imply 'random' was apparently not understood. Instead of tapping into quantum randomness they decided to shine light through a piece of kitsch. I guess it was the best idea that could be had over a foosball table.
# 27
pretty funky idea though, and if it sells that's good enough ;)
# 28
kernel random number source devices http://www.die.net/doc/linux/man/man4/random.4.html
# 29
> kernel random number source devices
>
> http://www.die.net/doc/linux/man/man4/random.4.html
The problem with this is the relatively small number of true random sources. A machine with no harddrive or user basically has none.
http://www.pinkas.net/PAPERS/gpr06.pdf
