Re: Recipient-verifiable messages

["David P. Kemp" <[e-mail]>]

Jon Callas wrote:
> 
> >David Chaum has a patent on a variation on this idea, and he gave a talk
> >at PGP several years ago in which he advocated that recipient-verifiable
> >signatures are very useful, and in fact ought to be the default for
> >an email encryption system like PGP.  As others in this thread have
> >commented, often you don't want to sign something such that you can
> >be bound by it later, but you do want to assure the recipient that the
> >message is authentic.  Only rarely do you want to make a signature that
> >anyone can read.
> >
> >Unfortunately I think that adding a new flavor of signature would tend
> >to create confusion among users who at best barely understand public
> >key cryptography.  The new kind of signature would have very different
> >security properties and usage scenarios, so it would add additional
> >complexity for people to deal with.
> 
> Could we do something both simple and useful, however?
> 
> For example, if I send a message to Alice, the signature could be made
> safely as a combo of my key and Alice's key. It would not be a
> misrepresentation in Alice's MUA for it to assume I signed it. You'd have
> to be careful in the UI, but I think it could be done. It might be able to
> be extended to multiple recipients, but with two it might be an easy
> hand-wave.


What is the difference between a "recipient-verifiable signature" and
a MAC?

One of the properties of a digital signature mechanism is that it
is computationally infeasible for any entity other than the signer
to find, for any message, a signature value that is valid for that
message.  [HAC, p.23]

Thus it would seem that a "signature" that can't be bound later
to the signer is an oxymoron.  Why not just call it an authentication
code, where it is accepted that anyone who can verify a MAC has
the information necessary to create it.