From: Ned Freed <ned(_at_)sigurd(_dot_)innosoft(_dot_)com>, replying to Ali...
I don't think your use of the term "non-repudiation" agrees with how it is
commonly used in this community.
I think a better name for the problem Ali solves is what is commonly
called "certified electronic mail", as described for example in "A
Randomized Protocol for Signing Contracts", Even/Goldreich/Lempel,
CACM, June 1985, p 644: "Let M denote a message A wants to send to B,
via certified mail. We remind the reader that A would like a receipt
which certifies that the mail has been received by B. B does not know
M and is to get it if and only if A gets B's acknowledgment to the fact
that he (B) has got M." I am sure we can agree that this is a useful
and important capability regardless of what it is called.
One which has clearly been spelled out in our paper
(assumptions III, page 4).
This section talks about your assumption that deliveries are performed in
bounded time and no service denial attacks are possible. This would be
relevant
if I was talking about an attack carried out on B, but I'm not.
[...]
This is not my scenario. I'm talking about the case where B receives E but
claims he did not. This is effectively the same as claiming not to have
received M, since EM by itself is worthless and so is any receipt signed
indicating that only EM was received. And you cannot prove otherwise with your
protocol. Since the entire point here is to prevent B from claiming that he
never received M, this seems like a big problem to me.
But, if you trust the sender to send EM, and according to the assumption
above you trust the infrastructure to deliver the message, then doesn't
this _prove_ that B has received EM, under these assumptions? The
difference from a claim by B that he did not receive M is that M was not
sent by an assumed-trusted party.
Hal Finney
hfinney(_at_)shell(_dot_)portal(_dot_)com