[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: Perfect forward SECURITY
Ashar and all,
> > Almost. However I think we can do better by authenticating the ephemeral DH
> > using the keys from the _previous_instance_ of the ephemeral DH. One can
> > either use just the previous shared ephemeral key or use the public
> > exponents from previous time by computing
> >
> > shared value in round i = g^{y_{i-1}}^x_i XOR g^{y_i}^x_{i-1}
> >
> > Therefore in each round we authenticate the DH keys for next round.
> > the result is that breaking req' breaking into both processors together
> > and then an active attack (rather than just message injection as is possible
> > in SKIP).
>
> I am happy to observe that we appear to be moving closer to agreement
> on at least the basic appearance of the protocol. This is good,
> because if the rest of WG members also agree, we can then talk
> about how other desirable goals such as anonymity etc. can
> be preserved with this approach.
Yes. But, we should really talk about the goals at least as much as we do
about how to achieve them... I propose that we want perfect forward security,
not just secrecy, which means that a successful attack requires ALL of the
following:
1. Breaking into BOTH parties at the same period $[T',T]$.
2. Active attack on the communication between the parties continuously
after $T$.
If the attacker loses either, the attack is defeated (at least detected).
I think this is a very good goal security wise and not too expensive
computation-wise. Do you agree it's a good goal (if not too expensive)?
>
> Now for comments on some of the details.
>
> In general, I like the notion of using key components from the last
> round to authenticate the next round. (If you read my paper on wireless
> network security, Feb 93, IEEE Personal Communications, essentially the
> same principle is used to authenticate the key-change protocol).
Please note the difference too!
>
> However, if you would like to use the last round's key components
> to authenticate the next round, I suggest a better way might be
> to simply include the last round's ephemeral public DH values in the
> authenticated/encrypted SKIP message that is used to communicate the
> current round's ephemeral DH components. This serves to authenticate the
> messages (and thereby the key), as opposed to simply authenticating the
> key.
No, this is not as secure. I don't want to base the security on any long-lived
secret key. Your proposal above requires that the SKIP keys would be secure
`forever'. I'm saying, let's not make a distinction between ephemeral DH
keys and long-lived, SKIPish DH keys. The DH keys we use may change
periodically, period :-) Thereby, we achieve the stronger security property
which I called above `perfect forward SECURITY'.
Authenticating the messages, in addition to the key, is a simple addition
to the protocol so I've omitted it (essentially you merge the protocol with
a challenge-response mechanism such as 2PP).
I agree that this cost three exponentiations which is painful... But
considering this is a periodical procedure (and the frequency is tunable)
I think this is not so terrible.
What do you say?
Happy new year to all, and I join Ashar in hoping for a cooperative -and
hence productive - year for IPSEC.
Best, Amir
p.s. Yes, we can also achieve anonymity for this, and even for non-interactive
SKIP so together this would be a nice protocol - I'll write about it soon...
References: