[Cryptography] Proposal of a fair contract signing protocol

mok-kong shen mok-kong.shen at t-online.de
Mon Jun 27 18:22:14 EDT 2016


Am 27.06.2016 um 19:16 schrieb Dennis E. Hamilton:
>
>
>> -----Original Message-----
>> From: cryptography [mailto:cryptography-
>> bounces+dennis.hamilton=acm.org at metzdowd.com] On Behalf Of mok-kong shen
>> Sent: Sunday, June 26, 2016 14:50
>> To: cryptography at metzdowd.com
>> Subject: Re: [Cryptography] Proposal of a fair contract signing protocol
>>
>> Am 25.06.2016 um 23:32 schrieb Dennis E. Hamilton:
> [ ... ]
>>> Now the question is, who does she communicate having done that to --
>>> how is it witnessed or verifiable -- and until she has, and it is not
>>> repudiatable (by anyone), how did this Protocol become "fair?"
>>>
>>> There have been enough descriptions of how contracts work in reality
>>> under common law and also under conditions where there is something
>>> significant at risk.  Where the temptation of fraud is quite
>>> high, brokers and escrow companies and other arrangements come into
>>> the picture.  Simply notaries are sufficient in some cases.
>> Attempting
>>> to do this in a digital, distributed arrangement is where the whole
>>> business of non-repudiatable/-falsifiable time-stamping crops up.
>>>
>>> It almost doesn't matter what the C = X || Y piecewise multi-stage
>>> protocol is until the context and the above questions are addressed.
>>>
>>> A different definition of fairness is simply a misdirection against
>>> the general concern of how to verify that a contract has been
>>> entered into and that the agreement is neither refutable nor
>>> falsifiable.
>>
>> Are you questioning the validity of digital signature? This is
>> however orthogonal to the present issue. In Germany, for example,
>> a digital signature can have a value equivalent to a hand-written
>> signature, if certain specifications stated in the law are satisfied.
>>
> [orcmid]
>
> Of course not.  The issue is not whether a digital signature is verifiable
> and not refutable.  The issue is what does the signature provide an
> attestation to and who holds the signed artifact as evidence of all that.
>
> 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?

M. K. Shen


More information about the cryptography mailing list