# Secure multi-party random number generation

This question is actually continuation of my previous one.

Secure multi-party computation for digital signature

to implement solution there, I have to generate random data for padding (I will use PSS).

1. There are N parties. Up to M are malicious adversaries (were trusted, but got taken over silently). I will be happy with solution for any N and M = 1.
2. Parties should send to each other some random data d[i] and each party based on all d[1..N] should generate some final random value R.

From one side, value should be one and the same for all parties, i.e. calculation should be a fixed predictable process and all parties should get one and the same value R. From another side, malicious adversary party should not be able to affect randomness of R[i], i.e. even malicious adversary should not be able to generate d[m] to get specific R.

Looks like I can achieve this by simply hashing all d[i] values in predictable order. For instance sort d[i] and calculate hash of "well-known-secure-prefix" + d[1..N] + "well-known-secure-suffix".

Am I missing anything?

• What you're looking for is called a coin-flipping protocol. – Maeher Feb 27 '19 at 17:52

The fix for that is for to have everyone submit commitments to their shares before revealing them. For example, party i first publishes $$\text{hash}( d[i] || r_i )$$ to everyone, and not until everyone has published their commitments, everyone then publishes their $$d[i]$$ and $$r_i$$ values (and everyone can check that their revealed values matches their commitments). Then, everyone can combine all the $$d[i]$$ values, and you then get a hash value that no one has control over.
The best an attacker can do is arrange to be the last person to reveal their $$d[i], r_i$$ values, and then, if the combined value isn't what they like, just refuse (or misopen their commitment). This does allow the attacker a veto over the randomness; however for the attacker to use their veto, they have to give a hint that they are the malicious party. You could try to avoid this by using a function that is hard to compute quickly (e.g. Argon2 with appropriate parameters); I'm not sure if it's worth the trouble...