[Cryptography] Proposal of a fair contract signing protocol

[Benjamin Kreuter]

On Fri, 2016-06-24 at 10:50 +0200, mok-kong shen wrote:
> There have been a number of comments in this thread after my last
> post. I like to express my opinions in the following:
> 
> (a) The definition of unfairness I have in mind is: A valid contract
> C is unfair in its signing processing, if there existed a certain
> finite
> time interval in which one partner had already fully committed while
> the
> other had yet the freedom to commit or not.

You need to define "fully committed." After step 2 of your protocol,
Alice has a choice to make: she can output her second signature and
finish the protocol, or she can pretend she never saw Bob's message.
There is some period of time where she can make that choice; but by
that point, Bob cannot back out, since he already sent his signature.

Of course, Bob does have one signature from Alice -- but is that enough
to say that Alice agreed to the contract? If it is, then after step 1,
Bob can choose to send his signatures or to pretend he never got the
message. There is some period of time where Bob can make this choice,
but Alice cannot back out.

So, please clarify: is Alice's first signature enough to say that she
signed the contract, or is the contract invalid if Alice does not send
her second signature?

> (b) Validity of digital signatures is an issue orthogonal to the
> present
> one. In my protocol signing is involved at lots of places. It is
> assumed that they are all properly done and hence can be checked by
> anyone who wants to verify the contract.

The issue is not whether or not signatures are valid, it is how the
parties know that their contract has been signed. In other words, at
some point each party must make a decision about whether or not the
protocol has finished and what the outcome is i.e. whether or not the
contract has been signed.

> (c) In step 1 Alice could, if she desires, expressly reserve her
> right
> to cancel the proposal at anytime before getting Bob's acceptance in
> T.
> (This could be useful e.g. for one selling a rare book which he has
> only a single copy.)

In that case Alice could cancel after Bob accepts, by pretending not to
have seen the acceptance message (the two signatures).

> (d) I surmise that, contrary to the impossibility claims,

This is why precision is needed. The impossibility of solving the two
generals problem in the general case has been proved rigorously and is
not in doubt. It is possible that your protocol involves some different
assumption e.g. a reliable channel. Another possibility is that you are
assuming more than two parties, in which case you are dealing with
Byzantine agreement and everything will depend on how many parties are
colluding with each other. Yet another possibility is that you are
achieving a slightly different goal e.g. TCP does not actually solve
the two generals problem because it involves a timeout.

Let's suppose that neither of those caveats apply and that your
protocol does indeed achieve its apparent goal -- two parties are able
to guarantee that at every point in time the contract is either signed
by both or signed by neither, and they do not require any assumptions
about clocks, third parties, reliable links, etc. Great! Now, instead
of using TCP, what I will do is for each bit I want to send over an
unreliable channel, set up two contracts C0 and C1, and then sign C0
before C1 to represent a '0', and sign C1 before C0 to represent a '1'.

(Can I force one to be signed before the other? Of course: whatever
message I am supposed to send first in the protocol, I simply delay
until the other contract is signed.)

That would imply a solution to the two generals problem and contradict
the impossibility proof. So we know that we are not in such a
situation. That leaves us with a question: what sort of situation are
we in?

So, please, be more precise about your protocol, the assumptions you
make, the setting you are in, the definition of "signed," "committed,"
and "fair," and so forth.

-- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160624/3dc69ed2/attachment.sig>