[Cryptography] Proposal of a fair contract signing protocol

mok-kong shen mok-kong.shen at t-online.de
Sun Jun 19 12:51:13 EDT 2016


[My OP of 10.06.2016 was also posted to a few other groups and
discussed there. Below is a copy of the updated version there:]

When a contract in digital from is to be signed online by Alice and
Bob, an issue concerning the fairness of the signing process crops up
as follows: If Alice first signs the document and sends it to Bob, it
means she has committed to something (e.g. ready to purchase an article
from Bob at a certain price), Bob can however, if he desires, to some
extent delay giving his digital signature and thus have a certain
finite time interval during which he has no corresponding commitment.
This is obviously unfair and hence to be avoided, if possible.

Noting that with visual cryptography a document can be separated into
two pieces such that they jointly can reproduce the original but
neither piece alone provides any information of the document, we
propose the following protocol which well fulfills the requirements of
fairness in the present context.

In the following the convention is that signed(A, U) denotes U (as a
single piece) digitally signed by A and that A thereby commits to U and
that nothing else, e.g. simply a V in a message which as a whole is
signed, has the meaning of a commitment.

Step 1: Alice formulates a contract document C, generates with visual
cryptography a pair (X, Y), sends a message containing signed(Alice,X)
and Y to Bob and asks him to accept C before a certain day T in the
future and promises to complete the contract formality within a certain
time period TP in case Bob commits to C in step 2.

Step 2: Bob obtains C from (X, Y). If he can't accept C, he informs
Alice and the protocol begins again at step 1. Otherwise he sends a
message containing signed(Bob,X) and signed(Bob,Y) to Alice and asks
her to release C. (If Bob does nothing before T is reached, the
protocol begins again at step 1.)

Step 3: Alice examines whether Bob has signed the correct stuff, i.e.
whether he hadn't e.g. by mistake sent signed(Bob,Z) in place of
signed(Bob,X) with Z != X. If Bob had signed the wrong stuff, she
informs Bob and the protocol begins again at step 1. Otherwise she
releases C, signed(Alice,X), signed(Alice,Y), signed(Bob,X) and
signed(Bob,Y) to the public. (Alice is responsible to complete step 3
within TP.)

The messages of step 1 and 2 are to be sent with signcryption, i.e.
encrypted with reciever's public key and signed by the sender, and with
authentication (integrity check). Receipt acknowledgments are to be
requested for resolving eventual timing issues.

Note that:

(a) In step 1 Alice has not committed to C. Thus there can be no
unfairness of the nature mentioned above.

(b) If Bob commits to C in step 2, then Alice is immediatly obliged to
commit to C as well, since the pair (X, Y) stems from herself (hence
she couldn't eventually claim that C corresponds to (X, Z) with
Z != Y). That is, C is virtually already a valid document. Hence there
can be also here no unfairness of the nature mentioned above.

(c) Our protocol doesn't involve/need any trusted third party, which is
an advantage.

For comments and critiques I should be very grateful.

(For signcryption, see e.g. Example 3S in 
s13.zetaboards.com/Crypto/topic/7234475/1/)

[Edited 18.06.2016]

[Addendum 19.06.2016] There are literatures which claim (if I have not
misinterpreted) that protocols of our genre are impossible. My humble
knowledge is unfortuantely insufficient to study them in details so as
to resolve the apparent contradiction between our result and the
impossibility claims. Readers interested in probing the causes of that
contradiction may eventually desire to read a paper of H. Pagnia and
F. C. Gaertner of 1999 entitled "On the Impossibility of Fair Exchange
without a Trusted Third Party" which is however currently not online
accessible from the institution where the paper was originally
published. In that case I could send over a copy. (My address:
mok-kong.shen at t-online.de)

M. K. Shen


More information about the cryptography mailing list