[Cryptography] Proposal of a fair contract signing protocol

Ray Dillinger bear at sonic.net
Fri Jun 10 20:28:39 EDT 2016

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

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?


-------------- 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>

More information about the cryptography mailing list