• Proposal of a fair contract signing protocol (without a trusted third p

    From Mok-Kong Shen@21:1/5 to All on Tue Jun 21 01:34:37 2016
    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/)

    [Remark] 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.

    M. K. Shen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)