| Maybe there are well known attacks against this scheme. Let's try a naive one. Conditions first: it's a 6 sides die. I need 1 to win, you need 2. The final number will be the hash of step 4 modulo 6. Let's try a naive implementation with 1 byte long numbers, no random bits to fill out the unused 5 bits of that byte. When I receive your hash I compare it with the only 6 possible hashes (micro rainbow table.) I know your number is 4. The possible pairs will be 14, 24, 34, 44, 54, 64 (how we mix the bits of those pairs is deterministic so let's do a simple n*10+m.) If the hash of one pair modulo 6 is 1, I'll give you the hash of the first number of that pair otherwise maybe you cheated and sent me a hash that will at least ensure that I don't win now ;-) We can add random bits, a lot of them, with the idea of making sure that the time I must spend is a very long one and exceed a timeout. However I must know where your number is in those bits. Let's say the number is at position 5 and you sent me the hash for 9999499999. I can try to be lucky and find your number by hashing random ones, then try to find a number with a digit <= 6 in its fifth position so that I win and send you that hash. Occasionally I will be able to generate a good number for me, not all the times. As a side note, a friend working with inmates told me that when they play backgammon they share the same dice because they don't trust the other player not to have loaded dice. Those dice become a trusted third party. If they are loaded, the distribution is the same for everybody. Finally, is the random distribution of your method still uniform? I didn't reason about it. |
> "I can try to be lucky and find your number by hashing random ones," If we were using sha-256, then you would be very impossibly lucky. There are 2^256 possible hash values for sha-256. It's extremely unlikely, that you would find a collision in the lifetime of the universe.