# Safe and computationally efficient way to verify a curve25519 identity?

A client identifies itself as a curve25519 public key. The server wants to verify the client owns the associated private key. Is there a safe and computationally efficient way of doing so? Which approach could be regarded to be “the most recommendable” from a safety point of view, while keeping it computationally efficient?

The community seems unsure whether curve25519 can be used for ECDSA. It should be safe to authenticate a nonce using a secret-key agreed with ECDH, but wouldn't ECDH itself be enough? The server sends a one-time use public key, the client returns a hash of the ECDH shared key and the server compares it.

• 1) Authentication always needs to be bound to something. A message or an integrity protected channel. You cannot just authenticate. 2) Your scheme suffers from trivial forwarding attacks where an attacker impersonates the server to learn shared keys. 3) You need to apply some form of MAC, not the key itself. Else an attacker impersonating a server can learn arbitrary shared keys. – CodesInChaos Feb 12 '14 at 8:47
• You should use an existing higher level protocol, like CurveCP. You're not ready yet to design your own protocol. – CodesInChaos Feb 12 '14 at 8:49
• 1) It is bound to a tcp connection. If arbitrary data is needed, the server can send a nonce. 2) how about a hash of the shared key ? – Kai Elvin Feb 12 '14 at 8:52
• Also, I do not need encryption in this setting. – Kai Elvin Feb 12 '14 at 8:54
• @KaiElvin : $\:$ Is the client's public key used for anything other than such identification? $\;\;\;\;$ – user991 Feb 12 '14 at 8:56

Yes, it is possible to authenticate using ephemeral-static Diffie-Hellman. You would however first trust the public key of the static key pair. One way to do this would be to put it into a DH-based certificate, signed with a CA. It's not so common because usually certificates are used to establish trust, and certificates commonly use a public key used for signature generation when it comes to authentication. Of course you cannot use ECDH to sign/verify certificates, so you'd be stuck with a different algorithm to verify a certificate, if you decide to go that way.

After you've trusted the received public key you can perform normal DH-key agreement, then use the resulting session keys derived from the established secret to perform HMAC authentication. Within this authentication you would need to make sure that the ID's are used, that the nonces are random, that the public keys are included etc. etc. So generally we make it ourselves easy and lift the handshake procedure from an existing, known secure protocol, as indicated in the comments.

• It's not clear to me that the question is about authentication using an X25519 key; rather it seems to me that the question is about proving ownership of an X25519 key, without enough context to say how that figures into a protocol. – Squeamish Ossifrage Mar 12 '19 at 15:49
• That's fortunately covered by authentication. If you are able to derive the correct key using a static DH private key then you must control it. – Maarten Bodewes Mar 12 '19 at 19:24
• If the context is that you're holding a one-on-one conversation, sure, but that's not necessarily the context. Maybe the author is thinking about third-party verifiability, which an X25519 key agreement doesn't enable. – Squeamish Ossifrage Mar 12 '19 at 20:08
• "The server wants to verify the client owns the associated private key." I don't see any unclarity in that statement, and the question mainly seems to turn around ECDSA vs ECDH. – Maarten Bodewes Mar 12 '19 at 21:09
• ‘It is bound to a tcp connection’—doesn't tell me much. There's apparently something involving NaCl boxes here, but without a clearer notion of who the parties are and what they're trying to do in the face of what capabilities of an adversary, this question is not really answerable. Maybe it will turn out that static/static DH is what the asker wants, I don't know. Maybe DNSCurve or CurveCP or MinimaLT or Noise is what the asker wants, I don't know. – Squeamish Ossifrage Mar 12 '19 at 21:12

You could use Schnorr Identity Scheme.

Client owns the Public key P where P = pG. and p is the private key

1. Client generates nonce r and sends Server R where R = rG.

2. Server sends client a random nonce e

3. Client sends Server s = r + pe

4. Server accepts if:

sG = rG + epG = R + eP

Which is only possible if the client owns R and P

• This doesn't quite work because an X25519 key is only an x coordinate so you can't do addition as easily as that. You can share key material between Montgomery DH and EdDSA, but it takes a little more effort like XEdDSA. You can make a Montgomery-based signature scheme (or identification scheme), but it also takes a little more effort like qDSA. – Squeamish Ossifrage Mar 12 '19 at 22:24
• Ahhh thanks for the correction – WeCanBeFriends Mar 13 '19 at 0:08