1

I want to randomly choose a game in the 50 games I have, in order to play with one of my friend. But this friend doesn't trust me, and neither do I: every time one of us pick up a game, the other complains that the choice was not really random.

A first solution could be to put all the names in a hat and after pick up one name; but we're both paranoiac: the hat could contain only one name repeated 50 times, so we have to check that all the names are present only once to ensure an random choice. This is to long.

Second solution: we both randomly choose an integer in [1,50], write it on a paper, and then sum the result modulo 50. This is a good solution when we face each other.

But what if we want to choose an online game, me playing at Paris and my friend playing at NY ? I've trued to emulate the above protocol: each player choose randomly a number in huge interval like [1,1e30] and in a first time send a hash of its number (simulating the fact of hide the number on a piece of paper). When each player have received the hash of the other, the two players publish their numbers and add them modulo 50.

Is this protocol correct? Is there a better (maybe faster) protocol for this purpose?

Sebastien
  • 111
  • 1
  • http://www.miniwebtool.com/random-name-picker/ and take a screenshot of the result.... – schroeder Jan 05 '15 at 21:22
  • I can use your website, modify the HTML to change the name chosen by the name I want and then send the screen shot to my friend. – Sebastien Jan 05 '15 at 21:27
  • Plus it introduce a third part which we have to both trust (maybe I have corrupted miniwebtool's webmaster). – Sebastien Jan 05 '15 at 21:29
  • The solution is trivial if you trust a 3rd party, so I think that goes against the spirit of the question. It's interesting though. Is there some applicability to this, or is it more a puzzle kind of problem? – Steve Sether Jan 05 '15 at 21:47
  • I'm assuming you're purposefully ignoring the need for a secure channel to exchange information, and assuming an existing means to do this, correct? – Steve Sether Jan 05 '15 at 21:49
  • @SteveSether Depending on what you're trying to protect against, a secure channel may not be required. Secure channels protect against third parties, but if the goal is just to protect against one of the parties cheating by improperly controlling the decision, secure channels are neither necessary nor helpful. – cpast Jan 05 '15 at 22:02
  • @cpast I hadn't thought of that, but I think you're right. I can't see any way that a MITM could defeat the given protocol. – Steve Sether Jan 05 '15 at 22:10
  • Of course this is about information security. It's true it's more of a mathematical/cryptography question, but those are both subsets of information security. Please restore this question. – Steve Sether Jan 05 '15 at 23:00
  • If this is off-topic here, it should be migrated to Crypto.SE. – cpast Jan 05 '15 at 23:09

2 Answers2

1

What you want is a variant of a coin-flipping scheme. The standard way to do this is, as you've identified, to have both people come up with a value and then combine those values such that neither side has any control over the outcome by themselves. You've decided to use modular addition; this is indeed a standard way. You've also identified the issue with that, which is that whoever decided second could control the outcome (as they know what the first person picked), so you need people to commit to their values before they know the other person's value.

This sort of thing is called a commitment scheme. In these systems, Alice has some value she wants to commit to. Specifically, she should send something to Bob which encodes her value, but from which Bob cannot recover the value. Alice can then send Bob a piece of information when it's time to reveal her secret; the idea is that she can only reveal the value she originally committed to.

To get more concrete, assume Alice wants to commit to one bit. She wants to produce a "blob" to send to Bob; this blob encodes either 1 or 0. Then, when it's time to reveal the bit, Alice and Bob can open this blob, using some additional information Alice provides. The two key properties of the blob are that Bob can't discover which bit it encodes, and they can only open the blob to one of the two bits (Alice can't produce a blob encoding 1 and then cheat by opening it to 0).

With bit commitment, you can use a collision-resistant hash, compute the blob as H(s||b) with long random s (you hash s concatenated with b), and reveal s to open it (well, s and b, but revealing s makes it easy to get b). This is equivalent to having a long number and taking it modulo 2 to get the committed bit. Your scheme has similar effect, and should work provided you can't find collisions.

Unfortunately, just doing that means that someone who does find a collision can use it repeatedly. It's better to have Bob provide some random bitstring b to Alice, and have Alice compute a second (secret) random bitstring a, have Alice encode a number from 0 to 50 as 6 bits n (fixed-length, so she can't claim the dividing line is somewhere different than what it actually is), and compute the blob as H(b||a||n). This means that even if Alice finds a collision in H, it doesn't help; she needs a colliding pair that starts with b.

cpast
  • 7,413
  • 1
  • 31
  • 35
  • I think that Sebastien has chosen a commitment scheme to solve the problem, but that's not the actual problem. The problem is choosing a random value that both parties can agree was chosen randomly. – Steve Sether Jan 05 '15 at 22:21
  • 1
    @SteveSether Commitment schemes are the standard way of doing this. – cpast Jan 05 '15 at 22:28
  • Sure. Then the question becomes, is a commitment scheme the most optimum was of solving this problem? – Steve Sether Jan 05 '15 at 22:39
  • @SteveSether It's ordinarily how it's done. You don't want to trust a third party, and don't want either side to have any control over the result. That means both sides have to produce some input to the process. You can't let Bob make a decision once he knows what all of Alice's decisions were (if he did, he could see what the outcome of all hes choices was, so he could pick the result). So, you need both sides to make their last choice before they learn the other one's last choice; the best way to do that is commitment, because what you need is precisely what it gives. – cpast Jan 05 '15 at 23:08
  • Unfortunately this was shut down, but I think another solution would be using one or several "entropy beacons". A good entropy beacon is another matter of discussion, but I think bitcoin might make quite an excellent one. Apparently I'm not the first to think of this idea: https://crypto.stanford.edu/seclab/sem-14-15/bonneau.html The idea of an entropy beacon is it's a 3rd party that publishes randomly generated numbers. Bitcoin is already decentralized, and would be hard to manipulate. Both sides could choose different entropy beacons and hash them. – Steve Sether Jan 06 '15 at 01:22
  • You seem to oddly be gunning for having "the right answer", for a question that was broadly defined. When people design real systems it's best to have multiple options on the table, and think about the problem broadly. Jumping to the conclusion that "this is the only way" leads to narrow solutions. The OP was asking for new ways of thinking about his problem, and that's precisely what I've done. Bringing this up as a commitment problem is also useful, so thanks. But the real world presents different challenges, where different solutions can be helpful. – Steve Sether Jan 06 '15 at 01:39
  • @SteveSether I had a reply, but actually yeah, you're right. Removing some comments. – cpast Jan 06 '15 at 01:40
  • Let us continue this discussion in chat. – Steve Sether Jan 06 '15 at 01:44
0

Is there a better (maybe faster) protocol for this purpose?

Have a look at "Commitment schemes".

Here's a simple one: think up a random secret and your commitment. Run both of them through HMAC-SHA256. Using the random part as the key (or salt if you will.)

Publish the outcome. When both of the partners have received the hash, then publish the keys/salt. Now each partner can calculate the hash for him/herself and verify that the correct operation.

Now there can be no haggling after the fact.

StackzOfZtuff
  • 18,093
  • 1
  • 52
  • 86