Re: Breaking: Shuffle-based Provably Fair Implementations Can Cheat Players (proof)

Quote from: TrevorXavier on June 01, 2016, 11:52:23 AM

Quote from: NLNico on June 01, 2016, 10:27:29 AM

^ I am more curious about above. BitZino allows 32 "aZ09" characters (62^32?) as clientseed and the MT seed is a SHA256 based on that. Isn't that a lot more than 2^32? Maybe I misunderstand that part though.

Good catch, but sadly, the seed maxes out at 2³² – 1.

bitZino combines the server seed and client seed, hashes it with SHA256, but then only uses the first 8 bytes of it. So, the range is 0x0 to 0xFFFFFFFF. (FFFFFFFF)₁₆ = (4294967295)₁₀. They write about this in their techblog: https://techblog.bitzino.com/2012-06-30-provably-fair-shuffling-through-cryptography.html

Ah, right. So this seems like a limitation of MT19937. So if they would use MT19937-64, would this be a sufficient solution? This is still less than 52! but at least less feasible to calculate? (I guess there is no JS code for MT19937-64 though.)

Like JackpotRacer I am wondering what "the best solution" would be to get a provably fair random card deck.

I can imagine something like the "dice nonce method" but adding an extra nonce so it could calculate more numbers (since a "duplicate card" cannot happen, so might need to loop a bit more.) But this might get a bit heavy in performance the more unique cards you need Tongue