

Agreeing a coin toss remotely - RiderOfGiraffes

I've just had reason to use this, so I thought I'd share it here.  You can find similar stuff, and generalisations, all over the web, but I've put it here so you can read and discard, or read and research, as you choose.<p>Suppose you and I need to toss a coin, but we're separated physically and can only communicate by phone or email.  How can we do that?<p>Obviously I can toss, you can call, and I can tell you whether you win or lose, but you might not trust me.  How can we add some verification?<p>Simple.  I toss the coin and write the sentence "HEADwibblewibblerandomrandomXX$&#38;*HmmWhat?" into a file, where the random stuff is actually random.  I then compute a hash such as sha-256 or similar, and send that to you.<p>Now you call heads or tails, and tell me.  If you win then there's unlikely to be an argument, but if you lose I can "prove" it by sending you the original sentence for you to hash and compare.<p>So there you are, remote coin tossing.  Sadly, I can't tell you why I needed it, but it was rather useful.
======
evgen
Bit commitment is a core concept in crypto -- this is also a piss-poor
commitment protocol. After I flip the coin and say tails you can claim to have
"won" and when I dispute the result you just pull out a sentence that has TAIL
at the front and claim that this is what you sent to me. How can either party
prove the claim? If you build a good bit commitment scheme you can get by with
a very small number of message exchanges and still have both parties accept
the results.

Start with the wikipedia entry for bit commitment, read Blum's coin flipping
over the telephone paper and work your way up to zero knowledge protocols...

~~~
RiderOfGiraffes
I appreciate you taking the time to reply, but I'm not sure I understand you.
You seem to be claiming that what I've outlined has a flaw, but I don't
understand your objection. I don't just pull out any sentence with (for
example) "tail" at the front, I have to find one that has the hash I sent you.

Could you expand a little further as to why the scheme I've described doesn't
work?

Thanks.

~~~
evgen
I think we have a difference in threat models. It sounds like you are dealing
with a non-adversarial model in which neither party has much of an incentive
to cheat. If this is the case then your system works fine. If either party
gains much by cheating then your system is insufficient to solve the problem.

~~~
RiderOfGiraffes
You might be right, but I don't understand how either party could cheat.

Let's assume that the hash is computationally secure, so that it's effectively
impossible to compute a file to match a given hash. SHA-256 seems to me to
meet that assumption.

I decide whether I want heads or tails, and create a file that starts with my
choice, then has random padding. I compute the hash and send it to you.

You now tell me openly your call. I believe you have no way to compute from my
hash what I've chosen, so to you, my choice is hidden. Whether you guess right
is effectively random.

Now I reveal the file from which the hash was computed. Again, I can't compute
a different file with the same hash, so I'm forced to reveal the choice I
made. If you were right we both know it. If you were wrong we both know it.

Can you explain how it's possible for either of us to cheat?

I appreciate your time - thanks.

------
qbunny
As said above, this is well known in crypto circles. There's even a quantum
coin flipping protocol to address the possible future case where these sorts
of factoring-based bit commitment schemes are insecure. (see the seminal BB84
quantum cryptography paper or a recent experimental demonstration of a "fair"
quantum coin flipping protocol by F. Bussieres.)

~~~
RiderOfGiraffes
Two observations:

evgen above seems to think it's wrong, and yet you seem to be saying it's
right (implicitly, because it's "well known in crypto circles.") So, is it
right or wrong? Obviously I believe it to be right ...

Secondly, I know that it's well known in crypto circles. I read about it,
refined it (I hope without breaking it as evgen suggests but does not prove)
and reproduce it here because it does not seem to be well known outside of
them. I find that this is about the most accessible non-obvious result, and
yet it rarely seems to be described in simple, clear terms. I've tried to do
so here, but if you know of a better, clearer explanation I'd genuinely
appreciate the pointer.

Thanks.

(small edits for clarity)

~~~
stephen_cagle
Near as I can tell (no expert mind you) it seems right. Given that SHA is
secure (cannot calculate a plaintext that will result in the same SHA result)
then only the original text could have reasonably generated it. Sending the
SHA result to your friend does not help him in determining your original
plaintext. Only with random text can he determine the plaintext that generated
the SHA result. Seems good enough.

