[messages] [General Discussion] revisiting preventing rigged dice rolls in online play
uckelman at nomic.net
Sun Jan 22 19:15:27 MST 2012
Thus spake ewilen:
> An earlier thread asked whether Vassal had any protection against
> rigged dice rolls during online play. The conclusion there was that this
> was impossible to protect against without a 3rd-party dice roller.
> But I wonder if the following approach might work. Suppose two copies of
> Vassal are communicating with each other. User1, using Vassal1,
> initiates a dice roll.
> Vassal1 transmits an encrypted, randomly-generated Seed1 to Vassal2. I'm
> not an expert in cryptography by any means but it seems to me that the
> seed may need to be "padded" in a way that would authenticate the value
> on decryption. For example, it could consist of a series of
> randomly-selected dictionary words. (There are probably better ways to
> confirm that decryption has been performed using the correct key.)
> Vassal2 responds to Vassal1 with an unencrypted, randomly-generated
> Seed2. Vassal1 then combines the two seeds to deterministically generate
> a die roll. Vassal1 sends the die roll back to Vassal2 along with the
> key to decrypt Seed1. Vassal2 decrypts Seed1, authenticates it (in my
> example, by confirming that the padding decrypts into dictionary words),
> and confirms that the combination of the two seeds generates the same
> value reported by Vassal1.
Using a salt which is not random makes this much less secure than it
I had forgotten that it was possible to do this, thanks for reminding
Each party chooses a secret number in 0,...,n-1, appends a salt, hashes
that, and tells every other party the hash. Then, each party reveals his
number and salt, which permits everyone to verify the hashes. Finally,
sum the numbers modulo n and add 1 to get a result in 1,...,n.
The security of this depends on the security of the hash function, the
quality of the RNGs the parties use, and the length of the salt. If I
can generate a hash collision, then I can choose from among two
different secret numbers to reveal. We can always devise a perfect hash
function (one with no collisions), but we can't guarantee it will be
one which is one-way. The less salt we use, the less likely there will
be a collision, but the more likely that an attacker could brute-force
the hash function. With enough rolls, it would be possbile to guess
the seed or some internal state of a PRNG that someone uses for
generating their salt, which could also help you guess the salt.
Finally, this method requires O(n^2) messages to be passed among n
players. The only way that a player can be certain (supposing that a
secure hash function and RNG are used) that a roll was not fudged by the
other players is to provide input himself, even for rolls to which he is
not a party. In a 6-player game, there would have to be 2*36 = 72
messages passed in order to ensure the integrity of a single die roll.
As a further consequence of this, certain kinds of secret rolls become
impossble. I know I've played at least one game where I have a choice
whether to make a particular roll, but my opponent is privy neither to
the result nor to whether I've even made the roll before the game ends.
If this roll is not an interrupt, then I could simply announce a hash at
every possible opportunity to take the roll, but hash in whether I was
in fact taking the roll. Then my opponent could anounce his hash and
secret number, and I could announce mine at the end of the game. That
would work, but could be unbelievably tedious if the roll was something
that could be done at many different points in play. If, however, the
roll was an interrupt, I see no way at all of generating such rolls
using this method without leaking information that a roll had occurred.
So, to sum up:
1. We could implement this using SHA1 and a cryptographic-quality PRNG.
2. This would not scale well to large games with many separate
occasions for dice rolling. Consider running a Car Wars game with
a large area and 20 players. Every single roll would require 800
messages to be sent over the network if you pass messages peer-to-peer.
You could reduce this by pasing all messages via a trusted third party,
but if you have trusted third party, why not just have them roll for
I'll consider implementing this in VASSAL 4, but there needs to be a
limit on the number of clients which will provide input for any given
More information about the messages