[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A Photuris variant
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.