Joe Damien wrote:
> What yall think ?
> http://crystalpoker.net/securityreview.php
>
> looking for the best shuffling algortihm to copy for a little project
> i'm doing, this one seems like it'd make the best results, just
> looking for a few experts' opinions and potential weakness in the
> design
This design is fairly reasonable. Its main weakness is that colluding
clients could rig the entropy source and thus make the random number
generator deterministic. Since they reveal that they are using the
Mersenne Twister, then an attacker in control of all the clients could
in fact simulate the full output. (The attackers control could be
"spoofing" the mouse position and timers for the client software, or
simply observing the same thing as the client software by intercepting
the OS calls to get that information, and hiding the
intercepting/hacking program behind SONY's rootkit, or something of a
similar nature.)
As always, people who implement in-house solutions ignore the experts
at their peril. For a more serious RNG Read this:
http://www.schneier.com/yarrow.html . The crystalpoker.net idea is
fairly good, but doesn't measure up to yarrow.
To make it more secure, I would modify the crystalpoker.net idea.
First you must incorporate server generated entropy with the client
sourced entropy. In this way *neither* side can rig or observe the
random numbers. I.e., when each client returned with its "entropy
fragment", the server could take that as an event trigger, and simply
read from its own internal timers and append that as further entropy.
Secondly, as good as the Mersenne Twister is for generating long-cycle
random numbers, I don't think its reliable as a cryptographically
useful PRNG. I.e., it may be that observing a long enough sequence of
output from MT, one can reverse engineer what the seed values are (I
don't know how true this is or not, but clearly MT was not designed
with this in mind.) But a straightfoward fix to this is to append 256
bytes of output from the Mersenne Twister at a time to some rotating
buffer (which itself may be somewhat larger than 256), then use SHA-2
(if we consider SHA-1 to be considered broken in the long run) on the
buffer, and use the hash output as the final PRNG output. In this way
observing the output, it is basically infeasible to reverse engineer
the seeds, except by a direct brute force attack on the seeds
themselves.
But then again, I am not a crypto expert myself. I would take these
comments as something "even a non-expert can come up with as an
improvment."
But, of course, generating good random numbers might be the least of
the online poker world's problems:
http://www.thisismoney.co.uk/money-savers/article.html?in_article_id=405333&in_page_id=5
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Received on Sat Dec 3 04:20:30 2005