# Authenticated EC key exchange without a signing/signature scheme?

1. From my little understanding of EC-based authenticated key exchange protocols, I believe that it is not possible for authenticated key exchange without a signing/signature scheme. Is this correct?

2. Consider a scenario where neither client nor server have any certificates, and server has the pre-shared secret of User/client. In this scenario, what is the technique/protocol for using ECDHE-based authenticated key exchange?

For a pre-shared secret, you just use a secure MAC to authenticate the key exchange, e.g. for the exchanged public ephemeral keys $A$, $B$ and the resultant shared secret $S$, one side could send $HMAC(PSK, S, A, B)$ and the other $HMAC(PSK, S, B, A)$. Each side can easily verify that the other is using the same exchanged values and shared secret, and that the message could only have come from someone with the same PSK. They could then use $HMAC(PSK,S)$ for the encryption key, for example.

There are several public-key methods of authenticated key exchange that can work using EC, basically using DH with an ephemeral session key and a public key. Although the use of the public key can be thought of as signing the key exchange, it's done in an integrated fashion so there's no explicit signing step, the proofs exchanged are as much a proof of the ephemeral keys as they are of the public keys.

An example is SRP-Z (the mutually-authenticating version) with keys instead of passwords (the method uses modular addition, but that's not necessary if the public key isn't subject to a dictionary attack, i.e. it's a strong key rather than a password). You could also just use ordinary SRP if the verifier is kept secret and a strong key is used (instead of deriving the key from a salt and password), with the same reasoning as above.

Other examples are YAK, which has a very similar structure to SRP-Z, STS, and KEA+.

• There's very little written about the SRP-Z form, probably because it isn't covered under the SRP license. I show the basic SRP-Z exchange in my question about an alternative form of it (which would also work with EC, assuming my variant is secure, which you shouldn't): Is this variant of SRP useful? – Steve Peltz May 23 '15 at 10:13

1.
It is "possible for authenticated key exchange without signing/signature scheme".
Any means of authenticating messages can replace the signature scheme.

2.
If the "pre-shared secret" is a key, then the technique is using MACs to authenticate
the messages. $\:$ If the "pre-shared secret" is a passphrase, then the technique
is using PAKE to get a shared secret key. $\:$ (Of course, in that case, it would be
more efficient to just use PAKE on its own rather than as preparation for ECDHE.)

• you may wish to add a reference to this. – SEJPM Apr 22 '15 at 15:30
• I don't understand why you distinguish between a key and password, a password is just a low entropy key that can be remembered and typed by a human. – Steve Peltz May 22 '15 at 15:33
• @StevePeltz, I'd guess that they're widely considered different is that passwords require special processing (using PBKDFs and such), whereas pre-shared high entropy key don't require this. Hence you have to consider using a PBKDF when designing something that has to deal with passwords, whereas with "shared keys" you don't need to. – SEJPM May 22 '15 at 16:08
• Where I see a difference is with a protocol like SRP where the verifier can't be guessed offline even if it's weak. The verifier is still subject to dictionary attack by the server, or if the server is compromised. Is that what's meant here by PAKE? Simply using a PBKDF (with or without key stretching/strengthening) doesn't really make a new protocol. – Steve Peltz May 22 '15 at 16:37
• Do you have a non-paywalled reference to that PAKE paper? – Steve Peltz May 22 '15 at 17:30