Last week I was thinking about some new research ideas and I have some stuff which’s (at least from my point of view) really interesting. Something I’d like to present now is Ranum. Today many things are based on random numbers but the problem we have there is, that normal computers can just generate so called pseudo random numbers and so you can run into security problems. Now I thought about what the problem is and it’s just, that if a machine generates “random” numbers, you can try to enumerate the next number. So my idea was now to have “Distributed Random Number Generator” because there you don’t have the possibility to analyze a machine to enumerate anything because every participating machine is different and you’ll never now from which machine you’ll get your next random number. It’s not that easy to explain so we better go to the POC stuff which’s an easy Firefox Extension I called Ranum (-> Random Numbers) and some small server side PHP scripts which communicates with a MySQL database.
Ranum:
This is the main part of the Distributed Random Number Generator because when you install this Firefox extension, your browser will generate pseudo random numbers all the time in the background and build a SHA-256 hash out of it and then send this hash to the server which will collect this values in a MySQL database.
PHP scripts:
index.php is the script where Ranum will send the numbers to and which will store them into the database.
ranum.php gives you X random numbers out of the database (and delete them afterwards). Also the number you will get are once more pseudo random so that even if for example only one person is sending pseudo random numbers for a hour you never will be able to enumerate the next random number you’ll get because you won’t get just the next number.
One random number
Ten random numbers (I’ve set the maximum to 20 numbers per request)
ranum_info.php is nearly the same as ranum.php but it contains some more information.
One random number
Ten random numbers (I’ve set the maximum to 20 numbers per request also here)
MySQL database:
Nothing interesting here:
CREATE TABLE `ranum` (
`id` int(10) NOT NULL auto_increment,
`number` varchar(64) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `number` (`number`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
So, now I need people who like to help generating pseudo random numbers for getting a database with real or at least much better random numbers 
PS: Hope the server wouldn’t go down because of the load 
Nice idea, but as the database grows wouldn’t it boil down to the mentioned predictability by mysql rand() being used then to retrieve the numbers?
May be a theoretical weakness if INT(10) is large enough and also moot if you allow duplicates (but you don’t atm according to the CREATE statement)…
Then again I guess the randomness of the id number assignment is sufficient
Interesting idea, but I’m not sure where this would be a practical and useful solution.
Here are some issues I can see with the current implementation:
Not only is the number sent in plain text from the extension, but also sent in plaintext from the server.
– Could be solved by crypto on both ends
– You only lose performance
There are no safe guards stopping someone poisoning the random number pool with their own numbers.
– Could only allow X submissions from a single IP?
– Botnets can still poison it.
– Could only X submissions per account?
– Depending on where this is used, getting people in 3rd world countries to solve CAPTCHAs may be economically feasible.
– Could only allow trusted sources to send you data.
– What’s a trusted source?
– You lose lots of untrusted computers
There are no safe guards stopping someone requesting lots of numbers.
– Ideas from previous issue
– Could only allow access by trusted sites
– Why would people contribute?
DoS against the ranum server kills everything relying on it, well either that or they fall back to local crypto, so if we can break something we’re back to square one – and DoS isn’t that uncommon.
Oh, and I don’t see how this could be exploitable against your site, but I *think* this is relevant to your preg_match() statement in index.php: http://blog.php-security.org/archives/76-Holes-in-most-preg_match-filters.html
So yeah, while its an interesting idea, that could be utilised in an organisation by doing something like running a bunch of VMs or something on some machines submitting the data to a server, but I don’t think it cold work on the internet due to the fact that all data you get is probably untrustable.
@ fa
You’re absolutely right, that the MySQL rand() function is also just a random number generation function and so the number you’ll get out of the database is chosen only pseudo random like but this is not a problem because the rand() function’s completely independent from the number generation mechanism for the stored (pseudo) random numbers (which are not real pseudo anymore in the database). This means, that it doesn’t depend on which number you get out of the database because all of them are random and even if you get always the number with the lowest ID it will works. The rand() function’s just in place because then you don’t have (big) chance to send a number to the server and know, when you’ll get back exactly this number.
@ kuza55
Most of this stuff is really a problem and I’ve thought also about most of it. My first ideas about Ranum where much more complicated and for example covered the integrity problems through cryptography but because I think this is just a nice idea and not directly useful I decided to do just a POC and if someone’s interested in the idea, go ahead and implement crypto, IP blockers, timers and so on
On your thoughts about poisoning the database with your own numbers; This is of course possible but shouldn’t be a problem from my point of view. You only have the possibility to bring values into the database when they look like SHA-256 hashes and also every number can be just once in the database. So, you can poison the database but you won’t know if you’ll get one of your own numbers or not and as soon as there are enough numbers in the database and if theres a blocker which allows for example only to submit a number every five seconds, you should not have a problem with this. An idea I had right now would also be, to let the server add a pseudo random value to the number and then once more make a SHA-256 hash out of it so the base is still from outside but the stored random number was modified so that your value will never be in the database.
DoS is always a problem when we have such services but once more, with a timer like described before we can fix this.
Btw. I don’t know if there’s really a possibility to exploit the preg_match() statement in my script but to be sure that it’s not possible (in a known way) I’ve fixed it now. thx
Why would you delete the number from database once it has been given to someone? Why not just leave it in teh pool?
Hi jas,
that’s really simple:
This database makes only sense as long as not every possible value is in it because then the server will chose a pseudo random database entry out of all possible values and in this case the whole idea won’t work anymore Now because not every possible value’s in the database, the chance to get the same value twice is higher that to get another number out of all possible numbers because not all possible values are stored in the DB and so I have to delete the values which has already been used.
Hope you get the point
I’m sure Marcus Ranum (http://www.ranum.com/) will be honored. Just don’t try to fight him for the domain