[Cryptography] Proposal of a fair contract signing protocol

[Dennis E. Hamilton]

> -----Original Message-----
> From: cryptography [mailto:cryptography-
> bounces+dennis.hamilton=acm.org at metzdowd.com] On Behalf Of mok-kong shen
> Sent: Monday, June 27, 2016 15:22
> To: cryptography at metzdowd.com
> Subject: Re: [Cryptography] Proposal of a fair contract signing protocol
> 
> Am 27.06.2016 um 19:16 schrieb Dennis E. Hamilton:
[ ... ]
> > And remember, all these machinations are only relevant in the case of
> > non-performance, falsification, or fraud on someone's part, whether
> > suspected, alleged or demonstrable.  The complete use case matters,
> > not complexification of primitives.
> 
> In step 1 Alice sends signed(Alice, X) to Bob (she also sends Y to Bob,
> but not signed(Alice, Y)). After that Bob could claim to a third person
> that Alice has signed X by showing him the received stuff, namely
> signed(Alice, X), which can be verified by the third person with
> Alice's public key.
> 
> In step 2 Bob sends signed(Bob, X) and signed(Bob, Y) to Alice. After
> that Alice could claim to a third person that Bob has signed both X an
> Y by showing him the received stuff, namely signed(Bob, X) and
> signed(Bob, Y), which can be verified by the third person with Bob's
> public key.
> 
> signed(Alice, X) denotes a certain sequence of bytes defined to be
> the object having the name "X" and carries the digital signature of
> Alice, i.e. Alice testifies thereby that that byte sequence is truly
> what she understands to be the object having the name "X". Similarly
> for the other signed objects.
> 
> Have I rendered the denotations employed sufficiently clear now?
[orcmid] 

Yes.  The point is that Alice is not obligated to perform step 3 and she can deny that she ever saw Bob's result from step 2.

Consider this.

  1'. Alice makes an offer to Bob, a document C.  It has her embedded signature, let's call that C||X for simplicity.  The C is visible and the signature is verifiable.  (C is useless if X is removed from C||X).

  2'. Bob at step 2, on accepting the offer in C, counter-signs (C||X) with his signature and let's call that (C||X)||Y.

  3'. On receiving the counter-signed acceptance (or promise to perform, whatever), Alice countersigns declaring that she has received the acceptance from Bob, producing ( (C||X)||Y ) || Z.  She records that in some public manner and that is her visible, verifiable commitment, closing the deal, presuming that she does so under whatever conditions there are in Bob's acceptance.

Now, in all respects, this is equivalent to the protocol you propose and it is very similar to how this sort of agreement works in practice.  We assume secure but unreliable communication between Alice and Bob.

This can be quite practical.  It is *not* fair in the technically-understood sense.

Furthermore, this simplified, entirely-equivalent procedure, makes it clear that Alice can deny receiving the result of Bob's step 2, claiming it did not arrive on time, or in some other manner revoking her offer because Bob failed to execute.  That Bob can wave (C||X)||Y around doesn't count without demonstration that Alice received it and close the deal at 3.

> 
> M. K. Shen
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography