Next: , Previous: , Up: Operations on Stacks   [Contents][Index]

#### 3.5.2 Shuffling the Deck

Every player must perform a shuffle of the deck, because only such a procedure guarantees that no coalition has influence on the outcome. Thus we build a shuffle chain (e.g. using the strict total order P_i < P_j, if and only if i < j) such that each player shuffles the deck once.

First the regular stack `s` is initialized with open cards from `deck`. Then each player shuffles the stack (see SchindelhauerTMCG, i.e, `TMCG_MixStack`) using randomness (see `TMCG_CreateStackSecret`) and proves the correctness of this operation (see `TMCG_ProveStackEquality`). Consequently, every player should verify these proofs (see `TMCG_VerifyStackEquality`) and complain deviations immediately. Finally, the stack `s` contains the shuffled result. Consider the following code fragment for the player P_j.

 ```for (size_t i = 0; i < 5; i++) { TMCG_Stack s2; if (i == j) { TMCG_StackSecret ss; tmcg->TMCG_CreateStackSecret(ss, false, s.size(), vtmf); tmcg->TMCG_MixStack(s, s2, ss, vtmf); for (size_t i2 = 0; i2 < 5; i2++) { if (i2 == j) continue; out_stream[i2] << s2 << std::endl; tmcg->TMCG_ProveStackEquality(s, s2, ss, false, vtmf, in_stream[i2], out_stream[i2]); } } else { in_stream[i] >> s2; if (!in_stream[i].good()) std::cerr << "Read or parse error!" << std::endl; if (!tmcg->TMCG_VerifyStackEquality(s, s2, false, vtmf, in_stream[i], out_stream[i])) std::cerr << "Verification failed!" << std::endl; } s = s2; } ```

If you want to use the more efficient shuffle verification protocol of Groth, then you have to replace `TMCG_ProveStackEquality` and `TMCG_VerifyStackEquality` by `TMCG_ProveStackEquality_Groth` and `TMCG_VerifyStackEquality_Groth`, respectively.16

### (16)

The non-interactive version of Groth’s protocol (see `TMCG_ProveStackEquality_Groth_noninteractive` and `TMCG_VerifyStackEquality_Groth_noninteractive`) provides an even more efficient implementation, because the prover has to compute the argument of correctness only once. Additionallly, it protects agains malicious verifiers and reduces the communication complexity, i.e. instead of O(n^2) the prover must perform only O(n) steps. Thus this approach is strongly recommended. However, the security then relies on the random oracle assumption. Please have a look at the included source code tests/t-poker-noninteractive.cc to get a clue.