I need to generate random numbers for a lottery game,
the lottery front-end will work in flash AS3 the idea is to run a script that generates 10 random numbers (the winners) and save them in a SQL database
What's a reliable way to create random numbers?
Is js Math.rand() function reliable enough for a lottery?
On wikipedia I found Fortuna a "cryptographically secure pseudorandom number generator" that is inclucded in the Javascript Crypto Library.
Another option is the web site http://www.random.org, it offers a free API to provide random numbers, but what guaranties can it offer?
The javascript Math.rand() is unlikely to be good enough for a lottery, as the specification does not require it to be cryptographically secure. For instance, there are known weaknesses in the generator used in some versions of Chrome.
What you would need would be a cryptographically secure pseudo random number generator (such as blum-blum-shub), and a way of seeding it. You need a good way of seeding it because if anyone can figure out what seed you used, they will be able to generate all the lottery numbers. You would probably want to seed the pseudo-random generator with a genuinely random, rather than a pesudo random number. This would require a hardware random number generator. Random.org supposedly provides a source of genuinely random numbers, however if anyone were to eavesdrop on your connection to random.org, they could still discover your random seed. You might prefer to invest in your own hardware, rather than rely on someone external.
Infact, unless you needed an awful lot of random numbers (much more than 10) there would be little point in using any pseudo random number generator at all. You might as well get all your random numbers from a true, hadware, random number generator.
It seems that random.org is basing its numbers off of static noise, which is pretty random, well more random than the javascript random library, which is probably basing its randomness on some time algorithm.
If the lottery involves money (purchasing 'tickets' and paying prizes) then you may need to be able to demonstrate that you are using 'real' random numbers. In that case you might want to invest in your own hardware for generating random numbers. A quick search reveals a few, for example this one.
Otherwise, either of the two pseudorandom sources would seem adequate to me.
Related
I want to design a lottery winning mechanism using random number generator. I know that for computer, there is no true randomness but only "pseudorandom". If the system gets hacked and random seed is seen, people will know the sequence of random numbers. In fact, there is news that people did this and won several lotteries. I am thinking about two ways of designing my system:
Use random number generator as a global variable. There is only one
random seed; the sequence is generated when the system starts.
Con:
a. Once the random seed is seen, hackers will know the sequence
easily.
b. Once the system crashes and restarts, the sequence will repeat
itself.
Create a random number generator using timestamp as random seed each
time to generate a number.
Con:
a. Obviously timestamp cannot be directly used. There are some
tricks needed to be done with the timestamp each time. For example,
plus or minus some values each time on the timestamp. What algorithm can I use here to do this kind of modification on timestamp?
b. Is this method even taking advantage of random number generator?
It seems I am just creating a random number by myself...
As we can see, either of the method above is not secure enough. Which way is slightly better? Or is there a better way?
The notion that computers are incapable of truly random numbers hasn't been true for decades. All modern desktop and laptop computers have true hardware-based random number generators. Even most small embedded systems do as well.
That said, it may be the case that your programming language hasn't caught up to the recent hardware, or that even if it has, it's easy to make a mistake with RNGs and get a bad result from a good generator. So it's probably a good idea to use something like random.org unless you know what you're doing.
I am in the process of building a brute force applicaiton however when thinking about encoding, there are codes online that use the word "random" however are they actually totally random numbers generated by the computer. I say this because the way havent been taught about how computers work, goes against this word "random"
Am I correct in thinking there is no "random" in computers? or have I misunderstood.
Various platforms provide a pseudo random number generator, which is:
an algorithm for generating a sequence of numbers whose properties approximate the properties of sequences of random numbers.
A lot's already been written here and on other sites why generating a truly random sequence of numbers is hard for machines, see for example Is /dev/random considered truly random?, How can I generate truly (not pseudo) random numbers with C#? and so on.
From Can a computer generate a truly random number? | MIT School of Engineering:
“One thing that traditional computer systems aren’t good at is coin flipping” [...]
There are devices that generate numbers that claim to be truly random. They rely on unpredictable processes like thermal or atmospheric noise rather than human-defined patterns.
In programming we often use term 'psuedorandom' because any random number which can be generated by program is based on some logic. Program cannot generate number on its own without any logic.
So by that logic humans cant generate random numbers either......
It all depends on how you want to argue. If you want to argue for the sake of arguing of coarse they cant. But if you want to just say can we 100% accurately guess the next number they will choose. We cant...thus its random
I have been reading various articles about random numbers and their generators. There are usually 3 important conclusions that I draw from them:
Random numbers are not truly random
Much of the time they have a bias (modulo bias)
Humans are incapable of being random number generators, when they are trying to "act randomly"
So, with the latter-most of these observations in mind, how would we be able to
Tell if a sequence of numbers that we see is truly random, and more importantly
Is there some way we can prove that said sequence is really random?
I'm tempted to say that so long as you generate a sufficiently large enough sample set 1,000,000+, you should see more or less a uniform dispersion of (pseudo)random numbers occur. However, I'm sure some Maths genius has a way of discrediting this, because surely the by laws of probability you could get a run of one number just as likely as any other sequence.
From what I have read, if you really need random numbers its best to try and reuse what cryptographic libraries use. The field of Cryptography is obviously complex and relies on random numbers for key generation. From the section in OWASP's guide titled "Reversible Authentication Tokens" it says this...
The only way to generate secure authentication tokens is to ensure
there is no way to predict their sequence. In other words: true random
numbers.
It could be argued that computers can not generate true random
numbers, but using new techniques such as reading mouse movements and
key strokes to improve entropy has significantly increased the
randomness of random number generators. It is critical that you do not
try to implement this on your own; use of existing, proven
implementations is highly desirable.
Most operating systems include functions to generate random numbers
that can be called from almost any programming language.
My take is that unless you're coding Cryptographic libraries yourself, put trust in those that are (e.g. use Java Cryptography Extension) so you don't have to proove it yourself.
Pretty Simple Test:
If you really want to get into testing random numbers, you could simulate a program that outputs random numbers from 1-100 100 times as an example.
Then look at those numbers and see if there's any patterns. Then follow that test by restarting the program several times and repeating the process.
Examine all data to figure out if random numbers are always random, just random during individual tests, or never. :P
Testing a random number generator is probably mostly up to what you want to look for. Even pure non-repeatability is no guarantee of randomness.
There are some companies that will test a random number generator for the purposes of certification (e.g. online casinos). One that I found quickly is called iTech Labs, though their testing methodology page leaves a lot to be desired in terms of technical detail.
Other testers and certification bodies publish the required data for a certification; there's more specific detail here but not as much as you want.
You could potentially do a statistical analysis and compare the results of your random number generator to a "true" random source but the argument could be made for bias from trying to translate the true random source into your possibility space anyway.
Randomness tests verify the mathematical properties of the sequence. For example entry frequencies (all symbols are expected to have the same frequency), local variance, sequence analysis (the probability of a symbol must not depend on the previous ones).
A definite proof does not exist, but there is a quality factor - the probability of a sequence to really be random.
Another criterion could be based on compressibility: true randomness has maximum entropy and can not therefore be compressed.
This test is not reliable for randomness, of course, but allows quick and dirty testing with ready tools such as zlib.
From what I understand PRNG uses a seed that generates a sequence of numbers that is not truly random. Would it be possible to create a truly random number generator by reusing PRNG over and over with different seeds each time it is used. The seed could be extracted from dev/random or the current time or clock tick. If not then is there a truly random number generator implemented in software?
Thanks
If you re-seed the PRNG every time you need a random number you can just cut out the middle man and use the seed directly as random number.
But what you're talking about is done in practice. Those are so-called cryptographically-secure PRNGs and they are employed in many operating systems to provide random numbers for cryptographic applications. They get re-seeded frequently from the entropy pool and are designed so that it is computationally very hard to figure out the next number from knowing past ones (something that's very trivial to do for an LCG, for example) and also to figure out past numbers from the current one.
The benefot of this approach is that you don't block generating random numbers. Entropy in a system is a limited resource and can only come from outside sources, so by using a CSPRNG you can safely stretch it and not compromise security at the same time.
The simple answer is that there is no such implementation because, as far as I know, it's simply not possible. To generate truly random numbers you need an outside source of entropy like a hardware random number generator.
The clock is not very random, but /dev/random has some randomness - it's actually like a bucket of randomness that you can deplete depending on the rate of randomness production and consumption. If you use dev/random, then you don't have use an RNG. Seeding an RNG from /dev/random is redundant.
Intel is working on something that could be truly groundbreaking if it works as advertised. It would practically render hardware PRNGs redundant.
Is there a difference between generating multiple numbers using a single random number generator (RNG) versus generating one number per generator and discarding it? Do both implementations generate numbers which are equally random? Is there a difference between the normal RNGs and the secure RNGs for this?
I have a web application that is supposed to generate a list of random numbers on behalf of clients. That is, the numbers should appear to be random from each client's point of view. Does this mean I need retain a separate random RNG per client session? Or can I share a single RNG across all sessions? Or can I create and discard a RNG on a per-request basis?
UPDATE: This question is related to Is a subset of a random sequence also random?
A random number generator has a state -- that's actually a necessary feature. The next "random" number is a function of the previous number and the seed/state. The purists call them pseudo-random number generators. The numbers will pass statistical tests for randomness, but aren't -- actually -- random.
The sequence of random values is finite and does repeat.
Think of a random number generator as shuffling a collection of numbers and then dealing them out in a random order. The seed is used to "shuffle" the numbers. Once the seed is set, the sequence of numbers is fixed and very hard to predict. Some seeds will repeat sooner than others.
Most generators have period that is long enough that no one will notice it repeating. A 48-bit random number generator will produce several hundred billion random numbers before it repeats -- with (AFAIK) any 32-bit seed value.
A generator will only generate random-like values when you give it a single seed and let it spew values. If you change seeds, then numbers generated with the new seed value may not appear random when compared with values generated by the previous seed -- all bets are off when you change seeds. So don't.
A sound approach is to have one generator and "deal" the numbers around to your various clients. Don't mess with creating and discarding generators. Don't mess with changing seeds.
Above all, never try to write your own random number generator. The built-in generators in most language libraries are really good. Especially modern ones that use more than 32 bits.
Some Linux distros have a /dev/random and /dev/urandom device. You can read these once to seed your application's random number generator. These have more-or-less random values, but they work by "gathering noise" from random system events. Use them sparingly so there are lots of random events between uses.
I would recommend using a single generator multiple times. As far as I know, all the generators have a state. When you seed a generator, you set its state to something based on the seed. If you keep spawning new ones, it's likely that the seeds you pick will not be as random as the numbers generated by using just one generator.
This is especially true with most generators I've used, which use the current time in milliseconds as a seed.
Hardware-based, true [1], random number generators are possible, but non-trivial and often have low mean rates. Availablity can also be an issue [2]. Googling for "shot noise" or "radioactive decay" in combination with "random number generator" should return some hits.
These systems do not need to maintain state. Probably not what you were looking for.
As noted by others, software systems are only pseudo-random, and must maintain state.
A compromise is to use a hardware based RNG to provide an entropy pool (stored state) which is made available to seed a PRNG. This is done quite explicitly in the linux implementation of /dev/random [3] and /dev/urandom [4].
These is some argument about just how random the default inputs to the /dev/random entropy pool really are.
Footnotes:
modulo any problems with our understanding of physics
because you're waiting for a random process
/dev/random features direct access to the entropy pool seeded from various sources believed to be really or nearly random, and blocks when the entropy is exhausted
/dev/urandom is like /dev/random, but when the entopy is exhausted a cryptographic hash is employed which makes the entropy pool effectively a stateful PRNG
If you create a RNG and generate a single random number from it then discard the RNG, the number generated is only as random as the seed used to start the RNG.
It would be much better to create a single RNG and draw many numbers from it.
As people have already said, it's much better to seed the PRNG once, and reuse it. A secure PRNG is simply one which is suitable for cryptographic applications. The only way re-seeding each time will give reasonably random results is where it comes from a genuinely random "real world" source - ie specialised hardware. Even then, it's possible that the source is biased and it will still be theoretically better to use the same PRNG over.
Normally seeding a new state takes quite while for a serious PRNG, and making new ones each time won't really help much.
The only case I can think of where you might want more than one PRNG is for different systems, say in a casino game you have one generator for shuffling cards and a separate one to generate comments done by the computer control characters, this way REALLY dedicated users can't guess outcomes based on character behaviors.
A nice solution for seeding is to use this (Random.org) , they supply random numbers generated from the atmospheric noise for free. It could be a better source for seeding than using time.
Edit: In your case, I would definitely use one PRNG per client, if for no other reason than for good programming standards. Anyways if you share one PRNG among clients, you will still be providing pseudo-random values to each, of a quality equal to your PRNG's quality. So that's a viable option but seems like a bad policy for programming
It's worth mentioning that Haskell is a language which attempts to entirely eliminate mutable state. In order to reconcile this goal with hard-requirements like IO (which requires some form of mutability), monads must be used to thread state from one calculation to the next. In this way, Haskell implements its pseudo-random number generator. Strictly speaking, generating random numbers is an inherently stateful operation, but Haskell is able to hide this fact by moving the state "mutation" into the bind (>>=) operation.
This probably sounds a little abstract, and it doesn't really answer your question completely, but I think it is still applicable. From a theoretical standpoint, it is impossible to work with a RNG without involving state. Regardless, there are techniques which can be used to mitigate this interaction and make it appear as if the entire operation is of a stateless nature.
It's generally better to create a single PRNG and pull multiple values from it. Creating multiple instances means you need to ensure that the seeds for the instances are guaranteed unique, which will require incorporating instance-specific information.
As an aside, there are better "true" Random Number Generators, but they usually require specialized hardware which does things like derive random data from electrical signal variance inside the computer. Unless you're really worried about it, I'd say the Pseudo Random Number Generators built into the language libraries and/or OS are probably sufficient, as long as your seed value is not easily predictable.
The use of a secure PRNG depends on your application. What are the random numbers used for?
If they're something of real value (e.g. anything cryptographically related), you wouldn't want to use anything less.
Secure PRNGs are much slower, and may require libraries to do operation of arbitrary precision, and primality testing, etc etc...
Well, as long as they are seeded differently each time they're created, then no, I don't think there'd be any difference; however, if it depended on something like the time, then they'd probably be non-uniform, due to the biased seed.