[Cryptography] Proposal of a fair contract signing protocol

[mok-kong shen]

Am 24.06.2016 um 15:22 schrieb 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?

Fully committed by a partner means he/she has signed both X and Y
or has promised to sign both because a certain condition is satisfiled
(see step 1 for what Alice promises to do in case Bob fully commits).

>
>> (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.

They exchages messages according to the protocol and the receipts
mean one partner has got the stuff from the other and the protocol
has advanced one step. The values T and TP ensure that the protocol
either procedes and finishes or else ends without a contract coming
into being.

>
>> (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).

The messages are sent with request for acknowledment of receipt.
Note also that my definition of fairness applies only to a valid
document C. If for any reason (technical or human) C never comes into
being, i.e. step 3 is not done, that definition has no opportunity of
being applied (or questioned).

M. K. Shen
>
>> (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
>
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>