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

i'm not so good at codin though
haha

haha i actually wanna crack this, be tite

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/

<websnarf@gmail.com> wrote in message 
news:1133382096.743139.101890@g49g2000cwa.googlegroups.com...
> Joe Damien wrote:
>> What yall think ?
>> http://crystalpoker.net/securityreview.php
>>
> 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.
>

Towards the end of the crystalpoker.net article, we're told:

"So before a new deck is shuffled, we use a Mersenne Twister. The data we 
provide it with is all this new entropy seed data we've collected from all 
the clients and the server's local chipset Timer Stamp Counter."

....which seems to cover that eventuality.

--
Roger

In article <1133382096.743139.101890@g49g2000cwa.googlegroups.com>, 
websnarf@gmail.com says...

> 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.  

As Roger points out, they add entropy from the server.

However, if their business is running poker games for a fee or a 
percentage of the pot, if their clients all collude they will just be 
organising the payouts between themselves, with no harm to Crystal 
Poker!

- Gerry Quinn 

Hey Gerry,
been busy trying to figure this out.
programming is not my strong point
I wish they had some sample code on the website heh.

but blah, i think i'm gonna just contact crystalpoker.net and ask them
to provide some sample code on the article





On Thu, 1 Dec 2005 13:04:40 -0000, Gerry Quinn
<gerryq@DELETETHISindigo.ie> wrote:

>In article <1133382096.743139.101890@g49g2000cwa.googlegroups.com>, 
>websnarf@gmail.com says...
>
>> 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.  
>
>As Roger points out, they add entropy from the server.
>
>However, if their business is running poker games for a fee or a 
>percentage of the pot, if their clients all collude they will just be 
>organising the payouts between themselves, with no harm to Crystal 
>Poker!
>
>- Gerry Quinn