The Previous discussion can be found [here]. Please continue the discussion now in this DiscussionArea on this page below:

Thanks. --DouglasReay

[Thread 1] - what order to reveal the plaintexts?
[Thread 2] - does it work?
[Thread 3] - which hash algorithm to use?
[Thread 4] - best length for the plaintext?
[Thread 5] - Cryptographic Pseudo-Random Number Generators
[Thread 6] - shuffling
[Thread 7] - (your new thread here)

what order to reveal the plaintexts?

[PaulCrowley] wrote:

The house publishes a list of parties (including itself)
All parties privately choose a random seed
All parties reveal a hash of their seed
All parties except the house reveal their seeds
The house hashes all seeds including its own in the order of the list published

: DouglasReay wrote: I'd prefer if people didn't have a completely free choice of random seed, to help prevent them using the birthday-party effect to pre-generate collisions

: [MoonShadow] wrote: Split step 4 up: make all revealing parties reveal their seeds one bit at a time (so everyone's bit 0 are known before any bit 1 are revealed, etc.) This forces you to commit to one of your many precalculated birthday seeds that all hash to the same thing before you know enough of anyone else's to be able to decide which one benefits you most. Hm. The house can still usefully precalculate hash collisions. Maybe use something more resistant to collisions than a crypto hash in order to commit to your seed? What is there? Sign your seed along with a load of salt and publish the signature? Paul, you suggested 160-bit seeds above to resist birthday attacks; how computationally hard is it to find two 160-bit strings that have the same MD5 hash?

: DouglasReay wrote: revealing the seeds one bit at a time sounds nice, but I'm not sure it could be done efficiently enough in practice over the internet between multiple players. It would certainly make tunneling over email problematic.

does it work?

which hash algorithm to use?

best length for the plaintext?

Cryptographic Pseudo-Random Number Generators

shuffling

[HalFinney] wrote: Card shuffling is a harder problem because the probabilities must change with every card, and some cards aren't shown to everyone. You might want to take a look at [crypt21] which also has some code to implement fair dice rolling and card shuffling. (from an old thread) [PeterTaylor] observes that you don't need to do it 51 times for a deck of cards. You need to generate one integer in [0, 51!). That's about 220 bits, so if you're using a 256-bit hash it's just one exchange. The algorithm is just a base change. Divide by 51! to get a number in [0, 51], divide the remainder by 50!, etc. Then with your array arr, and an array deck containing the cards, for (int i = 51; i >= 0; i--) swap(deck, i, arr[i]);

 (your new thread here)