[Cryptography] Proposal of a fair contract signing protocol

Sidney Markowitz sidney at sidney.com
Tue Jun 28 09:08:09 EDT 2016

mok-kong shen wrote on 28/06/16 10:21 AM:
>> mok-kong shen wrote on 27/06/16 9:54 AM:
>>> I wrote: "The messages of step 1 and 2 are to be sent with
>>> signcryption, .....", i.e. that promise is signed by Alice.
> The message sent by Alice in step 1 contains in it, among others, two
> pieces, one is signed(Alice, X), i.e. X digitally signed by her, the
> other is Y, i.e. simply Y. She promises to sign Y in step 3, i.e. to
> produce signed(Alice, Y), if Bob does step 2. The whole message sent
> by her in step 1, which contains besides signed(Alice, X) and Y also
> the said promise, is sent to Bob with signcryption, i.e. first
> encrypted with Bob's public key and signed with Alice's private key.

If "signcryption" means, as you said, that step 1 sends signed(Alice,
encrypt(Bob, signed(Alice, X)|"I, Alice, promise to sign X|Y when Bob signs
X|Y")) then Alice has never signed her promise, all she has signed is a
message that is encrypted with Bob's public key with no proof that she even
knows what is in it. If you have Alice sign the promise, then the promise
itself is a contract that she fully commits to in Step 1 and so is unfair by
your definition. There is still the recursion.


More information about the cryptography mailing list