Sender and receiver non-repudiation

Dimitrios.Petropoulos at reuters.com Dimitrios.Petropoulos at reuters.com
Tue Jul 3 10:17:24 EDT 2001


The problem you are referring to is known as 'selective receipt' (where a party acknowledges only messages it wishes) and generally there are two ways to overcome it:

a. make use of an incremental disclosure protocol over many rounds where in each round some knowledge about the message and the receipt acknowledgement are transmitted. If any party aborts the execution of the transaction prior to completion then both parties have comparable information (one party has an incomplete message and the other an incomplete receipt acknowledgement). This method however suffers from the fact that requires many rounds and also assumes the two parties have equal computational power.

b. make use of a TTP that is somehow involved in the message exchange and guarantees the production of evidence about the actions that have taken place. Such TTPs can be:
- inline, where all communications between the two parties go through the TTP
- online, where production of evidence requires the TTP to be online for the duration of the transaction, but communication between parties does not take place via the TTP
- offline, where the TTP does not need to be present during the execution of the transaction but is otherwise somehow involved, e.g. a Certification Authority

You might want to take a look at the following (by no means an exhaustive list):
1. ISO/IEC 10181-4. Information technology - open systems interconnection - security frameworks for open systems, Part 4: Non-repudiation framework, 1997.
2. ISO/IEC 13888-1. Information technology - Security techniques - Non-repudiation - Part 1: General, 1997.
3. ISO/IEC 13888-2. Information technology - Security techniques - Non-repudiation - Part 2: Mechanisms using symmetric techniques, 1998.
4. ISO/IEC 13888-3. Information technology - Security techniques - Non-repudiation - Part 3: Mechanisms using asymmetric techniques, 1997.
5. J. Zhou and D. Gollmann. Evidence and non-repudiation. Journal of Network and Computer Applications, 1997.
6. J. Zhou and D. Gollmann. A fair non-repudiation protocol. Proceedings of 1996 IEEE Symposium on Research in Security & Privacy, 1996
7. J. Zhou and D. Gollmann. Observations on non-repudiation. Advances in Cryptology - Asiacrypt 96, 1996.
8. J. Zhou and D. Gollmann. An Efficient Non-repudiation Protocol. 10th Computer Security Foundations Workshop, IEEE Computer Society Press, 1997.
9. T. Coffey and P. Saidha. Non-Repudiation with Mandatory Proof of Receipt. ACM Computer Communication Review, 26(1), 1996.

Regards,
Dimitrios Petropoulos


> It is well known that digital signatures can be used to ensure
> non-repudiation of the sender in message exchange.
>
> Say that Alice (A) sends to Bob (B) a mesage M. If Alice sends to Bob a
> signed receipt of the message sent, then Alice cannot refuse of having
> send the message.
> A-->B: M, SIGN_A(A sends M to M)
>
> Now if Bob receives the message and replies with a signed receipt
> B-->A: SIGN_B(B received M from A)
> then Bob cannot later refuse of having received the message M.
>
> The problem in this scheme is that Bob signs and sends the proof after
> he has received M. Bob can receive M and never send a receipt.
>
> By using a trusted delivery service, it is easy to produce
> non-repudiation evidence both for the sender and the receiver.
> Is there any cryptographic protocol that "forces" Bob to produce
> non-repudiation evidence during execution?
>
>
>
> [Your exposition is filled with statements lots of people might take
> issue with, like the concept that Alice "cannot" deny sending the
> message. What if Alice claims it wasn't her key, or her key was stolen
> or misappropriated, or what have you? One lesson I've learned -- you
> cannot perfect law with technology, or eliminate business risk with
> law. --Perry]
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at wasabisystems.com



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com




More information about the cryptography mailing list