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?


2 Answers 2


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+.

KEA+ is patented, as is SRP (though SRP is licensed for free for the non-Z form).

  • $\begingroup$ 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? $\endgroup$ May 23, 2015 at 10:13

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

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.)

  • $\begingroup$ you may wish to add a reference to this. $\endgroup$
    – SEJPM
    Apr 22, 2015 at 15:30
  • $\begingroup$ 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. $\endgroup$ May 22, 2015 at 15:33
  • $\begingroup$ @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. $\endgroup$
    – SEJPM
    May 22, 2015 at 16:08
  • $\begingroup$ 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. $\endgroup$ May 22, 2015 at 16:37
  • $\begingroup$ Do you have a non-paywalled reference to that PAKE paper? $\endgroup$ May 22, 2015 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.