Hi Sergio! I'm the owner and primary developer of bitZino. Thanks for the feedback! I relish the opportunity to defend our approach to shuffling as truly Provably Fair. I firmly believe that the best cryptography is that which is practiced in the open, with honest and open discussion about any possible weaknesses or avenues of attack.
I believe that the blog post you linked to has a pretty good discussion about most of your points, but I'll take the time to individually address all of your critiques:
(1) Client_seed is not big enough (32 bits) to assure a fair statistical distribution. The server can try each possibility in advance...
The client_seed is only used to
reshuffle the deck, so it's not necessary to use it to be able to represent the full set of possible decks. In effect, the reshuffling is like cutting the deck, but significantly more robust. Even if the server could analyze all possible deck combinations before each shuffle, it wouldn't help. This is because the Mersenne Twister has the property of having a
Uniform Distribution, which means the avenue of attack of "creating a pre-shuffled deck such that all possible re-shuffled decks still favor the house" is impossible.
(2) The server knows the shuffled deck (every card) BEFORE the user, so the server can abort the game (showing any strange error message) if the deck is too good for the user.
Even if there is a server error prior to the deal, the user can still confirm that the server didn't change the pre-shuffled deck - as long as the `Hash(secret)` which is presented to the user doesn't change when the user reloads the page, they will know the server is being honest. I do agree though, that if the `Hash(secret)` changes, this would be a clear indication that the house is cheating.
(3) Last but not least, the site is HTML5 only (no open source client application), so there is no way to know if the client-side javaScript code is actually verifying anything !!!
The code for the
Javascript Hand Verifier is indeed open source! If you view the source for that page, you will see the algorithm implemented in 100 lined of clean, well-commented javascript. If you don't trust the javascript though, you are free to re-implement your own verifier - that's why I created the detailed blog post as well as the reference javascript implementation - I want to be as open about this whole process as possible.
(4) Where is the "proof" for the "Provably Fair" algorithm?
Ok, I admit there is no rigorous mathematical proof to accompany the algorithm - but that's why it's not "Proven" - it's just "Provable". I do believe a rigorous mathematical proof could accompany this, and prove that it would be NP hard to cheat a user at dealing if this algorithm is followed. You could say it's just in the theory stage right now
The only way to implement secure card games on the Internet is by using Mental Poker protocols (crypto newbies, check it on Wikipedia). And it happens that I designed the fastest MP protocol so far... humbly
A link to the wikipedia Mental Poker page, for the lazy
I'm a big fan of these types of approaches, and the general guiding principal is what drove me to make bitZino provably fair. But, I disagree on your assessment that MP is the
only way to have a secure game. MP is great for situations when neither player can know the shuffle of the deck. But in a casino game's use case, it is not a problem for the house to know the shuffle - as long as it doesn't know the shuffle until the moment the game is dealt (again, assuming that `Hash(secret)` doesn't change in the event of an error - which would be a clear indication that the house is cheating).
Thanks again for the critique! I truly do love how the bitcoin community embraces cryptographic approaches to solve real-world problems, and I also love how it's rigorous in its critique of systems that aren't truly secure. Please, bring on any more critiques you have, I'd love to continue the discussion!