[Cryptography] Proposal of a fair contract signing protocol

[Ray Dillinger]

On 06/10/2016 01:59 PM, mok-kong shen wrote:
> 
> 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, at least
> to some extent arbitrarily delay giving his digital signature, i.e.
> having a period during which he has no corresponding commitment. This
> is obviously unfair and thus to be avoided, if possible.
> 

Contracts as legal commitments are not operative until signed
by all parties.  Software commitments, when competently implemented,
are the same.

The fairness issue arises, to some extent, if there is a period
of time during which Bob may have the *option* of signing or not,
after Alice has already signed.

But this is easily prevented - by incremental signing, as you
suggested, but secret splits, including visual-cryptography
splits, are not appropriate, because for any such split one can
fabricate a corresponding split that combines with it to make
a different contract.  Thus the commitment fails, because
Alice has signed a split of contract A, and Bob provides a
specially constructed split that combines with it to form
contract B and claims Alice agreed to contract B when she
signed.

Instead, incremental signing starts with the hash of the whole
document, forming a bit commitment, and continues by signing
the document itself.  It's impractical (hopefully impossible)
to create a meaningful-looking contract that has the same hash,
so Bob doesn't get the option of fiddling it.

To prevent contract substitution using visual cryptography,
you'd have to start with a contract containing a signature
using a key Bob doesn't know, so he couldn't substitute a
different validly-signed contract - but if Alice has to create
a signature (a signed hash) anyway why not let the protocol
use the operation of signing a hash in the first place?

				Bear


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160610/8c503741/attachment.sig>