crypto flaw in secure mail standards

[Radia Perlman - Boston Center for Networking]

	From: "Jeffrey I. Schiller" <jis at mit.edu>
>> There may be a class
>> of message where you want to prove that you originated it *only to the
>> original sender*.  If he has a way to do that, it sounds like a good
>> thing.

Actually I don't think Don was talking about that. Instead he was
talking about the danger of leaving things out of the
signature like the subject
line, the to field, the date, etc., that would allow someone to
take Alice's message out of context, and other people on the list
have explained that you need to have all stuff that matters be
covered by the signature, perhaps by having the user consciously
know what matters and include it in the body.

But what Jeff suggested as a feature in
his email is interesting, and Charlie and I worked
that out in our book when we were discussing how to do what we
called "plausible deniability" with public keys, and non-repudiation
with secret keys, since obviously the opposite is straightforward.
What Jeff is asking about is doing plausible deniability with public
keys, i.e., Bob knows the message came from Alice but he can't prove
it to anyone else.

And the way we specified for Alice to send a "signed only to Bob" message
to Bob is for her to pick a secret key S that she'll only
use for this message, encrypt S with Bob's public key (i.e., {S}Bob),
sign the result (i.e., [{S}Bob]Alice), and compute a MAC on the message using S.
Bob can't prove to anyone else that Alice sent it, since he could construct
any message he wants using a MAC(msg, S). All he can prove is that
at some point Alice sent him something that used S. But he knows it
came from Alice.

Radia




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