Gathering entropy in web apps to create (more) secure random numbers

Question

after several days of research and discussion i came up with this method to gather entropy from visitors (u can see the history of my research here)

when a user visits i run this code:

$entropy=sha1(microtime().$pepper.$_SERVER['REMOTE_ADDR'].$_SERVER['REMOTE_PORT'].
$_SERVER['HTTP_USER_AGENT'].serialize($_POST).serialize($_GET).serialize($_COOKIE)); 

note: pepper is a per site/setup random string set by hand.

then i execute the following (My)SQL query:

$query="update `crypto` set `value`=sha1(concat(`value`, '$entropy')) where name='entropy'";

that means we combine the entropy of the visitor's request with the others' gathered already.

that's all.

then when we want to generate random numbers we combine the gathered entropy with the output:

$query="select `value` from `crypto` where `name`='entropy'";
//...
extract(unpack('Nrandom', pack('H*', sha1(mt_rand(0, 0x7FFFFFFF).$entropy.microtime())))); 

note: the last line is a part of a modified version of the crypt_rand function of the phpseclib.

please tell me your opinion about the scheme and other ideas/info regarding entropy gathering/random number generation.

ps: i know about randomness sources like /dev/urandom. this system is just an auxiliary system or (when we don't have (access to) these sources) a fallback scheme.

Answer 1

In the best scenario, your biggest danger is a local user disclosure of information exploit. In the worst scenario, the whole world can predict your data. Any user that has access to the same resources you do: the same log files, the same network devices, the same border gateway, or the same line that runs between you and your remote connections allows them to sniff your traffic by unwinding your random number generator.

How would they do it? Why, basic application of information theory and a bit of knowledge of cryptography, of course!

You don't have a wrong idea, though! Seeding your PRNG with real sources of randomness is generally quite useful to prevent the above attacks from happening. For example, this same level of attack can be exploited by someone that understands how /dev/random gets populated on a per-system basis if the system has low entropy or its sources of randomness are reproducible.

If you can sufficiently secure the processes that seed your pool of entropy (for example, by gathering data from multiple sources over secure lines), the likelihood that someone is able to listen in becomes smaller and smaller as you get closer and closer to the desirable cryptographic qualities of a one-time pad.

In other words, don't do this in PHP, using a single source of randomness fed into a single Mersenne twister. Do it properly, by reading from your best, system-specific alternative to /dev/random, seeding its entropy pool from as many secure, distinct sources of "true" randomness as possible. I understand you've stated that these sources of randomness are inaccessible, but this notion is strange when similar functions are afforded to all major operating systems. So, I suppose I find the concept of an "auxiliary system" in this context to be dubious.

This will still be vulnerable to an attack by a local user cognizant of your sources of entropy, but securing the machine and increasing the true entropy within /dev/random will make it far more difficult for them to do their dirty work short of a man-in-the-middle attack.

As for cases where /dev/random is indeed accessible, you can seed it fairly easily:

• Look at what options exist on your system for using /dev/hw_random
• Embrace rngd (or a good alternative) for defining your sources of randomness
• Use rng-tools for inspecting and improving your randomness profile
• And finally, if you need a good, strong source of randomness, consider investing in more specialized hardware.

Best of luck in securing your application.

---

PS: You may want to give questions like this a spin at Security.SE and Cryptography.SE in the future!