[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A Photuris variant

Ref:  Your note of Mon, 13 Mar 1995 17:03:10 -0800 (attached)


Ashar, thanks for the comments (and I expect more)

I agree with all what you say. You know how many concerns
I have raised about freshness in other protocols.
Believe me I am not going to overlook this in mine.

I did not include these aspects in the first description
from fear to obscure the main ideas.

I tried to put in that note everything that explain these ideas, as well
as everything that is computational intensive.

The freshness mechanisms, as you pointed out, are easy to add
and have negligible performance impact or system complexity cost.
(Still, they are essential for security).

Moreover, we are in complete agreement on the way to provide freshness when
the share phase is skiped.

Another aspect not covered in my note is what happens when only the SHARE
phase is performed and the DH skipped. How do the parties test that they
have shared a key (notice that the SHARE phase as described in my note
does not give assurance to I that it talked to R, only that nobody except
R can learn the key). This hand-shake requires again some cheap exchange
based on MD5 kind of functions.

I prefer to get more feedback on the basic approach before
I get into the presentation of these (important) details.


Hugo

 > I offer the following initial comments on your note.
 >
 > First, I observe that the freshness property of the protocol
 > is achieved in the "share" phase, where K0 will be fresh
 > when used with public-key encryption based share phase.
 >
 > However, you then suggest that the same protocol can be used with
 > other key sharing models which don't necessarily have a fresh
 > K0 e.g. manual key distribution, SKIP master keys etc. (Assuming
 > I properly understood the "Compatibility with Other Key Sharing
 > Models" section).
 >
 > When used with these other key-sharing models, the protocol
 > loses its freshness property, and therefore there is
 > nothing to prevent playbacks of {g^x, MAC_K0(g^x)}. This
 > is especially bad since the protocol does not require
 > the parties to prove that they can compute g^xy, so
 > the above can be played back even if the attacker
 > never learn's x.
 >
 > The fix to this problem appears to be simple. Include in the
 > MAC_K0 computation the other side's exponential in a direction
 > sensitive manner. Concretely, replace in the second
 > message (using the last compact description of your
 > proposal)  MAC_K0(g^y) with MAC_K0(g^y, g^x) and in the
 > last message MAC_K0(g^x) with MAC_K0(g^x, g^y). Throwing in
 > the parties names in the MAC function (direction sensitive)
 > probably wouldn't hurt either.
 >
 > This incurs minimal additional overhead, as all you are
 > doing is computing the MAC over one extra exponential, while
 > allowing K0 to be in fact something long-lived (and not
 > per session).
 >
 > (If you do this, then this part of your proposal starts bearing
 > a lot of similarity to an extension of the basic SKIP proposal I am
 > in the process of drafting).
 >

 > Kind regards,
 > Ashar.