Random Number Generation

https://www.random.org/

There are some nice explanations and real random numbers.

Though you should not try to get megabytes of data from there, as I remember there are quotas and you might get banned for abuse.

I don't doubt that there are applications that have these requirements, but I do want to ask: why? What exactly are you doing that needs that much (true) random data? (As opposed to cryptographically secure pseudo-random, or pseudo-random with other guarantees on distribution, etc...)

True randomness is hard. (Technically, impossible on a deterministic machine.)

If you really need to generate a megabytes of random bits, there are ways to do it locally (of varying quality). Unix systems provide /dev/random, which is cryptographically secure.

How can it be cryptographically secure if iy's only pseudo-random? That doesn't sound secure at all!

Are you kidding me? That websites limits it to 16k? WTF am I supposed to do with 16k?!

How can it be cryptographically secure if iy's only pseudo-random? That doesn't sound secure at all!

http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator

How can it be cryptographically secure if iy's only pseudo-random? That doesn't sound secure at all!

According to the corresponding Wikipedia article a key property would be fulfilling the next-bit test, that is "given the first k bits of a random sequence, there is no polynomial-time algorithm that can predict the (k+1)th bit with probability of success better than 50%". That sounds pretty reasonable to me as a computer scientist without a specialization in cryptography.

Edit: Ninjaed...

True randomness is hard. (Technically, impossible on a deterministic machine.)

If you really need to generate a megabytes of random bits, there are ways to do it locally (of varying quality). Unix systems provide /dev/random, which is cryptographically secure.

You probably won't be able to draw megabytes from /dev/random in any amount of time anyway (unless the configuration is screwed with) as entropy is difficult to collect on your average system because estimates are conservative and there aren't *that* many entropy sources in the system. If you really need "real" random bits, there are small, fairly affordable USB devices that use signal noise or quantum physics to produce large amounts of it. Google for "true random number generator" or "hardware random number generator" (HRNG).

But like others have said above, you seem to be misguided. The output of cryptographically secure random number generators is designed to be computationally indistinguishable from a stream of "truly random" bits. And when you think about it, that's all you need; doesn't matter if the output bits aren't "really" random, there is no test anyone without the original key can perform in reasonable time to detect that they aren't! So is there really any observable, measurable difference? And they are much cheaper to generate (since you only need a few dozen truly random bits in total to seed the CSPRNG and generate a virtually infinite pseudorandom stream of bits) which is the whole point.

In fact, and I like to point this out to people, the probability that someone somehow manages to distinguish between the output of a CSPRNG and a truly random stream of bits is actually far, far lower than the probability of your hardware number generator failing and producing correlated, non-random bits (and also lower than the probability of the computer generating the CSPRNG output failing). So there is in any case a physical limit to how reliable a process can be made to be, and CSPRNG's happen to fall below that threshold.

I guess this is a programming question, but only indirectly (I wasn't sure where to post it).

Anyway, I need random data, and lots of it! I need many megabytes worth of random bits, and it can't be PSEUDO-random, but actually random (at least in the sense that it wasn't created by any mathematically predictable pattern at all)!

Is there any way to prove that even exists?

What specifically is the property that you seek, that is critical to your purpose, which you believe truly random data will give you, but no pseudo-random implementation possibly can?

In the best case, a well-chosen pseudo-random algorithm might in fact be able to give you data with that property.

And I wouldn't be surprised if in the worst case, seeding a well-chosen pseudo-random algorithm with small amounts of truly random data would be plenty sufficient to do so.

I know you explicitly asked to avoid pseudo-random algorithms, but I frankly doubt that your reason, which you have so far refrained from stating, is well founded. If you are looking to make some kind of exploit truly impossible, then what you seek is likely impossible. In the world of randomness and cryptography and such, the objective is generally to make things obscenely difficult, because most things cannot be proven impossible, and in many cases are actually proven possible, but it doesn't matter due to how astronomically difficult they are.

>If you are looking to make some kind of exploit truly impossible...

You just answered your own question. That's exactly what I need.

>If you are looking to make some kind of exploit truly impossible...

You just answered your own question. That's exactly what I need.

Even if you had true random number generation (you can buy such things, if you really want), it doesn't necessarily help all that much with security.

Most common security exploits don't attack the cryptographic function itself, rather they attack the key exchange process. It's generally way easier to execute a Man-In-The-Middle attack by jacking the secure keys in transit, than to crack even a moderately effective cryptographic pseudo-random number generator...

Whether truly random numbers exist is a question for philosophers, and not a particularly interesting one, from my point of view. But I'll give you a practical recipe to compute numbers that are random for all intents and purposes.

Let's say you need 100 megabytes of data. I would generate that much data using a variety of methods. Off the top of my head:
* a chunk of data extracted from /dev/urandom on a modern Linux system,
* a chunk from a compressed tar of all the files in your home directory,
* a chunk from a compressed file containing video captured from your webcam,
* [Add your favorite method[s] here].

Now take all those 100-megabyte blocks and XOR them together. The result is random mush. In some sense that can be made precise, the result is at least as random as the most random of the ingredients. Whatever you are trying to do with random numbers, these are good enough.

Use your friendly neighborhood ssl library's random implementation to seed a deterministic prng which you then pull your megabytes from. Something like a mersenne twister, and re-seed at semi regular random intervals.

If that's good enough for ssl, it should be more than enough for any game...

Edit: couldn't resist...

How can it be cryptographically secure if iy's only pseudo-random? That doesn't sound secure at all!

The way this works is, you append some kind of entropy which you can collect from many sources (like, for example, nanoseconds since last received network packet) to a buffer, and run a secure hash function over it, which causes an avalanche effect on the input bits, creating a "more random looking" output. This can be repeated many times, with new entropy being added or no new entropy being added. In the latter case, the output will be merely pseudorandom, but it is still "cryptographically secure" insofar as there is no straightforward way of predicting the output.

If true random entropy is being added continuously, the output remains "truly random" (to some extent, it is only truly random if the number of entropy bits added is equal or higher than the number of bits you pull from the generator, but in every practical respect, it's "truly" random if you pull a lot more anyway, you won't be able to show a difference).

Are you kidding me? That websites limits it to 16k? WTF am I supposed to do with 16k?!

No kidding, generating 16k true random numbers is very hard. And, nobody really needs that much random data.

braindigitalis, this isn't actually for a game - that's why I put it in the general programming section, but wasn't really sure where it belonged - I just thought you all might have some ideas, that's all.

>And, nobody really needs that much random data.

samoth, http://en.wikipedia.org/wiki/One-time_pad

braindigitalis, this isn't actually for a game - that's why I put it in the general programming section, but wasn't really sure where it belonged - I just thought you all might have some ideas, that's all.

>And, nobody really needs that much random data.

samoth, http://en.wikipedia.org/wiki/One-time_pad

Now you're just sounding paranoid! The only organizations with the need to use such a method are not going to ask how to do so here! Whatever you're trying to encrypt isn't nearly as important as you may think. ;)

For some reason this comes to mind.

>Whatever you're trying to encrypt isn't nearly as important as you may think.

But it is, TO ME.