[curves] Mutual-auth Ace (was Re: MQV)

Robert Ransom rransom.8774 at gmail.com
Thu May 15 02:53:23 PDT 2014


On 5/14/14, Trevor Perrin <trevp at trevp.net> wrote:
> On Wed, May 14, 2014 at 7:48 PM, Robert Ransom <rransom.8774 at gmail.com>
> wrote:
>> On 5/14/14, Trevor Perrin <trevp at trevp.net> wrote:
>>>
>>> Maybe, but other protocols resist KCI.
>>
>> If you want that feature in a mutual-authentication protocol,
>
> Since resisting KCI is a design goal of MQV and descendants, it would
> be nice to have in an alternative IMO.
>
>> you
>> could use CDH(P, A, Y_1) + CDH(P, X_1, B) + CDH(P, Y_1, Y_2) as the

Er.  The last term should be CDH(P, X_2, Y_2).

>> secret input to the KDF.
>
> That's cool!, if it's secure it seems like a better extension of Ace
> to mutual-auth.  It's similar to TripleDH but each party has 2
> ephemerals instead of 1, and the 3 ECDHs are added together before
> being hashed into a session key.

It does need a systematic security analysis.  (It also needs a name --
“Mace”? “Deuce”? Insert random winged insect name here?)


>  (Also similar to MTI/A0 with an
> ephemeral-ephemeral op added.)

I thought Ace was similar to MTI/C0, not MTI/A0.

Remember that the MTI protocol didn't specify to include the public
keys in the KDF input.  Ace is only secure if you hash all of the
public keys along with the secret group element.

(Otherwise, an attacker can MITM a connection, sending the client Y=0
and sending the server X_2=0.  This allows two attacks:

* The attacker can start a second connection to the same server,
sending the same X_1 and X_2=0, and the server will open a second
connection with the same symmetric key material, which is usually a
disaster.  (A nonce sent by the server and included in the hash would
prevent this -- but anyone who does that would also hash the public
keys in the first place.)

* Setting those ephemeral keys to 0 removes forward secrecy for the
connection; the attacker can then grab the server's long-term secret
key s and decrypt the connection data.)


> But it could be faster than TripleDH because you could use Shamir's
> trick to compute the sum of the 3 ECDHs.
>
> Assuming MQV is ~2x faster than TripleDH:
>  - 1.5 variable-base ops, 1 fixed-base (MQV) vs
>  - 3 variable-base ops, 1 fixed-base (TripleDH)
>
> I wonder how close to MQV speed this could get?:
>  - 1 variable-base triple-op, 2 fixed-base

Again, remember that in TripleDH and the Ace variants, the fixed-base
exponentiations (to generate ephemeral keypairs) can be reused across
multiple protocol runs *if* the parties which reuse their keys each
contribute a nonce to the shared key.  (This does make the protocol
runs linkable, but that's often acceptable.)  I suspect that that's
not safe in MQV.


Robert Ransom


More information about the Curves mailing list