crypto flaw in secure mail standards

[Eric Rescorla]

Radia Perlman - Boston Center for Networking <Radia.Perlman at Sun.COM> writes:
> 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.
This sounds to me like what's usually called "data origin authentication".

> 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.
That's one way to do it. Of course, if you're using Diffie-Hellman
keys then there's a far easier approach. You simply generate a MAC key
from the DH shared secret and use that the compute a MAC over the
message. Note that it's perfectly straightforward to have a key
expansion transform which generates both a MAC key and an encryption
key so that you only need to do one DH exchange.

Of course, this requires that the sender has a static DH key--watch
out for small subgroup attacks :)

-Ekr

[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/






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