Getting truley random in C Options

[Valirian_Oak]

Pseudo random, I am not

CODE

int ssrand(int min, int max) {       //This creates a function called ssrand(min, max) which generates a random int between min and max
        FILE* f;
        unsigned q;
        float randmax=65536;
        float x;
        f=fopen("/dev/urandom", "r");
        fread(&q, 1, 4, f);
        randmax *= randmax;
        x = q / randmax;
        x = x * (max-min);
        x= x + min;
        fclose(f);
        return x;
}

I needed to write this for a phone line tester, i figured someone will eventualy need it.

This function will read for the urandom device and return a truly random int between MIN and MAX from your computers "entropy pool". The data from urandom is truly random because it is calculated using the disorderin mouse movements and keystrokes. To see this open a terminal and type

CODE

cat /dev/random

This will dump the current entropy pool to the screen.
Now type

CODE

cat /dev/urandom

That will dump the current entropy pool and automaticly [and mst importantly, randomly] create more.

[ChefNinja]

But you see, calculating random numbers from mouse/keyboard movements ISN'T truely random. It's algorithmic. Computers CANNOT generate TRULY random numbers. :P

[Valirian_Oak]

This is very close to being truly random, for even though there is an Algorithm to determine what gets writen to the device, The input that controls Algorithm IS random.


EDIT: I very quickly dumped 1000 pages from the device and ran them through File Merger, and no 2 pages are the same, nor are there any duplicated lines. Then i dumped another 1000 pages and ran them against the first 1000 and again found that no pages or lines were duplicated.. This to me lends to truly random, and while i agree with you chef that with out silicone decay, [which produces some pretty cool random results] no computer can generate a trully random number, but this is as close as your going to get. ;)

This post has been edited by Valirian_Oak: Apr 1 2006, 02:54 AM

[psyba]

What about if you automated this? Would it work in a server environment that didn't have frequent mouse/keyboard input?

[Subterraneus]

well, if it only gets it's entropy from user input, than that might be kinda weird. But I'm gonna make a random guess it could take the tiny imperfections of miliseconds of that computers make and use them...but you know...I don't

by the way, it's silicon decay...
silicone: H4Si (pretend that's a good subscript)
silicon: Si

edit: on second thought, you could get a cat and just have them mes around with your server, bat the mouse around, sleep on the keyboard. or, you know about the monkeys at typewriters...
yes, yes I am kidding

This post has been edited by Subterraneus: Apr 1 2006, 09:34 AM

[Siph0n]

What about if you automated this? Would it work in a server environment that didn't have frequent mouse/keyboard input?

urandom pulls from other sources as well...randomly polls hard drive RPM, temperature on any devices available, exact clock speed of the CPU, stuff like that. Keep in mind that it saves the random state in a dump...so once you first boot your computer (the very first time), the /dev/random (they call this the RNG) and /dev/urandom (they call this the PRNG) are seeded.

A while ago someone I met tried to replace /dev/random (which is a custom job by a guy at MIT who is one of the guys who maintain the crypto API), which relies heavily entropy estimation (which is unreliable), and also blocks when it runs out of it's estimated entropy, with Fortuna from Practical Cryptography. They turned him down. They failed to see /dev/random as a PRNG (which is what Fortuna is) and /dev/urandom as a RNG (as I stated in my above paragraph, they felt the opposite, that /dev/urandom was a PRNG and /dev/random was a RNG).

A big advantage Fortuna has over /dev/random is that it can recover from a state discovery, whereas with /dev/random you'd have to re-install. In addition, Fortuna is almost twice as fast. The supposed disadvantage of Fortuna is that it relies on AES in CTR mode with a 256 bit key and SHA-256, if either are broken this can pose serious issues for the PRNG. Of course, the good news is there were several submissions to AES, and any could easily serve as a drop-in replacement. (Twofish, RC6, MARS, Serpent, etc) And there are a wealth of hash functions which can be truncated (Tiger, WHIRLPOOL, etc) ... But, /dev/random also relies on SHA-1 (160 bit hash XORed to fold over it's self to make an 80 bit result, i.e. they split it into two 80 bit portions and XOR them by each other) which is no longer cryptographically secure (SHA-1 has a 2^60 'keyspace' and a 2^80 'keyspace' is required out of a 160 bit hash...not really sure of the word for hash functions, but when dealing with cryptographic keys it's called a keyspace...so..quotes a' hoy!).

One of the most shocking things in the above mentioned ordeal was that David Wagner, (Professor who teaches the Cryptography course at Berkeley University, specializing in randomness and PRNGs and RNGs), agreed with the guy who wanted to change the PRNG to Fortuna...and they still practically flamed them for it. So it was 3 guys (another guy I haven't mentioned + the 2 I have) against the entire sci.crypt newsgroup.

Ok I've um...had your head for long enough.

[Subterraneus]

O.o

interesting...I think

[madruse]

You really shouldn't say truly random. It is really only pseudo-random, thought it might be better than say the random values you would get from rand, it is still only pseudo-random. And at that /dev/urandom is not as good as /dev/random when the entropy pool is low, or at least this is true on Linux. Also, if you are looking for cycles, comparing entire pages (what's a page anyway?) of values wouldn't be the way to go. You would want to compare something much smaller. Consider the sequence 123456789012345678901234, and pages that are 6 numbers long, that gives you page1:123456 page2:789012 page3:345678 page4:901234, there are no two pages alike, but there is a cycle...

[Siph0n]

You really shouldn't say truly random. It is really only pseudo-random, thought it might be better than say the random values you would get from rand, it is still only pseudo-random. And at that /dev/urandom is not as good as /dev/random when the entropy pool is low, or at least this is true on Linux.

But entropy estimation is unreliable, therefore you could possibly have no entropy at all with /dev/random, and that is dangerous (maybe not for a random number guesser or something, but for cryptographic reasons, yeah).

[madruse]

But entropy estimation is unreliable, therefore you could possibly have no entropy at all with /dev/random, and that is dangerous (maybe not for a random number guesser or something, but for cryptographic reasons, yeah).

Entropy estimation is unreliable? Unlike /dev/urandom, /dev/random is supposed to block when it has no entropy, which I would consider a good thing. However, you are saying that the decision to block or not is unreliable? Will you explain more please.